Fallo común WCAG 2.2
F79Menús y listas a medida que no informan de dónde está el foco
Nombre oficial en el W3C: Fallo del criterio de conformidad 4.1.2 debido a que el estado de foco de un componente de interfaz de usuario no es determinable por software o no hay notificación disponible del cambio de estado de foco
En pocas palabras
Este fallo aparece en menús, listas o pestañas programados a mano. El componente resalta en pantalla la opción activa, pero no informa al navegador de qué opción tiene el foco. Así, el lector de pantalla no sabe qué leer y el ampliador no sabe qué zona mostrar.
Por qué es importante
El foco es el punto de la página que recibe lo que se pulsa en el teclado. Los lectores de pantalla (programas que leen en voz alta lo que hay en la pantalla) leen el elemento que tiene el foco. Los ampliadores de pantalla mueven la zona ampliada hasta él.
Con los botones y campos normales de HTML, el navegador hace este trabajo solo. En un componente hecho a medida, el resaltado puede ser solo un cambio de color. La persona ciega oye «menú», pero no la opción en la que está. Quien usa un ampliador ve otra parte de la página. Al final, puede elegir la opción equivocada.
Cómo evitarlo
- Use elementos nativos siempre que pueda:
button,select,aoinput. Informan del foco sin trabajo extra. - En un componente a medida, mueva el foco de verdad a la opción activa con
focus(). Para recibirlo, las opciones necesitantabindex: 0 en la activa y -1 en las demás. - Otra opción: deje el foco en el contenedor y señale la opción activa con
aria-activedescendant. Cambie su valor cada vez que cambie la opción. - Dé a cada parte su función con ARIA, por ejemplo
role="listbox"yrole="option". Así el lector puede anunciarla bien. - No se limite a cambiar una clase CSS para resaltar la opción. El cambio debe llegar también al navegador.
Cómo comprobarlo
- Recorra el componente con el teclado: Tab y las flechas.
- Active un lector de pantalla, como NVDA en Windows o VoiceOver en Mac. Compruebe que anuncia la opción nueva con cada movimiento.
- En la consola de las herramientas del navegador (F12), escriba
document.activeElement. Verá qué elemento tiene el foco. Si es el contenedor, debe señalar la opción conaria-activedescendant. - Si el lector solo anuncia el nombre del menú, o repite siempre la misma opción, hay fallo.
Ejemplo
Lista a medida que señala la opción activa con aria-activedescendant; un script cambia ese valor al pulsar las flechas.
<ul role="listbox" tabindex="0" aria-label="Provincia"
aria-activedescendant="prov-2">
<li role="option" id="prov-1">Alicante</li>
<li role="option" id="prov-2" aria-selected="true">Murcia</li>
<li role="option" id="prov-3">Valencia</li>
</ul>
<!-- Al pulsar las flechas, el script actualiza
aria-activedescendant y aria-selected -->
Ver el texto completo del W3C (traducción al español)
Esta es una traducción no oficial al español de la técnica F79 de Techniques for WCAG 2.2, del W3C. Puede contener errores. El único documento oficial y normativo es la versión original en inglés, publicada en el sitio web del W3C.
Aplicabilidad
Todas las tecnologías
Descripción
Que un componente de interfaz de usuario tenga el foco es una faceta especialmente importante de su estado. Muchos tipos de tecnología de asistencia dependen del seguimiento del foco actual del teclado. Los lectores de pantalla mueven el punto de atención del usuario al componente de interfaz de usuario que tiene el foco, y los magnificadores de pantalla cambian la visualización del contenido para que el componente enfocado sea visible. Si no se notifica a la tecnología de asistencia cuando el foco se mueve a un componente nuevo, el usuario se confundirá al intentar interactuar con el componente equivocado.
Aunque los agentes de usuario suelen gestionar esta funcionalidad para los controles estándar, los componentes de interfaz de usuario programados a medida son responsables de usar las API de accesibilidad para que la información y las notificaciones del foco estén disponibles.
Ejemplos
Un menú personalizado muestra los elementos de menú dibujándolos de forma explícita, gestionando directamente los eventos de ratón y de teclado y resaltando el elemento de menú seleccionado en cada momento. El programador no expone a través de la API de accesibilidad qué elemento de menú tiene el foco, por lo que la tecnología de asistencia solo puede determinar que el foco está en algún lugar del menú y no puede determinar qué elemento de menú lo tiene.
Pruebas
Procedimiento
- Usando el verificador de accesibilidad de la tecnología (o, si no está disponible, inspeccionando el código o probando con una tecnología de asistencia), comprobar si los controles exponen el estado de foco a través de la API de accesibilidad.
- Usando el verificador de accesibilidad de la tecnología (o, si no está disponible, inspeccionando el código o probando con una tecnología de asistencia), comprobar si se notifica a la tecnología de asistencia cuando el foco pasa de un control a otro.
Resultados esperados
- Si la comprobación n.º 1 o la comprobación n.º 2 es falsa, se da esta condición de fallo y el contenido falla este criterio de conformidad.
Recursos
Cómo lo comprobamos en ADDAW
Este error es uno de los que buscamos en cada auditoría de ADDAW. Se lo entregamos con capturas y la forma de corregirlo.
Basado en la técnica F79 del W3C (WCAG 2.2). Explicación y ejemplos: ADDAW. Traducción no oficial del texto del W3C © W3C, licencia de documentos del W3C. ¿Ha visto un error? Escríbanos.