Cómo funciona la accesibilidad: la cadena de componentes

Cuando una persona ciega compra un billete de tren desde su móvil, en esa compra intervienen muchas piezas a la vez: la web de la compañía, el navegador, el sistema operativo, el lector de pantalla, la herramienta con la que se publicó el contenido y la propia experiencia de esa persona. La accesibilidad no es una propiedad aislada de una página, sino el resultado de que todas esas piezas encajen. En esta lección vemos cuáles son, cómo se pasan la información unas a otras y qué parte de la cadena depende de ti.

Los componentes esenciales según el W3C

La Iniciativa de Accesibilidad Web (WAI) del W3C describe la accesibilidad web como un sistema de componentes que dependen unos de otros, en su documento Essential Components of Web Accessibility. Son estos:

• Contenido: todo lo que hay en una página o aplicación web: textos, imágenes, sonidos y vídeos, y también el código o marcado que define su estructura y su comportamiento.
• Agentes de usuario: los programas que muestran el contenido a la persona, sobre todo navegadores y reproductores multimedia.
• Tecnologías de apoyo: lectores de pantalla, magnificadores, teclados alternativos, pulsadores, software de reconocimiento de voz… Las estudiarás con detalle en el curso «Personas y tecnologías de apoyo».
• Conocimientos y estrategias de las personas usuarias: su experiencia con el navegador y con su tecnología de apoyo, y las estrategias que han desarrollado para moverse por la web.
• Desarrolladores, en sentido amplio: quienes diseñan, programan y redactan, y también las personas usuarias que publican contenido (un comentario, una reseña, un vídeo).
• Herramientas de autor: el software con el que se crea el contenido: gestores de contenidos o CMS (content management system, como WordPress o Drupal), editores de texto enriquecido, generadores de PDF, plataformas de formularios y herramientas de diseño.
• Herramientas de evaluación: validadores, comprobadores automáticos, analizadores de contraste y similares.

Para cada grupo de componentes existen unas pautas de referencia del W3C. Las WCAG (Pautas de Accesibilidad para el Contenido Web) se ocupan del contenido. Las ATAG 2.0 (Pautas de Accesibilidad para Herramientas de Autor, 2015) piden dos cosas a esas herramientas: que las pueda usar una persona con discapacidad y que ayuden a producir contenido accesible. Las UAAG 2.0 (Pautas de Accesibilidad para Agentes de Usuario, publicadas como nota técnica en 2015) orientan a navegadores y reproductores. La ley y las auditorías se centran en las WCAG, pero conviene conocer las otras dos, sobre todo al contratar un CMS.

Cómo viaja la información hasta la persona

Un lector de pantalla no «mira» la página como lo hace una persona que ve. El recorrido de la información es, simplificando, este:

1. El servidor envía el código: HTML para la estructura, CSS para la presentación y JavaScript para el comportamiento.
2. El navegador interpreta ese código y construye el DOM (Document Object Model), la representación interna de la página con todos sus elementos.
3. A partir del DOM, el navegador genera el árbol de accesibilidad: una versión simplificada en la que cada elemento tiene un rol (botón, enlace, encabezado, casilla de verificación), un nombre («Comprar billete») y, si procede, un estado (marcada, desplegado, desactivado).
4. El navegador expone ese árbol al sistema operativo mediante sus interfaces de programación de accesibilidad, distintas en Windows, macOS, iOS, Android o Linux.
5. La tecnología de apoyo consulta esas interfaces y convierte la información en voz, braille, ampliación o comandos de voz.

La consecuencia práctica es sencilla: si el código no dice qué es cada cosa, el navegador no puede contarlo y la tecnología de apoyo no puede inventarlo. Verás el árbol de accesibilidad en detalle en el curso de HTML semántico del nivel 3.

<!-- Incorrecto: el enlace no tiene nombre -->
<a href="/"><img src="logo_ayto_v3.png"></a>

<!-- Correcto: el texto alternativo da nombre al enlace -->
<a href="/"><img src="logo_ayto_v3.png" alt="Ayuntamiento de Villaserena: página de inicio"></a>

Cuando un eslabón falla

Como los componentes dependen unos de otros, un fallo en cualquiera de ellos repercute en los demás. Estos son algunos casos habituales:

• Una herramienta de autor que no ayuda: un CMS que no tiene campo para el texto alternativo, o un editor que convierte los títulos en texto en negrita en lugar de en encabezados. Quien redacta quiere hacerlo bien y la herramienta se lo impide.
• Contenido que no aprovecha lo que el navegador ya ofrece: un desplegable construido con <div> y JavaScript que imita a un <select>, pero no informa de su rol, de la opción elegida ni de si está abierto o cerrado.
• Un agente de usuario o una tecnología de apoyo sin soporte: una característica reciente de HTML o de ARIA que algunos navegadores o lectores de pantalla todavía no interpretan bien.
• Una persona usuaria que aún está aprendiendo: alguien que acaba de perder visión y todavía no domina su lector de pantalla depende más que nadie de que la web sea sencilla, coherente y predecible.

El W3C describe también el círculo virtuoso contrario: cuando navegadores y tecnologías de apoyo soportan bien una característica, los desarrolladores la usan y las herramientas de autor la incorporan, y producir contenido accesible deja de exigir un esfuerzo especial. Si un componente falla, los demás recurren a parches frágiles y caros.

«Funciona en mi navegador» no basta

Las WCAG introducen un concepto que aquí solo apuntamos: las tecnologías deben usarse de una forma compatible con la accesibilidad (en inglés, accessibility supported), es decir, de un modo que funcione con los navegadores y las tecnologías de apoyo que la gente usa realmente. No basta con que el código sea técnicamente válido ni con que funcione en el ordenador del equipo de desarrollo.

Esto tiene dos consecuencias prácticas. La primera: lo más seguro es usar los elementos nativos de HTML (<button>, <a>, <input>, <select>), que navegadores y tecnologías de apoyo llevan años soportando y que ya incluyen rol, nombre, estado y manejo con teclado. La segunda: las pruebas deben hacerse con varias combinaciones reales, por ejemplo NVDA con Firefox o Chrome en Windows, VoiceOver con Safari en iPhone y TalkBack con Chrome en Android, y no con una sola. Aprenderás a hacerlo en el nivel de auditoría.

Las preferencias del sistema también son parte de la cadena

Un eslabón que a menudo se olvida son los ajustes que la persona ya tiene configurados en su dispositivo: tamaño del texto, zoom, modo oscuro, alto contraste, reducción de movimiento o subtítulos activados por defecto. Una web accesible respeta esos ajustes en lugar de anularlos: no bloquea el zoom en el móvil, no fija tamaños que impiden agrandar el texto y no ignora la preferencia de movimiento reducido. Por eso un botón propio para «agrandar la letra» no sustituye a que la página funcione bien con el zoom del navegador, que la persona ya conoce.

Resumen

• La accesibilidad depende de una cadena: contenido, agentes de usuario, tecnologías de apoyo, conocimientos de la persona, desarrolladores y herramientas de autor y de evaluación.
• Las WCAG cubren el contenido; las ATAG (se abre en una ventana nueva), las herramientas de autor; las UAAG, los navegadores y reproductores.
• El navegador traduce el código en un árbol de accesibilidad con rol, nombre y estado: si el código no lo dice, la tecnología de apoyo no puede saberlo.
• Lo más fiable es usar HTML nativo y probar con varias combinaciones reales de navegador y tecnología de apoyo.
• Una web accesible respeta las preferencias que la persona ya tiene configuradas en su dispositivo.