Accesibilidad en SPA (Single Page Application): 3 claves para garantizar una experiencia accesible e inclusiva.

En muchos portales web no navegas realmente cuando pulsas los enlaces de las páginas, sino que todo el contenido de la página, o buena parte del mismo, se modifica dinámicamente. Es posible que ni siquiera te des cuenta... a menos que accedas con un lector de pantalla o solo con el teclado.

La experiencia de una persona ciega en una Single Page Application (SPA) en la que no se ha trabajado la accesibilidad puede ser desastrosa: escucha solo silencio cuando navega, no sabe dónde se encuentra y el foco de teclado se vuelve impredecible.

En este artículo voy a explicar cuáles son las 3 claves para que una Single Page Application (SPA) sea accesible para todas las personas.

Índice

• Diferencia entre una Multiple Page Application (MPA) y una Single Page Application (SPA)
• Feedback al usuario: incluye mensajes de cargado datos y de página cargada
• Título de la página dinámico: proporciona a cada página un título único y descriptivo
• Control del foco de teclado: tres opciones según la situación
• Otras recomendaciones a tener en cuenta
• Esta no es la solución...

Diferencia entre una Multiple Page Application (MPA) y una Single Page Application (SPA)

Una Multiple Page Application (MPA) y una Single Page Application (SPA) son dos enfoques diferentes para construir portales y aplicaciones web.

El enfoque tradicional y más habitual es el de una Multiple Page Application (MPA), donde cada página se carga por separado desde el servidor cuando el usuario solicita una nueva página. Es decir, cuando navegas de una página a otra, la aplicación realiza una solicitud al servidor para obtener la nueva página completa, de modo que la navegación implica recargar toda la página.

Por el contrario, en una Single Page Application (SPA):

• Se carga una única página en el navegador del usuario.
• A medida que interactúas con la aplicación, en lugar de cargar páginas completas desde el servidor, solo se cargan los datos necesarios y se actualiza dinámicamente la interfaz de usuario.
• La transición entre secciones de la aplicación se realiza de manera suave sin recargar la página completa.
• Se puede cambiar dinámicamente solo una parte del contenido, por ejemplo, la región principal, pero también en ocasiones todo el contenido de la página.

Por tanto, la principal diferencia radica en cómo se maneja la navegación y la carga de contenido.

En una MPA, cada página requiere una carga completa desde el servidor, mientras que en una SPA, la aplicación se carga una vez y la navegación subsiguiente ocurre de forma más rápida y fluida sin recargas completas de página.

Imagen de Single-Page Applications: Build Modern, Responsive Web Apps with ASP.NET https://learn.microsoft.com/

En resumen, una MPA implica recargar páginas completas al navegar, mientras que una SPA carga la aplicación una vez y actualiza dinámicamente el contenido según las interacciones del usuario.

Un ejemplo tradicional de aplicación web SPA es Gmail, pero también lo son portales como Zara, Yoigo o Pinterest.

Feedback al usuario: incluye mensajes de cargado datos y de página cargada

Cuando accedes a un portal tradicional con un lector de pantalla, este te anuncia el título de la página que se ha cargado. Sin embargo, en una SPA solo hay silencio, porque realmente no se ha cargado la página, solo se ha modificado el contenido dinámicamente.

Para evitar este problema debemos trabajar con mensajes de estado.

Las WCAG no nos obligan a tener mensajes de estado, solo a marcarlos adecuadamente con ARIA para que sean anunciados por el lector de pantalla.

Si te limitas a cumplir estrictamente con las WCAG, las SPA podrían serán inaccesibles con el lector de pantalla. Necesitamos incluir obligatoriamente mensajes de estado.

Las buenas prácticas a seguir son:

• Incluye un mensaje de estado cada vez que modifiques dinámicamente el contenido de la página. Lo más recomendable es que el mensaje esté visible para todas las personas.
• Incluye atributos ARIA para que el lector de pantalla anuncie el mensaje aunque no tenga el foco:

  <div role="status" aria-live="polite"><p>Cargando datos de la página... <img alt="" src="spinner.gif"></p></div>

  

• A menudo me encuentro que el mensaje de estado solo contiene la animación ... sin texto alternativo, de modo que el lector no tiene nada que anunciar. Si el mensaje es solo una animación, debe tener texto alternativo:

  <div role="status" aria-live="polite"><img alt="Cargando datos de la página..." src="spinner.gif"></div>

• Igual de importante es anunciar que se están cargando los datos, como que la página ya se ha cargado. Cuando se carguen los datos modifica el mensaje de estado por "La página [título de la página] se ha cargado".

  <div role="status" aria-live="polite"><p>La página 'Proceso de compra. Paso 2 de 3 Dirección de envío' se ha cargado.</p></div>

• El mensaje de que la página se ha cargado no suele estar visible para todas las personas, solo para las personas que acceden con un lector de pantalla. Recuerda que NO debes ocultar el mensaje con los estilos display:none o visibility:hidden, porque ocultan también el contenido para el lector de pantalla.

Artículos de interés:

• Ocultar contenido visualmente y/o para el lector de pantalla (tabla resumen).
• Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente.

Título de la página dinámico: proporciona a cada página un título único y descriptivo

En un portal tradicional MPA, cada página que se carga tiene su propio título de página (en la etiqueta <title> del <head>).

Sin embargo, en una SPA solo hay una página cuyo contenido se modifica dinámicamente, por tanto, aunque te parece que se cargan diferentes páginas, solo es una con su título inicial. Por ello, es imprescindible que se modifique dinámicamente el título de la página (el contenido de la etiqueta <title> del <head>).

Cambiar dinámicamente el título de la página no provoca que el lector lo anuncie automáticamente como un mensaje de estado.

Por eso seguimos necesitando los mensajes de estado ya explicados.

Es raro encontrar una SPA de acceso público donde no se modifique dinámicamente el título, fundamentalmente por motivos SEO. Por la misma razón, es habitual encontrar errores cuando el título de la página no es relevante para el SEO: por ejemplo, podemos encontrar varias páginas de un proceso de compra que mantienen el mismo título; o que las páginas dentro de la zona de clientes, de acceso restringido, mantienen siempre el título de la página inicial.

El título de la página es importante para una persona usuaria de lector de pantalla, que puede preguntarlo en cualquier momento para ubicarse (normalmente con el atajo del lector: [tecla modificadora, como Insert] + "t").

Un título claro también es importante para cualquier persona: es el que se muestra en la pestaña del navegador, al guardar la página en marcadores, el nombre por defecto al compartir la página en redes sociales, etc.

Hay otra razón por la cuál el título puede ser relevante en una SPA. Ya he indicado que debemos incluir un mensaje de página cargada: "La página [título de la página] se ha cargado". Si utilizamos el contenido de la etiqueta <title> para generar dinámicamente el mensaje de página cargada, será muy confuso cuando el lector de pantalla anuncie que se han cargado diferentes páginas siempre con el mismo nombre:

Incorrecto: "La página 'Proceso de compra' se ha cargado", "La página 'Proceso de compra' se ha cargado", "La página 'Proceso de compra' se ha cargado" ...

Un título único y descriptivo para cada página provocará mensajes de estado más claros cuando se utiliza el título para generarlos:

Correcto: "La página 'Proceso de compra. Paso 1 de 3. Datos del cliente' se ha cargado", "La página 'Proceso de compra. Paso 2 de 3 Dirección de envío' se ha cargado", etc.

Control del foco de teclado

El tercer gran error que me suelo encontrar en las auditorías de portales o aplicaciones web SPA es el manejo del foco. Ten en cuenta que el usuario no sabe que se encuentra en una SPA ni tiene por qué saberlo.

Hay muchas personas que acceden a las páginas mediante pulsadores o solo con el teclado, entre ellas las personas que usan un lector de pantalla, muchas de las cuales son ciegas y no pueden ver dónde está el foco.

En un portal tradicional, cuando la página se carga, el foco de teclado se sitúa al comienzo de la página.

En una SPA donde no se ha trabajado la accesibilidad es muy confuso manejarte con el foco de teclado si no puedes ver la pantalla porque, a menudo, resulta impredecible saber a dónde irá el foco. Cuando se carga nuevo contenido, quizás el foco de teclado se pierda debido a la ausencia de un elemento que ya no está presente; o tal vez se quede donde está, aunque se haya anunciado la carga de una nueva página y tú esperes que el foco del teclado se encuentre ahora al inicio de la misma.

Por tanto, la tercera clave para que una SPA sea accesible es manejar correctamente el foco de teclado cuando el contenido se carga.

Para hacerlo bien impera el sentido común, conocer cómo acceden las personas usuarias de lector de pantalla y de teclado; e involucrarlas siempre que se pueda en las pruebas.

Opción 1. Mandar el foco de teclado al comienzo de la página

Si se está modificando dinámicamente todo el contenido central de la página, una opción puede ser mandar el foco al comienzo de la página, que es lo que el usuario espera. En concreto, sitúalo en el primer enlace del <body>: en el enlace "Saltar al contenido".

De este modo, después de que el mensaje de estado anuncie "La página [título de la página] se ha cargado", el foco se sitúa siempre de manera predecible al comienzo de la página, en el enlace para saltar al contenido central.

El usuario de lector de pantalla tiene el feedback necesario y es un comportamiento predecible.

El usuario de teclado que ve la página y no usa un producto de apoyo, no se queda con el foco en un lugar donde le resulte difícil regresar al inicio de la página o a la región principal. Por ejemplo, no se queda con el foco de teclado en el pie de página tras pulsar uno de sus enlaces.

Opción 2. Mandar el foco de teclado al título de la página

En otros casos, puede ser más usable mandar el foco al título de la página (al <h1> en el <main>).

Os pongo un ejemplo muy claro. Estas son dos pantallas de un curso accesible (de ejemplo) de isEazy, en concreto la página de inicio y una página interior:

isEazy genera automáticamente la versión accesible de un curso como una SPA. Por tanto, cuando pulsas "Comenzar curso" o "Siguiente sección" no se navega a otra página, sino que se modifica dinámicamente el contenido de la página.

Teniendo en cuenta los elementos concretos de la cabecera del curso y que el objetivo del alumno es ir avanzando por los contenidos del mismo, la conclusión a la que llegamos en este proyecto fue que la mejor alternativa era enviar el foco al título de la página (al <h1> en el <main>). De este modo, el usuario avanza de manera rápida, fluida y consistente. También puedes simplificar el mensaje de cargando página a "La página se ha cargado" o "El contenido se ha cargado", puesto que a continuación coge el foco el título de la página (el <h1>), por lo que el lector ya lo va a anunciar y no es necesario repetirlo en el mensaje de estado.

Cuando envíes el foco de teclado a un elemento ten en cuenta estos dos puntos:

• Si el elemento que coge el foco NO es un elemento de interacción, como en este caso el <h1>, debe tener el atributo tabindex="-1", nunca tabindex="0". Si le añades tabindex="0" cogerá el foco al tabular por la página. Si le añades tabindex="-1" solo cogerá el foco por programación, pero nunca al tabular por la página, que es lo correcto.
• La indicación visual de que tiene el foco debe ser clara. Evita limitarte a un simple cambio de color; por ejemplo, podría estar resaltado mediante un recuadro.

Opción 3. Mantener el foco de teclado en el elemento de interacción pulsado

En otros casos, cuando se modifica dinámicamente solo una parte del contenido, mover el foco al comienzo de la página o al título no es la mejor solución.

Por ejemplo, puedes tener un buscador en la región principal, de modo que solo se recargan los resultados de la búsqueda:

En este caso, puede ser más adecuado que:

• el foco se quede en el botón "Buscar", como se muestra en el ejemplo anterior;
• el mensaje "Mostrando 9 Tiendas" tenga los atributos ARIA de mensaje de estado que hemos comentado. De este modo, el lector de pantalla anunciará el mensaje aunque no se haya movido el foco. La siguiente tabulación nos llevará al primer resultado de la búsqueda.

Otras recomendaciones

Otras recomendaciones a tener en cuenta a la hora de plantear la accesibilidad de una SPA son:

• Acuérdate de modificar la miga de pan convenientemente para que refleje en qué página estamos.
• Si marcas el menú o paso actual, acuérdate de marcar el correcto cuando modifiques el contenido.
• Tendrás que programar un retardo para que el lector de pantalla anuncie todo adecuadamente. Debemos asegurarnos de que el lector de pantalla carga el nuevo contenido en el búfer; y que le da tiempo a leer el mensaje de estado antes de leer el contenido que coge el foco, sin interrupciones ni cambios abruptos.

Si quieres añadir algún consejo más puedes proponerlo en los comentarios.

Esta no es la solución...

Una SPA puede suponer un grave problema de accesibilidad para las personas usuarias de lector de pantalla si no se trabaja correctamente la accesibilidad, pero si se siguen las pautas de accesibilidad que he dado, se genera una gran experiencia de usuario compatible con sus productos de apoyo.

Algunos portales tienen la tentación de solucionarlo incluyendo una overlay o widget de accesibilidad. En vez de hacer que su portal sea compatible con los productos de apoyo habituales de los usuarios, les obligan a usar un componente que incorporan en su portal y que no soluciona el problema.

Es como si al entrar a Aragón te obligáramos a bajarte de tu coche porque nuestras carreteras no están asfaltadas, pero hemos invertido unos millones de euros en comprar burros que ofrecemos a nuestros visitantes. Mejor invierte el dinero en asfaltar las carreteras.

Artículos relacionados:

• WCAG 2.2 (recomendación - octubre 2023) Todas las novedades de la nueva versión de las WCAG.
• 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.
• Etiquetas, atributos y estilos HTML / CSS que no debes usar o debes usar bien

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

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

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

Artículos relacionados:

• Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA)
• LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA, HTML5)
• Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas
• Asociación compleja de radios y labels de forma accesible
• Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online

Estudio del soporte de aria-label y aria-labelledby

Os comparto mi Estudio de soporte de aria-label, aria-labelledby, title, alt en imágenes, vínculos y regiones con NVDA, Olga Carreras, 2017.

Los test los he realizado de momento con NVDA 2016.1 + IE 11, Chrome 57, Firefox 53, pero iré añadiendo más lectores y versiones.

He realizados tres tipos de test:

• Con imágenes, analizando cómo anuncia NVDA la imagen con la combinación de diferentes atributos (alt, title, aria-label, aria-labelledby). Se analiza también el tooltip y qué se visualiza si la imagen no se carga.
• Con vínculos, analizando cómo anuncia NVDA el vínculo imagen con la combinación de diferentes atributos (title, aria-label, aria-labelledby). Se estudia en el acceso lineal, en el acceso con el tabulador y en la lista de enlaces de NVDA.
• Con regiones, analizando cómo anuncia NVDA una region con la combinación de diferentes atributos(aria-label, aria-labelledby). Se estudia en el acceso lineal, en el acceso con la tecla "d" para saltar de región a región y en el listado de puntos de referencia o landmark roles (insert + f7)

Incluyo las tablas resumen, pero en el estudio podréis consultar todos los test, los resultados y las conclusiones.

También podéis consultar más test en Test, estadísticas, encuestas y estudios sobre lectores de pantalla, Olga Carreras.

Tabla resumen (imágenes y NVDA 2016.1)

Atributos en <img>	Chrome57 lee*	Firefox53 lee*	IE11 lee*
alt	alt	alt	alt
alt + title	alt	alt	alt
alt + title + aria-label	aria-label	alt	aria-label
alt + title + aria-label + aria-labelledby	aria-label	alt	aria-label
aria-label	aria-label	aria-label	aria-label
aria-labelledby	aria-labelledby	aria-labelledby	ignora la imagen
alt + aria-labelledby	aria-labelledby	alt	alt

* En el acceso lineal. Al saltar con "g" el title se lee añadido al texto anunciado solo en Chrome, en IE no.

Tabla resumen (vínculos y NVDA 2016.1)

Atributos en <a>	Chrome57 lee*	Firefox53 lee*	IE11 lee*
aria-labelledby	aria-labelledby	aria-labelledby	texto de enlace
aria-labelledby + aria-label	aria-labelledby	aria-labelledby	aria-label
aria-labelledby + aria-label + title *	aria-labelledby	aria-labelledby	aria-label
aria-label + title *	aria-label	aria-label	aria-label
title *	texto de enlace	texto de enlace	texto de enlace

* En la lectura lineal. En el acceso con el tabulador, Chrome y Firefox añadirán al texto anunciado el texto del title.

Tabla resumen (regiones de la página y NVDA 2016.1)

Atributos en <section>	Chrome57 lee **	Firefox53 lee **	IE11 lee **
aria-labelledby	aria-labelledby	aria-labelledby	no lo anuncia / lo anuncia con todo su contenido*
aria-label	aria-label	aria-label	no lo anuncia / aria-label*
aria-label + aria-labelledby	aria-labelledby	aria-labelledby	no lo anuncia / aria-label*

* Si se sustituye por <div role="complementary"> lee lo que se indica.

** Además se anuncia seguido el primer elemento que le sigue.

Enlace: Estudio de soporte de aria-label, aria-labelledby, title, alt en imágenes, vínculos y regiones con NVDA, Olga Carreras, 2017.

Artículos relacionados:

• Test, estadísticas, encuestas y estudios sobre lectores de pantalla
• Landmark Roles (WAI-ARIA). Navegación más accesible y semántica en 2 minutos.
• LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA:aria-describedby y aria-describedat, HTML5: figure y picture)
• Novedades WAI-ARIA 1.1
• WAI-ARIA. Introducción, referencias, ejemplos, herramientas
• Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente

Reseña "Inclusive Design Patterns. Coding Accessibility Into Web Design"

Autor: Heydon Pickering

Nº páginas: 313

Idioma: inglés

Formato: PDF/ePub y/o impreso en tapa dura (calidad alta)

Fecha de publicación: 2016

Web: "Meet 'Inclusive Front-End Design Patterns', A New Smashing Book" en Smashing Magazine.

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

No se publican muchos libros de accesibilidad y tengo que decir que hacía tiempo que no encontraba un libro tan útil y tan inspirador.

Me ha encantado: es ameno, claro, pero a la vez trata muchos temas complejos, con ejemplos concretos de código HTML, CSS y JS.

También me gusta cómo plantea la enseñanza de la accesibilidad desde un enfoque diferente al habitual. En vez de abordar la accesibilidad en base a principios y pautas, lo hace a través de patrones de diseño concretos: una lista de productos, un formulario de registro, un botón hamburguesa, etc.

La explicación de cómo hacer accesibles para todas las personas cada uno de estos componentes le sirve de excusa para ir tratando todos los requisitos de accesibilidad de forma temática.

Esto permitirá que el lector se cree una biblioteca básica de componentes accesibles, pero lo que es más importante, le dota del conocimiento y las herramientas necesarias para poder ir ampliándola con garantías.

Al final, nos está documentado paso a paso el proceso de creación de un pequeño sitio web accesible. No habla de frameworks concretos, deberás buscar uno flexible que te permita aplicar los patrones definidos.

En relación con esta manera de abordar la accesibilidad hay una reflexión que me parece muy relevante.

Los consultores de accesibilidad estamos acostumbrados a hacer auditorías de accesibilidad en base a las WCAG 2.0, y por ello a evaluar por los principios, pautas y criterios en los que se organizan las WCAG 2.0.

Sin embargo, la presentación de los resultados a los desarrolladores que van a corregir los errores hay que plantearla de otro modo.

Imaginemos un botón que incumple tres o cuatro criterios de las WCAG. Si organizamos los resultados por criterios, en una tarea les diremos que mejoren la etiqueta del botón; en una tarea distinta (que puede ser resuelta por un desarrollador diferente), o 20 páginas más adelante en el informe, les diremos que ese botón debe poder coger el foco; y luego en otra, más adelante, les decimos que el código asociado a ese botón no es válido y que tienen que hacer determinado cambio en el HTML, etc.

Eso no es práctico.

Si se aborda el botón como un componente (pattern) podemos explicar todos sus problemas de manera unitaria, recomendando enfoques y técnicas alternativas.

De esta manera los errores del botón se solucionarán mejor y más rápido. Les das una solución completa e integrada, un modelo a seguir que les permita tomar decisiones futuras con confianza.

Sin duda esto vuelve nuestro trabajo más agradable, eficaz y gratificante, porque no solo auditas, sino que formas.

El libro está dirigido a diseñadores, maquetadores y programadores, no solo les recomiendo que lo lean, les suplicaría que lo hicieran.

El autor les quiere transmitir la nueva forma de pensar que define al Inclusive Design, que supone buscar la mejor solución a un problema, siendo esta la que incluye a todas las personas, con sus diferentes capacidades, preferencias y circunstancias. El libro demuestra que es posible hacerlo, que genera una solución más robusta, y que no es ni más costoso ni más difícil, por el contrario, a cambio ganamos una audiencia más amplia y menos frustrada.

La inclusividad es una cualidad del producto, no una mera característica adicional, y si está integrada en el proceso de desarrollo apenas supone trabajo extra. De hecho, usar tecnologías estándar de una forma correcta da en realidad menos trabajo.

El enfoque del libro os será muy útil porque, como digo, ofrece soluciones concretas, con ejemplos y código real. De hecho, vais a encontrar mucho código HTML, CSS, JavaScript, y mucho WAI-ARIA. También es muy recomendable para consultores de accesibilidad, pues aquí encontrarán muchas propuestas concretas de mejora, algunas bastante ingeniosas.

A continuación, comento brevemente los temas que trata el autor en 9 de los patrones que aborda en el libro:

• The Document
• A Paragraph
• A Blog Post
• Navigation Regions
• A Menu Button
• A List Of Products
• A Filter Widget
• A Registration Form
• Test-Driven Markup

The Document

El objetivo final de este capítulo es ofrecer la plantilla base HTML del documento, es decir, el código del esqueleto de la página donde se incluirá el contenido (se puede consultar completo en la página 43).

A lo largo del capítulo va repasando los siguientes temas:

• el DOCTYPE;
• la definición del idioma en la etiqueta HTML y las diferentes ventajas que esto conlleva;
• la importancia del diseño responsivo (Responsive Design) para el diseño inclusivo. Hace hincapié en permitir el zoom en los dispositivos móviles (traté este tema en profundidad en Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes)
• la definición de los tamaños de fuente en medidas relativas. Los problemas de las medidas rem y vh/vw y las soluciones para que incrementen su tamaño proporcionalmente con el viewport y admitan zoom.
• la importancia de la Mejora Progresiva (Progressive Enhancement) como metodología de trabajo. Los patrones del libro están fundados en estructuras HTML semánticas y bien formadas, mejoradas con CSS y JS. Esté o no activo el JS, el HTML semántico asegura una experiencia inclusiva para los usuarios de productos de apoyo, además de hacer la interacción más predecible y eficiente.
• pensar siempre en el peso de la página y la velocidad de carga, optimizando, por ejemplo, recursos como las fuentes externas (propone alternativas a FOIT, cargar las fuentes una vez que se cargue la página, cargar solo el subset necesario, etc.)
• el <title> de la página y sus características;
• las ventajas del uso de etiquetas semánticas como <main>;
• los enlaces "saltar al contenido" y recomendaciones para su implementación.

En esencia, el código final es bastante similar al código que os proponía en mi artículo "Plantilla base HTML accesible", pero mucho más simplificado, más apropiado para el objetivo con el que se inserta en el libro. La mía incluía aspectos como los metas o la navegación semántica que no hubiera tenido sentido incluir en este libro. Otra diferencia importante es que su plantilla está en HTML5, y la mía, escrita en 2007, está en XHTML 1.0 Strict.

A Paragraph

El párrafo es quizás el patrón más básico y le sirve para hablar de la importancia del contenido y del principio "Content firt design". El contenido es lo más importante y el resto de actividades de diseño deben ser tratadas como apoyo al contenido y su forma. Por ello es importante que los prototipos tengan contenidos reales listos para probar con el usuario. En resumen si vas a hacer algo bien desde el principio que sea el contenido.

Otros temas que trata a lo largo del capítulo son:

• Measure o número de caracteres por línea. En este sentido apoya la propuesta de Robert Bringhurst de 45-75 por línea. En el libro incluye el código concreto CSS para definirlo respecto al tamaño de fuente y que al crecer este se reajuste proporcionalmente.
• Justificación, y las razones por las cuales debe alinearse el texto a la izquierda y nunca justificarse.
• Leading o altura de línea (line-height). Incluye el código concreto para que cumpla con las WCAG 2.0, utilizando mediadas relativas y proporcionales, de manera que cuando crezca el texto se mantenga la altura de línea adecuada.
• Contraste. Habla de la importancia de contraste de color, cómo revisarlo y la advertencia de atemperar el contraste extremo (negro sobre blanco).
• Subrayado de los enlaces, y su importancia. Incluye un código concreto CSS para evitar que el subrayado tache los trazos que sobresalen por debajo de la línea base de determinadas letras (p, q, g, etc.) y que permite controlar el estilo del subrayado (grosor, color, distancia del texto, etc.)
• Visibilidad del foco. Cada navegador identifica de una manera el elemento que tiene el foco (punteándolo, coloreándolo). Además de insistir en la importancia de no anular este efecto, propone un código CSS para normalizarlo en todos los navegadores y que sea más visible, al estilo del que tiene el portal gov.uk.
• Iconos automáticos. Explica el código CSS para incluir de forma automática (sin depender de los editores del contenido) un icono tras los enlaces externos.
• Normas de redacción. Traté este tema en la reseña de "Cómo escribir para la Web" de Guillermo Franco.

El autor parte de la premisa de Susana González en Designing for extremes de que no existe el usuario medio, y diseñar para este individuo artificial hace que creemos algo que no encaja con las necesidades de nadie. Diseñar para las situaciones extremas hace que al final diseñemos para todos.

Todas las pautas dadas son adecuadas para un público muy diverso (baja visión, dislexia, bajo nivel de alfabetización, conocimiento técnico limitado, etc.) así que una lectura cómoda y una interacción garantizada para ellos lo será también para todos los demás.

La web de Heydon Pickering, por si queréis ver cómo utiliza el texto y su diseño, es: Heydonworks

A Blog Post

Este componente le sirve para repasar aspectos fundamentales del diseño inclusivo como son la estructura del contenido, y su coherencia con la información visual que se ofrece, el orden del código, el sistema de encabezados o cómo establecer un CSS Flow System robusto y tolerante a los cambios de contexto. Todo ello ayudará a que la página sea navegable y operable por todos los usuarios.

El autor realizó una encuesta sobre las preferencias de los usuarios de lector de pantalla (Screen Reader Strategy Survey), de manera que las afirmaciones que hace (por ejemplo sobre sus preferencias de navegación: landmarks, encabezados o lectura lineal) pueden basarse en datos objetivos.

Podéis consultar una recopilación de este tipo de encuestas en mi artículo Test, estadísticas, encuestas y estudios sobre lectores de pantalla.

Entre los temas que trata en este capítulo están:

• Los encabezados, su importancia y buenas prácticas. Tiene un apartado específico para los <h1>, con opciones de codificación para casos concretos como los subtítulos (entendidos como frases que complementan un título).
• Orden del código, y su importancia en determinados contextos de uso.
• <article>, su uso correcto y el soporte actual.
• On single-page applications. Desaconseja el contenido estático generado por JS en cliente y repasa los problemas implícitos a esta práctica.
• La readability de los textos. Traté este tema en mi artículo anterior Medición de la readability o comprensión de los textos en español. Estado actual y retos.
• Las características que deben tener los textos de los encabezados y enlaces (concisos, descriptivos, significativos fuera de contexto).
• El vídeo y la importancia de los subtítulos y la transcripción, una forma de consumir el contenido que mucha gente utiliza en contextos muy diferentes, más allá de que tengan o no una discapacidad. Repasa sus requisitos imprescindibles, así como el del reproductor, que debe ser operable por teclado. Incluye en su recomendación 4 reproductores concretos.
• Flow system. Incluye el código para ir creando una CSS robusta que permita que el contenido fluya regular, -siempre bien espaciado y legible-, independientemente de que se amplíe el texto o se vea en diferentes tamaños de pantalla. Trata con detalle cómo definir los márgenes de los elementos o cómo proteger el código de los párrafos vacíos desde la CSS.

Otro de los aspectos en los que insiste es en la necesidad de que los editores de contenido solo tengan que escribir, sin preocuparse de si rompen o no el diseño visual. Esto se tiene en cuenta en el código CSS que propone, y se consigue en gran de medida gracias a los selectores que utiliza, que hacen que el diseño se aplique de manera general, independientemente de los elementos que se incluyan con el editor.

Navigation Regions

En este capítulo explica cómo crear un menú principal y una tabla de contenidos dentro de las páginas. Ofrece una solución accesible, semántica y construida con un CSS robusto.

El autor parte de una lista de enlaces para, mediante mejora progresiva (Progressive Enhancement) , ir creando un sistema de navegación inclusivo.

Los temas que trata en el capítulo son:

• Correcto etiquetado HTML5 y el uso de Landmark Roles (puedes consultar mi artículo Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA))
• La importancia de seguir las convenciones.
• Dónde colocar los elementos, no solo visualmente, sino en el código, para no perjudicar a los usuarios que acceden por teclado.
• Cómo codificar y resaltar correctamente la opción en la que nos encontramos, y cómo hacerlo de una manera no solo visual.
• Cómo reducir la redundancia, con alguna idea bastante original.
• Los problemas que provoca que los enlaces a las anclas tengan asociado un efecto de scroll suavizado en vez del salto directo habitual.

A Menu Button

Este capítulo está dedicado por completo a cómo diseñar e implementar correctamente el navicon o icono hamburguesa. Las pautas son en realidad válidas para cualquier icono de una página.

Algunos temas que trata son:

• Desde un punto de vista del diseño: las convenciones, si es mejor acompañarlo del texto "menú" y/o recuadrarlo, o el tamaño que debe tener para una correcta interacción táctil.
• Desde un punto de vista del código: las diferentes maneras que hay de incluir y etiquetar el icono, y las ventajas y desventajas de cada una. Al final opta por los SVG sprites, incluyendo el código concreto a utilizar, de tal manera que sea una solución robusta y soportada por navegadores antiguos.
• Desde un punto de vista del comportamiento:
  • el código con el que incluir las opciones de menú que despliega el botón, siendo muy importante su orden dentro del código;
  • cómo ocultar las opciones de menú correctamente;
  • cómo comunicar el cambio de estado (abierto/cerrado) a los usuarios de productos de apoyo;
  • cómo hacer todo esto sin depender de JS o CSS, es decir, que sea accesible cuando el JS o la CSS falle;
  • etc.

Algunos de estos temas los traté en el artículo Responsive Design y accesibilidad

A List Of Products

Este componente es un listado de productos, de tal manera que cada uno de los productos tiene: título, imagen, características, call-to-action ("Comprar ahora") y valoración de los usuarios mediante estrellas. Ofrece el código concreto, con una estructura clara (con o sin CSS cargadas) y un etiquetado semántico.

Este capítulo le sirve para tratar diversos temas:

• Cómo incluir de forma correcta caracteres especiales.
• El texto alternativo de las imágenes en diferentes circunstancias, evitando siempre la redundancia. La primera lección que aprendemos en accesibilidad es que las imágenes deben tener texto alternativo, pero el hacerlo bien es lo que marca a menudo la diferencia (podéis consultar mi artículo Textos alternativos, imágenes accesibles. Herramientas de ayuda: mapa de decisión y wizard online).
• La composición consistente en las diversas imágenes de un mismo producto.
• La optimización de las imágenes para su rápida descarga y adecuada para cada dispositivo. Recorre aspectos como la comprensión, el lazing loading o el elemento <picture>.
• El call-to-action ("Comprar ahora") le sirve para tratar errores habituales en el diseño e implementación de los enlaces:
  • los enlaces con el mismo texto,
  • los enlaces con href=javascript:;
  • los block-level links, es decir, la posibilidad de incluir en HTML5 todo el contenido del producto dentro del enlace que, aunque válido, tiene muchos inconvenientes.
  • etc.
• Datos estructurados, puesto que nuestra interface no es el único camino por el cual los usuarios encuentran y consumen nuestra información, en este caso, la información de nuestros productos.

A Filter Widget

En este capítulo se complementa el listado de productos con opciones de filtro y la posibilidad de visualizar el listado en formato lista o cuadrícula. Esto permite al autor insistir en la importancia de principios UX básicos como que el usuario pueda elegir o que tenga el control.

La solución que propone se basa de nuevo en la mejora progresiva, de manera que funciona sin CSS y sin JS, pero después añade ambas tecnologías para mejorar la experiencia.

Además, no es necesario un widget complicado construido a partir de JavaScript y ARIA, sino que sigue el principio básico de si puedes utilizar elementos y atributos HTML nativos, hazlo, no reinventes la rueda.

Este componente se convierte en un claro ejemplo de que a veces las cosas se pueden conseguir simplemente con HTML y CSS, sin necesidad de JavaScript o ARIA. Nos da una solución eficiente y robusta, accesible por teclado y para todos los usuarios, y sin dependencia de JS o CSS.

Este capítulo le sirve para repasar también otros temas:

• Las animaciones "Cargando contenido" y asociadas a las mismas las Live Regions (puedes consultar mi artículo Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente )
• La necesidad de un botón en todos los formularios, repasando todas las razones por las cuales no deberíamos eliminarlo.
• Las ventajas e inconvenientes de diferentes maneras de paginar los resultados del listado. El desplazamiento infinito secuestra la acción de desplazamiento del usuario para realizar un comportamiento inesperado, controlando al usuario y empeorando su experiencia. El botón "Cargar más" invita al usuario a realizar una acción explícita y por lo tanto se ajusta más al principio UX de dar el control al usuario.

• Vista lista/ Vista cuadrícula. Permite decidir al usuario sobre la forma en que quiere visualizar el resultado, aquella que se ajuste mejor a sus necesidades. Le sirve de pretexto para hablar en detalle de Flexbox, que nos permite tener una rejilla ordenada en cualquier resolución (con adaptación a los idiomas que se leen de derecha a izquierda como el árabe), un reflujo automático de columnas sensible al tamaño de la fuente o un ancho máximo para una lectura cómoda.
• La relevancia de que en los prototipos no pongamos texto idealizado, que después en la realidad puede provocar efectos indeseados. Propone evaluarlo con texto aleatorio mediante su librería JS forcefeed.js

A Registration Form

En este patrón implementa un formulario de registro, de manera que le sirve para repasar requisitos de accesibilidad y usabilidad que se han de tener en cuenta en los formularios.

Los temas que trata son:

• La convivencia del formulario de login y el formulario de registro en muchos sitios. Tras repasar los problemas de algunas soluciones habituales, el propone como una alternativa (no la única posible) incluirlos con dos pestañas. En realidad, esto le sirve para repasar la implementación adecuada de pestañas con WAI-ARIA.
• El correcto etiquetado de los campos de formulario.
• El atributo PLACEHOLDER que permite en HTML 5 incluir texto por defecto en el campo. Repasa sus problemas habituales y soluciones. También comenta alguna propuesta ingeniosa como el Float Label Pattern de Brad Frost.
• El correcto uso de fieldset/legend, cuándo es conveniente utilizarlo y cuándo su uso solo añade ruido.
• La implementación de los campos obligatorios. Repasa el uso del asterisco combinado con aria-required para una solución más robusta (lo traté en el artículo HTML5 y accesibilidad: nuevos tipos de input, atributos asociados y validación nativa)
• La implementación de la opción de visualizar el password que se introduce.
• La validación del formulario, a la que dedica buena parte del capítulo. Trata, por ejemplo:
  • la live región que tendrá los mensajes generales de error,
  • el uso de aria-describedby para los mensajes en línea (traté este atributo en el artículo Ayuda contextual de los formularios más accesible con "aria-describedby" (WAI-ARIA) ),
  • el aspecto visual de los mensajes y de los campos con errores,
  • la redacción de los mensajes de error,
  • la implementación correcta de una validación en línea que mejore el rendimiento y la experiencia. En concreto propone incluirla solo en la revisión de los errores, eliminando el error a medida que el usuario lo corrige.

Test-Driven Markup

El último capítulo del libro anima a los desarrolladores a crear su propio test de pruebas. Propone validar la estructura HTML de tu componente mediante una CSS de test que utilice selectores (expresiones basadas en condiciones) para resaltar los errores:

[undesired pattern] {
/* error style, such as
outline: 0.5em solid red;
*/
}


Como ejemplo, presenta y explica una CSS de test bastante compleja. Además, aunque los elementos con errores se resalten en la página, explica cómo podría usarse el inspector CSS de las herramientas de desarrollador como una consola JS, para poner allí los mensajes de error explicativos, en lugar de escribirlos en la página. Al final conseguiríamos algo como esto:

Aunque existen otras soluciones de terceros, alienta a escribir tus propias pruebas para tus propios patrones. El objetivo es que te vayas haciendo tu propia librería de patrones inclusivos con su test de prueba específico. Esto te asegura que, aunque tu patrón evolucione con el tiempo, su integridad se mantenga intacta.

Artículos relacionados:

• Podéis consultar más reseñas de libros en: "Libros y reseñas"
• Novedades WAI-ARIA 1.1
• Reseña de “Pro HTML5 Accessibility”
• Plantilla base HTML accesible
• Landmark Roles (WAI-ARIA). Navegación más accesible y semántica en 2 minutos.
• Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente.
• Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página
• Reseña del libro "Inclusive Components" de Heydon Pickering

Reseña: Monográfico "Accesibilidad Web" de la revista Novática

Editores invitados: Emmanuelle Gutiérrez y Restrepo, María del Carmen Ugarte García y Loïc Martínez Normand

Autores: Miguel Ángel Valero (entrevista), Terrill Thompson, Olga Revilla, Olga Carreras, Andy Heath, Rory Heap, Lisa Seeman, Shadi Abou-Zahra, Fernando Machicado Martín, José Ángel Martínez Usero y más.

Nº páginas: 86

Idioma: español

Formato: versión digital

Fecha de publicación: 2015

Revista: Monográfico "Accesibilidad Web", revista Novática, nº 232, abril-junio 2015 (PDF, 4MB)

 

Novática es la revista de la Asociación de Técnicos de Informática (ATI), decana de la prensa informática española, creada en 1975 y de periodicidad trimestral (más información sobre la revista Novática).

El número 232 (abril-junio 2015) es un monográfico sobre "Accesibilidad Web" con tres editores invitados de lujo: Emmanuelle Gutiérrez y Restrepo (Patrona y Directora General de Fundación Sidar), María del Carmen Ugarte García (socia sénior de ATI) y Loïc Martínez Normand (profesor de la Universidad Politécnica de Madrid y presidente de Fundación Sidar).

He tenido el placer de poder colaborar en el monográfico con el artículo "Documentos electrónicos accesibles". En él explico las buenas prácticas, -sencillas y al alcance de todos-, que podemos seguir en los documentos que creamos y divulgamos para favorecer que sean accesibles para todos.

La revista está disponible solo en formato digital. En la web de la revista podéis encontrar el sumario completo y el resumen de cada artículo: "Monografía: Accesibilidad web", revista Novática, nº 232, abril-junio 2015.

A continuación voy a reseñar los 9 artículos que componen propiamente la monografía sobre Accesibilidad Web.

Presentación. Accesibilidad Web: Tendencias de Futuro

Autores: Emmanuelle Gutiérrez y Restrepo, María del Carmen Ugarte García y Loïc Martínez Normand.

En la presentación se introduce qué es la accesibilidad web y los diferentes artículos que se incluyen en la monografía, cuyo objetivo es ofrecer información actualizada y relevante sobre las tendencias de futuro en el campo de la Accesibilidad Web.

De la presentación me quedo con este párrafo:

Hoy en día debería ser natural considerar que un buen profesional del diseño y desarrollo web debe ser capaz de desarrollar sitios web accesibles, de la misma forma que se preocupa de otros aspectos como la eficiencia, la seguridad y la privacidad. Por lo tanto, las técnicas de diseño y desarrollo accesible deben formar parte de la “caja de herramienta” que los diseñadores y desarrolladores tienen a su alcance para realizar correctamente su trabajo.

No obstante, al día de hoy, la accesibilidad sigue considerándose un plus, algo que puede distinguir nuestro trabajo frente a otros, y por supuesto es deseo de estos editores el que esta diferencia desaparezca lo antes posible.

CEAPAT: El diseño para todos como objetivo fundamental

Entrevista a Miguel Ángel Valero, director de CEAPAT (Centro de Referencia Estatal de Autonomía Personal y Ayudas Técnicas)

Es una entrevista extensa y muy interesante. Parte de qué es el CEAPAT y cuáles son sus programas de acción:

Es frecuente que vengan investigadores del área TIC, tanto nacionales como de proyectos europeos, en busca de asesoramiento por parte del CEAPAT con el fin de no reinventar la rueda

Hace hincapié en lo relevante que es la formación, no solo en las carreras técnicas, sino también la formación para los profesores y educadores, donde se enmarca por ejemplo la publicación "Diseño para todos en educación" (PDF), 2015.

Miguel Ángel Valero también reflexiona sobre la situación actual de la accesibilidad web en España o sobre las razones que subyacen tras la falta de accesibilidad en los sitios web.

Una parte muy interesante de la entrevista es la que versa sobre las denuncias, sanciones y el proceso de resolución de quejas así como el papel que en ellas tiene el CEAPAT. Aunque la labor del CEAPAT es más formativa y divulgativa, están haciendo informes técnicos cuando las denuncias llegan al CENTAC, en quien ha delegado Red.es, que es quién lo gestiona y hace la canalización técnica:

Cuando llegan a nosotros esas denuncias es porque la accesibilidad de esas webs ha sido certificada previamente por entidades privadas, y a lo mejor sí lo era el diseño pero no la implementación. Entonces nosotros aconsejamos cómo hacerlo bien, no tanto qué es lo que está mal, porque lo que está mal con validadores o peritajes técnicos es suficiente.

En los casos que conozco de cerca encuentro rigor técnico en la ejecución de los informes, pero hay plazos demasiado largos en las entidades denunciadas para que procedan a su ejecución.

[...]

Entonces el papel del CEAPAT es más formativo, el papel del CERMI y otras entidades es más de denuncia y el de Red.es es la canalización técnica para que se cumpla, y está bien que estemos separados, para que no haya un efecto “juez y parte”.

También comenta que las entidades se suelen aferrar a la norma antigua WCAG 1.0. Por último reflexiona extensamente sobre el futuro de la accesibilidad web, la accesibilidad móvil, la accesibilidad en redes sociales o la accesibilidad para las personas mayores.

El concepto de accesibilidad llega al gran público cuando se da cuenta de que su producto no es solo útil para él, sino también para otros con alguna limitación en su capacidad funcional y para él mismo, caso de que la tuviera. La accesibilidad llega cuando se comprende que un producto no solo te beneficia a ti mismo, sino también a los que te rodean y a tu entorno.

Deberíamos dar a conocer como diseñando para todas las personas se diseña para cada uno y no a la inversa, pues se entendería mejor la accesibilidad universal. Es imprescindible que la gente comprenda que la necesidad también es tuya, porque el gran público, una vez que comprende, colabora.

Vídeos accesibles para todos

Autor: Terrill Thompson, especialista en accesibilidad tecnológica en la Universidad de Washington.

Comienza con una introducción sobre la importancia de hacer vídeos accesibles, y los estándares del W3C relacionados:

• las WCAG 2.0, donde podemos encontrar los criterios de conformidad que han de cumplir;
• HTML 5,
  • con sus nuevos elementos vídeo y track que permiten insertar vídeo usando solo HTML y sincronizar con ellos ficheros de texto marcados con tiempo,
  • o con su API multimedia que permite construir reproductores propios usando JavaScript para controlar los elementos multimedia;
• WebVTT (Web Video Timed Text), formato para las pistas de texto marcadas con tiempo.

En el grueso del artículo repasa las soluciones para hacer más accesibles los vídeos. Además de explicar cada una de ellas, repasa el soporte actual de las mismas:

• Subtítulos para personas sordas (captions) y subtítulos para traducción (subtitles), y el soporte de track y su atributo kind="captions" y kind="subtitles". Habla también de herramientas libres para incluir subtítulos, de experiencias de crowdsourcing para crear subtítulos (como el proyecto OpenTranslation de TED) o de la tecnología ASR (Automatic Speech Recognition) que usa Youtube. Me parece interesante su reflexión, en la que no reparamos a menudo: la mayor barrera que impide el acceso a la información es el idioma, "la mayor parte del contenido en Internet está únicamente en inglés, idioma que habla solo el 14% de la población mundial".
• Audiodescripción y el soporte de track y su atributo kind="descriptions" (donde se referencia al fichero WebVTT para que sea leído por el navegador o el lector de pantalla del usuario).
• Transcripciones, reflexiona sobre la importancia de las transcripciones, no solo para las personas con discapacidad, sino también para las personas que disponen de poco ancho de banda (habitual en los países en desarrollo) o incluso para las personas muy ocupadas, que pueden echar un vistazo a la transcripción sin tener que visualizar todo el texto o que pueden buscar en el mismo.
• Lengua de señas (HTML5 no facilita un mecanismo específico).
• Reproducción a velocidad variable, y como HTML5 incluye la posibilidad de modificar la velocidad de reproducción a través de la API.
• Controles de reproducción accesibles, y repasa criterios de las WCAG 2.0
• Preferencias del usuario

Al final del artículo aborda el tema de los reproductores de vídeo HTML5 nativos frente a los reproductores de terceros. Incluye un listado de reproductores multimedia HTML5 con soporte para accesibilidad (lista completa disponible en Media Player Accessibility Comparisons).

Destaca claramente el reproductor Able Player, disponible en castellano, puesto que incluye soporte para subtítulos para sordos, subtítulos de traducción, audiodescripción, lengua de señas y reproducción a velocidad variable, además de que ha sido cuidadosamente diseñado para asegurar que sus botones y controles sean accesibles para cualquiera usuario.

En definitiva, un artículo muy interesante que merece la pena leerlo detenidamente.

WAI-ARIA, el gran desconocido de la accesibilidad web

Autor: Olga Revilla, autora de "WCAG 2.0 made easy" que reseñé en su día en el blog.

El artículo resume qué es WAI-ARIA, para qué sirve y a quién beneficia o cómo se implementa, incluyendo varios ejemplos. Creo que consigue sintetizar de manera muy clara todo ello, intentando demostrar, como dice, que la complejidad de su implementación es más aparente que real.

La autora reflexiona también sobre las razones que hacen de WAI-ARIA una de las tecnologías menos conocidas e implementadas por los desarrolladores, algo con lo que estoy de acuerdo y por lo cual me parece muy importante que haya artículos como este.

Le agradezco la referencia a mi post "WAI-ARIA. Introducción, referencias, ejemplos, herramientas", que se enmarca en ese esfuerzo por difundir la especificación WAI-ARIA en español.

Documentos electrónicos accesibles

Autor: Olga Carreras.

Le agradezco a Emmanuelle Gutiérrez y Restrepo que haya contado conmigo para divulgar las buenas prácticas que se han se seguir para crear documentos electrónicos más accesibles.

Incluyo el resumen formal del artículo, que espero poder publicar para su libre descarga a corto plazo.

Todos los días se generan y comparten millones de documentos electrónicos, pero por desgracia, la mayoría de estos documentos presentan barreras de accesibilidad. Esto impide que muchas personas puedan participar en la Sociedad de la Información y del Conocimiento con igualdad de oportunidades.

La accesibilidad es un derecho de todos, pero también una responsabilidad compartida. Como creadores y divulgadores de contenidos en formato digital, está en nuestras manos favorecer que todas las personas puedan percibirlos, entenderlos e interactuar con ellos de forma satisfactoria.

Para lograrlo, vamos a repasar una serie de buenas prácticas, sencillas y al alcance de todos, que puedes aplicar a cualquier tipo de documento electrónico en tu día a día.

Texto, imágenes y traducción en Facebook

Autores: Andy Heath, autor y colaborador de muchos estándares internacionales técnicos de soporte a la accesibilidad; y Rory Heap, coordinador de accesibilidad en la Consumer and Public Interest Network dentro del British Standards Institution (BSI).

Gran parte de las publicaciones en Facebook son o incluyen imágenes como parte del contenido. Sin embargo, pocas de estas imágenes son accesibles para las personas que, por cualquier razón, no pueden acceder al contenido visual, o bien necesitan traducir el texto que incluyen; y para demostrarlo exponen los resultados de un estudio informal.

El grueso del artículo, y el objetivo final del mismo, trata sobre la descripción de una solución usable que permita a los usuarios incluir alternativas textuales a las imágenes que publican en Facebook.

En este artículo argumentaremos que la integración del soporte OCR en una interfaz simple, invocada en tiempo de publicación de la imagen, combinada con el soporte de herramientas de autor para la inclusión de un texto alternativo que describa el contenido de las imágenes mejoraría significativamente la accesibilidad y enriquecería la audiencia de muchos posts en Facebook.

Repasan diferentes casuísticas que se pueden dar: imagen informativa, imagen cuyo contenido se describe en el post, imagen decorativa no relevante para la compresión del post (caso muy raro en Facebook) o imagen en la que desvelar el texto alternativo podría interferir con el propósito de publicar la imagen o del propio post (por ejemplo un chiste visual).

La solución que proponen abarca no solo la publicación sino también cuando se comparte un post ya existente que contiene una imagen, ayudando a corregir la falta de texto alternativo a las misma si dicho texto no se está proporcionando ya.

Por otra parte, en la implementación se tiene también en cuenta la usabilidad, mediante un procedimiento no intrusivo, que no ralentice al usuario y que no le suponga mucho trabajo adicional, pues de lo contrario lo más probable es que no use el procedimiento.

En el artículo "Texto, imágenes y traducción en Facebook" (PDF) podéis consultar la propuesta detallada con imágenes que lo ilustran.

Grupo de Trabajo de Accesibilidad para Discapacidades Cognitivas y Dificultades de Aprendizaje (COGA)

Autor: Lisa Seeman, coordinadora del grupo de trabajo COGA del W3C

El objetivo del grupo de trabajo Cognitive A11Y TF consiste en mejorar la accesibilidad de la web para las personas con discapacidades cognitivas y dificultades de aprendizaje. Este trabajo forma parte de las WCAG y de la Iniciativa de Accesibilidad Web (WAI) del W3C.

La autora explica los progresos y primeros borradores (ya comenté en "Pautas de accesibilidad que benefician a las personas con discapacidad cognitiva" que su principal documento es Cognitive Accessibility User Research), o en qué están trabajando. Como dice la autora, conforme la población va envejeciendo encontrar soluciones en este campo es algo cada vez más urgente desde una perspectiva humana, económica y empresarial.

Me quedo con una reflexión muy interesante que hace en el artículo:

Las dificultades de aprendizaje y las discapacidades cognitivas están entre las deficiencias menos comprendidas por los profesionales de la accesibilidad

[...]

La mayoría de las necesidades que debemos satisfacer respecto a la accesibilidad hacen referencia a las discapacidades sensoriales o físicas [...], que representan aproximadamente un 0,4 % de un mercado impulsado fundamentalmente por las denuncias de grandes grupos de defensa internacionales.

No obstante, aunque los usuarios con discapacidades cognitivas representan entre el 6,3 % y el 11 % del mercado en los Estados Unidos, la accesibilidad apenas ha prestado atención a dichas discapacidades y eso que esta cifra no incluye a las personas con un deterioro cognitivo leve debido a la edad.

Evaluación de la accesibilidad de los sitios web

Autor: Shadi Abou-Zahra, líder de la Oficina Internacional de Programas de la W3C Web Accessibility Initiative (WAI)

El artículo es una descripción detallada de la Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0, el documento del W3C que proporciona una metodología armonizada internacionalmente para la evaluación de todo tipo de sitios web.

Traduje en 2012 el documento al español Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM) (y lo he ido actualizando a medida que el documento evolucionaba) por la importancia que creo que tiene.

Debido a que generalmente no es factible evaluar cada una de las páginas de un sitio web, resulta fundamental emplear un método fiable para determinar el nivel de accesibilidad, de forma global, de un sitio web completo.

La WCAG-EM 1.0 especifica los pasos concretos, y ofrece orientación sobre las buenas prácticas para definir el alcance de la evaluación, explorar el sitio, seleccionar una muestra representativa cuando no es factible evaluar todo el sitio, auditar la muestra seleccionada y reportar los resultados de la evaluación mediante informes estructurados y uniformes.

El artículo termina con un apartado dedicado a WCAG-EM Report Tool, herramienta de software libre, que no es un validador sino un generador de informes que guía a los evaluadores por todos los pasos descritos en la WCAG-EM 1.0 (lo reseñé en WCAG-EM Report Tool. Herramienta de generación de informes de una evaluación de accesibilidad).

El autor también comenta que se está rediseñando y actualizando How to Meet WCAG 2.0 para hacerlo más dinámico y personalizable, y que se pretende integrarlo en la WCAG-EM Report Tool para facilitar el paso de la inspección del proceso de evaluación.

Las compras públicas como motor de una mayor accesibilidad TIC en Europa

Autores: Fernando Machicado Martín, de AENOR, secretario de varios comités de normalización relacionados con la accesibilidad y que participó como secretario en las fases finales de los trabajos del Mandato 376 de la Comisión Europea; y José Ángel Martínez Usero, responsable de Asuntos Internacionales de Funka, una empresa sueca especializada en accesibilidad

Se introduce el contexto internacional y europeo en materia de accesibilidad TIC, y se presentan los principales resultados del Mandato 376 de la Comisión Europea sobre la accesibilidad en la contratación pública de productos y servicios TIC. En particular, la norma UNE-EN 301 549 y la herramienta web para facilitar las compras públicas de productos y servicios TIC accesibles (toolkit).

La contratación pública de bienes y servicios supone alrededor del 18% del PIB de la Unión Europea (UE). Este hecho le da la fuerza para ser un sector estratégico con capacidad de hacer de palanca para la implementación de medidas efectivas de accesibilidad, así como para la concienciación de la sociedad.

Por ello, la Comisión Europea lanzó dos mandatos (M/376 y M/420) para elaborar normas técnicas que impulsaran la accesibilidad en las compras públicas, y que fomenta que la industria desarrolle productos más accesibles, más baratos y más eficientes. Ambos mandatos dan soporte técnico a las políticas europeas de accesibilidad y a la futura y esperada Ley europea de accesibilidad (Accessibility Act).

El documento principal resultante del mandato M/376 es la Norma EN 301 549 ‘Requisitos de accesibilidad adecuados para la contratación pública de productos y servicios TIC en Europa’, primera norma europea de accesibilidad para productos y servicios de TIC considerados de modo global, aplicable a las compras públicas, y redactada bajo este enfoque pero no de modo limitativo.

Esta norma establece los requisitos funcionales que garantizarán que los productos y servicios TIC sean accesibles para todas las personas; por ejemplo, desde un teléfono móvil y ordenadores, pasando por páginas web hasta servicios en la nube. Los requisitos para la web se basan en las Pautas de Accesibilidad para el Contenido Web (WCAG) 2.0

Reseñé la norma en el artículo EN 301 549: primera norma europea de Accesibilidad para productos y servicios de Tecnologías de la Información y Comunicación (TIC)

También habla de la herramienta desarrollada para facilitar la aplicación de la norma: “Herramienta web para las compras públicas de productos y servicios ICT accesibles”

Por último termina con una reflexión sobre si las WCAG 2.0, de 2008, se adaptan a los tiempos, por ejemplo al acceso mediante dispositivos móviles o a si cubren todos los aspectos de la discapacidad cognitiva. O de la importancia de superar las limitaciones de las legislaciones nacionales que establecen los mínimos requisitos a cumplir pero no el objetivo final que se desea: satisfacer las necesidades de los usuarios, ser competitivos y desarrollar productos de calidad y hacer felices a los usuarios ("Why WCAG is not enough", Funka).

Una posible receta para diseño web accesible orientado a las tendencias del mercado actual, podría ser:

• Usar tecnologías de desarrollo avanzadas: web reactiva.
• Seguir la norma UNE 139803 (WCAG 2.0) como base.
• Utilizar guías profesionales para un diseño accesible sofisticado.
• Considerar los aspectos de accesibilidad que más afectan a los usuarios finales y cubrir esos aspectos con requisitos extra.
• Probar el servicio/producto con usuarios finales

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

Otras reseñas del monográfico:

• Loïc Martínez Normand editor de la monografía sobre "Accesibilidad Web" en Novática, en la ETSI