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 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:

• 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

Reseña del libro "Accessibility for everyone" de Laura Kalbag

Autor: Laura Kalbag

Nº páginas: 168

Idioma: inglés

Formato: digital e impreso

Fecha de publicación: 2017

Web: Ficha en A Book Apart

Podéis consultar más reseñas de libros en: "Libros y reseñas"

"Accessibility for everyone" es un libro que recomiendo a cualquier persona que quiera introducirse en el mundo de la accesibilidad web. 

El libro hace un repaso por la mayoría de los temas que deben conocerse, pero sin profundizar demasiado en ninguno de ellos. Es sencillo de entender y no usa un lenguaje técnico.

Por tanto, no aportará demasiado a las personas que ya tengan conocimientos de accesibilidad web, ni a los desarrolladores o diseñadores que busquen un libro más técnico o con ejemplos concretos, para ello os recomiendo otros libros (ver "Libros y reseñas").

El libro se estructura en 7 temas que resumo a continuación.

Tema 1. Considerando la accesibilidad

El mensaje más importante de este capítulo es que la accesibilidad no es responsabilidad de un desarrollador que repara todos los errores.

• Los product manager, los responsables del contenido y los arquitectos de información diseñan el contenido y la estructura en base a la información y los objetivos proporcionados por los researchers y los ejecutivos. Todos ellos deben comprender y tener en cuenta los requisitos de accesibilidad.
• Los responsables del contenido deben escribir de manera clara y fácil de comprender.
• Los diseñadores deben hacer el contenido legible y usar bien el color.
• Los desarrolladores deben implementar páginas que sean accesibles por teclado, por los lectores de pantalla u otros productos de apoyo.

Cada decisión del equipo afecta a la accesibilidad del sitio, por tanto, la accesibilidad no puede abordarse fuera, o de forma separada, al proceso de creación del sitio web.

La autora desmonta las excusas habituales para no hacer sitios accesibles. Explica la diferencia entre accesibilidad y diseño universal, así como la importancia de la empatía para no crear productos que se ajusten solo a nuestras necesidades.

En este capítulo también repasa los diferentes productos de apoyo o formas de acceso y qué personas las utilizan: lector de pantalla, acceso por teclado, pulsadores, eye tracker, reconocimiento de voz, magnificadores de pantalla, etc.

Tema 2. Discapacidades y limitaciones

En EEUU el 12% de la población tiene una discapacidad, en Reino Unido el 16% de los adultos en edad de trabajar. 

Partiendo de la definición de discapacidad, recorre los diferentes tipos de discapacidad: visuales, auditivas, motoras, cognitivas, desordenes vestibulares (artículo relacionado: Scrolljacking y Parallax Scrolling en accesibilidad web. Peligro para personas con desordenes vestibulares, epilepsia y migrañas).

También repasa los problemas derivados del contexto de acceso según: el dispositivo o el software utilizado; la conectividad del usuario; su idioma materno; cómo accede y desde dónde; si sufre alguna  enfermedad o ha tenido un accidente; su edad; las preferencias de acceso de cada uno; etc.

Tema 3. Planificando para la accesibilidad 

Incorporar la accesibilidad al comienzo del proyecto es más facil, más efectivo y más barato. 

Además, la accesibilidad proporciona una serie de beneficios extras: impacta positivamente en el posicionamiento; mejora la usabilidad y, por tanto, reduce los costes en otros ámbitos, como la atención al cliente; el sitio es más competitivo y cumple con la normativa legal.

Para integrar la accesibilidad en el proceso de desarrollo propone:

• Construir el equipo: todo el equipo tiene que estar involucrado en la accesibilidad del sitio, cada uno en el ámbito de su responsabilidad, liderados por un experto en accesibilidad digital.
• Alcance del proyecto: al comienzo del proyecto se toman muchas decisiones que tendrán un impacto en el enfoque de la accesibilidad y los esfuerzos necesarios para lograrla. Se deben transmitir eficazmente los requisitos de accesibilidad al equipo e informar de forma temprana del impacto en el presupuesto. Por ejemplo, si será necesaria formación o crear alternativas accesibles como los vídeos.
• Investigación con usuarios: recomienda el libro Just Ask: Integrating Accessibility Throughout Design, 2007 de Shawn Lawton Henry, que reseñé hace tiempo. Lo que aprendes en la investigación es acumulativo, te sirve de un proyecto para otro. También puedes aprovechar la investigación UX con usuarios para incluir en la misma a personas con diferentes discapacidades o limitaciones.
• Producción y desarrollo: los frameworks, las tecnologías, las herramientas, el CMS o el editor de texto que se seleccionan, pueden tener un gran impacto en la accesibilidad. Es importante testear con diferentes productos de apoyo y en diferentes contextos de acceso.
• Mantenimiento: la autora comenta los beneficios de tener una política de accesibilidad y cómo debería ser. Pone el ejemplo del portal Post Office de Reino Unido, que sigue la norma "BS 8878:2010 Web Accessibility. Code of Practice" para integrar la accesibilidad en todo el ciclo de vida de un producto web. Lo traté en el artículo BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web 
• Justifica tus decisiones de accesibilidad: a ti mismo, a tu equipo, a tus clientes y a todos las personas involucradas. 

Tema 4. Contenido y diseño

Las decisiones de diseño hechas en nombre de la accesibilidad benefician a todas las personas. Para mejorar la experiencia de todas ellas podemos poner el foco en la usabilidad, haciendo sitios que sean fáciles de ver, de oír, de comprender y de interactuar con ellos.

Muchos de los principios para hacer sitios más accesibles son comunes a los principios para hacer los sitios más usables:

• Affordance y convenciones para que las personas reconozcan los elementos de la interfaz e intuyan su función.
• Navegación y orientación: es más difícil que una persona se pierda en una página con una sólida arquitectura de información, por ello, tenemos que proporcionarle caminos consistentes, para que sepa en todo momento dónde está y encuentre lo que necesita (artículo relacionado: Arquitectura de información. Fundamentos)  La autora habla del menú de navegación; los títulos; el aspecto y redacción de los enlaces; o las migas de pan, especialmente importantes para las personas con problemas de memoria o confusión, como las personas con síntomas de demencia.
• Redacción: el contenido debe ser comprensible, útil y apropiado para tu audiencia. Trata la jerarquía y la estructura del contenido, así como el uso de un lenguaje sencillo y conciso.
• Tipografía: es relevante su tamaño; su grosor; la longitud de las líneas; y que crezca en todos los contextos, por ejemplo, en móvil no se debe impedir el zoom (artículo relacionado Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes). Dedica un apartado específico a las fuentes de iconos y a los problemas que pueden dar según su implementación.
• Diseño de interacción: se centra en la importancia de dar tiempo al usuario para hacer las tareas y leer el contenido, algo que resulta difícil, por ejemplo, en los carruseles si no se pueden parar. Otros temas que abarca son: evitar que los usuarios comentan errores en los formularios y ayudarles a reponerse de ellos rápidamente; o la importancia de que los mensajes y las alertas del sitio sean comprensibles y todas las personas puedan percibirlos, por ejemplo, si acceden con un lector de pantalla.
• Color: trata el contraste de color. Hay que recordar que el contraste blanco y negro no es el más adecuado, por ejemplo, para las personas con síndrome de Irlen. También habla de la importancia de no transmitir la información solo con el color. 
• Rich media: 
• Imágenes: aborda temas como el texto alternativo en las imágenes, las imágenes de texto y los gráficos e infografías.
• PDF: en este caso no estoy de acuerdo con la autora, que en vez de hablar de los PDF accesibles de forma nativa, propone poner la información en HTML en vez PDF, convirtiendo los PDF en HTML mediante algún programa. Si bien es cierto que a veces se incluye información en un PDF cuando podría haberse incluido en una página HTML, en otros muchos casos el PDF es necesario. En estos casos, la conversión de PDF a HTML suele generar un código muy malo, y resulta tanto o más costoso convertir el HTML en accesible que convertir el propio PDF en accesible de forma nativa. Lo que hay que hacer es formar a los editores en las buenas prácticas que deben seguir en los programas de origen para que el PDF generado sea lo más accesible posible, de modo que el trabajo para mejorar su accesibilidad con Acrobat Professional sea mínimo.
• Subtítulos y transcripciones para vídeos y audios, necesarios, por ejemplo, para las personas sordas, pero que resultan muy útiles para cualquiera de nosotros en determinados contextos: ayudan a concentrarse en lo que se dice en el audio, especialmente si no es tu idioma materno; puedes leerlos si estás en un ambiente ruidoso o en uno en el que se ha de guardar silencio y no tienes auriculares; etc.

La autora da apuntes concisos y generales sobre cada punto, pero sin entrar en mucho detalle en ninguno de ellos.

Tema 5. Accesibilidad y HTML

Para que la página pueda ser correctamente interpretada por el navegador y los productos de apoyo o los crawlers, deberá seguir los estándares y tener una estructura correcta.

Los aspectos de accesibilidad generales al implementar las páginas en HTML son: 

• Estructura: visualiza la página sin CSS para comprobar que la página tiene una estructura correcta, está bien jerarquizada y los contenidos se encuentran en un orden lógico. Así es cómo leerá la página un lector de pantalla o una araña como GoogleBot, por eso la accesibilidad mejorará también el posicionamiento (artículo relacionado "Accesibilidad y SEO" (PDF, 248)). La página debe tener un buen título; la información más importante debe situarse arriba; tiene que estar estructurada con encabezados; y se deben utilizar las listas cuando sea necesario, pues así la información es más fácil no solo de ojear y de comprender, sino también de acceder y saltar con el lector de pantalla.
• Formularios: utiliza siempre que se pueda los elementos estándar de los formularios, etiquétalos e indica los campos obligatorios.
• Acceso por teclado: trata aspectos como los atajos de teclado y las accesskey; los enlaces para saltar al contenido; la importancia del foco en el acceso por teclado, que debe ser visible; o el uso de tabindex= 0 / -1. Esto último lo trato en el artículo WAI-ARIA. Introducción, referencias, ejemplos, herramientas 
• Separación del contenido y la presentación: se debe trabajar con CSS; no usar los estilos para simular etiquetas, por ejemplo, un tamaño de letra grande para simular un <h2>; y no usar una etiqueta para dar al texto un estilo concreto, por ejemplo <blockquote> para indentar un texto si este no es realmente una cita. 
• Mejora progresiva y degradación elegante:  trata la diferencia entre ambos términos, siendo siempre más recomendable la mejora progresiva.
• WAI-ARIA: hace una breve introducción al estándar.

Tema 6. Evaluación y testing

Se debe tener un plan de evaluación y testing, para ello hay que:

• definir los métodos que se van a utilizar y cuándo se llevarán a cabo; 
• cómo se documentarán los resultados;  
• cómo se usará el feedback para mejorar.

Repasa diferentes métodos de análisis y evaluación, así como herramientas de apoyo. 

Propone usar una matriz para validar, como la de Anne Gibson en Reframing Accessibility for the Web, aunque personalmente me gusta la que propone ella en la pagina 126.

Matriz de revisión de accesibilidad de Anne Gibson en A list Apart

Sobre las herramientas para medir la comprensión de los textos, hay que tener en cuenta que en español hacen falta algoritmos específicos, lo traté en: Medición de la readability o comprensión de los textos en español. Estado actual y retos.

Tema 7. Leyes y pautas

Repasa brevemente leyes de accesibilidad en EEUU y Reino Unido, con ejemplos de denuncias por falta de accesibilidad en sitios web. Podéis consultar una recopilación extensa de leyes en el artículo Legislación sobre accesibilidad web en España, Europa y otros países.

Después hace una breve introducción a la estructura de las WCAG.

Artículos relacionados

• "Libros y reseñas"
• Scrolljacking y Parallax Scrolling en accesibilidad web. Peligro para personas con desordenes vestibulares, epilepsia y migrañas
• BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web
• Reseña Just Ask: Integrating Accessibility Throughout Design, 2007 de Shawn Lawton Henry 
• Arquitectura de información. Fundamentos
• Legislación sobre accesibilidad web en España, Europa y otros países
• Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes
• Medición de la readability o comprensión de los textos en español. Estado actual y retos.
• Responsabilidad de accesibilidad de cada uno de los roles profesionales implicados en el ciclo de vida de un proyecto web
• Reseña: Monográfico "Accesibilidad Web" de la revista Novática
• Reseña "Inclusive Design Patterns. Coding Accessibility Into Web Design"

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

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)

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.

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