Aria-live, para mejorar la navegación

 

Las aplicaciones dinámicas son las que actualizan el contenido de la página sin tener que volver a cargar la página web. Un ejemplo común sería actualizar los resultados de los partidos de futbol, mostrar banners de alerta de éxito o advertencia, nuevos mensajes de chat y muchos más.

 

El atributo aria-live permite que las tecnologías de asistencia, como los lectores de pantalla, transmitan actualizaciones de contenido a un usuario de lector de pantalla, mejorando la experiencia del usuario al mantenerlo informado de los cambios que ocurren en la página.

Descripción del atributo ARIA Live

ARIA, o Accessible Rich Internet Applications, es un conjunto de atributos que definen formas de hacer que el contenido y las aplicaciones web sean más accesibles para las personas con discapacidades.

aria-live se utiliza para definir regiones de una página web que están activas y que deben ser anunciadas por tecnologías de asistencia, como lectores de pantalla, cuando se actualizan o cambian dinámicamente.

Tipos de regiones activas de ARIA

Puede utilizar las siguientes opciones de atributos de ARIA Live en función de la urgencia de cómo se debe anunciar el contenido dinámico a los usuarios. Estas opciones incluyen:

 

·       aria-live="off": De forma predeterminada, está desactivado. Este valor indica que las tecnologías de asistencia no deben anunciar cambios en el contenido dentro de la región.

·       aria-live="polite": Con este valor, los cambios se anuncian al usuario una vez completada la tarea actual. Es útil para actualizaciones no críticas que no interrumpen trabajo del usuario.

·       aria-live="assertive": Este valor indica que los cambios se anuncian inmediatamente, incluso si el usuario está en medio de una tarea. Es adecuado para actualizaciones importantes que requieren atención inmediata. Aria-live assertive se comporta de manera similar a role=" alert" con la única diferencia de que un lector de pantalla agrega la palabra "alerta" al principio. Tenga en cuenta que un anuncio asertivo interrumpirá un lector de pantalla si está en medio de la lectura del texto y leerá el anuncio aria-live. Lo que sea que el lector de pantalla haya estado leyendo se truncará y no continuará automáticamente después del anuncio de aria-live.

ARIA in HTML ya es una recomendación (por lo tanto especificación) del W3C

 

Ya que ARIA a 9 de diciembre de 2021 pasa a ser una recomendación del W3C, es bueno recordad las 5 recomendaciones.

Regla 1: No uses ARIA, usa un elemento o atributo HTML nativo.

INCORRECTO

<div role="button">Click aquí</div>

Los botones HTML son ejecutables (con teclado y ratón), pueden tener foco, y los lectores de pantalla los reconoce como botones.

CORRECTO

<button>Click aquí</button>

Regla 2: No cambies la semántica nativa, a menos que realmente lo necesites hacer.

INCORRECTO

<h2 role="tab">AREA 1</h2>

Los títulos no deberían tener el atributo role="tab". Para eso deberemos usar otro elemento como un <div>.

CORRECTO

<div role="tab">

  <h2>AREA 1</h2>

</div>

Regla 3: Todos los controles interactivos de ARIA deben poder utilizarse con el teclado.

Tenemos que recordar que entre los usuarios de nuestro sitio web se encuentran usuarios con discapacidad visual, y que habitualmente esos usuarios navegarán por nuestro sitio web usando el teclado (gracias a sus software de lectura de pantalla). Si alguno de los controles interactivos no es accesible mediante teclado, esos usuarios no podrán clicar en los botónes, o introducir datos en el formulario.

Regla 4: No uses role=“presentation” o aria-hidden=“true” en elementos que requieran foco.

Si en nuestro sitio web tenemos algún elemento que requieran foco, por ejemplo, botones o campos de un formulario, no deberemos usar los atributos role="presentation o aria-hidden="true".

Si usamos cualquiera de esos atributos en un elemento HTML, ese elemento no podrá tener foco y serán omitidos en una navegación usando el teclado. Deberemos usar esos atributos para elementos como un gráfico decorativo o iconos, en los que no queremos que el usuario pueda hacer foco.

INCORRECTO

<button aria-hidden="true">Click aquí</button>

CORRECTO

<img src="./icon.png" alt="Icono de una papelera" aria-hidden="true" />

Regla 5: Todos los elementos interactivos deben tener un nombre accesible.

Cualquier elemento interactivo de nuestro sitio web, por ejemplo, un botón o un campo en un formulario, solo tendrá un nombre accesible si su propiedad de nombre accesible de API de accesibilidad (o equivalente) tiene un valor.

 

INCORRECTO

<html>

  <form>

    ...

    <label>Nombre</label>

    <input type="text" />

    ...

  </form>

</html>

Pero un lector de pantalla no sabrá como relacionar la etiqueta con el campo, ya que no tiene un nombre accesible, y no están relacionadas de ningún modo. En el siguiente ejemplo podemos ver la forma correcta de hacerlo, usando el atributo id="username" en el campo y el atributo for="username" en la etiqueta. De esta manera estarán relacionadas, y el lector de pantalla podrá identificarlos juntos.

CORRECTO

<html>

  <form>

    ...

    <label for="username">Nombre</label>

    <input id="username" type="text" />

    ...

  </form>

</html>