La WAI: UAAG, ATAG y ARIA

El W3C (World Wide Web Consortium) es el organismo que estandariza las tecnologías de la web: HTML, CSS, XML o SVG salen de ahí. Sus documentos pasan por varias etapas y la más alta es la recomendación, que es lo que en la práctica se considera el estándar.

Dentro del W3C, la WAI (Web Accessibility Initiative) es la iniciativa dedicada a la accesibilidad. No publica una sola norma, sino una familia, y el criterio para repartirlas es a quién obligan: hacer una web accesible no depende solo de quien escribe el contenido, sino también del programa con que se edita y del programa con que se lee.

Las tres siglas parecidas se distinguen por el destinatario: WCAG obliga al contenido, ATAG a la herramienta de autor y UAAG al agente de usuario. Esa es la pregunta típica.

Un agente de usuario es cualquier programa que accede al contenido web y se lo presenta a una persona: navegadores, reproductores multimedia, extensiones, lectores de documentos y las propias tecnologías de apoyo cuando actúan sobre el contenido. Las UAAG dicen qué debe ofrecer ese programa para no ser el eslabón que rompe la cadena.

Ejemplos de lo que exigen: poder ampliar el texto sin romper la maquetación, poder cambiar los colores y las fuentes, poder recorrer y manejar todo con el teclado, poder detener el contenido en movimiento, y exponer el contenido y sus cambios a las tecnologías de apoyo a través de una interfaz de programación.

• Perceptible: la interfaz y el contenido que muestra el agente deben poder percibirse.
• Operable: todo debe poder manejarse, con teclado incluido.
• Comprensible: el comportamiento del agente debe ser previsible y documentado.
• Acceso programático: debe exponer el contenido a las tecnologías de apoyo mediante una interfaz de programación.
• Especificaciones: debe cumplir las especificaciones web aplicables, incluidas las de accesibilidad.

Conviene saber que UAAG 2.0 y ATAG 2.0 no tienen el mismo estatus dentro del W3C: ATAG 2.0 llegó a recomendación en 2015 y UAAG 2.0 se quedó en nota del grupo de trabajo, es decir, en documento informativo. Su contenido sigue siendo la referencia sobre qué debe hacer un navegador, pero no es un estándar formal.

Una herramienta de autor es cualquier programa con el que se produce contenido web: un editor visual de los que muestran el resultado mientras se escribe, un gestor de contenidos, un gestor de blogs, foros o wikis, e incluso un procesador de textos cuando exporta a HTML o a EPUB. Si la herramienta no ayuda, la persona que publica tiene que acordarse de todo a mano, y no se acuerda.

ATAG 2.0 se divide en dos partes, y cada una responde a una forma distinta de fallar. La parte A exige que la interfaz de la propia herramienta sea accesible, para que una persona con discapacidad pueda ser autora y no solo lectora. La parte B exige que la herramienta ayude a producir contenido accesible y que lo haga por defecto. Cada parte se organiza a su vez en cuatro principios.

• Parte A, ejemplo: el panel de administración se puede manejar entero con el teclado y lo anuncia bien un lector de pantalla.
• Parte B, ejemplo: al subir una imagen, la herramienta pide el texto alternativo y avisa si se deja vacío sin marcarla como decorativa.
• Parte B, ejemplo: las plantillas que ofrece de fábrica ya tienen contraste suficiente y una jerarquía correcta de encabezados.
• Parte B, ejemplo: la herramienta comprueba la accesibilidad de lo publicado y ofrece cómo corregirlo, en vez de limitarse a marcarlo en rojo.

ATAG tiene dos partes porque una herramienta puede fallar de dos maneras: que no la pueda usar un autor con discapacidad (parte A) o que permita publicar contenido inaccesible sin decir nada (parte B).

ACT (Accessibility Conformance Testing) es el formato común para escribir las reglas con las que se comprueba la conformidad. Una regla ACT dice a qué elementos se aplica, qué condiciones tienen que cumplirse y qué resultado se obtiene, siempre de la misma forma. Sirve para que dos herramientas distintas que comprueban lo mismo lleguen a la misma conclusión y para que los resultados se puedan comparar.

EARL (Evaluation And Report Language) es el vocabulario, basado en RDF, con el que se expresan los resultados de una evaluación: quién evalúa, qué se ha evaluado, contra qué criterio y con qué resultado. Al ser un formato de datos y no un informe en prosa, permite juntar los resultados de varias herramientas, guardarlos y compararlos en el tiempo.

Regla mnemotécnica: ACT normaliza la entrada del proceso de evaluación, que es la regla que se aplica; EARL normaliza la salida, que es el resultado que se obtiene.

HTML tiene elementos con significado propio: un enlace es un enlace y un campo de formulario es un campo de formulario, y el lector de pantalla sabe anunciarlos. El problema aparece con los componentes que HTML no tiene: pestañas, acordeones, árboles, menús, ventanas modales, deslizadores o autocompletados. Construidos con div y span, para una tecnología de apoyo no son nada.

WAI-ARIA resuelve eso con un conjunto de atributos que no cambian lo que se ve, sino la información que se expone a las tecnologías de apoyo. Se agrupan en tres familias.

• Roles: qué es el elemento. Se declaran con el atributo role y no cambian a lo largo de la vida del componente.
• Propiedades: características estables de ese elemento, como a qué otro elemento controla o qué nombre accesible tiene.
• Estados: lo que cambia mientras se usa, como si está desplegado, seleccionado, deshabilitado o marcado. Los actualiza el código.

<!-- Un desplegable de subtemas hecho con elementos nativos. -->
<button id="btn-subtemas" aria-expanded="false" aria-controls="subtemas-t8">
  Subtemas del tema 8
</button>

<ul id="subtemas-t8" hidden>
  <li><a href="/estudio/desarrollo/accesibilidad/wcag">Las WCAG</a></li>
  <li><a href="/estudio/desarrollo/accesibilidad/rd-1112">Real Decreto 1112/2018</a></li>
</ul>

<!-- role dice qué es; aria-expanded es el estado y lo cambia el código
     al abrir o cerrar; aria-controls es la propiedad que enlaza los dos. -->

La primera regla de ARIA es no usar ARIA: si existe un elemento HTML nativo que ya hace el trabajo, se usa ese. ARIA solo informa, no aporta comportamiento, así que un div con role de botón hay que hacerlo enfocable y programarle la tecla Intro y la barra espaciadora a mano.

Los landmarks o zonas funcionales son roles que estructuran la página en regiones y permiten saltar directamente de una a otra con el lector de pantalla, igual que una persona vidente localiza de un vistazo la cabecera y el menú. Los principales son banner (la cabecera del sitio), navigation (los bloques de navegación), main (el contenido principal, uno por página), complementary (contenido relacionado), search (el buscador), form y contentinfo (el pie).

En HTML actual casi todos tienen un elemento nativo equivalente: header, nav, main, aside, footer y form. Usar el elemento nativo es preferible a poner el rol a mano, y es exactamente lo que dice la primera regla de ARIA.

El atributo tabindex controla el foco del teclado. Con valor cero, el elemento entra en el orden natural de tabulación, que es el del código; con valor menos uno, deja de estar en ese recorrido pero se le puede dar el foco desde el código, que es lo que se hace al abrir una ventana modal; con valores positivos se fuerza un orden propio, y eso se desaconseja porque desordena la página entera y es imposible de mantener.

Las regiones dinámicas o live regions resuelven un problema que no existe para quien ve la pantalla: cuando una parte de la página cambia sola, sin que la persona haya hecho nada, un lector de pantalla no se entera. El atributo aria-live marca esa zona para que su contenido se anuncie al cambiar. Con el valor polite el aviso espera a que el lector termine lo que estaba diciendo; con assertive interrumpe, y por eso se reserva a errores y avisos críticos.

<!-- Estructura por landmarks usando los elementos nativos. -->
<header>...</header>
<nav aria-label="Temario">...</nav>
<main>
  <h1>Tema 8. Accesibilidad, diseño universal, usabilidad</h1>

  <!-- El contador se actualiza solo al corregir cada pregunta:
       sin aria-live, el lector de pantalla no diría nada. -->
  <p id="marcador" aria-live="polite">
    Llevas 6 aciertos de 8. Te quedan 2 preguntas.
  </p>

  <!-- Un error de validación sí interrumpe. -->
  <p id="error-test" role="alert">
    Selecciona una opción antes de continuar.
  </p>
</main>
<footer>...</footer>

role="alert" equivale a una región dinámica con aria-live assertive. Se usa para lo que no puede esperar; para un marcador o un contador se usa polite, o el lector interrumpirá a la persona cada pocos segundos.