Regiones vivas de ARIA

Las regiones vivas de ARIA (aplicaciones de Internet enriquecidas accesibles) marcan áreas de una página web cuyo contenido cambia. Permiten que los lectores de pantalla, programas que presentan el contenido mediante voz o braille, anuncien actualizaciones como «¡Se añadió al carrito!». Estos anuncios pueden informarte mientras sigues en el mismo control. Prueba esto: añade un artículo a un carrito y escucha la confirmación con un lector de pantalla.

Una región viva es un área de una página web que se marca en el código, por ejemplo con aria-live, para que los programas de asistencia puedan detectar cambios y anunciar actualizaciones. En un carrito de compras hipotético, prepara una región vacía con aria-live='polite' en el código inicial de la página antes de insertar «¡Se añadió al carrito!». Dale tiempo a la tecnología de asistencia para reconocer la región antes de actualizarla; crear la región y su mensaje al mismo tiempo puede dar resultados poco fiables. Este enfoque presupone que la combinación de navegador y lector de pantalla lo admite [1].

El atributo aria-live solicita una prioridad para los anuncios. Por lo general, 'polite' permite anunciar las actualizaciones cuando no estás interactuando; 'assertive' solicita un anuncio urgente y puede interrumpir la lectura en voz alta. Reserva assertive para información crítica que necesite atención inmediata. El momento exacto del anuncio y las interrupciones varían según la combinación de navegador y lector de pantalla. 'off' no significa que nunca se anuncien las actualizaciones: se espera que se anuncien cuando el foco, el punto actual de interacción, esté en la región o en alguno de sus elementos [1].

El atributo aria-atomic controla si una actualización debe presentar toda la región o solo el contenido que cambió. Supón que un carrito muestra «Carrito: 2 artículos» y solo cambia el número a 3. Un anuncio del fragmento «3» podría carecer de contexto; aria-atomic='true' solicita el mensaje completo «Carrito: 3 artículos». Úsalo cuando haga falta el texto que rodea al cambio, sin asumir que es la mejor opción para cualquier error de formulario [1] [2].

El atributo aria-relevant selecciona los tipos de cambios relevantes: elementos añadidos, elementos eliminados o cambios en el texto. Su valor predeterminado incluye los elementos añadidos y los cambios en el texto. Por ejemplo, una lista de participantes de un chat puede incluir las eliminaciones cuando sea importante saber quién se ha ido. Mantener aria-atomic='false' puede permitir que se anuncien los cambios de participantes individuales sin solicitar la lista completa cada vez [1].

El criterio 4.1.3 de las Pautas de Accesibilidad para el Contenido Web (WCAG) trata sobre los mensajes de estado: información sobre resultados, esperas, progreso o errores que no cambia tu contexto. El número de resultados de una búsqueda puede encajar en esta categoría, pero la propia lista de resultados no. Un cuadro de diálogo de error que recibe el foco queda fuera del alcance de los mensajes de estado de este criterio. El criterio no exige un anuncio para cada actualización visual [2].

Una confirmación rutinaria como «Saldo actualizado» encaja con la prioridad polite. Un error que aparece tras un intento fallido de enviar un formulario también puede hacerse accesible como mensaje de estado mientras el foco permanece en Enviar; elige la urgencia según la situación. Mantén los anuncios breves y evita repetirlos en exceso. Prueba interacciones realistas con las combinaciones de navegador y lector de pantalla que usa tu público, incluidas las combinaciones móviles pertinentes, y realiza pruebas con usuarios para evaluar si la información es suficiente o aparece con demasiada frecuencia [1] [2].

Estos dos documentos ofrecen orientación técnica, no resultados experimentales ni mejoras medidas.

• Orientación técnica: MDN recomienda preparar una región viva antes de cambiar su contenido, preferiblemente incluyéndola en el marcado inicial. También señala que el comportamiento varía según la combinación de navegador y tecnología de asistencia [1]
• Orientación técnica: W3C limita el criterio 4.1.3 a los mensajes de estado que no cambian el contexto. Distingue el número de resultados de una búsqueda de los propios resultados y recomienda realizar pruebas con usuarios para evitar un exceso de avisos al aplicar regiones vivas de forma más amplia [2]
• Orientación técnica: MDN explica que aria-atomic='true' solicita que se presente toda la región cuando solo cambia una parte. El ejemplo del carrito de W3C ilustra por qué anunciar solo el número que cambió puede omitir contexto útil; ninguno de los dos documentos establece que anunciar la región completa sea lo mejor para cualquier mensaje de error [1] [2]

La prioridad del anuncio expresa el comportamiento previsto, así que no debes dar por hecho el momento exacto del anuncio ni las interrupciones de la lectura en voz alta en distintas combinaciones de navegador y lector de pantalla. Los anuncios de las regiones vivas suelen ser texto sin formato; es posible que el propio anuncio no transmita la función interactiva de los enlaces y botones que haya dentro de una región actualizada [1]. Prueba la secuencia real de actualización, el contexto del mensaje, el comportamiento cuando el foco está en la región y las combinaciones de navegador y lector de pantalla compatibles. W3C también recomienda realizar pruebas con usuarios para evaluar si los avisos aparecen con demasiada frecuencia [2].