Addaw, ir a inicio Donar

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

  1. Use elementos nativos siempre que pueda: button, select, a o input. Informan del foco sin trabajo extra.
  2. En un componente a medida, mueva el foco de verdad a la opción activa con focus(). Para recibirlo, las opciones necesitan tabindex: 0 en la activa y -1 en las demás.
  3. 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.
  4. Dé a cada parte su función con ARIA, por ejemplo role="listbox" y role="option". Así el lector puede anunciarla bien.
  5. No se limite a cambiar una clase CSS para resaltar la opción. El cambio debe llegar también al navegador.

Cómo comprobarlo

  1. Recorra el componente con el teclado: Tab y las flechas.
  2. Active un lector de pantalla, como NVDA en Windows o VoiceOver en Mac. Compruebe que anuncia la opción nueva con cada movimiento.
  3. 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 con aria-activedescendant.
  4. 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

  1. 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.
  2. 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.

Solicitar una auditoría

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.