Mostrando entradas con la etiqueta WAI-ARIA. Mostrar todas las entradas

jueves, 8 de junio de 2023

WAI-ARIA 1.2. Novedades de la nueva versión del estándar Accessible Rich Internet Applications (WAI-ARIA), de 6 de junio de 2023

En este artículo enumero y explico detalladamente todas las novedades de la nueva versión del estándar WAI-ARIA: Accessible Rich Internet Applications (WAI-ARIA) 1.2, recomendación desde el 6 de junio de 2023.

Me parece que fue ayer cuando escribía el artículo explicando las novedades de la versión 1.1, pero ya han pasado más de cinco años: Novedades WAI-ARIA 1.1, Usable y accesible, 22/12/2017.

Este artículo parte de la base de que conoces el estándar WAI-ARIA, imprescindible hoy en día para hacer accesible un portal web para los productos de apoyo, como un lector de pantalla, y para realizar una auditoría de accesibilidad web.

Si no estás familiarizado con el estándar, puedes consultar los artículos introductorios sobre WAI-ARIA.

Nuevo rol "caption"

Se añade el rol caption para definir el nombre visible de los siguientes roles:

figure
table
grid
treegrid

El rol caption puede nombrar, o nombrar y describir.

En cualquiera de estos roles, caption debe ser un hijo directo y ser el primer hijo de forma obligatoria, salvo en el rol figure, donde puede ser el primero hijo o el último.

Estos roles, además, deberían tener un atributo aria-labelledby que haga referencia al caption.

Si el caption incluye una descripción, entonces el atributo aria-labelledby solo hará referencia a la parte que tiene el nombre, y se añadirá un atributo aria-describedby para hacer referencia al texto que funciona como descripción.

En el propio rol caption está prohibido usar aria-label o aria-labelledby.

<div role="table" aria-labelledby="name" aria-describedby="desc">
   <div role="caption">
     <div id="name">Contest Entrants</div>
     <div id="desc">
       This table shows the total number of entrants (500) the
       contest accepted over the past four weeks.
     </div>
   </div>
   <!-- ... -->

Ejemplo de código del estándar WAI-ARIA 1.2

Consulta el rol "caption" en ARIA 1.2.

Nuevo rol "code"

El nuevo rol code permite definir un fragmento de código, es decir, es el equivalente a la etiqueta HTML <code>.

La especificación indica que los productos de apoyo deberían asegurar la lectura completa de la puntuación dentro de un contenido marcado con code. De este modo se garantiza su comprensión.

Consulta el rol "code" en ARIA 1.2.

Nuevo rol "time"

El nuevo rol time permite definir un punto específico en el tiempo.

Todavía no tiene una propiedad equivalente al atributo datetime de la etiqueta HTML equivalente, <time>, pero se prevé incluirla en la versión ARIA 1.3. Por ahora marcaría una cadena válida con la fecha o la hora.

Consulta el rol "time" en ARIA 1.2.

Nuevos roles "subscript" y "superscript"

Con el nuevo rol subscript podemos marcar un subíndice, es decir, es el equivalente a la etiqueta HTML <sub>.

Con el nuevo rol superscript podemos marcar un superíndice, es decir, el equivalente a la etiqueta HTML <sup>.

No deben usarse para aspectos de presentación, sino cuando se usan para marcar convenciones tipográficas que tienen significados específicos.

Por ejemplo, en 10³, el significado cambia si el "3" está o no marcado como superíndice.

Consulta el rol "subscript" en ARIA 1.2.

Consulta el rol "superscript" en ARIA 1.2.

Nuevos roles "insertion" y "deletion"

Con el nuevo rol insertion definimos un contenido agregado, o que se sugiere agregar, es decir, es el equivalente a la etiqueta HTML <ins>.

Por el contrario, con deletion definimos un contenido eliminado, o que se sugiere eliminar, es decir, es el equivalente a la etiqueta HTML <del>.

Es habitual utilizarlos para marcar las diferencias entre dos versiones de un contenido, o para marcar sugerencias en la revisión de un documento.

Consulta el rol "insertion" en ARIA 1.2.

Consulta el rol "deletion" en ARIA 1.2.

Nuevos roles "strong" y "emphasis"

Con el nuevo rol strong definimos un contenido importante, serio o urgente, es decir, es el equivalente a la etiqueta HTML <strong>. Igual que la etiqueta HTML, este rol no debe usarse para cambios en la presentación del contenido, sino solo si su ausencia cambiaría el significado.

Por su parte, el nuevo rol emphasis permite transmitir énfasis y es el equivalente a la etiqueta HTML<em>. Tampoco debe usarse para comunicar cambios en la presentación que no impacten en el significado.

Recuerda que no es lo mismo transmitir importancia que énfasis: "Voy a nadar todos los días."

Consulta el rol "strong" en ARIA 1.2.

Consulta el rol "emphasis" en ARIA 1.2.

Nuevo role "blockquote"

Con el nuevo rol blockquote definimos una sección de contenido que es una cita, es decir, es el equivalente a la etiqueta HTML <blockquote>.

Consulta el rol "blockquote" en ARIA 1.2.

Nuevo role "paragraph"

Con el nuevo rol paragraph definimos un párrafo, es decir, es el equivalente a la etiqueta HTML <p>.

Consulta el rol "paragraph" en ARIA 1.2.

Nuevo rol "meter"

El nuevo rol meter permite definir un elemento que representa una medida escalar dentro de un rango conocido o fraccionado, es decir, es el equivalente a la etiqueta HTML <meter>.

No se debe utilizar para indicar progreso, porque para ello ya está el rol progressbar.

Consulta el rol "meter" en ARIA 1.2.

Nuevo rol "generic"

Este nuevo rol permite definir un elemento contenedor que no tiene significado semántico, como son en HTML las etiquetas <div> o <span>.

Debe ser un contenedor sin nombre, está prohibido que tenga nombre.

No lo uses en el contenido: no está pensado para ser usado en el contenido, sino por los agentes de usuario. Los autores deben usar role="presentation" o role="none" para eliminar la semántica implícita en un elemento.

Consulta el nuevo rol "generic" en ARIA 1.2.

Roles eliminados

Se eliminan los roles:

directory, definía una lista de referencias a miembros de un grupo, como una tabla de contenido estática. Se recomienda que en su lugar se use el rol list.

Nueva implementación de un "combobox"

La guía para implementar un combobox ha cambiado significativamente en ARIA 1.2 debido a los problemas con la implementación de los patrones anteriores.

En ARIA 1.1 el combobox tenía tres partes primarias: un input, que estaba dentro de un contenedor combobox, y una lista con el rol listbox:


<div aria-label="Tag" role="combobox" aria-expanded="true" 
     aria-owns="owned_listbox" aria-haspopup="listbox">
     
    <input type="text" aria-autocomplete="list" 
    aria-controls="owned_listbox"
    aria-activedescendant="selected_option">
</div>
<ul role="listbox" id="owned_listbox">
    <li role="option">Zebra</li>
    <li role="option" id="selected_option">Zoom</li>
</ul>

Implementación en WAI-ARIA 1.1

Esta implementación tenía diferentes debilidades. Por ejemplo, hay tres elementos que se pueden nombrar, cuando en pantalla solo hay un elemento que necesita un nombre accesible. La especificación dice que se dé nombre solo al contenedor, pero entonces se incumplen las WCAG porque hay un input sin nombre. Por ello, los autores nombran las tres partes, creando problemas de verbosidad en la escucha con el lector.

Este es solo un ejemplo de los problemas de esta implementación. Se listan todos en Resolving ARIA 1.1 Combobox Issues, W3C.

En ARIA 1.2 la implementación que se propone es:


<label for="tag_combo">Tag</label>

<input type="text" id="tag_combo"
      role="combobox" aria-autocomplete="list"
      aria-haspopup="listbox" aria-expanded="true"
      aria-controls="popup_listbox"
      aria-activedescendant="selected_option">

<ul role="listbox" id="popup_listbox">
   <li role="option">Zebra</li>
   <li role="option" id="selected_option">Zoom</li>
</ul>

Implementación en WAI-ARIA 1.2

Ahora el combobox tiene solo una parte, el input, y luego el listado asociado. Es una implementación análoga a la habitual para un botón de menú.

Se puede consultar el ejemplo operativo de la implementación de combobox en ARIA 1.2 en Combobox With List Autocomplete Example.

Consulta el rol "combobox" en ARIA 1.2.

Grupos en los roles "listbox" y "list"

Con el rol listbox marcamos un componente que permite seleccionar al usuario uno o más elementos de una lista de opciones. Los elementos de la lista son estáticos y, a diferencia de una select de HTML, la lista de opciones puede tener imágenes.

En ARIA 1.2, un listbox puede contener roles de tipo option, como hasta ahora, pero, como novedad, también puede incluir ya roles de tipo group.

Además, en el rol listbox ya no se admite el atributo aria-haspopup.

Por el contrario, en el rol list se quita la opción de que haya grupos y ahora solo admite el hijo listitem, ya no admite el hijo group.

Consulta el rol "listbox" en ARIA 1.2.

Consulta el rol "list" en ARIA 1.2.

Cambios en el estado "aria-expanded"

En ARIA 1.2 el rol menuitem ya soporta el atributo aria-expanded, y por herencia, puede ser soportado en los roles menuitemcheckbox y menuitemradio.

También se admite en el rol checkbox.

Sin embargo, se elimina el soporte del atributo aria-expanded en los siguientes roles:

alert, alertdialog, article, banner, blockquote, caption, cell, complementary, contentinfo, definition, deletion, dialog, directory, feed, figure, form, grid, group, heading, img, insertion, landmark, list, listitem, log, main, marquee, math, menu, menubar, navigation, note, paragraph, radiogroup, region, search, select, status, subscript, superscript, table, tabpanel, term, time, timer, toolbar, tooltip, tree, treegrid.

Consulta el estado "aria-expanded" en ARIA 1.2.

Cambios en el rol "spinbutton"

Con el rol spinbutton definimos un botón giratorio que normalmente permite cambiar el valor que se muestra mediante unos botones. Algunas implementaciones tienen el valor en un campo de texto que se puede editar.

spinbutton. botones giratorios para seleccionar una fecha

Ejemplo spinbutton de ARIA Authoring Practices Guide

En la versión ARIA 1.1, se incluían los atributos aria-valuemax, aria-valuemin y aria-valuenow como obligatorios, y aria-valuetext como heredado. En la versión 1.2 los cuatro están en el apartado de estados y propiedades soportados.

Consulta el rol "spinbutton" en ARIA 1.2.

Cambios en el atributo "aria-level" de los roles "tablist" y "grid"

El rol tablist nos permite definir, en una implementación mediante pestañas, la zona que contiene las pestañas.

En ARIA 1.1 el rol tablist admitía la propiedad aria-level en el caso de que hubiera tablist anidadas. En la nueva versión ARIA 1.2 tablist ya no se admite este atributo.

También se elimina la propiedad aria-level del rol grid, rol que permite definir una tabla cuyas celdas pueden coger el foco.

Es una manera de decir que no anides pestañas ni tablas.

Consulta el rol "tablist" en ARIA 1.2.

Consulta el rol "grid" en ARIA 1.2.

Cambios en el rol "rowgroup"

El rol rowgroup permite definir una agrupación de elementos row.

Los estados y propiedades aria-disabled, aria-errormessage, aria-haspopup y aria-invalid están obsoletos en el rol rowgroup de ARIA 1.2.

Hay que tener en cuenta que estas cuatro propiedades ya no se admiten como globales, sino que en ARIA 1.2 se especifica en concreto qué roles las admiten.

Consulta el rol "rowgroup" en ARIA 1.2.

Cambios en los roles "menuitemcheckbox" y "menuitemradio"

En la definición de estos roles en ARIA 1.2 están obsoletos los estados y propiedades: aria-errormessage y aria-invalid.

Por otra parte, se elimina que el valor implícito por defecto de su atributo aria-checked sea "false".

Consulta el rol "menuitemcheckbox" en ARIA 1.2.

Consulta el rol "menuitemradio" en ARIA 1.2.

Cambios en el rol "checkbox"

En el rol checkbox se admite el atributo aria-expanded, pero se elimina que el valor implícito por defecto de su estado aria-checked sea "false".

Consulta el rol "checkbox" en ARIA 1.2.

Cambios en el rol "progressbar"

El rol progressbar permite definir una barra de progreso. En ARIA 1.2 se establece que los valores por defecto para aria-valuemin y aria-valuemax son 0 y 100, respectivamente.

Además, se indica que en este rol están obsoletos los estados y propiedades: aria-disabled, aria-errormessage, aria-haspopup y aria-invalid.

Consulta el rol "progressbar" en ARIA 1.2.

Otros cambios

Otros cambios del WAI-ARIA 1.2 respecto a WAI-ARIA 1.1 son:

Se quita la obligación de que los roles log y timer tengan un nombre accesible.
Se hace hincapié entre la diferencia de los roles alert y alertdialog.
En el rol form se obliga a que tenga un nombre accesible.
En el rol gridcell se elimina la obligatoriedad de que tenga un nombre accesible.
Los atributos aria-valuemin y aria-valuemax pasan a ser soportados, en vez de obligatorios, en los roles separator, slider, y scrollbar.
El atributo aria-orientation pasa a ser soportado, en vez de obligatorio, en el role scrollbar.
En el rol switch se elimina que el valor implícito por defecto de su estado aria-checked sea "false".
Se especifica que un elemento con el atributo aria-errormessage (que relaciona un campo de formulario con su mensaje de error) no puede tener el atributo aria-invalid="false".

Ocultar contenido visualmente y/o para el lector de pantalla (tabla resumen)

Ejemplos de diferentes maneras de ocultar el contenido con etiquetas y atributos HTML y sus consecuencias. Se pueden consultar en la tabla de este artículo.

En HTML/CSS existen muchas técnicas para ocultar contenido, pero no todas tienen las mismas consecuencias. Este artículo muestra un cuadro resumen que sirve de consulta rápida sobre las consecuencias de usar una u otra técnica para ocultar el contenido.

Las posibles consecuencias de las técnicas para ocultar el contenido son tres:

Oculto visualmente- Disponible para el lector de pantalla: unas técnicas ocultan el contenido visualmente, pero este contenido sigue estando disponible para los productos de apoyo. Por ejemplo, es útil para incluir alguna información destinada a clarificar el acceso para los usuarios de lector de pantalla o línea braille (productos de apoyo utilizados fundamentalmente por las personas invidentes). Podría servir para ocultar un texto explicativo en los enlaces: Leer más <span class="ocultovisual">sobre el artículo "Accesibilidad y HTML5"</span>).
Oculto visualmente - Oculto para el lector de pantalla: otras técnicas ocultan el contenido visualmente pero también para el lector, por ejemplo, es útil para ocultar un menú plegado.
Visible - Oculto para el lector de pantalla: en otros casos, la técnica permite que el contenido se vea pero el lector de pantalla lo ignore y no lo anuncie, por ejemplo, es útil para evitar contenido redundante y repetitivo al usuario de lector de pantalla.

Tabla resumen de las consecuencias de ocultar el contenido con diferentes técnicas

En cada fila de la siguiente tabla se incluye una técnica para ocultar el contenido, indicando si oculta visualmente el contenido y si el lector de pantalla lo anuncia. La respuesta puede ser: Sí (visto verde); No (cruz roja); o una Advertencia (exclamación naranja) que se explicará en una nota.

Consecuencias de ocultar contenido con diferentes técnicas
Técnica para ocultar contenido	Tipo de técnica	¿El lector anuncia el contenido?
`display:none` (1)	CSS
`visibility:hidden` (1)	CSS
`height:0` (2)	CSS
`aria-hidden=true (3)`	atributo ARIA
`hidden (3)`	atributo HTML5
`role=presentation / role=none` (4)	rol ARIA	Si es una imagen: Cualquier otro contenido lo lee como texto plano (5):
`text-indent:-999em`	CSS
`clip: rect (...)`	CSS
`opacity:0`	CSS
`transform: scale (0)`	CSS

Si necesitáis saber las consecuencias de ocultar el contenido con otra técnica, dejadme un comentario y lo añadiré a la tabla.

Notas de interés sobre el cuadro resumen

(1) display:none oculta el elemento y sus descendientes no solo visualmente, sino también para los lectores de pantalla. Aunque es el comportamiento habitual, no es cierto para todos los lectores de pantalla, en todos los casos y con todos los navegadores. Por su parte, el contenido con el estilo visibility:hidden no se anuncia en muchos contextos, pero la aplicación de esta técnica en determinadas etiquetas y con cierta combinación de navegadores y lectores de pantalla, provoca que el lector sí anuncie el contenido. Como el lector de pantalla no interpreta igual ambas técnicas, se pueden usar combinadas para mayor soporte.

Artículos de interés:

“JAWS, Window-Eyes and display:none: Return to 2007” de Jason Kiss, 2011
“Do not use display:none to visually hide content intended for screen readers”, de Roger Johansson, 2011.
Empty Links and Screen Readers

(2) Esta técnica se aplicaría por ejemplo así: .element-invisible { height: 0; overflow: hidden; position: absolute;}. Los lectores de pantalla NVDA y Jaws leerán el contenido, pero Voice Over (en dispositivos Apple) no lo lee. Por tanto, es mejor usar otras técnicas con un soporte más homogéneo, por ejemplo, text-indent:-999em si lo que se quiere es ocultar contenido visualmente pero no para el lector de pantalla.

Artículo de interés:

"Using CSS clip as an Accessible Method of Hiding Content" de Jeff Burnz.

(3) Artículo de interés: Screen reader support for hidden content

(4) WAI-ARIA 1.1 añade un nuevo role=none que es sinónimo de role=presentation y al que espera sustituir cuando esté ampliamente soportado. Mientras esto no ocurra es preferible seguir usando role=presentation. Artículo relacionado: Novedades WAI-ARIA 1.1).

(5) La consecuencia de aplicar role=presentation es diferente según el elemento al que se aplica. En una imagen (<img role=presentation ...>) el lector ignorará la imagen y no la anunciará. En cualquier otro elemento, lo leerá solo como texto, ignorando la información semántica. Por ejemplo, <h1 role="presentation">Ventas</h1> será anunciado como "Ventas", en vez de como "Ventas encabezado de nivel 1". Este rol es muy útil para aplicarlo a las tablas de presentación.

Reseña del libro "Designing with progressive enhancement"

Portada del libro 'Designing with progressive enhancement. Building the web that works for everyone.' de Todd Parker

Autores: Todd Parker, Patty Toland, Scott Jehl, Maggie Costello Wachs

Nº páginas: 428

Idioma: inglés

Formato: digital e impreso

Fecha de publicación: 2010

Web: Ficha en Filament Group

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

Recomiendo este libro a cualquier desarrollador front-end, de hecho les animaría a todos a que lo leyeran. El libro tiene 10 años, pero sigue plenamente vigente.

Es una guía práctica que enseña a implementar páginas con una gran interactividad, de manera que el mismo código funciona correctamente en cualquier navegador antiguo o moderno, sea cual sea la configuración del usuario, e independientemente de su contexto de acceso o los productos de apoyo que utilice.

Para lograrlo, el libro enseña a desarrollar mediante el enfoque de "progressive enhancemente" (mejora progresiva) que supone dejar atrás malos hábitos y adoptar una perspectiva diferente de diseño y desarrollo.

Hay muchos contextos de acceso en los que nos vamos a beneficiar de una implementación que siga un enfoque de mejora progresiva:

acceso con un dispositivo o un navegador antiguo, a veces impuesto por la empresa;
acceso con dispositivos o navegadores actuales pero con capacidades limitadas, como el navegador de Kindle;
situacionales, por ejemplo, si desactivamos ciertas capacidades por:
- seguridad: plugins, JS...
- por conectividad: imágenes, vídeos...;
si hay un problema en la conexión o en el servidor que provoque que se cargue la página sin ficheros CSS, JS, etc.
personas con menor experiencia tecnológica, por ejemplo, si se requiere la instalación o actualización manual de plugins (Flash, Silverlight, Sun Java...), que además pueden no ser compatibles con todas las plataformas o navegadores;
las personas que acceden con productos de apoyo también se van a beneficiar de que las páginas se implementen con el enfoque que voy a resumir.

La metodología es sencilla y la explican con mucho detalle. Uno de los puntos fuertes del libro es que incluye numerosos ejemplos de maquetación y programación, paso a paso, de diferentes widgets.

Partimos de un código HTML correcto y semántico, formado por elementos estáticos estándar y controles de formulario, al que aplicamos una CSS de estilos básicos que trabajan correctamente en todos los navegadores. Esto nos proporciona una página completamente funcional, usable y accesible desde el principio, que funciona en cualquier dispositivo, navegador o contexto de acceso.

Una vez que tenemos la experiencia básica, la página llama al framework EnhancedJS, un JS gratuito que testea las capacidades del navegador. Si pasa todos los test, se cargan los ficheros CSS y JS que añaden una capa de diseño e interacción que mejoran la experiencia para los navegadores que la soportan, haciéndola más rica e interactiva.

Esta capa de mejora se implementa de manera que sea accesible por teclado y accesible con un lector de pantalla. Además, EnhancedJS incluye un enlace en la página para que el usuario pueda intercambiar de forma manual entre la versión básica y la versión avanzada.

Hay una serie de aspectos claves que subyacen a este enfoque, entre los que destacaría:

la separación entre el contenido, la presentación y el comportamiento;
el uso de JavaScript no intrusivo;
la maquetación HTML semántica;
el uso de WAI-ARIA.

No hay que confundir la "mejora progresiva" con la "degradación elegante" (graceful degradation).

Un ejemplo de degradación elegante sería el uso de la etiqueta <noscript>. En este enfoque se implementa la solución teniendo en cuenta a los usuarios con los dispositivos y navegadores más modernos, y luego se da una solución alternativa a los usuarios con navegadores más antiguos.

Por el contrario, en la mejora progresiva, siempre más recomendable, no sería necesario el uso de una etiqueta <noscript>, porque tendremos una página que trabaja sin JS y sin CSS, que es soportada por todos los navegadores y dispositivos, pero que ofrece una experiencia avanzada y accesible para los dispositivos y navegadores que la soportan.

Árbol desplegable con iconos de carpetas. La versión sencilla es una lista anidada desplegada.

Mejora progresiva. Ejemplo de un árbol desplegable en la versión mejorada y en la versión básica.

El libro de divide en dos partes:

En la primera parte repasa la metodología, esta manera diferente de pensar la planificación de los diseños. Tiene capítulos específicos sobre las buenas prácticas para implementar HTML semántico; aplicar CSS de forma adecuada; añadir JavaScript no intrusivo; y usar el framework EnhancedJS, que testea la capacidad del navegador antes de aplicar la capa avanzada de mejoras.
En la segunda parte hay doce capítulos, cada uno tiene el ejemplo de la implementación de un widget diferente mediante mejora progresiva.

Primera parte. Mejora Progresiva

Capítulo 1. Nuestro enfoque

En este capítulo explican el enfoque de mejora progresiva, tal y como lo he resumido previamente.

Como he indicado, se tienen dos experiencias, pero una única página y un único código. Hay una experiencia básica que funciona universalmente en todos los dispositivos, y una mejorada que se entrega a los navegadores con más funciones.

Las claves son:

Todos los componentes están basados en HTML semántico y bien estructurado, de tal manera que la funcionalidad para una experiencia básica está disponible sin CSS y sin JS. Sobre esta experiencia básica se construye lo demás.
Habrá una estricta separación entre contenido, presentación y comportamiento.
Se testea las capacidades CSS y JS del navegador antes de aplicar las mejoras o mantener la experiencia básica.
En los navegadores que admiten la experiencia mejorada, se añadirá la capa no intrusiva de estilos y comportamiento, que será accesible por teclado y por los lectores de pantalla.

Introducen el concepto "the x-ray perpective" que desarrollan en el siguiente capítulo y que hace referencia a cómo analizar el diseño de una interfaz compleja, por ejemplo, una aplicación web para organizar fotos.

La "perspectiva de rayos X" toma el diseño de una interfaz web compleja y lo descompone en sus diferentes partes, para encontrar el elemento HTML nativo adecuado para la experiencia básica. Por ejemplo, en un árbol desplegable, sería una lista UL anidada.

Consiste por tanto en pensar de forma creativa cómo deconstruir esos widget e interacciones en elementos HTML nativos estándar que puedan hacer la misma tarea. Mapear el HTML semántico que soportará la experiencia con la funcionalidad básica, y planear cómo se desarrollará la capa avanzada, con CSS y JS, para crear la experiencia mejorada, accesible además en el acceso por teclado y con el lector de pantalla.

Capítulo 2. X-ray perspective

Este capítulo incluye diversos ejemplos de la "perspectiva de rayos X", es decir, de la descomposición de una interfaz con una interacción y un diseño complejo, en componentes básicos y estándares de HTML a partir de los cuales poder construir la experiencia mejorada.

Partimos de la base de que hasta el diseño dinámico más complejo se puede descomponer en contenidos y funcionalidades esenciales expresados en elementos de HTML simples y semánticos, que proporcionarán una experiencia usable y accesible para todos los visitantes. Es un ejercicio muy divertido y creativo que todos deberían probar.

Si queremos tener, por ejemplo, una aplicación web para organizar fotos, pensamos en su versión más avanzada y seguimos un proceso que explican a lo largo del capítulo:

Definimos la jerarquía y la prioridad del contenido.
Mapeamos los componentes en sus equivalentes en HTML básico y semántico.
Construimos el marcado base que proporciona todo el contenido y toda la funcionalidad esencial, con una CSS básica y sin JS.
Escribimos la capa de mejora visual y funcional con CSS y JS en los navegadores que la soporten.

Una vez hecho esto, pasamos la siguiente checklist de verificaciones:

¿La experiencia básica es totalmente funcional y usable solo con HTML?
¿El marcado de base codifica toda la información, incluido el diseño y la estructura, que necesita la experiencia mejorada?
¿Tanto en la experiencia básica como en la experiencia avanzada, la pagina se lee y trabaja en un orden lógico y promueve el contenido y la funcionalidad más importante?
¿Son todas las páginas navegables y todos los elementos de formulario accesibles usando solo el teclado?
¿Las paginas tienen sentido al navegar con el lector de pantalla? ¿puede el usuario navegar por la estructura de encabezados?
¿Hay un opción clara para todos los usuarios (incluidos dispositivos móviles y lector de pantalla) para cambiar entre la experiencia básica y la experiencia avanzada? Por ejemplo, podemos querer acceder a la versión básica en función de la conexión, las preferencias o si por alguna razón la versión mejorada falla?

Capítulo 3. Escribir código HTML semántico

Este capítulo es un repaso de cómo implementar correctamente HTML de forma semántica. Trata los encabezados, párrafos y listas; el uso de BR y el abuso de DIV y SPAN; las citas, el texto enfatizado y las abreviaturas; las tablas, las imágenes y los elementos interactivos (enlaces y formularios); las zonas semánticas de la página (cabecera, pie, zonas de navegación...); o el contenido del head.

Por último, hace una enumeración básica de los requisitos de accesibilidad de las WCAG relacionados.

Capítulo 4. Aplicar estilos de forma efectiva

Se revisan las buenas prácticas relativas a las técnicas que comúnmente se emplean para aplicar CSS en el enfoque de mejora progresiva:

la importancia de usar ficheros CSS y en el menor número posible, salvo excepciones muy concretas en que sí puede ser mejor usar el atributo style;
los inconvencientes de usar @import;
los diferentes tipos de CSS;
las recomendaciones para usar convenciones en el nombre de las CSS;
sobre los comentarios condicionales;
etc.

Como ya he explicado previamente, habrá una CSS básica con estilos "seguros" (basic.css) y una CSS avanzada (enhacenced.css), por lo que hay que decidir qué estilos son básicos y cualés avanzados para saber en cuál de estas CSS incluirlos.

Por ejemplo, serán seguros para todos los navegadores los estilos que hacen referencia a la fuente o al estilo del texto; pero los relacionados con la posición, las cajas flotantes, las dimensiones o los márgenes, deberían estar en la CSS avanzada.

Una ventaja añadida de tener una CSS básica es que nos sirve también como CSS de impresión, simplemente habrá que tener cuidado en ocultar los bloques que no se deben imprimir, como la navegación.

También incluyen consideraciones de accesibilidad:

la definición de la fuente en medidas relativas;
el contraste de color;
evitar la información que se transmite solo por el color;
la necesidad de subrayar los enlaces dentro del texto;
definir los colores de fondo bajo las imágenes de fondo;
no ocultar el foco;
el ancho de columna recomendado; u
ocultar correctamente el contenido.

Por último, repasa diversos trucos para dudas habituales relacionadas con los elementos flotantes o los bugs en IE, como los relacionados con el z-index o el hasLayout.

Capítulo 5. Mejorar la experiencia y la interactividad con scripts

Este capítulo de centra en cómo aplicar JS no intrusivo para extender la funcionalidad de las páginas:

Aplicar el código JS al HTML de manera correcta: dónde y cuándo cargar los scripts.
La inclusión del JS EnhancedJS para testear las capacidades del navegador y cargar los JS y CSS para la experiencia mejorada.
Cómo construir el marcado mejorado y añadir la interactividad a los controles por JS no intrusivo. Por ejemplo, aprovechando el texto existente en el HTML de base; controlando correctamente la ocultación de contenido con la técnica adecuada para cada caso; etc.
La importancia de conservar y mejorar la usabilidad y accesibilidad, asegurando el acceso por teclado y el acceso mediante lector de pantalla, para lo cual será imprescindible el correcto uso del atributo tabindex y el estándar WAI-ARIA (artículo relacionado WAI-ARIA).

Capítulo 6. Testear la capacidad del navegador

El framework javascript EnhancedJS testea las capacidad CSS y JS del navegador. Si pasa todos los test y, por tanto, soporta todas las características, se cargan las CSS y JS de la capa mejorada; de lo contrario, se mantiene la experiencia básica que es totalmente funcional.

No solo testea si se soportan ciertos elementos, sino si los soporta correctamente, en especial en aspectos como el modelos de cajas y sus dimensiones o posiciones. Por ejemplo, dada una caja con unas dimensiones (ancho, márgenes, padding, …) compara su ancho final con la suma de sus dimensiones.

Cuando el test pasa:

Asigna la clase "enhanced" a los elementos HTML. De este modo, por ejemplo, en la CSS avanzada defines el estilo de HMTL.enhanced {} y en la CSS básica el estilo de HTML {}.
Se incluyen las CSS y JS especificados para la experiencia mejorada.
Graba el resultado en una cookie para prevenir al framework del resultado del test en cada pagina, así primero busca si existe la cookie.
Añade un enlace en la página para que el usuario pueda intercambiar de forma manual entre ambas versiones. Tiene opciones de personalización y se puede deshabilitar.

También se puede forzar a pasar o fallar el test; a borrar la cookie y refrescar la pagina; o hacer que el valor de la cookie sea "pasa" o "falla" y refrescar.

Para incluir el framework:

Se añade la llamada a la función "enhance()" en cada página. Acepta diferente parámetros, como el listado de JS y CSS que quieres añadir en la versión mejorada. Si el navegador no soporta JavaScript o no lo tiene activado, se ignora la función y se carga la versión básica. Los autores indican también un método para que no haya un flash de la pagina sin estilos mientras se carga la versión avanzada.
La inclusión del fichero "enhance.js" que realiza todos los test, que pueden ser editados y extendidos fácilmente.

Hay otras librerías que podrían ser complementarias a esta, como modernizr.

Segunda parte. Mejora Progresiva en acción

Esta segunda parte incluye los ejemplos sobre cómo construir diferentes widget desde cero, paso a paso, mediante mejora progresiva.

Cada capítulo es un ejemplo diferente, pero todos tienen la misma estructura:

Se parte del resultado final, la versión mejorada interactiva a la que se quiere llegar, revisándolo desde la perspectiva de rayos x (x-ray perspective).
Se mapea para descomponer sus piezas funcionales en elementos HTML estándar.
Se escribe el marcado base.
Se aplican estilo "seguros" en una CSS básica.
Se crea la capa de mejora con CSS avanzadas y ficheros JS.
Se asegura la accesibilidad por teclado y con el lector de pantalla.

Todos los ejemplos están disponibles en la web del libro:

Acordeón
Pestañas
- pestañas que mantienen funcional el botón atrás del navegador
- pestañas que rotan solas
Tooltips. Tengo que decir que no estoy de acuerdo con esta solución. En la versión básica, la ayuda de las etiquetas de los campos de texto, que en la versión avanzada se incluye con tooltips, se sustituye por el atributo title, que no es accesible con teclado.
Árbol
Gráfica con html5 canvas
Ventanas de diálogo
Botones
- versión con iconos
Votaciones con estrellas
Slider
Menu desplegable (I) y Menu desplegable (II)
Crear elementos en una lista

Podéis pulsar el enlace "View high-bandwidth version" / "View low-bandwidth version" que hay al final de cada página de ejemplo para ver la versión avanzada o básica.

Para evitar que la página se vea sin estilos mientras se testea el navegador y se carga la versión avanzada, propone:

html.enhanced body {visibility: hidden}

y una vez cargada

html.enhanced body {visibility: visible}

Todos los ejemplos en:

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

Portada del informe de accesibilidad del sitio www.usableyaccesible.com con el validador del Observatorio de accesibilidad de acuerdo a la EN 301 549:2019

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.

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.

Página del Rastreador OAW corriendo en una máquina virtual que tiene instalada Tomcat y MySQL.

Cómo utilizar el validador

Destinatario

Campo de texto Destinatario: correo electrónico

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

Opción seleccionada 'Tipo de análisis: Sitio web'. Los campos asociados son: campo de texto 'URL del portal o página a analizar'; y el desplegable 'Cantidad de páginas' con las opciones: Única; Complejidad baja: 17 páginas; Complejidad media: 33 páginas; Complejidad alta: 51 páginas

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.

Opción seleccionada 'Tipo de análisis: Conjunto de URLs'. El campo asociado es una textarea donde se incluye una URL en cada línea, con un máximo de 51 URLs

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.

Opción seleccionada 'Tipo de análisis: Código fuente'. El campo asociado es una campo de tipo fichero para subir la página. El tamaño máximo es 4 MB.

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.

Selección de tipo de informe: a) comprobaciones 2.3 (beta) respecto a la UNE 139803:2012; b) (por defecto) conforme a la UNE-EN301549:2019; c) UNE2012 (versión 2). Otras opciones: comprobar enlaces rotos.

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 PDF del Rastreador OAW. El validador de accesibilidad de Adobe reporta gran cantidad de errores en diversos criterios.

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.

Gráfica distribución de páginas según nivel de adecuación. Bajo la gráfica una tabla con el nivel de adecuación estimado (A, AA, no válido), el número de páginas y el porcentaje de páginas.

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.

Tabla con el listado de todas las páginas analizadas. En cada columna el resultado por cada indicador analizado.

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.

Captura de un error en el indicador 1.10 Formularios y estructura. Se describe el problema y se indica la línea y el código en el que se ha detectado el 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.

Descripción de las tablas en HTML5. Alternativa a "summary"

Tabla precedida de un párrafo con una descripción. El párrafo y la tabla están asociados por código con el atributo aria-describedby. El párrafo con la descripción está oculto para el lector con aria-hidden= true para evitar redundancias. La tabla tiene un título (caption) sobre la tabla.

Resumen:

Las tablas que se incluyen en una página web deben cumplir ciertos requisitos de accesibilidad. Uno de estos requisitos es que la tabla tenga una descripción. La descripción se incluía con el atributo summary del elemento <table>. Sin embargo, el atributo summary está obsoleto en HTML5.

Las WCAG 2.1 solo indican al respecto:

En HTML5, el atributo "summary" está obsoleto. Los productos de apoyo pueden o no continuar admitiendo el atributo. Los autores deben considerar alternativas y solo usarlo con precaución.

H73: Using the summary attribute of the table element to give an overview of data tables

Este artículo explica cuál puede ser esta alternativa, tratando los siguientes temas:

cómo se incluye la descripción de la tabla en HTML5;
si es obligatorio que el párrafo con la descripción esté antes de la tabla;
por qué es importante que las tablas tengan descripción;
la diferencia entre la descripción y el caption;
cómo lee el lector de pantalla la descripción y el caption;
cómo redactar descripciones útiles, con ejemplos;
cómo incluir la descripción de las tablas a través del gestor de contenidos;
qué dicen las WCAG 2.1 sobre la descripción de las tablas

Cómo se incluye la descripción de la tabla en HTML5

La descripción de una tabla se incluía en HTML con el atributo summary:

En HTML4 y (X)HTML:

<table summary="[Descripción de la tabla]">

Sin embargo, el atributo summary está obsoleto en HTML5.

En los desarrollos en HTML5, la descripción se incluye en la página y se relaciona por código con la tabla mediante el atributo aria-describedby:

En HTML5:

<p id="table1">[Descripción de la tabla]</p>

<table aria-describedby="table1">

¿Es obligatorio que el párrafo con la descripción esté antes de la tabla?

La descripción asociada por código con la tabla podría estar en cualquier parte de la página, o incluso oculta visualmente (por ejemplo, con text-indent:-999em), y el lector de pantalla la leería igual.

Sin embargo, yo os recomiendo que el párrafo con la descripción de la tabla esté visible y antes de la tabla por varias razones:

Una descripción redactada de forma adecuada ayuda a que muchos usuarios comprendan mejor la información que se ofrece en la tabla, especialmente ayuda a las personas que tienen más dificultades para comprender la página y los datos dispuestos en tablas.
Como la descripción también es de utilidad para las personas que pueden ver la tabla, el lugar más lógico y útil para quien puede verla es antes de la tabla.
Si la descripción se incluye visible antes de la tabla, es más probable que el publicador redacte una descripción para la tabla y lo haga de manera adecuada, además, seguramente así será más sencillo de implementar con el gestor de contenidos.
Si la tabla se incluye en un portal de la Administración Pública, evitarás un posible error en el validador automático del Observatorio de Accesibilidad que revisa estos portales.
El validador del Observatorio de Accesibilidad da error si encuentra un encabezado (h1, h2, h3...) seguido inmediatamente de una tabla, pues presupone que dicho encabezado está simulando el caption de la tabla.

Por tanto, incluir la descripción de la tabla antes de la misma evitará este error y, lo que es más importante, ayudará a comprender al publicador que el encabezado (h2, h3...) debe ser el de la sección, mientras que el título de la tabla, en caso de necesitarlo, debe incluirse con el elemento caption.

Por qué es importante que las tablas tengan descripción

Cuando una persona que puede ver se enfrenta a una tabla, de un solo vistazo obtiene mucha información:

ve la estructura de la tabla;
dónde están los encabezados y cuántos niveles tiene;
si hay celdas unidas o vacías;
si hay filas o columnas con enlaces o con totales;
etc.

Sin embargo, una persona que no puede ver y accede con un lector de pantalla, no tiene esa visión general de la tabla que le ayude a hacerse una imagen mental de la misma, y a recorrerla después más rápidamente con los atajos de teclado del lector de pantalla.

La descripción de la tabla proporciona a los usuarios de lector de pantalla la información que obtienen las personas que pueden ver en un primer vistazo de la tabla.

Por ejemplo, si el usuario sabe que en la última columna o fila están los totales, puede utilizar los atajos de teclado del lector para saltar más rápidamente a estos contenidos.

Por último, ya he comentado que una descripción concisa y bien redactada también es útil para que todas las personas comprendan mejor la tabla.

No es lo mismo la descripción de la tabla que su `caption`

El objetivo del título de la tabla (el caption) y el objetivo de su descripción es diferente.

El título (`caption`)

El título de la tabla se incluye con la etiqueta caption justo después de la etiqueta table, mientras que, como hemos comentado, la descripción se incluye en un párrafo antes de la tabla, asociado a la misma con el atributo aria-describedby.

<p id="tabla1">
   [Descripción de la tabla]
</p>
<table aria-describedby="tabla1">
<caption>[Título de la tabla]
</caption>

El caption de la tabla identifica la tabla para que sepamos qué información contiene.

Por ejemplo:

<caption>Tabla 1. Comparativa de las ventas en los años 2018, 2019 y 2020</caption>
<caption>Tabla 2. Indicadores sociodemográficos de 2019</caption>
<caption>Tabla 3. Recursos y actividades de innovación social por distritos</caption>

El caption es muy útil para los usuarios:

Permite ojear más fácilmente el contenido de la página, ya que de un solo vistazo identificas qué datos tienen las tablas, sin tener que investigarlo leyendo el título de la sección y el contenido que precede a cada tabla.
Los usuarios de lector de pantalla también pueden ojear las tablas de la página más eficazmente, pues, como luego comentaré, al pulsar la tecla "t" saltan de tabla en tabla, y el lector las anuncia con su caption en primer lugar (si tienen caption).
Otra ventaja, es que el título de una tabla ayuda a referenciarla en el contenido de la página (por ejemplo, "como se aprecia en la 'Tabla 2. Indicadores sociodemográficos de 2019'") o a incluir un índice de tablas.

En los casos en los que hay varias tablas, resulta muy útil que el título comience por "Tabla 1.", "Tabla 2.", "Tabla 3.", porque de este modo es más fácil encontrar la tabla referenciada, tanto al ojear visualmente la página, como al hacerlo con el atajo de teclado del lector de pantalla (tecla "t").

La descripción de la tabla

Mientras que el objetivo del caption es identificar la tabla, hemos comentado que el objetivo de la descripción es, en gran medida, suplir ese primer vistazo de la tabla que tienen las personas que pueden verla.

Por tanto, la descripción debe resumir aspectos estructurales de la tabla que permitan hacerse una visión mental de la misma y encontrar más fácilmente la información dentro de ella, sin necesidad de recorrerla celda a celda.

Hay que tener en cuenta que los lectores de pantalla tienen atajos de teclado que facilitan moverse por la tabla. Por tanto, una vez que conoces la estructura de la tabla, es mucho más fácil recorrerla con el lector para encontrar la información.

Es importante saber que en la descripción no debes indicar el número de filas o columnas que tiene la tabla, porque esto ya lo anuncia el lector de pantalla por defecto.

También hay que tener en cuenta que el lector de pantalla leerá tanto el caption como la descripción, tal y como voy a explicar a continuación, por tanto no deben ser iguales ni repetitivos.

¿Como lee el lector de pantalla la descripción y el caption?

Imaginemos la siguiente tabla:


  
<h3>Ejemplo de tabla</h3>

<p id="tabla1" aria-hidden="true">

En cada fila de la siguiente tabla encontrará los datos de un criterio de las
   WCAG 2.1. El nombre del criterio en la primera columna es un enlace a la página 
   "Comprender el criterio ..." del portal del W3C.

</p>
<table aria-describedby="tabla1">
<caption>
  Tabla 1. Criterio de las WCAG 2.1
</caption>
  <tr>
    <th>Criterio</th>
    <th>Nivel</th>
    <th>Principio</th>
    <th>En las WCAG 2.0</th>
  </tr>
  <tr>
    <td lang="en"> 
     <a href="[...]" 
        target="blank"
        title="Abre la página  
              'Comprender el 
              criterio 1.1.1' 
              en ventana nueva">
     1.1.1 Non-text Content
     </a>
    </td>
    <td>A</td>
    <td>Perceptible</td>
    <td>Sí</td>
  </tr>
  [...]
</table>

* En el código de sobrentiende que los acrónimos se han explicado previamente.

El resultado del código anterior, sin estilos, es el siguiente:

Ejemplo de tabla

Tabla 1. Criterio de las WCAG 2.1
Criterio	Nivel	Principio	En las WCAG 2.0
1.1.1 Non-text Content	A	Perceptible	Sí

Esta tabla tiene un caption que la identifica y una descripción útil para todos los usuarios. Voy a explicar cómo lee el lector de pantalla la tabla.

En primer lugar hay que saber que puedes llegar a una tabla con el lector de pantalla de las siguientes maneras:

Saltando a la tabla con el atajo de teclado (tecla "t") que permite saltar de tabla en tabla.
Con las flechas arriba/abajo del teclado, en una lectura lineal de la página. La flecha abajo te permite acceder al siguiente contenido y la flecha arriba al contenido anterior.

La lectura difiere en ambos casos. Voy a explicar ambas.

Lectura al saltar a la tabla con la tecla "t"

Si llegas a la tabla saltando con la tecla "t", el lector de pantalla anunciará lo siguiente:

"Tabla 1. Criterios de las WCAG 2.1. Tabla con 79 filas y 4 columnas. En cada fila de la siguiente tabla encontrará los datos de un criterio de las WCAG 2.1. El nombre del criterio en la primera columna es un enlace a la página 'Comprender el criterio ...' del portal del W3C."

* lectura con NVDA+Chrome

El lector nos lee la información en este orden: Caption + Número de filas y columnas + Descripción.

Es importante tener en cuenta que el lector de pantalla:

indica por defecto el número de filas y columnas que tiene la tabla, por eso esta información no debe indicarse en la descripción, pues resultaría repetitiva.
lee el título y la descripción de la tabla, por tanto el caption y la descripción no deben ser iguales ni repetir la misma información.

Si la tabla no tiene caption, la descripción deberá identificar la tabla para que el usuario sepa a qué tabla ha llegado. Pero si está en tu mano, intenta usar el caption para el título.

Lectura en el acceso con las flechas

Cuando llegas a la tabla con la flecha abajo, el lector de pantalla anunciará lo siguiente:

[Flecha abajo]

"Encabezado de nivel 3 Ejemplo de tabla."

[Flecha abajo]

Tabla con 79 filas y 4 columnas. En cada fila de la siguiente tabla encontrará los datos de un criterio de las WCAG 2.1. El nombre del criterio en la primera columna es un enlace a la página 'Comprender el criterio ...' del portal del W3C. Tabla 1. Criterios de las WCAG 2.1."

* lectura con NVDA+Chrome

Como se observa:

Llegamos al encabezado y nos lo anuncia: "Encabezado de nivel 3 Ejemplo de tabla".
Pulsamos la tecla "flecha abajo" para llegar al siguiente contenido y el lector ignora el párrafo de la descripción, no lo lee, sino que pasa a anunciar la tabla.
La información de la tabla la lee en un orden diferente al del acceso con la tecla "t", ahora es: Número de filas y columnas + Descripción + Caption

¿Por qué el lector de pantalla se ha saltado la lectura del párrafo?

Porque tiene el atributo aria-hidden="true". Este atributo permite que un contenido se vea pero que esté oculto para el lector de pantalla, de forma que no lo anuncie.

Si no pusiéramos aria-hidden="true" el lector leería el párrafo dos veces, la primera como párrafo, y la segunda como parte de la información de la tabla:

"Encabezado de nivel 3 Ejemplo de tabla. [flecha abajo] En cada fila de la siguiente tabla encontrará los datos de un criterio de las WCAG 2.1. El nombre del criterio en la primera columna es un enlace a la página 'Comprender el criterio ...' del portal del W3C. [flecha abajo] Tabla con 79 filas y 4 columnas. En cada fila de la siguiente tabla encontrará los datos de un criterio de las WCAG 2.1. El nombre del criterio en la primera columna es un enlace a la página 'Comprender el criterio ...' del portal del W3C. Tabla 1. Criterios de las WCAG 2.1.".

El soporte de aria-describedby es muy alto, por ello, y según las características del proyecto, valora el uso de aria-hidden="true" para evitar contenido repetitivo.

Cómo redactar descripciones útiles. Ejemplos.

Sigue estas recomendaciones a la hora de redactar la descripción:

Debe ser concisa y clara.
No hay que indicar el número de filas y columnas que tiene la tabla porque esto ya lo anuncia el lector de pantalla por defecto.
Redacta la descripción pensando también en las personas que ven la tabla, de manera que la información les sea de utilidad.
La descripción resumirá aspectos relevantes de la estructura y/o contenido de la tabla.
Si la tabla no tiene caption, la descripción debe identificar además la tabla, para que el usuario sepa qué información contiene.
Si la tabla tiene caption, la descripción y el caption nunca serán iguales, para que la información no sea repetitiva. En este caso, la descripción no debe identificar la tabla a menos que se haga de manera complementaria al caption.

Un truco si tienes dudas sobre cómo redactar la descripción es pensar: ¿que información he obtenido yo de la tabla en un primer vistazo?

Ejemplos de descripciones de tablas

Os voy a poner ejemplos de tablas con caption y una descripción adecuada.

No pondré el resto de la tabla para que estéis en la misma situación que una persona que no puede verla. De este modo, puedes valorar si tienes suficiente información sobre la tabla para comprender qué información contiene y poder hacerte una imagen mental de la misma.

Ejemplo 1

<p id="tabla1">

Esta tabla tiene tantas filas como canales de comunicación tiene la empresa, y tantas columnas como grupos de interés a los que queremos dirigirnos. Se incluye una imagen con un visto verde ("Sí") si el canal permite el diálogo con ese grupo de interés, de lo contrario, la celda está vacía.

</p>
<table aria-describedby="tabla1">
<caption>

Tabla 1. Principales canales de comunicación.

</caption>

Ejemplo 2

<p id="tabla2">

En cada fila de esta tabla encontrará los datos de una comunidad autónoma. En las dos primeras columnas se agrupan los datos de 2017; y en las dos siguientes los datos del 2016. En la última fila y columna encontrará los totales.

</p>
<table aria-describedby="tabla2">
<caption>

Tabla 2. Distribución de la plantilla con contrato fijo.

</caption>

Ejemplo 3

<p id="tabla3">

En cada fila de esta tabla encontrará los datos de un objetivo específico del tema 10, con el enlace a la página de actuaciones en la última columna.

</p>
<table aria-describedby="tabla3">
<caption>

Tema 10. "Aprendizaje permanente"

</caption>

Incluir la descripción de las tablas a través del gestor de contenidos

Es habitual que el editor de texto del gestor de contenidos solo permita incluir la descripción con summary, así ocurre por ejemplo con CKEditor. Permite incluir un título y una descripción a la tabla en su ventana de propiedades, en los campos "Título" y "Síntesis". El título lo incluye con caption y la descripción la añade con el atributo summary de la tabla.

En estos casos, se puede implementar un botón personalizado en el editor, algo relativamente sencillo con CKEditor.

Por ejemplo, al pulsar este botón personalizado se puede solicitar el número de filas, columnas, el título y la descripción de la tabla, de tal manera que, cuando el editor inserta la tabla, lo hace incluyendo automáticamente un párrafo antes de la tabla con la descripción, asociado a la misma con el atributo aria-describedby.

Que dicen las WCAG 2.1 sobre la descripción de las tablas

Las WCAG 2.1 indican que el resumen es especialmente útil cuando la tabla tiene una estructura compleja (por ejemplo, cuando hay varios conjuntos de encabezados de fila o columna, o cuando hay múltiples grupos de columnas o filas); o cuando las tablas de datos simples tienen muchas columnas o filas de datos.

Pero, como hemos explicado, la descripción es útil en todas las tablas: si tienen filas y columnas de totales; si tienen enlaces; si tienen celdas vacías o con iconos; o incluso si la tabla es muy sencilla, para aportar ese primer vistazo a los usuarios de lector de pantalla, de modo que estén en igualdad de condiciones con una persona que ve.

La clave para que la descripción sea siempre útil está en redactarla de forma adecuada.

Mi recomendación es que se anime a los publicadores a incluirla siempre, explicándoles su razón de ser y las buenas prácticas de redacción comentadas.