Revisión de la "Directiva 2016/2102 sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público" (en España "Real Decreto 1112/2018")

La Comisión Europea ha publicado la review de la "Directiva 2016/2102 sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público”, que en España fue transpuesta mediante el Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público.

Esto no significa que la directiva se haya modificado, sino que se ha evaluado tal y como establece su artículo 13:

La Comisión llevará a cabo un examen de la aplicación de la presente Directiva a más tardar el 23 de junio de 2022. Dicho examen tendrá en cuenta los informes de los Estados miembros sobre el resultado del seguimiento contemplado en el artículo 8 y el uso del procedimiento de aplicación del artículo 9. También incluirá un examen de los avances tecnológicos que podrían facilitar la accesibilidad para ciertos tipos de contenidos excluidos del ámbito de aplicación de la presente Directiva. Las conclusiones de dicho examen se harán públicas en un formato accesible.

Lo que se ha publicado es, por tanto, las conclusiones de dicho examen, que abarca los tres primeros años de aplicación de la Directiva (desde 2018 hasta 2021) y que se puede consultar en:

• Evaluation - SWD(2022)410 - English (1.9 MB - PDF - 101 pages)
• Executive summary of the evaluation - SWD(2022)411 - English (272 KB - PDF - 5 pages)

La directiva y sus decisiones de aplicación se han revisado en base a cinco criterios: eficacia, eficiencia, coherencia, pertinencia y valor añadido.

Se indica que la evaluación detallada del impacto económico, social y ambiental es limitada, principalmente debido a las dificultades para cuantificar y monetizar los costos y beneficios de la accesibilidad web, la inclusión y la no discriminación, así como la disponibilidad limitada de datos relevantes. No obstante, la evaluación general, los hallazgos y las conclusiones, basados en datos indirectos alternativos y la triangulación de hallazgos de varias fuentes, se consideran sólidos y completos.

Concluye que la Comisión ha cumplido las obligaciones cuantificables de la Directiva (adopción de los actos de ejecución y la armonización normativa) y que todos los estados han llevado a cabo las acciones pertinentes (transposición, creación de órganos de control, notificación y ejecución, sensibilización y mejoras de accesibilidad). Aunque reconoce que todavía queda mucho por hacer para que los sitios web y las aplicaciones móviles del sector público sean totalmente accesibles para las personas con discapacidad.

Se indica que la mayoría de las acciones hasta la fecha se han dirigido a las personas con discapacidad visual y que los organismos de normalización continúan trabajando sobre los requisitos para las personas con discapacidad cognitiva.

Admite que, aunque la redacción de la Directiva exige sitios web y aplicaciones móviles "más accesibles", ofrece herramientas limitadas para medir el progreso dentro de la categoría "parcialmente conforme".

Creen que los cimientos establecidos hacen probable que continúe la tendencia hacia sitios web y aplicaciones móviles "más accesibles", tanto en términos de cantidad como de calidad.

Repaso a continuación las conclusiones en base a los diferentes criterios evaluados.

Eficacia

En primer lugar, en base al estudio externo que respalda la revisión, la Directiva mejoró el funcionamiento del mercado interno para la prestación de servicios de accesibilidad web mediante la armonización normativa y el estímulo de la demanda.

En segundo lugar, ha mejorado el bajo nivel de accesibilidad de los sitios web y las aplicaciones móviles del sector público antes de su adopción.

A pesar de ello, muchas personas con discapacidad que han participado en la consulta pública todavía encuentran que los sitios web y las aplicaciones móviles del sector público son difíciles de usar.

Consideran que los principales factores para que la Directiva haya sido un éxito son:

• La introducción de mecanismos de feedback y cumplimiento.
• Las disposiciones para el seguimiento y la presentación de informes periódicos.
• La implementación de las declaraciones de accesibilidad.

Eficiencia

Concluye que los resultados de la revisión sugieren que la Directiva fue diseñada e implementada de manera eficiente y que los recursos fueron adecuados y proporcionados.

Aunque la mayoría de los organismos del sector público dijeron que la Directiva había introducido costes económicos adicionales, la evidencia recopilada muestra que los costes relacionados con la accesibilidad no han constituido una barrera importante para implementar la Directiva.

Hubo muy pocos casos en los que los organismos del sector público utilizaran la cláusula de carga desproporcionada de la Directiva.

Coherencia

Basándose en los comentarios de las partes interesadas y en la revisión de las políticas internacionales y de la Unión Europea pertinentes, se concluye que la Directiva es coherente internamente y no muestra superposiciones ni incoherencias con otras políticas o leyes de la Unión Europea relacionadas con la accesibilidad web, como la Ley Europea de Accesibilidad o la Estrategia de la Comisión para los derechos de las personas con discapacidad 2021-2030.

Se concluye que la Directiva también es coherente externamente y está en línea con los tratados y las medidas internacionales para apoyar la inclusión digital y social de las personas con discapacidad.

Pertinencia

Teniendo en cuenta la evolución del contexto político europeo e internacional, se indica que la Directiva sigue siendo pertinente para sus principales partes interesadas.

El compromiso de la Unión Europea con la transformación digital, fomentando la digitalización continua del sector público y el uso de los servicios públicos en línea, ha aumentado desde que la Comisión actual asumió el cargo y se destacó aún más durante la pandemia de COVID-19. Se han establecido objetivos ambiciosos para 2030, lo que confirma la necesidad continua de sitios web y aplicaciones móviles accesibles.

Valor añadido

El estudio sugiere que hay un valor añadido sustancial en la mejora de la accesibilidad en línea de los servicios públicos y, por lo tanto, el aumento de la inclusión digital de los usuarios.

Para muchos Estados miembros, la adopción de la Directiva significó la introducción de leyes nacionales sobre accesibilidad web que no existían anteriormente.

Sin la Directiva, los Estados miembros por sí solos no habrían alcanzado el nivel de actividad relacionada con la accesibilidad web demostrado en los informes de seguimiento, y esto incluye la sensibilización dentro del sector público.

Tampoco habría habido requisitos técnicos armonizados, por lo que continuaría la fragmentación nacional del mercado único.

Hallazgos sobre monitoreo, aplicación y avances tecnológicos

Destacan los siguientes hallazgos clave:

• 25 Estados miembros presentaron informes de seguimiento a la Comisión. Los principales hallazgos del análisis de los informes fueron:
  • la provisión transfronteriza de herramientas de accesibilidad, que se espera que aumente;
  • que los programas de formación y las actividades de sensibilización promovidas por la Directiva fueron realizadas por casi todos los Estados miembros que presentaron un informe.
• Si bien todos los Estados miembros han establecido un procedimiento de ejecución formal y han designado un organismo de ejecución, el uso del procedimiento de ejecución de la Directiva aún no ha alcanzado todo su potencial. Los usuarios a menudo desconocen el procedimiento o no se sienten seguros al utilizarlo.
• La revisión de los avances tecnológicos mostró que los medios automatizados, o eficientes y fáciles de implementar a través de la inteligencia artificial, y el aprendizaje automático, se utilizan cada vez más en herramientas relevantes para la accesibilidad digital. Esto ayuda a facilitar la accesibilidad de algunos tipos de contenido actualmente excluidos del alcance de la Directiva.

Conclusiones y lecciones aprendidas

Teniendo en cuenta estos hallazgos, la evaluación identifica las siguientes lecciones clave aprendidas que podrían tenerse en cuenta para futuras iniciativas de políticas relacionadas con la accesibilidad web:

• Hay escasez de experiencia en accesibilidad digital tanto en el sector público como en el privado, lo que dificulta que los organismos del sector público adquieran soluciones accesibles o contraten expertos. Existe potencial para que las personas con discapacidad se capaciten y trabajen como expertos en accesibilidad digital.
• Los actores entrevistados mencionaron la importancia de:
  • aumentar las oportunidades de capacitación;
  • módulos de accesibilidad obligatoria para los currículos de TIC en las universidades; y
  • certificaciones profesionales, incluso para personas con discapacidad que deseen trabajar como expertos en accesibilidad.
• Los mecanismos de retroalimentación y aplicación aún no han alcanzado su pleno potencial. Los organismos del sector público y otras organizaciones informaron conocer estos mecanismos, pero los usuarios finales informaron que solo tenían un conocimiento y un uso limitados de los mismos. La sensibilización y la promoción del uso de los mecanismos de retroalimentación y cumplimiento pueden beneficiar a todas las partes interesadas, tanto al señalar los problemas de accesibilidad a los organismos del sector público como al hacer que el contenido sea accesible para los usuarios.
• La comparabilidad de los resultados del seguimiento de los Estados miembros es limitada. La flexibilidad en la metodología de seguimiento y los criterios de notificación que ofrece la Directiva y sus actos de ejecución y, en particular, la falta de una definición común de los tres estados de cumplimiento (no cumplimiento, cumplimiento parcial o cumplimiento total), dificulta la comparación directa de la accesibilidad en todos los Estados miembros.

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

Validador del Observatorio de Accesibilidad Web - Rastreador OAW. Presentación, Instalación y uso, Metodología e Informes. (Parte I)

Nota 14/02/2022: el Observatorio de Accesibilidad ha liberado una nueva versión del validador en GITHUB con algunas novedades

El Ministerio de Hacienda y Función Pública de España ha liberado la herramienta con la que el Observatorio de Accesibilidad Web (OAW) analiza los portales de la Administración Pública de forma periódica y que, hasta ahora, solo podía utilizar bajo demanda el personal del sector público.

En este artículo os explico cómo funciona el validador, dónde podéis descargarlo para instalarlo, la metodología de validación que utiliza y los informes que genera.

El Rastreador OAW es, a mi parecer, uno de los validadores de accesibilidad más completos que existen actualmente.

Los aspectos que más valoro son que:

• realiza gran cantidad de validaciones en diferentes criterios;
• valida respecto a las WCAG 2.1 / EN 301 549:2019;
• permite validar una página, por URL o por código;
• permite validar de vez una muestra de hasta 51 páginas. Puedes seleccionar tú la muestra o, puedes dejar en su mano que seleccione una muestra representativa en base a una serie de criterios que indicaré más adelante;
• incluye validación de enlaces rotos;
• la metodología de validación, con la descripción de todas las comprobaciones que hace, está publicada y salió a debate público;
• es bastante fiable, aunque es verdad que no está libre de algún falso positivo o negativo;
• es gratuito.

El mayor inconveniente es que el informe solo se ofrece en formato PDF, y el PDF que genera no es accesible, de modo que una persona que accede, por ejemplo, con un lector de pantalla tendrá problemas para operar y comprender el informe.

Corregir los errores que detecta el validador mejorará la accesibilidad de las páginas, pero NO implica en ningún caso que solo con estas correcciones el portal será accesible o cumplirá con la EN 301 549 / WCAG 2.1

Es importante recordar que los validadores automáticos son solo una ayuda. El número de errores que detectan representa un porcentaje reducido de los errores que tiene realmente la página y, muchas veces, no reflejan algunos problemas bastantes relevantes.

Se debe tener esto siempre en mente para no perder la perspectiva. En ocasiones, se puede llegar a dedicar mucho tiempo o esfuerzo a intentar no tener ningún error en el validador, incluso tratando de solucionar algún error que no está suponiendo un problema real de accesibilidad, en vez de centrarse en solucionar otros graves que no detecta el validador. Pondré algún ejemplo en el apartado Fiabilidad de este artículo.

Índice

• El validador de accesibilidad "Rastreador OAW"
• Descargar e instalar el validador
• Cómo utilizar el validador
• Metodología de evaluación
• Informes resultantes
• Validaciones y fiabilidad (Parte II publicada el 23/06/2020)
• Novedades de la nueva versión liberada (14/02/2022)

El validador de accesibilidad "Rastreador OAW"

El estado español lleva utilizando desde el año 2010 la herramienta del Rastreador del Observatorio de Accesibilidad Web (OAW) para la monitorización, reporte y seguimiento de los portales de la Administración Pública.

Esta herramienta está a disposición del sector público de forma gratuita a través del Servicio de Diagnóstico en línea de la Comunidad Accesibilidad, para lo cual solo es necesario registrarse en ella.

El Rastreador OAW es, por tanto, la herramienta que:

• permite llevar a cabo las distintas iteraciones del Observatorio de Accesibilidad Web (OAW), evaluando de forma automática y periódica los portales de la Administración Pública; 
• se pone a disposición del personal de la Administración Pública para verificar en línea, y bajo demanda, la accesibilidad de una página o sitio web. En el validador indicas, como veremos, la página o muestra de páginas que deseas analizar, y este te envía por email el informe de accesibilidad en formato PDF, generado automáticamente a partir de las comprobaciones implementadas en la plataforma.

El uso bajo demanda permite obtener una estimación de cuáles serían los resultados alcanzados en una iteración oficial, facilitando la corrección de los errores que reportaría.

La "Directiva (UE) 2016/2102 del Parlamento Europeo y del Consejo sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público", traspuesta a la legislación española mediante el "Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público" obliga a que los portales y apps del sector público sean accesibles, y establece que deberá hacerse un seguimiento del cumplimiento de esta obligación e informar de ella a la Comisión Europea.

La "Decisión de Ejecución (UE) 2018/1524 de la Comisión Europea, de 11 de octubre de 2018, por la que se establecen una metodología de seguimiento y las disposiciones para la presentación de informes por parte de los Estados miembros de conformidad con la Directiva (UE) 2016/2102 del Parlamento Europeo y del Consejo sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público" especifica, entre otros aspectos:

• cómo los estados deben realizar el seguimiento de la accesibilidad de los portales del sector público, con métodos de seguimiento en profundidad para verificar la conformidad, y métodos de seguimiento simplificado con herramientas automáticas;
• la muestra de sitios a analizar, y dentro de estos, la muestra de páginas que se selecciona, teniendo en cuenta aspectos como:
  • la población del país;
  • que la muestra sea representativa en aspectos tales como el ámbito gubernamental, la temática y la distribución geográfica;
  • las ratios de rotación en los sitios web analizados, obligando a mantener una muestra de sitios web fijos y una muestra variable;
• cómo deben presentarse los informes.

El Real Decreto 1112/2018 establece que el órgano encargado de realizar este seguimiento y de presentar los informes a la Comisión Europea será el Ministerio de Política Territorial y Función Pública.

En este sentido, el Rastreador OAW hace un papel fundamental como método de seguimiento simplificado.

Según los datos del Observatorio de Accesibilidad Web (OAW), analiza dos veces al año más de 700 portales, lo que supone el análisis oficial de aproximadamente 25.000 páginas. Así mismo, a través del servicio de diagnóstico en línea, se solicita el análisis de más de 60.000 páginas anualmente.

El análisis periódico y automático de los portales de la Administración Pública se realiza en 4 ámbitos de actuación diferenciados: el ámbito estatal, el ámbito regional, el ámbito local y otros. Dentro de cada uno se establecen diferentes segmentos.

En función del ámbito y el segmento en el que se localice el portal web a analizar, habrá diferencias en cuanto, por ejemplo, la muestra de páginas a analizar o la periodicidad del análisis.

La muestra de páginas que se revisa en el análisis de cada sitio web es de 17, 33 o 51 páginas, dependiendo del tamaño y complejidad del sitio web. Por eso veremos más adelante que el validador de accesibilidad permite analizar una página o varias páginas, o indicar que el propio validador seleccione una muestra de 17, 33 o 51 páginas.

La selección de la muestra siempre incluye la página de inicio. El resto de páginas se seleccionan de forma automática, con un algoritmo que busca que la muestra sea lo más representativa posible de las diferentes tipologías de contenidos del sitio analizado. Para ello, siempre que sea posible, realiza un proceso de discriminación para seleccionar:

• Páginas con diferentes tipologías de contenidos, como tablas o formularios.
• Páginas de diferentes secciones y/o directorios del sitio web.

En el caso de los sitios web del segmento principal del ámbito estatal y autonómico, la muestra de páginas se realiza de forma manual para asegurar la inclusión de distintos tipos de páginas y plantillas. Esta selección siempre incluye determinados tipos de páginas (Home, Buscador, Mapa web, etc.)

En la Metodología para el seguimiento simplificado del Observatorio de accesibilidad (PDF, 1.62 MB) se pueden consultar todos los detalles.

Artículos relacionados:

• Directiva europea 2016/2102 sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público
• Modelo de declaración de accesibilidad y de presentación de informes definido por la Comisión Europea
• Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público

Descargar e instalar el validador

El Ministerio de Hacienda y Función Pública ha decidido liberar su herramienta de uso interno como software libre, que se distribuye con licencia EUPL v1.2: nota de prensa de la liberación del validador

Podéis descargar el Rastreador OAW desde el proyecto de github "Rastreador Observatorio de Accesibilidad Web".

Para instalarlo necesitas:

• Java 1.8.0_202
• Apache Tomcat 7
• MySQL 5
• Maven 3.0.0

Como es importante que sean estas versiones, yo he optado por instalarlo en una máquina virtual.

El proceso de instalación viene detallado en el proyecto: se ejecutan los scripts en MySQL para crear las tablas de la BD; se modifica el fichero "server.xml" de Tomcat como se indica en la documentación; se ejecuta el comando de Maven para crear el proyecto; y se configura la aplicación.

Si lo que os interesa es solo el validador, una vez instalada la aplicación podéis acceder directamente al mismo, sin pasar por la página de inicio (para la que os tendréis que crear en la BD un usuario / contraseña), mediante la página [http://localhost:8080/oaw/]diagnostico.html.

Cómo utilizar el validador

Destinatario

El primer campo es el correo electrónico al que quieres que se envíe el informe PDF generado.

El proceso por defecto consiste en que el PDF se crea en un directorio de forma temporal, se envía por correo y después se elimina de dicho directorio.

Nosotros hemos preferido prescindir del envío por correo y hemos modificado la aplicación para que el PDF se quede en el directorio local y no se borre.

Tipo de análisis

Puedes seleccionar tres tipos de informes.

Sitio Web

En el tipo de análisis "Sitio Web" puedes indicar:

• la URL exacta de la página web concreta que quieres analizar;
• la URL de un dominio para que el validador seleccione automáticamente una muestra representativa de ese portal de 17, 33 o 51 páginas. Ya he explicado en qué se basa para seleccionar las páginas y que, por ejemplo, siempre incluye la página de inicio.

Estos tamaños de muestra tan concretos que se pueden seleccionar (17, 33 y 51) se corresponden con el tamaño de la muestra en los análisis periódicos y automatizados, en función de la complejidad (baja, media y alta) con la que se clasifique el sitio. Cuánta mayor es su complejidad (basada en la amplitud y profundidad del sitio), más páginas se analizan.

El tiempo que la aplicación tarda en generar el informe depende de las opciones que seleccionas:

• Si indicas que analice 1 página, el informe se genera casi de forma inmediata.
• Si indicas que busque una muestra de 51 página (y además que valide los enlaces rotos), el informe tarda bastante más, una o dos horas. Puedes ir consultando el log para comprobar que efectivamente está trabajando y acabará generando el informe.

Conjunto de URLs

Otro tipo de informe es analizar varias páginas, pero indicando tú exactamente qué URLs quieres que analice. Puedes añadir hasta 51 páginas.

Código fuente

También puedes analizar el código de la página, en vez de su URL. Es útil si para acceder a la página se necesita usuario y contraseña, por ejemplo, porque está en un entorno de desarrollo o en una sede electrónica. El tamaño máximo del fichero que puedes subir es de 4MB.

Tipo de informe

Sigue permitiendo validar de acuerdo a la UNE 139803:2012 (equivalente a las WCAG 2.0), pero por defecto validará de acuerdo a la EN 301 549:2019 / WCAG 2.1, que es la normativa actualmente vigente.

Tiene una opción en beta para comprobar si se incluye la declaración de accesibilidad y determinados apartados de la misma. Recordemos que los portales de la Administración Pública deben tener un apartado "Accesibilidad" y que este debe seguir el modelo definido por la Comisión Europea. Consultar el artículo "Modelo de declaración de accesibilidad y de presentación de informes definido por la Comisión Europea".

También incluye la opción de validar o no enlaces rotos. Validar los errores rotos ralentiza el tiempo de generación del informe.

Estaría muy bien que en un futuro incluyera también la validación de la ortografía de la página.

Metodología de evaluación

La metodología que utiliza estuvo bajo debate público: consultar nota de prensa "Abierto a consulta el borrador de la Metodología del Observatorio de Web (ligada a la monitorización del cumplimiento de la Directiva 2016/2102-Real Decreto 1112/2018) para contar con la participación de todos los actores involucrados.

Como ya comenté por las redes sociales, propuse varias ideas, hubo otras muchas: consultar el foro de debate Metodología OAW.

La metodología es pública y en ella se explican todas las validaciones que se realizan, que están basadas en los criterios de la EN 301 549/ WCAG 2.1: Metodología para el seguimiento simplificado del Observatorio de accesibilidad (PDF, 1.62 MB)

Se estructura en 14 indicadores de nivel A y 6 indicadores de nivel AA. Dentro de cada indicador se realizan diferentes comprobaciones. En la metodología se pueden consultar las tablas de equivalencia entre cada validación y el criterio de las WCAG 2.1 o requisito de la EN 301549 con el que se corresponde, así como la discapacidad a la que beneficia.

Los indicadores son:

• 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)

Prepararé un segundo artículo más específico comentando las validaciones concretas que realiza y los falsos negativos más habituales, para no alargar más este artículo, pero podéis consultar un ejemplo en el apartado Fiabilidad de este artículo.

Informes resultantes

El informe se genera automáticamente con los datos de la validación y está en formato PDF.

Desgraciadamente, el PDF generado es un PDF no accesible, de modo que las personas que acceden, por ejemplo, con un lector de pantalla tendrán problemas para interacturar y comprender el documento.

Informe de accesibilidad de Adobe Acrobat en un informe del validador Rastreador OAW

Los apartados del informe son:

1. Introducción

Con información sobre cómo utilizar el informe.

2. Muestra de páginas

Listado de todas las páginas analizadas y la configuración con la que se solicitó el informe. Ya hemos comentado que las páginas las has podido seleccionar tú o el propio validador.

3. Resumen de resultados

En los resultados globales se indica la puntuación media del sitio, el nivel de adecuación (No válido, A o AA) y la situación de cumplimiento (No conforme, Parcialmente conforme o Plenamente conforme). Incluye la gráfica del número de páginas conformes y no conformes con su tabla correspondiente.

Distribución de páginas según nivel de adecuación

En el apartado de puntuación media y nivel de adecuación de cada página, se incluye la gráfica de cumplimiento por página y la puntuación obtenida, con su correspondiente tabla.

Por último, en el apartado de puntuación media de verificación a nivel de sitio web, se incluye la gráfica con la puntuación media obtenida en cada indicador analizado, con su correspondiente tabla, tanto en el nivel A como AA.

4. Resultados por verificación y página

Muestra en una tabla para el nivel A, y otra para el nivel AA, en qué indicador ha fallado cada página.

Estas tablas permiten consultar de forma rápida en qué páginas o en qué indicadores concentrar los esfuerzos para mejorar los resultados.

Resultados por verificación y página nivel A

Resultados. Página x

Hay un apartado como este para cada página analizada.

Se indica la puntuación y el nivel de adecuación de la página, así como el listado de indicadores en los que falla.

En cada indicador con problemas, diferenciados por nivel A y AA, se describe el error de forma común a todos los informes, y se incluyen todas las instancias del código en el que hay un error.

Ejemplo de error en el indicador 1.10

Anexo I. Metodología del observatorio

Incluye un enlace a la metodología de validación.

Fiabilidad

El 23/06/2020 publiqué una segunda parte de este artículo, dedicada exclusivamente a las validaciones y la fiabilidad del validador.

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

La fiabilidad del validador es bastante alta, pero es muy difícil que un validador que quiere abarcar muchas comprobaciones en muchos criterios acabe estando exento de falsos positivos y negativos.

Complementaré este artículo con un artículo futuro en el que hablaré de las diferentes comprobaciones que hace, o extendiéndome más sobre los falsos positivos y negativos.

Voy a poner aquí solo dos casos a modo de ejemplo.

Criterio 2.4.5 Múltiples vías

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

El validador de accesibilidad OAW verifica el criterio 2.4.5 en el indicador 2.4, verificando que se proporciona un mapa del sitio o una función de búsqueda dentro del sitio web.

Por tanto, es más estricto que las WCAG 2.1 / EN 301 549. El validador dará un falso positivo (es decir, un error que no es tal) 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.

Revisión de la CSS

En algún portal nos ha ocurrido que el validador encuentra un error en la CSS, por ejemplo, que se usa content: para incluir un contenido como " *". Pero esos estilos no están siendo utilizados en el portal, ni por tanto en la página analizada, y no suponen ningún problema real de accesibilidad. Estas CSS son las propios del CMS y es muy complicado sustituirlas o sobrescribirlas, por lo que al final resulta imposible evitar el error en todas las páginas analizadas.

Se solicitó que se valorara dar solo el error en el caso de que el estilo se usara en la página, pero los responsables del validador indicaron que no era posible.

Este es un ejemplo de un error en el que se acaba invirtiendo mucho tiempo y esfuerzo solo para no tener errores en el validador, pero que es un error que no es relevante para la accesibilidad de la página, de modo que ese tiempo y esfuerzo podría dedicarse a corregir otros errores más relevantes que el validador no detecta.

Novedades de la nueva versión liberada

El 08/02/2022 se liberó en GITHUB una nueva versión del validador de accesibilidad.

La mala noticia es que las dificultades para instalarla en local son incluso mayores que en la versión inicial.

La buena noticia es que trae dos novedades útiles:

• Desde la opción "Seleccionar el tipo de análisis > Código fuente" se puede subir un ZIP con varias páginas
• Opción "Generar informe de revisión en profundidad"

  Junto al PDF se obtiene el fichero JSON, ODS y Excel del Informe en profundidad. Los informes están rellenos por cada página analizada, indicando en cada criterio si pasa, falla, no decide o no está testeado:

  

Para los que me habéis preguntado sobre la mezcla de informes, cuando empieza a pasar lo solucionamos borrando ciertas tablas de la base de datos:

delete FROM oaw.tanalisis_css;
delete FROM oaw.tanalisis_accesibilidad;
delete FROM oaw.tanalisis;
delete FROM oaw.tincidencia;
delete FROM oaw.rastreos_realizados;
delete from oaw.observatorios_realizados;
delete from enlaces_rotos;
commit;

No sé si hace falta borrarlas todas, pero funciona.

Artículos relacionados

• Validador del Observatorio de Accesibilidad Web - Rastreador OAW. Validaciones y fiabilidad (Parte II)
• Validadores y herramientas para consultorías de accesibilidad y usabilidad
• Audit Tool WCAG 2.1
• Siteimprove, herramienta para el análisis programado de nuestro portal
• aXe Rules, Google ADT Rules y el Mobile Web Accessibility Checker
• Accessibility Scanner, evaluar la accesibilidad de una app de Android