Leer la especificación: la ficha de cada rol, ARIA in HTML y la APG

Muchos de los errores que catalogaremos en la última lección de teoría se evitan con una consulta de dos minutos antes de escribir un atributo. La duda «¿puedo poner aria-label aquí?» o «¿qué necesita un role="tab" para funcionar?» tiene una respuesta exacta y pública. En la lección anterior viste el vocabulario de roles, estados y propiedades; en esta aprenderás a leer los documentos que lo definen, para que dejes de depender de fragmentos copiados y de respuestas de foros.

El mapa de documentos

Bajo el nombre genérico de «ARIA» conviven varios documentos del W3C con funciones distintas. Saber cuál consultar en cada caso ahorra mucho tiempo:

En el día a día bastan tres: WAI-ARIA (qué es cada cosa), ARIA in HTML (dónde puedes ponerla) y la APG (cómo se comporta un patrón completo).

Anatomía de la ficha de un rol

Cada rol de WAI-ARIA 1.2 tiene una definición en prosa seguida de una tabla de características. La tabla está en inglés y es muy compacta, pero cada fila responde a una pregunta práctica:

• Is Abstract (rol abstracto). Roles como widget, structure, landmark, input, command, composite, section, select, range o window solo existen para ordenar la taxonomía. Nunca se escriben en el atributo role: role="widget" no significa nada para el navegador.
• Superclass Role / Subclass Roles (herencia). switch es subclase de checkbox y por eso hereda aria-checked; searchbox es subclase de textbox. La herencia explica qué atributos tiene un rol aunque no aparezcan en su propia lista.
• Base Concept / Related Concepts (equivalentes). Indican el elemento HTML o el concepto en que se inspira el rol: el de checkbox remite a <input type="checkbox">. Si hay un equivalente nativo, la regla 1 te dice que lo uses.
• Required Context Role (contexto obligatorio). Dónde debe estar el rol: tab dentro de tablist, option dentro de listbox (o de un group dentro de él), listitem dentro de list.
• Required Owned Elements (hijos obligatorios). Lo que el rol debe contener: tablist contiene tab, list contiene listitem, listbox contiene option.
• Required States and Properties (atributos obligatorios). Sin ellos el componente está incompleto: checkbox y switch exigen aria-checked; slider, aria-valuenow; heading, aria-level.
• Supported / Inherited States and Properties (atributos admitidos). Todo lo que el rol acepta, propio o heredado. Lo que no aparece aquí ni entre los atributos globales no tiene efecto en ese rol.
• Prohibited States and Properties (atributos prohibidos). Por ejemplo, el rol generic (el de <div> y <span>) prohíbe aria-label y aria-labelledby. Es la explicación formal de lo que vimos en la lección anterior: un aria-label en un <div> sin rol no sirve.
• Name From (origen del nombre). contents si el nombre puede salir del texto interior (botones, enlaces, pestañas); author si debe darlo quien desarrolla con aria-label, aria-labelledby o un <label> (campos, diálogos, listas de opciones); prohibited si el rol no admite nombre.
• Accessible Name Required (nombre obligatorio). Si es True, un elemento con ese rol sin nombre es un error de 4.1.2.
• Children Presentational (hijos presentacionales). Si es True, el contenido se aplana, como viste en la lección sobre el árbol de accesibilidad.
• Implicit Value for Role (valores por defecto). Por ejemplo, en slider el mínimo implícito es 0 y el máximo 100 si no indicas aria-valuemin y aria-valuemax.

ARIA in HTML: lo que puedes poner en cada elemento

La especificación WAI-ARIA define los roles en abstracto; ARIA in HTML aterriza esas reglas en HTML. Para cada elemento indica su rol implícito, qué roles se le pueden asignar y qué atributos aria-* admite. Algunas consecuencias que conviene conocer:

• Hay elementos que no admiten ningún rol, como <label> o <input type="password">. Otros admiten pocos: una imagen con alt="" solo puede llevar role="none" o role="presentation", y ningún atributo ARIA salvo aria-hidden.
• No dupliques el estado nativo. En un <input type="checkbox"> no se debe usar aria-checked: el estado lo da la propiedad checked. Del mismo modo, si un campo tiene required o disabled, el equivalente ARIA sobra, y contradecirlo (required con aria-required="false") es un error.
• Los roles redundantes se desaconsejan: <nav role="navigation"> o <button role="button"> no aportan nada.
• Permitido no significa recomendable. ARIA in HTML permite, por ejemplo, poner role="tab" en un <h2>, pero hacerlo destruye el encabezado. La regla 2 de la primera lección sigue mandando.

<input type="checkbox" id="lopd" aria-checked="true">
<label for="lopd" role="button">Acepto la política de privacidad</label>
<img src="separador.png" alt="" aria-label="Separador">

La APG: guía, no norma

La ARIA Authoring Practices Guide describe decenas de patrones (acordeón, diálogo, pestañas, combobox, árbol, deslizador…). Cada patrón incluye una tabla de interacción con el teclado, otra de roles, estados y propiedades, y ejemplos funcionales. Es la referencia más útil para construir componentes, y la usaremos a fondo en el curso N3-C5. Al consultarla, ten presentes tres cautelas:

• No es normativa. No forma parte de WCAG ni de la EN 301 549 (PDF, se abre en una ventana nueva). Un componente puede cumplir 4.1.2 sin seguir la APG al pie de la letra, y uno que la copie puede incumplir si se adapta mal.
• Sus ejemplos demuestran patrones, no son código de producción. La propia guía advierte de que el soporte en navegadores y lectores varía y de que hay que probar.
• Elige el patrón por la función, no por el aspecto. El patrón de menú está pensado para menús de aplicación; la navegación de un sitio no es un menu aunque visualmente se despliegue.

La APG incluye también páginas de prácticas transversales, como las dedicadas a los nombres y descripciones accesibles o a la interfaz de teclado.

Un método de consulta en cinco minutos

1. ¿Existe un elemento HTML? Mira el concepto base del rol y la tabla de ARIA in HTML. Si existe, úsalo y quizá no necesites ARIA.
2. Lee la ficha del rol: contexto obligatorio, hijos obligatorios, atributos obligatorios, origen del nombre e hijos presentacionales.
3. Comprueba ARIA in HTML: ¿se permite ese rol en el elemento sobre el que lo vas a poner?
4. Abre el patrón de la APG: teclado esperado y estados que hay que actualizar.
5. Prueba el soporte con los lectores de pantalla de tu público, como vimos en la lección sobre el árbol de accesibilidad.

Referencias: WAI-ARIA 1.2, ARIA in HTML y ARIA Authoring Practices Guide.

Resumen

• WAI-ARIA 1.2 define qué es cada rol y atributo; ARIA in HTML, dónde se puede usar; la APG, cómo se implementa cada patrón.
• La ficha de un rol responde a las preguntas clave: contexto y hijos obligatorios, atributos obligatorios, admitidos y prohibidos, origen del nombre e hijos presentacionales.
• No dupliques ni contradigas el estado nativo con ARIA, y recuerda que «permitido» no equivale a «recomendable».
• La APG es informativa: guía excelente, pero no es norma ni código listo para producción.
• Antes de escribir un atributo, sigue el método: HTML nativo, ficha del rol, ARIA in HTML, APG y prueba real.