Robusto: 4.1.2 Nombre, función, valor y 4.1.3 Mensajes de estado (4.1.1 eliminado)

El principio Robusto garantiza que el contenido pueda ser interpretado por una amplia variedad de agentes de usuario y tecnologías de apoyo, hoy y en el futuro. En WCAG 2.2 se reduce a dos criterios operativos, 4.1.2 y 4.1.3, pero ambos son enormes: el primero es el criterio que se incumple en casi todos los componentes personalizados mal construidos, y el segundo determina si las personas usuarias de lector de pantalla se enteran de lo que ocurre sin verlo. Esta lección explica cómo evaluarlos y por qué 4.1.1 ha dejado de existir; la lección 7 la completa con una tabla de referencia por patrón y los escenarios dinámicos más habituales.

Qué ha pasado con 4.1.1 Procesamiento

El criterio 4.1.1 exigía que el marcado tuviera etiquetas de inicio y fin completas, anidamiento correcto, sin id duplicados y sin atributos duplicados. Nació en 2008 para evitar que marcado malformado rompiera las tecnologías de apoyo, que entonces analizaban el HTML directamente. Hoy los navegadores reparan el HTML y construyen un DOM y un árbol de accesibilidad coherentes; las tecnologías de apoyo leen ese árbol. Por eso WCAG 2.2 eliminó 4.1.1 y el W3C publicó una errata para 2.0 y 2.1 que lo considera siempre satisfecho en contenido HTML o XML. Un id duplicado solo es un fallo si repercute en otro criterio: si rompe un label for (1.3.1, 4.1.2) o una referencia aria-describedby (3.3.1). En el informe, no cites 4.1.1; redirige al criterio afectado.

4.1.2 Nombre, función, valor (A)

Para todos los componentes de interfaz (enlaces, campos, botones, controles generados por script), el nombre y la función (rol) pueden determinarse programáticamente; los estados, propiedades y valores que el usuario puede establecer pueden determinarse y establecerse programáticamente; y la notificación de sus cambios está disponible para las tecnologías de apoyo. Con HTML nativo bien usado se cumple solo; el criterio se incumple sobre todo en componentes personalizados.

Nombre

El nombre accesible se calcula según el algoritmo de la especificación Accessible Name and Description Computation: primero aria-labelledby, luego aria-label, luego el mecanismo nativo (label, contenido del botón, alt, legend), luego title. Fallos: botones de icono sin nombre («botón» a secas); enlaces con imagen sin alt; campos sin etiqueta asociada; aria-labelledby apuntando a un id inexistente; nombres iguales para controles distintos («Eliminar» ×20 en una tabla, sin contexto accesible); nombres que no contienen la etiqueta visible (también 2.5.3).

Función (rol)

El rol indica qué es el elemento: botón, enlace, casilla, pestaña, cuadro de diálogo. Fallos: div y span clicables sin rol; enlaces (<a href="#">) que actúan como botones; role="button" en un enlace que navega; roles inventados o mal escritos; roles ARIA sin los hijos requeridos (tablist sin tab, menu sin menuitem).

Estado y valor

Expandido/contraído (aria-expanded), seleccionado (aria-selected), marcado (aria-checked), presionado (aria-pressed), deshabilitado, inválido, valor actual de un slider (aria-valuenow, aria-valuetext), página actual (aria-current="page"). Fallos: acordeones y menús sin aria-expanded o con el valor sin actualizar; pestañas sin aria-selected; interruptores personalizados sin aria-checked; estados comunicados solo con una clase CSS.

<!-- Incorrecto: sin rol, sin nombre útil, sin estado -->
<div class="acordeon-cab activo" onclick="toggle(this)">
  <span class="icono-flecha"></span> Requisitos
</div>

<!-- Correcto: botón nativo con estado y relación con el panel -->
<h3>
  <button type="button" aria-expanded="true" aria-controls="panel-req">
    Requisitos
  </button>
</h3>
<div id="panel-req">…</div>

Cómo evaluarlo

1. Inventario de componentes interactivos de la página y de sus estados.
2. Para cada uno, consulta el árbol de accesibilidad (panel Accessibility de Chrome, Inspector de accesibilidad de Firefox) y anota nombre, rol y estados calculados.
3. Opera el componente con teclado y comprueba que los estados cambian en el árbol.
4. Escucha con NVDA y con otro lector de la línea base: ¿se anuncian nombre, rol y estado? ¿y el cambio de estado?
5. Contrasta con el patrón de la ARIA Authoring Practices Guide correspondiente.

4.1.3 Mensajes de estado (AA)

Un mensaje de estado es el que informa al usuario del resultado o estado de una acción, de un proceso en curso o de un error, sin recibir el foco y sin suponer un cambio de contexto. El criterio exige que pueda determinarse programáticamente mediante rol o propiedades, para que las tecnologías de apoyo lo presenten sin que el usuario tenga que buscarlo. Ejemplos: «Se han encontrado 12 resultados», «Producto añadido al carrito», «Guardando…», «3 errores en el formulario» (cuando el foco no se mueve), contadores de caracteres.

Técnicas: role="status" (equivale a aria-live="polite") para confirmaciones y resultados; role="alert" (aria-live="assertive") para errores urgentes; role="log" para chats; role="progressbar" con valores para progreso. El contenedor debe existir en el DOM antes de que se inserte el mensaje; insertar el contenedor con el mensaje ya dentro suele no anunciarse. Qué no es 4.1.3: si el mensaje recibe el foco (un modal de confirmación, un resumen de errores al que se mueve el foco), el criterio no aplica, porque el foco ya lo anuncia; si el cambio es de contexto (nueva página), tampoco.

Fallos: resultados de filtros que se actualizan en silencio; «añadido al carrito» solo visual; toasts sin región viva; indicador de carga sin anuncio (el usuario de lector no sabe si pasó algo); contador de caracteres sin aria-live (o con assertive, interrumpiendo cada tecla); uso excesivo de aria-live="assertive".

Pruebas combinadas y documentación

Los fallos de 4.1.2 suelen ir acompañados de 2.1.1 (si el componente no es nativo, rara vez tiene teclado) y de 1.3.1; los de 4.1.3, de 3.3.1 cuando se trata de errores. En el hallazgo, indica nombre, rol y estado observados en el árbol de accesibilidad frente a los esperados, el anuncio literal del lector y el patrón APG (se abre en una ventana nueva) que debería seguirse. Para 4.1.3, documenta la acción, el mensaje visual y lo que anunció (o no) el lector, junto con el fragmento de DOM del contenedor.

Resumen

• 4.1.1 ha sido eliminado en WCAG 2.2 (y declarado siempre satisfecho en 2.0 y 2.1); los errores de marcado solo son hallazgo si afectan a otro criterio.
• 4.1.2: todo componente tiene nombre, rol y estados determinables y actualizados; se evalúa con el árbol de accesibilidad, el teclado y el lector, frente a los patrones de la APG.
• El nombre accesible sigue un algoritmo de prioridad (aria-labelledby, aria-label, nativo, title); los botones de icono sin nombre son el fallo más común.
• 4.1.3: los mensajes de estado que no reciben el foco se comunican con role="status", alert, log o progressbar, en contenedores presentes de antemano.
• Ni demasiado poco ni demasiado: sin anuncios el usuario no sabe qué pasa; con regiones vivas en exceso, no puede usar la página.