Validador del Observatorio de Accesibilidad Web - Rastreador OAW. Validaciones y fiabilidad (Parte II)

Este artículo es la continuación de Validador del Observatorio de Accesibilidad Web - Rastreador OAW. Presentación, Instalación y uso, Metodología e Informes (Parte I). En esta segunda parte me voy a centrar en las validaciones concretas que realiza el validador y su fiabilidad.

Os recomiendo que leáis la primera parte del artículo, donde explico la función que hace el Rastreador OAW en la monitorización y evaluación de los portales del sector público en España; cómo instalarlo y usarlo, ahora que ya no es de uso exclusivo para la Administración Pública; la metodología que utiliza, que salió a debate público; y el tipo de informes que genera.

Estructura del artículo

Como vimos, la validación del Rastreador OAW se articula en:

• 14 indicadores de nivel A
• 6 indicadores de nivel AA

Este artículo se estructura en un apartado para cada indicador, donde enumero:

• El criterio o criterios de las WCAG 2.1 / EN 301 549:2019 con los que se corresponde.
• Las validaciones que realiza en cada indicador.
• La fiabilidad de estas validaciones:
  • falsos positivos
  • falsos negativos
  • otros aspectos a tener en cuenta, por ejemplo, si sus validaciones son más estrictas o específicas que las de las WCAG 2.1.

Hay que tener en cuenta que un mismo criterio de las WCAG 2.1 / EN 301 549:2019 puede implicar una o varias comprobaciones, y que un mismo criterio se puede cumplir con diferentes técnicas, pero no todas pueden evaluarse automáticamente.

Por ello, no hay que sorprenderse si señalo que diferentes indicadores se corresponden con un mismo criterio de las WCAG 2.1 / EN 301 549:2019. Por ejemplo, hay varios indicadores diferentes que se corresponden con distintas validaciones que hay que hacer en el criterio 1.3.1 de las WCAG 2.1.

Por la misma razón, que un indicador se asocie a un criterio no quiere decir que abarque todas las comprobaciones que deben hacerse en dicho criterio. Por ejemplo, que un indicador esté asociado al criterio 2.4.4, no significa que se realicen todas comprobaciones asociadas a este criterio, puesto que puede haber algunas que no sea posible realizar automáticamente.

Por último, que el validador evalúe un criterio, tampoco implica que se esté evaluando en base a todas las técnicas permitidas, por ejemplo, el criterio 2.4.5 Múltiples vías (AA) puede cumplirse con la combinación de diferentes técnicas, pero el validador solo comprueba dos de ellas.

Estas observaciones aplican a cualquier validador automático. No hay que olvidar que son meras herramientas de ayuda y que no pueden sustituir a una evaluación manual, sino que solo reportan un número reducido de las barreras de accesibilidad de la página, que no tienen por qué ser las más importantes.

Metodología

El objetivo de este artículo es que sirva de guía rápida de consulta. Para más detalles os remito a la metodología de evaluación de la herramienta, que es pública: Metodología para el seguimiento simplificado del Observatorio de accesibilidad (PDF, 1.62 MB)

Aunque hace tiempo que estoy familiarizada con sus validaciones e informes, la posibilidad de instalarlo en local me ha permitido poner a prueba de una manera más sistemática todas sus validaciones.

Para evaluar la fiabilidad de las validaciones:

• He creado una página de prueba con todos los posibles errores que valida la herramienta.
• He validado la página con el validador instalado en local (versión instalada el 30 de mayo de 2020).
• No he realizado ningún cambio en el validador que afecte a las validaciones. Solo he modificado que guarde el informe en local, en vez de enviarlo por correo.
• He validado la página por código y después por URL.
• He validado con la opción "Conforme a la metodología del Observatorio de Accesibilidad, basada en la UNE-EN 301549:2019".

Pongo a vuestra disposición la página de prueba y los informes del validador (ZIP, 467 KB) por si queréis contrastar resultados. Este zip contiene:

• Página de prueba. Ten en cuenta que no es una página preparada para ser visualizada, sino para poner a prueba el validador. He añadido múltiples comentarios en el código con el resultado del validador para cada elemento.
• Informe resultante al validar la página por código.
• Informe resultante al validar la página por URL. Aunque la página validada es la misma, hay un error que detecta en este informe, pero no en el anterior.

Podéis dejar en los comentarios del artículo cualquier observación.

Índice de indicadores

• 1.1 Existencia de alternativas textuales (A)
• 1.2 Uso de encabezados (A)
• 1.3 Uso de listas (A)
• 1.4 Tablas de datos (A)
• 1.5 Agrupación estructural (A)
• 1.6 Separación de contenido y presentación (A)
• 1.7 Identificación del idioma principal (A)
• 1.8 Navegación con JavaScript accesible y Control de Usuario (A)
• 1.9 Formularios y etiquetas (A)
• 1.10 Formularios y estructura (A)
• 1.11 Título de página y de marcos (A)
• 1.12 Enlaces descriptivos (A)
• 1.13 Cambios de contexto (A)
• 1.14 Compatibilidad (A)
• 2.1 Identificación de los cambios de idioma (AA)
• 2.2 Legibilidad y contraste (AA)
• 2.3 Maquetación adaptable (AA)
• 2.4 Múltiples vías de navegación (AA)
• 2.5 Independencia de dispositivo (AA)
• 2.6 Navegación consistente (AA)
• Resumen: Ten en cuenta

1.1 Existencia de alternativas textuales (A)

Criterio de las WCAG 2.1: 1.1.1 (A)

Validaciones

• Los elementos AREA deben tener un texto alternativo con alt, aria-label o aria-labelledby.
• Los INPUT de tipo image deben tener un texto alternativo con alt, aria-label o aria-labelledby.
• Los elementos APPLET deben tener un texto alternativo con alt junto con contenido textual dentro de las etiquetas de apertura y de cierre del elemento APPLET; o bien mediante aria-label o aria-labelledby.
• El texto alternativo de las imágenes no puede tener el nombre de la imagen (*.jpg, *.jpeg, *.gif, *.png, *.bmp.) o un texto de relleno ("imagen", "foto"... ; o patrones similares en la misma página como “Pic1”, “Pic2”, “0001”, “0002”). 
• Todas las imágenes deben tener atributo alt o atributo aria-label o aria-labelledby, a no ser que tengan asignado el rol ARIA role="presentation".
• Si el alt está vacío, las imágenes no pueden tener aria-label, aria-labelledby, title (a no ser que esté vacío); y si tienen un rol será role="presentation".
• Se comprueba que las imágenes con un alto y/o ancho igual o inferior a 2px están marcadas como imágenes decorativas, es decir, tienen el texto alternativo vacío; no tienen atributo title (o está vacío); y carecen de atributo role (o bien es role="presentation" si no tiene atributo alt).
• Si la imagen tiene longdesc debe ser a una página válida.
• Las imágenes no pueden tener alternativas textuales (en los atributos alt, aria-label o aria-labelledby) cuyo contenido textual sea superior a 150 caracteres pues, en ese caso, lo que requieren son descripciones detalladas (por ejemplo, con los atributos longdesc o aria-describedby).
• El valor de los atributos aria-describedby deben ser identificadores reales de otros elementos existentes en la página que tengan contenido textual. Como en el atributo aria-describedby se pueden indicar varios identificadores (id), es suficiente con que solo uno de ellos exista y tenga contenido.

Falsos negativos

• Si tenemos un MAP con un AREA activa, y esta tiene alt="", el validador da error. Sin embargo, si el AREA activa no tiene alt, no da error, esto sería un falso negativo.
• Aunque la metodología dice que se validan los input type="image", si incluyes uno sin alt o con alt vacío, el validador no da error, esto sería un falso negativo.
• Aunque la metodología dice que se validan los applet, si incluyes un applet, un object o un embed sin alternativa y sin texto entre sus etiquetas de apertura y cierre, el validador no da error, esto sería un falso negativo.
• El validador reconoce que un texto alternativo como <img src="hola.jpg" alt="hola.jpg" /> es incorrecto y da error. Sin embargo, si tenemos varias imágenes con un texto alternativo que sigue el siguiente patrón: <img src="hola.jpg" alt="imagen1" /> <img src="hola.jpg" alt="imagen2" />, el validador no reconoce el patrón y no da error, lo cual sería un falso negativo.
• He usado una imagen con el atributo aria-describedby="desc1". A pesar de que el id "desc1" no existe en la página, el validador no ha dado error, lo cual sería un falso negativo.

Falso positivo

• Una de las novedades de WAI-ARIA 1.1 (recomendación desde 2017) es el rol role="none". Este rol es equivalente a role="presentation", al que viene a sustituir. Puedes consultar mi artículo: Novedades WAI-ARIA 1.1.

  El validador no da error con el código <img src="icono.jpg" alt="" role="presentation"/>, porque reconoce de manera adecuada que es una imagen decorativa. Sin embargo, sí da error con el código <img src="icono.jpg" alt="" role="none" />, porque no reconoce el rol role="none". Esto es un falso positivo.

  En general, el validador da error en todas las validaciones que incluyen role="presentation si se usa en su lugar role="none", rol que ya está suportado por JAWS y NVDA. En ocasiones, para mayor compatibilidad, los desarrolladores usan role="none presentation".

Ten en cuenta:

• Como he indicado, el tamaño máximo que permite el validador para el atributo alt es de 150 caracteres. Deberías limitarlo en el gestor de contenidos o, al menos, avisar del número de caracteres incluidos, para evitar este error a los publicadores.

1.2 Uso de encabezados (A)

Criterio de las WCAG 2.1: 1.3.1 (A)

Validaciones

• Se deben usar etiquetas de encabezado o su correspondiente rol ARIA (role="heading" con aria-level).
• Los encabezados no pueden estar vacíos.
• No puede haber dos encabezados del mismo nivel o superior (por ejemplo: H2, H2 o H2, H1) sin contenido entre ellos.
• Los encabezados no pueden saltarse niveles.
• Si la página tiene 15 o más párrafos P con al menos 80 caracteres, se verifica que la página no tenga un único encabezado. Si esta verificación se incumple, se daría 0.5 puntos en vez de 1, pero la página tendría el valor "pasa" (en vez de "falla").
• La página debe tener un H1 (o su equivalente rol ARIA). Si la página tiene encabezados, la ausencia de H1 dará 0.5 puntos en vez de 1, y la página tendrá el valor "pasa" (en vez de "falla").

Ten en cuenta

• Aunque la página "pase" sin tener H1, recuerda que es importante para muchos usuarios que las páginas tengan H1. Un auditor u otros validadores de accesibilidad lo remitirán como un error que es necesario corregir.
• Recuerda que los encabezados deben ser concisos y significativos. Eso implica que:
  • no debe haber dos encabezados con el mismo texto en la página;
  • no deben ser muy extensos, igual que no deben serlo ni los enlaces (el validador fija para ellos, como veremos, una longitud máxima de 250 caracteres) ni las alternativas de las imágenes (el validador fija para ellas una longitud máxima de 150 caracteres)

  Aunque este validador no incluya estas verificaciones en su metodología, otros sí lo hacen, y un auditor remitiría estos errores en una validación manual.

1.3 Uso de listas (A)

Criterio de las WCAG 2.1: 1.3.1 (A)

Validaciones

• Las listas deben estar bien formadas, bien anidadas y los elementos LI deben tener como padre directo un OL o UL.
• No puede haber listas OL o UL sin hijos LI.
• No se deben simular las listas mediante párrafos o tablas de una columna, para ello se verifica que:
  • No haya 3 o más elementos P seguidos que empiecen por “-“ o “- “ o “*”.
  • No haya 3 o más elementos BR seguidos que empiecen por “-“ o “- “ o “*”.
  • No haya 3 o más elementos P seguidos que empiecen por los patrones “x“, “x “, “x.“, “xº”, “xª”, ”x)”, “x-”, “x.-” donde ‘x’ pertenezca a una secuencia de números, letras o números romanos.
  • No haya 3 o más elementos BR seguidos que empiecen por los patrones “x“, “x “, “x.“, “xº”, “xª”, ”x)”, “x-”, “x.-” donde ‘x’ pertenezca a una secuencia de números, letras o números romanos. Solo se consideran aquellas secuencias que empiezan por la unidad (1, 1º, 1ª, a, A, i, I).
  • No haya 3 o más elementos LI de lista desordenada UL que empiecen por los patrones “x“, “x “, “x.“, “xº”, “xª”, ”x)”, “x-”, “x.-” donde ‘x’ pertenezca a una secuencia de números, letras o números romanos. Solo se consideran aquellas secuencias que empiezan por la unidad (1, 1º, 1ª, a, A, i, I).
  • No haya 3 o más párrafos seguidos que empiecen por una imagen cuyas dimensiones sean iguales o inferiores a 10x10 píxeles.
  • No haya 3 o más líneas separadas por BR que empiecen por una imagen cuyas dimensiones sean iguales o inferiores a 10x10 píxeles.
  • No haya tablas formadas por una única columna y 3 o más filas en la que el contenido textual de cada celda no supere los 150 caracteres.

Falso negativo

• A pesar de lo que se indica en la metodología, no han dado error las listas simuladas con párrafos precedidos de * o de letras (a. b. c.), lo cual sería un falso negativo. Tampoco ha dado error probando con la validación de acuerdo a la UNE 139803:2012.

Ten en cuenta

• Si se tienen tablas de una sola columna, con 3 o más filas, y contenido de menos de 150 caracteres, se entiende que se está simulando una lista y el validador da error. Tenlo en cuenta para evitar, si es posible, que los editores de contenido puedan crear tablas de una sola columna.
• Muchas veces los publicadores simulan las listas porque el editor de contenidos no les ofrece la posibilidad de crear listas de tipo "2, 2.1, 2.1.1" o "a. b. c.". Por ejemplo, CKEditor sí permite, con el botón derecho, modificar las propiedades de la lista para que sea de tipo "a. b. c." o "I. II. III.", pero hay que informar a los publicadores de esta opción que, de lo contrario, puede pasarles desapercibida.
• Los listados de enlaces deben estar maquetados como una lista. Aunque el validador no incluye esta validación, tenlo en cuenta, otros validadores sí pueden detectarlo y un auditor lo reportará como error.
• Es habitual encontrar listas vacías en bloques como "Tus últimas visitas", cuando es la primera vez que accedes. La lista no debe estar vacía en el código, sino crearse junto con el primer LI.

1.4 Tablas de datos (A)

Criterio de las WCAG 2.1: 1.3.1 (A)

Validaciones

Si es una tabla de datos (1)

• Debe tener al menos una celda de encabezado (TH) en las filas o columnas exteriores.
• Si la tabla es sencilla: debe tener encabezados (todos los elementos son encabezados TH) en la primera fila o en la primera columna, salvo para celdas con texto vacío. Es decir, falla si no hay ningún encabezado (TH) en la primera fila ni en la primera columna, o si en ellas hay al menos una celda de encabezado (TH) y al menos una de datos con texto (TD).
• Si la tabla tiene más de un nivel encabezados (si hay elementos TH en dos filas o en dos columnas):
  • Da error si no existen atributos id en los elementos TH y headers en los elementos TD.
  • En aquellas tablas con la celda superior izquierda vacía y marcada por tanto como TD, se verifica que el resto de celdas con texto de la fila sean encabezados (TH) y que todas las celdas de la primera columna (que tengan texto) sean encabezados TH, en caso contrario falla.

  Es decir, la siguiente tabla es correcta porque, aunque la celda superior izquierda de la fila de encabezados está vacía, el resto de celdas con texto de la fila son TH, y las celdas con contenido de su columna también son encabezados TH:

  TD vacío	TH	TH	TH
  TH
  TH
  TH
  TH

  • Si la tabla tiene scope, headers o axis el valor debe ser válido.
• No se puede simular el título (caption) de la página.
  • Si la primera fila de una tabla tiene una única celda que ocupa todo el ancho de la tabla, dará error porque se considera que se está simulando de forma incorrecta el título de la tabla, que debería marcarse con CAPTION.

    Es decir, la siguiente tabla da error porque tiene una primera fila de celdas unidas con colspan y se entiende que está simulando el título, cuando debería usarse para ello el atributo CAPTION:

    Error: celdas unidas en vez de CAPTION
    TH	TH	TH	TH
    X	X	X	X
    X	X	X	X
    X	X	X	X

  • Si una tabla no tiene título (CAPTION), dará error si es el único contenido de la sección correspondiente a un encabezado (H1, H2, H3...), considerando que dicho encabezado es en realidad el título de la tabla, y que este debería haberse incluido con CAPTION. Es decir, si tenemos un encabezado seguido de una tabla (por ejemplo, <h2>Título</h2> <table>...) dará error, haya o no más contenido tras la tabla.
• Las tablas deben tener un resumen:
• Se comprueba que las tablas complejas tienen un atributo summary con contenido. El validador considera que una tabla es compleja si tiene encabezados tanto de fila como de columna y, además, tiene dos o más filas o columnas de encabezados.
• Aunque no se indica en la metodología, si la descripción se incluye con aria-describedby (alternativa a summary en HTML 5), la tabla pasa la validación. Puedes consultar el artículo Descripción de las tablas en HTML5. Alternativa a "summary").
• El título (CAPTION) y el resumen (summary) no pueden ser iguales.

---

(1) Se considera tabla de datos si:

• No contiene a ninguna otra tabla.
• No contiene ninguna celda con más de 150 caracteres mostrados por pantalla.
• No se trata de una tabla con una sola celda.
• No se trata de una tabla con una sola fila.
• No se trata de una tabla con una sola columna.
• Al menos el 70% de las celdas de la tabla contienen texto. Para contabilizar el texto se tendrá en cuenta el contenido de los atributos alt, title o aria-label, así como la presencia de un atributo aria-labelledby o aria-describedby que hagan referencia a algún elemento con contenido.

---

Falsos negativos

• El validador da error cuando el summary y el caption son iguales, pero no da error cuando la descripción asociada por aria-describedby (alternativa a summary en HTML 5) es igual al caption, esto es un falso negativo (consulta el artículo Descripción de las tablas en HTML5. Alternativa a "summary").
• A pesar de lo que indica la metodología, la inclusión de una tabla compleja sin summary, o con summary vacío, no ha dado error, de modo que sería un falso negativo. Para probar esta validación, he validado la página tanto con el DOCTYPE de HTML5, como con el de HTML4, con el que en realidad debería dar error de tabla sin summary, pero no ha dado error en ninguno de los casos. Como ya he comentado, en el caso de DOCTYPE de HTML5, la descripción debería incluirse con aria-describedby y dar error si no la tiene.
• A pesar de lo que indica la metodología, la definición de un headers con un valor erróneo no ha provocado error en la página de prueba, de modo que sería un falso negativo.

Ten en cuenta

• Ten en cuenta que, si tienes una tabla con varios niveles de encabezado, si relacionas las celdas con scope, solo pasará el validador si la tabla tiene una fila y una columna de encabezados. Para otros tipos de tablas complejas (con varias filas o columnas de encabezados), deberás usar headers/id, algo que no permiten la mayoría de los editores, así que intenta siempre evitar las tablas complejas. Recomiendo leer: "Table concepts de WAI/W3C".
• Como he señalado, si utilizas colspan para unir la primera fila, el validador dará error por simular el caption. Puesto que además siempre es mala idea unir celdas, y es mejor, por ejemplo, repetir el dato en cada celda, plantéate eliminar la posibilidad de que los publicadores puedan unir celdas en el editor.
• También hemos comentado que, si tienes un encabezado (H1, H2, H3...) justo antes de una tabla, dará error porque presupone que está simulando un caption. Puesto que summary está obsoleto en HTML5 y lo recomendable en HTML5 es una descripción asociada con aria-describedby, esta descripción, en un párrafo antes de la tabla, impedirá siempre el error, porque nunca habrá una tabla inmediatamente después de un encabezado. Plantéatelo como solución estándar en el gestor de contenidos (consulta el artículo Descripción de las tablas en HTML5. Alternativa a "summary").
• Es recomendable que todas las celdas de una tabla de datos tengan contenido, aunque sea "0" o "sin datos", porque son más fáciles de comprender, especialmente con el lector de pantalla. Teniendo en cuenta que el validador considera una tabla como tabla de datos si al menos el 70% de sus celdas contienen texto, también evitarás errores en el validador si intentas no dejar celdas vacías.

1.5 Agrupación estructural (A)

Criterio de las WCAG 2.1: 1.3.1 (A)

Validaciones

• No se debe usar el elemento DIV para incluir directamente el contenido sin usar a su vez etiquetas semánticas. El validador solo dará error si hay algún elemento DIV cuyo contenido directo sea un texto de más de 150 caracteres, obviando las etiquetas en línea.
• No se deben usar las etiquetas BR, salvo en ADDRESS. Pero el validador solo dará error si:
  • Hay elementos P con más de 150 caracteres de texto (obviando el marcado de las etiquetas en línea) que contengan secuencias de 2 o más BR seguidos, ignorando aquellas secuencias de BR que estén al principio y final del párrafo.
  • Se están empleando más de 10 elementos BR en la página, considerando que un abuso del elemento BR implica que se están empleando saltos de línea para simular párrafos.

Ten en cuenta

• Aunque el validador solo dé error en los DIV sin etiquetas semánticas con textos mayores de 150 caracteres, no debe usarse tampoco en textos de menor longitud, como se indicaría en una auditoría manual y podrían evaluar otros validadores.
• Aunque el validador es relativamente permisivo con el uso de etiquetas BR, no debe usarse esta etiqueta salvo en ADDRESS, como se indicaría en una auditoría manual y podrían evaluar otros validadores.
• El validador no da error si utilizas varios elementos semánticos iguales para estructurar la página (por ejemplo, varios nav) y no los diferencias con una etiqueta aria-label o aria-labelledby. Esto es un error y es fácil de identificar automáticamente, por lo que sí que lo detectan otros validadores.

1.6 Separación de contenido y presentación (A)

Criterio de las WCAG 2.1: 1.3.1 (A)

Validaciones

• Si hay tablas de maquetación (2) no pueden tener: CAPTION, TH, THEAD, TBODY, TFOOT o los atributos summary, title, scope, headers o axis.
• No pueden usarse los siguientes elementos de presentación desaconsejados (deprecated): FONT, BASEFONT, CENTER, S, STRIKE y U.
• No puede incluirse contenido desde las CSS con :before o :after y la propiedad content, cuyo valor sea un texto de más de un carácter alfanumérico (las entidades HTML y los caracteres Unicode se contabilizan como un único carácter).

---

(2) Se considera tabla de maquetación si:

• Contiene a otra tabla o
• Tienen el atributo role="presentation".
• Contiene alguna celda con más de 150 caracteres mostrados por pantalla.
• Se trata de una tabla con una sola celda.
• Se trata de una tabla con una sola fila.
• Se trata de una tabla con una sola columna.
• Menos del 70% de las celdas de la tabla contienen texto. Para contabilizar el texto se tendrá en cuenta el contenido de los atributos alt, title o aria-label, así como la presencia de un atributo aria-labelledby o aria-describedby que haga referencia a algún elemento con contenido.

---

Falsos positivos

• La validación de la inclusión de contenido con content desde la CSS puede llevar a falsos positivos, porque el validador no comprueba si esos estilos de la CSS se están usando realmente en la página. Este problema lo hemos tenido en CSS propias de gestores de contenido como Liferay, que son complicadas de modificar o sobrescribir.
• Si la tabla tiene role=none en vez de role=presentation, el validador no entiende que es una tabla de presentación y da error de tabla de datos sin caption y sin th. El role=none viene a sustituir al role=presentation en WAI-ARIA 1.1, puedes consultar mi artículo Novedades WAI-ARIA 1.1
• El validador considerará la siguiente tabla como una tabla de maquetación en vez de una tabla de datos, porque tiene celdas con más de 150 caracteres. Por tanto, dará error porque tiene caption y th. Sin embargo, no puede considerarse que esta tabla sea de maquetación:

Ejemplo de tabla de datos que el validador considera tabla de maquetación.

Criterios de las WCAG 2.1

Criterio	Normativa	Nivel	Título	Descripción
1.4.1	WCAG 2.1	A	Use of Color	Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. NOTE: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.
1.2.7	WCAG 2.1	AAA	Extended Audio Description (Prerecorded)	Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in synchronized media.

Ten en cuenta

• El validador solo da error en etiquetas de presentación obsoletas, pero hay otras que no se deben usar, y que una auditoría manual u otros validadores reportarán como error:
  • <b>: si quieres definir el grosor de la fuente usa estilos para ello, si quieres dar énfasis a unas palabras importantes usa strong, pero en cualquiera de los casos recuerda no abusar de la negrita.
  • <i>: si quieres definir el estilo con itálica usa estilos para ello, pero recuerda que mucho texto en itálica es más difícil de leer. Si quieres enfatizar el texto para reflejar un carácter particular del mismo, como un extranjerismo, usa <em> o ponlo entre comillas. No uses la <i> con background-image para incluir iconos.
• El validador dará error con a::before {content: " ";}

1.7 Identificación del idioma principal (A)

Criterio de las WCAG 2.1: 3.1.1 (A)

Validaciones

• La etiqueta HTML debe tener el atributo lang, y debe definir el idioma correcto del documento. La identificación del idioma de una página se realiza mediante la técnica de detección de trigrams (n-gramas de tres caracteres).

1.8 Navegación con JavaScript accesible y Control de Usuario (A)

Criterios de las WCAG 2.1: 2.1.1 (A), 4.1.2 (A), 2.2.1 (A), 2.3.1 (A)

Validaciones

• Todos los eventos dependientes de dispositivo (salvo onclick) deben tener a su vez un evento lógico independiente o un evento para otro dispositivo de entrada (onmousedown con onkeydown; onmouseover con onfocus...)
• Los elementos que tienen onclick o onkeypress deben ser elementos estándar de interacción, en caso contrario deben tener tabindex y un role relativo a widgets (alert, button, link...)
• No se debe usar blink o marquee o el estilo text-decoration: blink.
• La página no debe actualizarse o redirigirse automáticamente con el elemento META y el atributo http-equiv (con un tiempo mayor de 0 segundos)

Falsos negativos

• El código <a href="" onmousedown="mover()">Aviso legal</a> sí da error.

  Sin embargo, si el evento está asignado con javascript no intrusivo, no da error: 

  <a href="" id="enlaceprueba">Aviso legal</a>

  <script>document.getElementById('enlaceprueba').onmousedown = function() {    alert('prueba');}</script>

  lo cual es un falso negativo.

• Lo mismo ocurre con la validación del evento onclick o onkeypress. Si se aplica el evento directamente en un elemento no estándar de interacción, sin un rol adecuado y sin tabindex, da error; pero en la misma situación, si el onclick está asociado por javascript no intrusivo, el validador no da error.

1.9 Formularios y etiquetas (A)

Criterios de las WCAG 2.1: 1.3.1 (A), 3.3.2 (A), 4.1.2 (A), 2.5.3 (A)

Validaciones

• Los campos de formulario deben tener una etiqueta (label, aria-label, aria-labelledby, title) correctamente asociada y no vacía. En caso de usar label, su for debe tener el id de algún control de formulario usado en la página.
• Si el campo solo tiene una etiqueta incluida con label, esta no puede estar oculta con display: none o visibility: hidden.
• Si el formulario tiene más de 5 campos (los grupos de radios o de checks contabilizan como uno) el validador busca términos como “obligatorio” u “opcional”, en varios idiomas, en el texto, las alternativas textuales o los títulos del formulario y su elemento contenedor. Si no las encuentra da error.
• Si un elemento tiene un nombre accesible con aria-label o aria-labelledby, este debe coincidir o contener la etiqueta visible del campo para facilitar el acceso por voz (consultar el artículo "WCAG 2.1 Comprende el criterio "2.5.3 Etiqueta en el nombre") . No es aplicable cuando el contenido accesible o el contenido visible sólo contiene caracteres Unicode, de puntuación (:, ;, ., /, \, |,…) , o emojis.

Falsos positivos

• En el análisis de un portal, he encontrado que el validador da error porque la etiqueta del campo "Buscar" está oculta, a pesar de que solo lo está visualmente y no para el lector de pantalla. En concreto está oculta con tamaño de 1 píxel y posicionamiento fuera de pantalla.

Falsos negativos

• La página de prueba tiene campos con una única etiqueta incluida con label, la cual está oculta visualmente y para los lectores de pantalla con display:none en unos casos, y visibility:hidden en otros. Los estilos que ocultan las etiquetas están definidos en un STYLE ubicado en el HEAD. El validador ha dado error al validar la página por URL, pero no ha dado error al validar la página por código, en cuyo caso es un falso negativo.
• Los input con un aria-label que no es igual o no contiene su etiqueta sí que dan error, tal y como es de esperar. Todos estos casos dan error: <input aria-label="Cerrar" value="X">; <input aria-label="Cerrar" value="-X-">; <input aria-label="Cerrar" value="Close">

  Sin embargo, los button con un aria-label que no es igual o no contiene su etiqueta, NO dan error. Por tanto, no dan error y son falsos negativos casos como: <button aria-label="Cerrar">X</button>; <button aria-label="Cerrar">-X-</button>; <button aria-label="Cerrar">Close</button> 

• Es necesario indicar siempre los campos obligatorios, aunque el validador solo lo compruebe en formularios de más de 5 campos. Por tanto, si tienes un formulario con 4 campos obligatorios y no indicas que lo son, el validador no dará error. Esto será un falso negativo respecto a las WCAG 2.1 / EN 301 549:2019, porque en este caso el validador es menos estricto que la normativa.

Ten en cuenta

• El label debe estar asociado al campo por el id, no por el name. Si incluyes dentro del for el nombre del campo, en vez de su id, dará error. Recuerda también, como hemos indicado, que no puedes ocultar el label al lector de pantalla. Sin embargo, no da error si lo ocultas solo visualmente, por ejemplo, con text-indent:-999em.
• Puedes indicar los campos obligatorios con un asterisco. En este caso, recuerda que deberás indicar el significado del asterisco al principio del formulario "* campos obligatorios". También podrías indicar "Todos los campos son opcionales", porque el validador busca tanto la palabra "obligatorio" como "opcional" (o equivalentes: exigido, preciso, requerido...).
• Que el validador encuentre la palabra "Obligatorio" en el formulario no significa que estés indicando de forma correcta los campos obligatorios. Por ejemplo, si diferencias los campos obligatorios solo por su color de fondo, e incluyes un mensaje como "Todos los campos amarillos son obligatorios", el validador no dará error. Sin embargo, es un error, porque transmites información solo por el color y das instrucciones basadas en aspectos visuales que no todos los usuarios pueden detectar.

1.10 Formularios y estructura (A)

Criterios de las WCAG 2.1: 1.3.1 (A), 4.1.2 (A)

Validaciones

• En formularios extensos, los campos deben estar agrupados con fieldset. El validador hace las siguientes comprobaciones:
  • Si hay grupos de dos o más radio o de cinco o más checks (con el mismo name) entonces cada uno de ellos debe estar agrupado bajo un FIELDSET o un rol de ARIA equivalente (“group” para los checks y “radiogroup” para los radio). 
  • Se comprueba que existan elementos FIELDSET, o elementos que tengan role="group", en aquellos formularios que contengan 8 o más campos de introducción de datos. Si hay 8 o más campos, pero menos de 12 sin haber un elemento FIELDSET, entonces la comprobación se evalúa con 0.5 puntos en vez de 1 y la modalidad "pasa". Si hay 12 o más campos entonces se le asigna el valor 0 puntos y la modalidad "falla".
• Si existen dos o más elementos de encabezado (H1, H2, H3...) dentro de un elemento FORM, da error porque entiende que hacen la función que deberían estar haciendo los elementos fieldset.
• El elemento fieldset debe tener como primer hijo un legend con contenido.
• Se comprueba que todo elemento con role="group" o role="radiogroup" tenga un atributo aria-label, o un atributo aria-labelledby que haga referencia a algún elemento de la página con contenido.
• Los select con muchos elementos deben estar agrupados con optgroup:
  • Se comprueba que, si una SELECT tiene más de 24 opciones, estén agrupadas con algún elemento OPTGROUP. Este límite se amplía hasta 100 en el caso de que las opciones sean números consecutivos.
  • Se comprueba que no existan elementos SELECT con opciones que comiencen por sucesiones de 3 o más caracteres repetidos no alfanuméricos (por ejemplo: “----”, “----texto”, “___”, “***”, “......”, etc.)
  • Se comprueba que los elementos OPTGROUP disponen de una etiqueta que identifique su contenido en forma de atributo label con texto.

Falsos negativos

• A pesar de que en la metodología se dice que se comprueba que todo elemento con role=group da error si no tiene etiqueta, el validador no ha dado este error en la página de prueba, ni teniendo varios role=group sin etiqueta. Esto es un falso negativo.
• En la página de prueba se tiene una select con 25 opciones textuales sin optgroup, pero el validador no ha dado error, es un falso negativo respecto a su metodología. 

Ten en cuenta

• No incluyas encabezados dentro del form, usa en su lugar fieldset.
• Las WCAG no indican un número exacto de elementos a partir de los cuales es obligatorio usar fieldset en el formulario o optgroup en las select, así que guíate por las pautas definidas por el validador.

1.11 Título de página y de marcos (A)

Criterios de las WCAG 2.1: 2.4.1 (A), 2.4.2 (A), 4.1.2 (A)

Validaciones

• La página tiene que tener un title en el head que sea válido (se verifica que no sean títulos que se hayan podido añadir por defecto: “Título del documento”, “Title”, “Untitled document”…)
• Cuando se analiza una muestra de más de 10 páginas, el validador dará error si son todos los títulos iguales. 
• Los frames e iframes deben tener title y no puede estar vacío.

Falso negativo

• Si en una muestra hay dos páginas con el mismo título, esto es un error, aunque el validador solo esté programado para dar error si todas las páginas de la muestra tienen el mismo título.

1.12 Enlaces descriptivos (A)

Criterio de las WCAG 2.1: 2.4.4 (A)

Validaciones

• El validador detecta el uso de enlaces poco descriptivos similares a “pincha aquí” o “pulse aquí”.
• No puede haber enlaces sin texto de enlace y/o imágenes sin alternativas textuales.
• Los enlaces no pueden tener mas de 250 caracteres a menos que empiecen por Decreto, Orden, Ley, R.D., ...
• La alternativa textual de una imagen incluida dentro de un enlace no puede ser igual que el resto del contenido textual del enlace.
• Todo elemento con role="link" o role="button" debe tener un contenido textual; o bien un atributo aria-label, o aria-labelledby que haga referencia a algún elemento de la página con contenido.

Falso positivo

• El siguiente código da error:

  <a href="http://www.usableyaccesible.com" aria-label="Accesibilidad"><img src="icono.png" alt=""/></a>

  También da error el código:

  <a href="http://www.usableyaccesible.com"><img src="icono.png" alt="" aria-label="Accesibilidad"/></a>

  Si bien el enlace está vacío, visualmente hay un icono y el lector de pantalla anuncia el enlace porque, en el primer caso tiene una etiqueta incluida con el atributo aria-label (técnica ARIA8: Using aria-label for link purpose), y en el segundo es la propia imagen la que tiene un texto alternativo incluido con aria-label (técnica ARIA6: Using aria-label to provide labels for objects).

  Dicho esto, es cierto que lo más adecuado sería que, en este tipo de casos, el texto alternativo estuviera en la imagen y concretamente en su atributo ALT, para asegurar que sin imágenes cargadas se muestre el texto alternativo de la imagen. De hecho, el primer caso dará error en el indicador 1.1 (criterio 1.1.1 de las WCAG), pero eso no implica que debiera dar error en el indicador 1.12 (criterio 2.4.4 de las WCAG). El segundo caso, que no da error en el criterio 1.1, como debe ser, no tiene sentido que sí dé error en este indicador 1.12.

Falsos negativos

• En las pruebas se han incluido elementos con role="link" tanto sin etiqueta, como con etiqueta mediante aria-labelledby pero referenciando a un id que no existe, y en ambos casos el validador no ha dado error. Serían falsos negativos.
• Tampoco han dado error los enlaces con un aria-label con texto que no es igual o no incluye su texto de enlace, como <a href="http://www.usableyaccesible.com" aria-label="Olga Carreras">Usable y accesible</a>. Este enlace debería reportar un error, tal y como se hace en los input para esta misma situación (se ha visto en 1.9 Formularios y etiquetas (A)).

Ten en cuenta

• El validador no da error si encuentra dos enlaces iguales en la misma pagina que apuntan a una URL diferente, ni viceversa. Este es un error que sí encuentran otros validadores y que también reportará un auditor en una evaluación manual.
• Aunque las WCAG 2.1 no indican el tamaño máximo de caracteres que deben tener los enlaces, el validador lo fija en 250 caracteres. Para evitar errores a los publicadores, si es posible, se puede limitar en el editor el tamaño máximo de los enlaces, o al menos informar de su longitud.

  Aunque los enlaces que comienza por "Orden", "Real Decreto", etc. son una excepción, ten en cuenta que un enlace de más de 250 caracteres como "la Orden de 27 de mayo de 1958 [...]" sí dará error, porque el enlace comienza en realidad por el artículo "la", no por "Orden".

  También he probado con "&nbsp; Orden del 27 de mayo de 1958 [...]" y da error porque tiene un espacio antes de la palabra "Orden".

  Ten esto en mente a la hora de seleccionar las palabras que incluirás dentro del texto del enlace.

1.13 Cambios de contexto (A)

Criterios de las WCAG 2.1: 3.2.1 (A), 3.2.2 (A)

Validaciones

• Se valida que no provoquen un cambio de contexto (abrir una nueva página, ventana, pestaña o aplicación; o que cambie el foco) mediante el uso de window.location, window.history, window.open, window.focus:
  • ni los eventos onfocus / onblur de los elementos de la página
  • ni el evento onload de la página 
  • ni el evento onchange de una select

Falso negativo

• En las pruebas realizadas, el validador solo detecta el error si incluyo directamente, por ejemplo, un window.open, en el onload, onchange o onfocus del elemento correspondiente, pero no ha funcionando llamando a una función que lo hiciera (<body onload="cargar();">).

1.14 Compatibilidad (A)

Criterio de las WCAG 2.1: 4.1.1 (A)

Validaciones

• La página debe tener un DTD válido.
• El código de la página no puede tener los siguientes errores de validación: etiquetas mal cerradas o anidadas; atributos repetidos en el mismo elemento; atributos con valores sin entrecomillar; atributos que deben tener valores únicos (id, accesskey) repetidos.
• Las CSS no pueden tener errores de sintaxis. Se admiten propiedades experimentales o propietarias siempre que la sintaxis de las CSS sea correcta.

Falso negativo

• En la página de prueba hay un código con errores de sintaxis que sí detecta el validador del W3C, pero que no detecta el validador del Observatorio, a pesar de ser un error que sí debería detectar. Concretamente no da error: <p style="" style="" id=51 id="51"><span accesskey="s"><div accesskey="s"></div></span></div></p>

2.1 Identificación de los cambios de idioma (AA)

Criterio de las WCAG 2.1: 3.1.2 (AA)

Validaciones

• Si se usa el atributo lang, se verifica que define un código de idioma que existe.
• Se buscan palabras concretas habituales en otros idiomas (“bienvenido”, “welcome”, “castellano”, “english”, …) para comprobar que tienen el atributo lang correspondiente. Detecta, por ejemplo, sin marcar, las palabras "english", "français", "català", "galego" o "euskera", pero no "deutsch".
• Se verifica que los cambios en inglés (textos, títulos y alternativas textuales) se marcan con lang. Para identificar textos en inglés se buscan al menos 4 palabras en un listado de las palabras más usadas del inglés que no existen en las lenguas cooficiales de España. No se tienen en cuenta aquellas que están en abreviaturas o acrónimos (ABBR o ACRONYM).

Falso negativo

• Si indicas que la página está en castellano, encuentra los cambios de idioma al inglés sin marcar. Sin embargo, si indicas que la página está en inglés, no detecta los cambios al castellano sin marcar.

2.2 Legibilidad y contraste (AA)

Criterios de las WCAG 2.1: 1.4.3 (AA), 1.4.12 (AA)

Validaciones

• Se comprueba que las combinaciones de color de primer plano (color) y de color de fondo (background-color o background), en una misma regla de las hojas de estilo, tiene el contraste suficiente. Se tienen en cuenta los diferentes umbrales según el tamaño del texto. Si no se conoce el tamaño de texto, se emplea el umbral más permisivo de 3:1.
• Se comprueba que no se usen las propiedades 'line-height', 'letter-spacing', 'word-spacing' fijadas mediante la clave !important.

2.3 Maquetación adaptable (AA)

Criterio de las WCAG 2.1: 1.4.10 (AA)

Validaciones

• Se tiene que poder hacer zoom en la página. En consecuencia, se comprueba que el uso de <meta name='viewport' no esté impidiendo hacer zoom (consultar artículo "Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.").

Ten en cuenta

• No se valida que el texto pueda crecer. Recuerda que este es un requisito diferente del requisito que hace referencia al zoom, pero igual de importante o más. El texto debe poder crecer con las opciones del navegador porque se usan medidas relativas, o bien, y de forma no excluyente, porque se incluyen controles específicos para aumentar o disminuir el tamaño de letra (A+ A-).

2.4 Múltiples vías de navegación (AA)

Criterio de las WCAG 2.1: 2.4.5 (AA)

Validaciones

• La página debe tener mapa del sitio o una función de búsqueda.
  • Se buscan palabras como "mapa" (en distintos idiomas), en los textos de enlace o en su title. Si no las encuentra, las busca en el title de la página, por si estamos en la página de mapa web. 
  • Se buscan palabras como "buscar", "buscador", "búsqueda"... (en distintos idiomas) en elementos de formulario.

Falso positivo

• El criterio de conformidad 2.4.5 (AA) de las WCAG 2.1 / EN 301 549 indica que se deben proporcionar dos o más de los siguientes mecanismos:
  • enlaces para navegar a páginas web relacionadas
  • una tabla de contenidos
  • un mapa del sitio
  • un buscador
  • una lista de enlaces a todas las páginas del sitio en la página de inicio
  • una lista de enlaces a todas las páginas del sitio en todas las páginas del sitio

  Por tanto, el validador es más estricto que las WCAG 2.1 / EN 301 549. Dará un falso positivo si el portal está cumpliendo este requisito mediante otras técnicas. Esto no quita para que sea verdad que en los portales extensos y complejos lo más adecuado sea tener al menos mapa web y buscador, pero estrictamente no se incumple la normativa si se opta por otras técnicas, por ejemplo, en portales pequeños y sencillos.

• Sí detecta que la página tiene mapa web si el enlace se incluye así:

  <a href="http://www.usableyaccesible.com/mapa_web.html"><img src="icono.png" alt="Mapa web"/></a>

  pero no lo detecta si se incluye de la siguiente manera:

  <div role="link" aria-label="Mapa web" tabindex="0"></div> 

  que es válida, como él mismo reconoce en sus validaciones relativas a los enlaces, por tanto, sería un falso positivo.

2.5 Independencia de dispositivo (AA)

Criterios de las WCAG 2.1: 1.3.4 (AA), 2.4.3 (A), 2.4.7 (AA), 1.3.5 (AA)

Validaciones

• Los elementos de interacción no pueden tener atributos outline:0/none, a menos que se use en ellos también :focus para definir un borde o color de fondo.
• No debe usarse tabindex con valores mayores de 0. El validador admite que se incluyan 3 tabindex con un valor mayor que 0; de 4-10 tabindex con un valor mayor que 0 dará 0.5 puntos (en vez de 1 punto) pero pasará.
• No se debe bloquear la orientación de pantalla. El validador comprueba que no existan reglas CSS tipo @media que definan la propiedad orientation que a su vez incluyan sentencias transform con valores 90degr o 270deg.
• Se debe usar autocomplete en ciertos campos de formulario. El validador solo comprueba que los campos de formulario con atributo autocomplete tengan un valor de los descritos en HTML 5.2.

Falsos negativos

• No da error:
  • input {outline:0;} 
  • button {outline:none;} 
  • a {outline:0;} 

Sí da error si se incluye en el focus:

• input:focus {outline:0;}
• button:focus {outline:none;}
• a:focus {outline:none;}

Debería dar error en ambos casos.

• Si la inclusión de outline:0/none se hace en línea (<a style="outline:0"...) el validador no da error.

Falso positivo

• La validación del uso de outline:0/none en la CSS puede llevar a falsos positivos, porque el validador no comprueba si esos estilos de la CSS se están usando realmente en la página.

2.6 Navegación consistente (AA)

Criterio de las WCAG 2.1: 3.2.3 (AA)

Validaciones

• La página no debería tener enlaces rotos:
• con 1 enlace externo roto pasa; 
• con 1 enlace roto dentro del dominio o, más de 1 y menos de 4 enlaces externos rotos, tendrá 0.5 puntos (en vez de 1) pero "pasa".
• No se permiten dos enlaces adyacentes (separados por un carácter y/o conjunto de espacios en blanco o por alguna etiqueta que no pertenezca al grupo de etiquetas en línea) que apunten al mismo destino, salvo que el destino sea "#".

Ten en cuenta

• En el informe no se incluye el listado de enlaces rotos (aunque se indique en las opciones de validación que los evalúe), pero se pueden consultar en el log.

Resumen: Ten en cuenta

En este apartado se recopilan los "ten en cuenta" que se han ido nombrando a lo largo del artículo. No se recopilan los falsos negativos o positivos, estos deben consultarse en cada indicador.

• Imágenes:
  • El número máximo de caracteres en el atributo alt de las imágenes debe ser 150 caracteres. Deberías limitarlo en el gestor de contenidos o, al menos, avisar del número de caracteres incluidos, para evitar este error a los publicadores.
• Encabezados:
  • Aunque la página "pase" sin tener H1, recuerda que es muy importante para muchos usuarios que todas las páginas tengan H1.
  • Aunque este validador no lo evalúe, recuerda que los encabezados deben ser significativos, eso significa que no debe haber dos encabezados con el mismo texto en la página, y que su número de caracteres no debe ser muy extenso. 
• Listas:
  • Si se tienen tablas de una sola columna, con 3 o más filas, y contenido de menos de 150 caracteres, se entiende que se está simulando una lista y el validador da error. Tenlo en cuenta para evitar, si es posible, que los editores de contenido puedan crear tablas de una sola columna.
  • Muchas veces los publicadores simulan las listas porque el editor de contenidos no les ofrece la posibilidad de crear listas de tipo "2, 2.1, 2.1.1" o "a. b. c.". Por ejemplo, CKEditor sí permite, con el botón derecho, modificar las propiedades de la lista para que sea de tipo "a. b. c." o "I. II. III.", pero hay que informar a los publicadores de esta opción que, de lo contrario, puede pasarles desapercibida.
  • Aunque este validador no lo evalúe, los listados de enlaces deben estar maquetados como una lista. 
  • Es habitual encontrar listas vacías en bloques como "Tus últimas visitas", cuando es la primera vez que accedes. La lista no debe estar vacía en el código, sino crearse junto con el primer LI.
• Tablas:
  • Ten en cuenta que, si tienes una tabla con varios niveles de encabezado, si relacionas las celdas con scope, solo pasará el validador si la tabla tiene una fila y una columna de encabezados. Para otros tipos de tablas complejas (con varias filas o columnas de encabezados), deberás usar headers/id, algo que no permiten la mayoría de los editores, así que intenta siempre evitar las tablas complejas. Recomiendo leer: "Table concepts de WAI/W3C".
  • Si utilizas colspan para unir la primera fila, el validador dará error por simular el caption. Puesto que además siempre es mala idea unir celdas, y es mejor, por ejemplo, repetir el dato en cada celda, plantéate eliminar la posibilidad de que los publicadores puedan unir celdas en el editor.
  • Si tienes un encabezado (H1, H2, H3...) justo antes de una tabla, dará error porque presupone que está simulando un caption. Puesto que summary está obsoleto en HTML5 y lo recomendable en HTML5 es una descripción asociada con aria-describedby, esta descripción, en un párrafo antes de la tabla, impedirá siempre el error, porque nunca habrá una tabla inmediatamente después de un encabezado. Plantéatelo como solución estándar en el gestor de contenidos (consulta el artículo Descripción de las tablas en HTML5. Alternativa a "summary").
  • Es recomendable que todas las celdas de una tabla de datos tengan contenido, aunque sea "0" o "sin datos", porque son más fáciles de comprender, especialmente con el lector de pantalla. Teniendo en cuenta que el validador considera una tabla como tabla de datos si al menos el 70% de sus celdas contienen texto, también evitarás errores en el validador si intentas no dejar celdas vacías.
• Agrupación estructural:
  • Aunque el validador solo dé error en los DIV sin etiquetas semánticas (por ejemplo, <div>texto</div>) si los textos son mayores de 150 caracteres, no debe usarse tampoco DIV para incluir textos de menor longitud.
  • Aunque el validador es relativamente permisivo con el uso de BR, no debe usarse esta etiqueta salvo en ADDRESS, como se indicaría en una auditoría manual y podrían evaluar otros validadores.
  • El validador no da error si utilizas varios elementos semánticos iguales para estructurar la página (por ejemplo, varios nav) y no los diferencias con una etiqueta aria-label o aria-labelledby. Esto es un error y es fácil de identificar automáticamente, por lo que sí que lo detectan otros validadores.
• Separación de contenido y presentación:
  • El validador solo da error en etiquetas de presentación obsoletas, pero hay otras que no se deben usar, y que una auditoría manual u otros validadores reportarán como error:
    • <b>: si quieres definir el grosor de la fuente usa estilos para ello, si quieres dar énfasis a unas palabras importantes usa strong, pero en cualquiera de los casos recuerda no abusar de la negrita.
    • <i>: si quieres definir el estilo con itálica usa estilos para ello, pero recuerda que mucho texto en itálica es más difícil de leer. Si quieres enfatizar el texto para reflejar un carácter particular del mismo, como un extranjerismo, usa <em> o ponlo entre comillas. No uses la <i> con background-image para incluir iconos.
  • Ten en cuenta que el validador dará error con a::before {content: " ";}
• Formularios:
  • El LABEL debe estar asociado al campo por el id, no por el name. Si incluyes dentro del for el nombre del campo en vez de su id dará error. 
  • Recuerda que no puedes ocultar el LABEL, si es la única etiqueta del campo, al lector de pantalla. Sin embargo, no da error si lo ocultas solo visualmente, por ejemplo, con text-indent:-999em.
  • Puedes indicar los campos obligatorios con un asterisco. En este caso, recuerda que deberás indicar el significado del asterisco al principio del formulario "* campos obligatorios". También podrías indicar "Todos los campos son opcionales", porque el validador busca tanto la palabra "obligatorio" como "opcional" (o equivalentes: exigido, preciso, requerido...).
  • Que el validador encuentre la palabra "Obligatorio" en el formulario no significa que estés indicando de forma correcta los campos obligatorios. Por ejemplo, si diferencias los campos obligatorios solo por su color de fondo, e incluyes un mensaje como "Todos los campos amarillos son obligatorios", el validador no dará error. Sin embargo, es un error, porque transmites información solo por el color y das instrucciones basadas en aspectos visuales que no todos los usuarios pueden detectar.
  • No incluyas encabezados dentro del FORM, usa en su lugar FIELDSET.
  • Las WCAG no indican un número exacto de elementos a partir de los cuales es obligatorio usar FIELDSET en el formulario o OPTGROUP en las SELECT, así que guíate por las pautas definidas por el validador. Asegúrate de que los publicadores, si pueden incluir formularios, pueden añadir elementos FIELDSET y OPTGROUP.
• Enlaces:
  • El validador no da error si encuentra dos enlaces iguales en la misma pagina que apuntan a una URL diferente, ni viceversa. Este es un error que sí encuentran otros validadores y que también reportará un auditor en una evaluación manual.
  • Aunque las WCAG 2.1 no indican el tamaño máximo de caracteres que deben tener los enlaces, el validador lo fija en 250 caracteres. Para evitar errores a los publicadores, si es posible, se puede limitar en el editor el tamaño máximo de los enlaces, o al menos informar de su longitud.
  • Aunque los enlaces que comienza por "Orden", "Real Decreto", etc. son una excepción, ten en cuenta que un enlace de más de 250 caracteres como "la Orden de 27 de mayo de 1958 [...]" o "&nbsp; Orden del 27 de mayo de 1958 [...]" sí darán error. Tenlo en mente a la hora de seleccionar las palabras que incluirás dentro del texto del enlace.
• Maquetación aceptable:
  • No se valida que el texto pueda crecer. Recuerda que este es un requisito diferente del requisito que hace referencia al zoom, pero igual de importante o más. El texto debe poder crecer con las opciones del navegador porque se usan medidas relativas, o bien, y de forma no excluyente, porque se incluyen controles específicos para aumentar o disminuir el tamaño de letra (A+ A-).
• Navegación consistente:
  • En el informe no se incluye el listado de enlaces rotos (aunque se indique en las opciones de validación que los evalúe), pero se pueden consultar en el log.

Artículos relacionados:

• Falsos positivos de validadores automáticos de accesibilidad basados en las WCAG 2.0
• Validador del Observatorio de Accesibilidad Web - Rastreador OAW. Presentación, Instalación y uso, Metodología e Informes. (Parte I)
• Audit Tool WCAG 2.1
• Recopilación de herramientas y validadores
• Siteimprove, herramienta para el análisis programado de nuestro portal
• aXe Rules, Google ADT Rules y el Mobile Web Accessibility Checker