Addaw, ir a inicio Donar

Fallo común WCAG 2.2

F103Mensajes de estado que el lector de pantalla no anuncia

Nombre oficial en el W3C: Fallo del criterio de conformidad 4.1.3 debido a proporcionar mensajes de estado que no pueden determinarse por software mediante funciones o propiedades

En pocas palabras

Un mensaje de estado es un aviso que aparece sin mover el foco: «Producto añadido al carrito», «0 resultados», «Enviando…». El error es mostrarlo sin marcarlo con role="status", role="alert", role="log" o aria-live. Así el lector de pantalla no lo lee y la persona no se entera.

Por qué es importante

Un lector de pantalla (programa que lee en voz alta lo que hay en la pantalla) lee la parte de la página donde está el usuario. Si un aviso aparece en otro sitio, no lo anuncia por sí solo.

Así, una persona ciega pulsa «Buscar» y no sabe si hay resultados. O envía un formulario de cita previa y no oye que falta un dato. Tiene que recorrer la página entera para adivinar qué ha pasado.

Cómo evitarlo

  1. Localice los mensajes de estado: textos que aparecen tras una acción, sin mover el foco, y que informan de un resultado, una espera, un progreso o un error.
  2. Ponga al contenedor del mensaje role="status" para avisos normales, o role="alert" para errores y avisos urgentes.
  3. Para zonas que se van ampliando, como un chat o un historial, use role="log". También sirven aria-live="polite", aria-live="assertive" o el elemento <output>.
  4. Ese contenedor debe estar en la página desde el principio, aunque esté vacío. Después, cambie solo su texto. Si se crea a la vez que el mensaje, muchos lectores de pantalla no lo leen.
  5. Si el aviso recibe el foco o lleva a otra página, no es un mensaje de estado y no necesita estas marcas.

Cómo comprobarlo

  1. Hacer las acciones que muestran avisos: buscar, añadir al carrito, enviar un formulario, subir un archivo.
  2. Confirmar que el aviso aparece sin mover el foco y que informa de un resultado, una espera, un progreso o un error.
  3. Con las herramientas del navegador (F12), revisar si el contenedor ya tenía role="status", alert, log o aria-live antes de que apareciera el texto.
  4. Repetir la acción con un lector de pantalla (NVDA, JAWS o VoiceOver). Si no anuncia el aviso, hay fallo.

Ejemplo

Código correcto: la zona del aviso existe vacía desde el principio y el script solo cambia su texto.

<form role="search">
  <label for="q">Buscar en la web</label>
  <input id="q" type="search">
  <button>Buscar</button>
</form>
<p id="aviso" role="status"></p>
<script>
  // Tras hacer la búsqueda:
  document.getElementById('aviso').textContent =
    'No hay resultados para su búsqueda.';
</script>
Ver el texto completo del W3C (traducción al español)

Aplicabilidad

Tecnologías compatibles con Accessible Rich Internet Applications (WAI-ARIA).

Descripción

El objetivo de esta técnica es describir un fallo en el que se usan mensajes de estado en el contenido pero no se comunican al usuario por falta de las funciones (roles) o propiedades adecuadas.

El primer paso para confirmar un fallo de Mensajes de estado es comprobar que el nuevo contenido dinámico se ajusta a la definición de mensaje de estado. Hay dos criterios que determinan si el contenido modificado de una página constituye un mensaje de estado:

  1. el nuevo contenido no recibe el foco (no cambia el contexto);
  2. el nuevo contenido proporciona al usuario información sobre el resultado de una acción, el estado de una aplicación, el progreso de un proceso o la existencia de errores.
Cuando el contenido actualizado no se ajusta a la definición de mensajes de estado, no se ha producido un fallo del criterio de conformidad 4.1.3 Mensajes de estado.

El segundo paso de esta técnica de fallo consiste en examinar el código. Cuando el contenido dinámico se ajusta a la definición de mensaje de estado, puede examinarse su contenedor en busca de una función (role) o propiedad WAI-ARIA adecuada que permita determinarlo por software como mensaje de estado. Actualmente solo existe un pequeño número de técnicas disponibles para indicar mensajes de estado a las tecnologías de asistencia. Son las siguientes:

  • el elemento output de HTML
  • role="status"
  • role="alert"
  • role="log"
  • el uso de un atributo aria-live en un elemento, con el valor «polite» o «assertive»
La ausencia de todas estas técnicas hace prever que el mensaje de estado no se anunciará al usuario y, por tanto, un fallo. Además, si la función o la propiedad no se establece antes de añadir el contenido dinámico, esto también hace prever un fallo.

Dado que pueden existir técnicas adicionales para alertar a una tecnología de asistencia, el último paso de esta técnica de fallo consiste en confirmar si una tecnología de asistencia (como un lector de pantalla) detecta el contenido dinámico y expone la información a los usuarios. Cuando existe un mensaje de estado pero la tecnología de asistencia no lo hace aflorar, se confirma que se ha producido un fallo.

Ejemplos

Incluir un mensaje de resultados de búsqueda sin la función status

Cuando un usuario realiza una búsqueda pulsando un botón «Search» (buscar), el contenido de la página se actualiza con los resultados de la búsqueda, que se muestran en una sección situada debajo del botón. Como la búsqueda no obtiene resultados, el cambio en el contenido transmite el mensaje de estado «0 results returned» (se han devuelto 0 resultados). A este texto no se le asigna una función adecuada para un mensaje de estado, por lo que un lector de pantalla no anunciará «Zero results returned» (cero resultados devueltos) a menos que el usuario se desplace hasta ese texto. Dado que el mensaje de estado no se presenta automáticamente al usuario (es decir, la persona tiene que descubrirlo manualmente), falla el criterio de conformidad 4.1.3.

Ejemplo práctico: mensaje de resultados de búsqueda sin la función adecuada

Pruebas

Procedimiento

Para el contenido que se añade dinámicamente a la página:

  1. Comprobar que el elemento que contiene el contenido actualizado no recibe el foco.
  2. Comprobar que el nuevo contenido proporciona al usuario información sobre alguno de los siguientes aspectos:
    • el éxito o el resultado de una acción
    • el estado de espera de una aplicación
    • el progreso de un proceso
    • la existencia de errores
  3. Comprobar que el elemento que contiene el nuevo contenido no tiene previamente una función (role) ARIA status, alert o log, ni un atributo aria-live.
  4. Comprobar que la tecnología de asistencia no hace aflorar (es decir, no anuncia) el mensaje de estado.

Resultados esperados

  • Si las comprobaciones n.º 1 a n.º 4 son todas verdaderas, entonces el contenido falla el criterio de conformidad.

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 F103 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.