ARIA: ¿veneno o antídoto?

¿Qué es ARIA?

ARIA permite que los autores web creen una realidad alternativa que solo ven los lectores de pantalla.

A veces, es necesario ampliar la verdad o incluso “mentir” a los lectores de pantalla sobre lo que sucede en el contenido web. Por ejemplo, "el enfoque está realmente aquí" o "este es realmente un control deslizante". Es como agregar notas adhesivas mágicas sobre las herramientas y los widgets de tu mesa de trabajo. Estas notas adhesivas mágicas hacen que todos crean lo que está escrito en ellas.

Cuando existe una nota adhesiva mágica, anula nuestra creencia sobre lo que es o hace cada herramienta. Por ejemplo, si agregas ARIA que indica “este objeto es una pistola de pegamento”. Aunque es una caja azul vacía, la nota adhesiva mágica nos dice que es una pistola de pegamento. También podemos agregar “y está al 30% de su capacidad”. El lector de pantalla ahora informa que hay una pistola de pegamento llena al 30%.

El equivalente web a esto es tomar un div simple con una imagen dentro y usar ARIA para indicar que es un control deslizante con el valor 30 de 100. ARIA no hace que div sea un control deslizante, solo le dice al lector de pantalla que diga que es uno.

ARIA no afecta la apariencia de una página web ni el comportamiento de un usuario de mouse o teclado. Solo los usuarios de tecnologías de accesibilidad notan el impacto de ARIA. Los desarrolladores web pueden agregar cualquier ARIA arbitrario sin afectar a los usuarios que no ejecuten una tecnología de accesibilidad.

Lo leíste bien: ARIA no hace nada con el enfoque del teclado ni el orden de tabulación. Todo se hace en HTML, a veces con ajustes de JavaScript.

¿Cómo funciona ARIA?

Un lector de pantalla o alguna otra tecnología de accesibilidad les solicita a los navegadores información sobre cada elemento. Cuando ARIA está presente en un elemento, el navegador recibe la información y cambia lo que le dice al lector de pantalla sobre ese elemento.

Estos son algunos de los usos más comunes de ARIA.

• Agrega componentes especiales que no existen en HTML, como autocompletar, un árbol o una hoja de cálculo.
• Agrega componentes que existen en HTML, pero el autor decidió que debía reinventarlos, posiblemente porque quería cambiar el comportamiento o la apariencia del elemento estándar. Por ejemplo, un elemento <input type="range"> de HTML es básicamente un control deslizante, pero los autores quieren que se vea diferente.
  • En la mayoría de los casos, esto se puede solucionar con CSS. Sin embargo, para range, CSS es awkwARD. Los autores pueden crear su propio control deslizante y usar role="slider" con aria-valuenow para indicarle al teclado cuál es el valor actual.
• Incluye regiones activas para informar a los lectores de pantalla sobre los cambios relevantes en un área de una página.
• Crea puntos de referencia, como encabezados. Los puntos de referencia ayudan a los usuarios de lectores de pantalla a encontrar lo que buscan más rápido. Los puntos de referencia pueden contener un área relacionada completa. Por ejemplo, "este contenedor es el área principal de la página" y "este contenedor aquí es un panel de navegación".

¿Por qué usar ARIA?

Puede ser útil agregar ARIA a HTML que ya funcione. Por ejemplo, es posible que deseemos que un control de formulario apunte a una alerta de mensaje de error para una entrada no válida. O tal vez queramos indicar el uso específico de una entrada de texto. Estos ajustes pueden hacer que los sitios web comunes sean más fáciles de usar con un lector de pantalla.

Ejemplo de barra de menú

Supongamos que la tienda web local no vende todos los widgets que necesitamos. Sin embargo, somos MacGyver. Podemos inventar nuestros propios widgets a partir de otros widgets. Esto es muy similar a un autor web que necesita crear una barra de menú.

Si bien existe el elemento <nav>, las barras de menú suelen estar juntas con divs, imágenes, botones, controladores de clics, controladores de teclas y ARIA.

Cómo admitir usuarios de mouse

Construyamos juntos una barra de menú. Mostramos muchos elementos en elementos de cuadro genéricos llamados divs. Cada vez que el usuario hace clic en un div, ejecuta el comando correspondiente. Genial, ¡funciona para los usuarios que hacen clic con el mouse!

A continuación, le daremos un aspecto atractivo. Usamos CSS para alinear los elementos bien y rodearlos con contornos visuales. Hacemos que se vea lo suficientemente similar a otras barras de menú para que las personas videntes sepan intuitivamente que es una barra de menú y cómo usarla. Nuestra barra de menú incluso usa un color de fondo diferente en cualquier elemento sobre el que se coloca el mouse, lo que le brinda al usuario algunos comentarios visuales útiles.

Algunos elementos del menú son elementos superiores. Generan submenús secundarios. Cada vez que el usuario coloca el cursor sobre uno de ellos, iniciamos una animación que desliza el submenú secundario.

Todo esto es bastante inaccesible, como es el caso habitual de muchas cosas en la web.

Hacer que nuestro teclado de la barra de menú sea accesible

Agreguemos accesibilidad del teclado. Esto solo requiere cambios en el código HTML, no en ARIA. Recuerda que ARIA no afecta los aspectos principales, como la apariencia, el mouse o el teclado, para los usuarios sin tecnologías de accesibilidad.

Así como una página web puede responder al mouse, también puede responder al teclado. Nuestro código JavaScript puede escuchar todas las pulsaciones de teclas que se producen y decidir si la pulsación de tecla es útil. De lo contrario, lo vuelve a enviar a la página como un pez demasiado pequeño para comer. Nuestras reglas son similares a las siguientes:

• Si el usuario presiona una tecla de flecha, veamos nuestros propios esquemas de barra de menú internos y decidamos cuál debe ser el nuevo elemento de menú activo. Borraremos los elementos destacados actuales y destacaremos el nuevo elemento de menú para que el usuario vidente sepa visualmente dónde se encuentra. Luego, la página web debe llamar a event.preventDefault() para evitar que el navegador realice la acción habitual (en este caso, desplazarse por la página).
• Si el usuario presiona la tecla Intro, podemos tratarla como un clic y realizar la acción adecuada (o incluso abrir otro menú).
• Si el usuario presiona una tecla que debería realizar otra acción, regresa a la página. Por ejemplo, nuestra barra de menú no necesita la tecla Tab, así que retírala. Esto es difícil de hacer bien. Por ejemplo, la barra de menú necesita teclas de flecha, pero no Alt + Flecha ni Comando + Flecha. Son combinaciones de teclas para ir a la página anterior y siguiente del historial web de la pestaña del navegador. Si el autor no tiene cuidado, la barra de menú se los comerá. Este tipo de error ocurre muchas veces, y aún no comenzamos con ARIA.

Acceso del lector de pantalla a nuestra barra de menú

Nuestra barra de menú se creó con cinta adhesiva y divs. Como resultado, un lector de pantalla no tiene idea de qué se trata. El color de fondo del elemento activo es solo un color. Los divs de los elementos de menú son solo objetos simples sin un significado en particular. En consecuencia, un usuario de nuestra barra de menú no recibe ninguna instrucción sobre qué teclas presionar o en qué elemento se encuentra.

¡Pero eso no es justo! La barra de menú funciona bien para el usuario vidente.

ARIA al rescate. ARIA nos permite simular que el enfoque está en una barra de menú al lector de pantalla. Si el autor hace todo bien, nuestra barra de menú personalizada se mostrará en el lector de pantalla como una barra de menú en una aplicación de escritorio.

Nuestra primera mentira de ARIA es el atributo aria-activedescendant. Establece el atributo en el ID del elemento de menú activo y asegúrate de actualizarlo cada vez que cambie. Por ejemplo, aria-activedescendant="settings-menuitem" Esto hace que el lector de pantalla considere nuestro elemento activo de ARIA como el foco, que se lee en voz alta o se muestra en una pantalla braille.

Cuando se usa aria-activedescendant para apuntar desde la barra de menú enfocada a un elemento de menú específico, el lector de pantalla ahora sabe a dónde se movió el usuario, pero no sabe nada más sobre el objeto. ¿Qué es esto div? Aquí es donde entra en juego el atributo de rol. Usamos role="menubar" en el elemento contenedor para todo el contenido, luego usamos role="menu" en grupos de elementos y role="menuitem" en … redoble de tambores … los elementos de menú individuales.

¿Y si el elemento del menú puede llevar a un menú secundario? El usuario debe saberlo. Para un usuario con visión, puede haber una pequeña imagen de un triángulo al final del menú, pero el lector de pantalla no sabe cómo leer imágenes automáticamente, al menos en este momento. Podemos agregar aria-expanded="false" en cada elemento de menú expandible para indicar que hay algo que se puede expandir, pero que no está expandido. Además, el autor debe colocar role="none" en el triángulo img para indicar que es solo con fines estéticos. Esto evita que el lector de pantalla diga algo sobre la imagen que sería redundante.

Cómo corregir errores del teclado

Si bien el acceso al teclado es parte del HTML principal, es fácil reemplazarlo. Por ejemplo:

• Una casilla de verificación usa la barra espaciadora para activar o desactivar, pero el autor se olvidó de llamar a preventDefault(). Ahora, la barra espaciadora activa y desactiva la casilla de verificación y mueve la página hacia abajo, que es el comportamiento predeterminado del navegador para la barra espaciadora.
• Un diálogo modal de ARIA quiere atrapar la navegación de pestañas dentro de él. Si el autor olvida permitir específicamente que Control + Tab abra una pestaña nueva mientras está en el diálogo, no funcionará como se espera.
• Un autor crea una lista de selección y, luego, implementa las teclas de flecha hacia arriba y hacia abajo. Sin embargo, el autor aún debe agregar la navegación de inicio, fin, página arriba, página abajo o primera letra.

Los autores deben seguir patrones conocidos. Consulta la sección Recursos para obtener más información.

En el caso de los problemas de acceso al teclado, también es útil probar sin un lector de pantalla o con el modo de navegador virtual desactivado. Puedes descubrir errores del teclado sin un lector de pantalla, ya que el acceso al teclado se implementa con HTML, no con ARIA. Después de todo, ARIA no afecta el comportamiento del teclado o del mouse, sino que le recae al lector de pantalla sobre el contenido de la página web, lo que se enfoca en ese momento, etcétera.

Los errores del teclado casi siempre son un error en el contenido web, específicamente en su código HTML y JavaScript, no en ARIA.

¿Por qué hay tantos?

Hay muchas formas en que un autor puede usar ARIA de forma incorrecta. Cada error conduce a una ruptura completa o a diferencias sutiles. Los problemas sutiles pueden ser peores, ya que es poco probable que el autor los detecte antes de publicarlos.

Después de todo, a menos que el autor sea un usuario experimentado de lectores de pantalla, algo saldrá mal en la ARIA. En nuestro ejemplo de barra de menú, el autor podría pensar que se debía usar el rol “option” cuando “menuitem” era correcto. Podría olvidarse de usar aria-expanded, olvidarse de configurar y borrar aria-activedescendant en los momentos adecuados o olvidarse de tener una barra de menú que contenga los otros menús. ¿Qué sucede con los recuentos de elementos de menú? Por lo general, los lectores de pantalla presentan los elementos del menú con algo como "elemento 3 de 5" para que el usuario sepa dónde se encuentra. Por lo general, el navegador cuenta esto automáticamente, pero en algunos casos, y en algunas combinaciones de navegador y lector de pantalla, es posible que se calculen los números incorrectos, y el autor debería anular estos números con aria-posinset y aria-setsize.

Y esto es solo para las barras de menú. Piensa en la cantidad de tipos de widgets que hay. Si quieres, consulta la especificación de ARIA o las prácticas de autoría. Para cada patrón, hay una docena de formas en que se puede usar ARIA de forma inadecuada. ARIA depende de que los autores sepan lo que están haciendo. ¿Qué podría salir mal, dado que la mayoría de los autores no son usuarios de lectores de pantalla?

En otras palabras, es 100% necesario que los usuarios reales de lectores de pantalla prueben los widgets de ARIA antes de que se consideren aptos para su envío. Hay demasiados matices. Idealmente, todo se probaría con varias combinaciones diferentes de navegador y lector de pantalla, debido a las numerosas peculiaridades de implementación, además de algunas implementaciones incompletas.

Resumen

ARIA se puede usar para anular o agregar algo y todo lo que dice el HTML. Puede realizar pequeños cambios en la presentación de accesibilidad o crear una experiencia completa. Por este motivo, ARIA es increíblemente potente y, al mismo tiempo, peligrosa en manos de nuestros desarrolladores que no son usuarios de lectores de pantalla.

ARIA es una capa de marcado que anula otras opciones. Cuando un lector de pantalla pregunta qué está sucediendo, si existe ARIA, el usuario obtiene la versión de la verdad de ARIA.

Recursos adicionales

En las Prácticas de autoría de ARIA del W3C, se documentan las características importantes de la navegación con teclado de cada ejemplo y se proporcionan JavaScript, CSS y ARIA funcionales. Los ejemplos se enfocan en lo que funciona actualmente y no abarcan los dispositivos móviles.

¿Qué es una API de Accessibility?

Una API de accesibilidad es la forma en que un lector de pantalla o cualquier otra tecnología de accesibilidad sabe qué hay en la página y qué sucede. Los ejemplos incluyen MSAA, IA2 y UIA. Una API de Accessibility tiene dos partes:

• Un "árbol" de objetos que representa una jerarquía de contenedores. Por ejemplo, un documento puede contener muchos párrafos. Un párrafo puede tener texto, imágenes, vínculos y decoraciones de texto. Cada elemento del árbol de objetos puede tener propiedades, como el rol (¿qué soy?), un nombre o una etiqueta, un valor ingresado por el usuario, una descripción y estados booleanos, como enfocado, enfocado, obligatorio o marcado. ARIA puede anular cualquiera de estas propiedades.
  • Los lectores de pantalla usan el árbol para ayudar a los usuarios a navegar en el modo de búfer virtual, como “ve al siguiente encabezado”.
• Es una serie de eventos que ocurren que describen los cambios en el árbol, como “el enfoque ahora está aquí”. El lector de pantalla usa eventos para indicarle al usuario lo que acaba de suceder. Cuando cambia el marcado HTML o ARIA importante, se activa un evento para indicarle al lector de pantalla que algo cambió.

El HTML se ajusta perfectamente a estas APIs de accesibilidad. Cuando el HTML no es suficiente, se puede agregar ARIA para que el navegador anule la semántica HTML antes de enviar el árbol de objetos o los eventos al lector de pantalla.