ARIA: ¿veneno o antídoto?

¡Cuánta mentira a los lectores de pantalla se puede curar la accesibilidad, cuando no se rocía sal en ella!

Aaron Leventhal

¿Qué es ARIA?

ARIA permite que los autores de la Web creen una realidad alternativa que solo puedan ver los lectores de pantalla 🤥

A veces, es necesario ampliar la verdad o, incluso, mentirles directamente a los lectores de pantalla sobre lo que sucede en el contenido web. Por ejemplo, "¡el enfoque está realmente por aquí!" o "¡realmente es un control deslizante!". Es como agregar notas adhesivas mágicas sobre las herramientas y los widgets en su banco de trabajo. Estas mágicas notas adhesivas hacen que todos crean lo que están escritos en ellas.

Cuando existe una nota adhesiva mágica, anula nuestra creencia sobre qué es cada herramienta o sobre algo sobre ella. Por ejemplo: "Esto es una pistola de pegamento". A pesar de que en realidad sigue siendo una caja azul vacía sobre el banco de trabajo, la nota adhesiva mágica nos hará ver que es una pistola de pegamento. También podemos agregar: "y está lleno un 30%". El lector de pantalla informará que hay una pistola de pegamento al 30% llena.

El equivalente web de esto es tomar un elemento de cuadro sin formato (un div) con una imagen dentro y usar ARIA para decir que es un control deslizante en el valor 30 de 100.

¿Qué no es ARIA?

ARIA no afecta la apariencia de una página web ni el comportamiento de los usuarios del mouse o del teclado. Solo los usuarios de tecnologías de accesibilidad notarán cualquier diferencia con respecto a ARIA. Los desarrolladores web pueden agregar cualquier ARIA arbitrario sin afectar a los usuarios que no ejecutan una tecnología de accesibilidad.

Lo leíste bien: ARIA en realidad no hace nada para enfocar el teclado ni en el orden de tabulación. Todo eso se hace en HTML, a veces ajustado con fragmentos de JavaScript.

¿Cómo funciona ARIA?

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

¿Por qué usar ARIA?

¿Por qué queremos mentirles a nuestros usuarios?

Supongamos que la tienda web local no vende todos los widgets que necesitamos. Pero nosotros somos MacGyver, maldita sea. ¡Podemos inventar nuestros propios widgets a partir de otros widgets! FWIW, las siete cosas más usadas de MacGyver son navajas suizas, goma de mascar, cuerdas para zapatos, fósforos, clips de papel, velas de cumpleaños y cinta adhesiva. Los usa para fabricar bombas y otros objetos que no son tan solo acostados. Esto se asemeja a un autor web que necesita hacer una barra de menú. Las barras de menú son tan útiles que pensarías que formarían parte del código HTML, pero no lo son. ¡Oh, bueno! ¿No pensabas que los autores estarían contentos con los vínculos y los botones? Por lo tanto, el autor improvisará uno con sus herramientas favoritas: divs, images, style, controladores de clics, controladores de pulsación de teclas, spit y ARIA.

A veces, en lugar de utilizar ARIA al máximo, lo utilizamos como una mejora. Puede ser útil agregar un poco de ARIA en algo de HTML que básicamente ya funciona. Por ejemplo, es posible que desees que un control de formulario apunte a una alerta de mensaje de error que se relacione con alguna entrada no válida. O puede que queramos indicar que un cuadro de texto es para buscar. Estos pequeños 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ú

Cómo brindar compatibilidad con las personas que hacen clic del mouse

Creemos juntos una barra de menú. Mostramos un conjunto de elementos en elementos de cuadro genéricos llamados divs. Cada vez que el usuario hace clic en un elemento div, ejecuta el comando correspondiente. Genial, funciona para las personas que usan el mouse.

Luego, le damos un aspecto bonito. Usamos CSS, es decir, estilos, alineando bien las cosas y contornándolas con contornos visuales. Hacemos que se vea lo suficientemente como otras barras de menú que las personas curiosas saben 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 que tenga el mouse, lo que le brinda al usuario comentarios visuales útiles.

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

Por supuesto, esto es bastante inaccesible, como es el caso habitual para muchos elementos de la Web, en gran medida porque los asistentes de estándares HTML no agregaban todo lo que necesita un autor web. Incluso si lo hicieran, los autores de la Web siempre querían inventar su propia versión especial.

Cómo hacer que el teclado de la barra de menú sea accesible

Como primer paso hacia la accesibilidad, agreguemos la accesibilidad del teclado. Esta parte solo usa HTML, y no ARIA. Recuerda que ARIA no afecta aspectos principales, como la apariencia, el mouse o el teclado para los usuarios que no tienen tecnologías de accesibilidad.

Así como una página web puede responder al mouse, también puede responder al teclado. Nuestro JavaScript escuchará todas las pulsaciones de teclas que se produzcan y decidirá si esta es útil. Si no, lo devuelve a la página como un pez que es demasiado pequeño para comer. Nuestras reglas son las siguientes:

• Si el usuario presiona una tecla de flecha, veamos nuestros propios planos de la barra de menú interna y decidamos cuál debería 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 está. Entonces, la página web debería llamar a event.preventDefault() para evitar que el navegador realice la acción habitual (desplazarse por la página, en este caso).
• Si el usuario presiona la tecla Intro, podemos tratarlo 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, ¡no te comas eso! Volvamos a la página como se espera. Por ejemplo, nuestra barra de menú no necesita la tecla Tab, por lo que debes deshacerla. Es difícil hacerlo bien, y los autores lo arruinan. Por ejemplo, la barra de menú necesita teclas de flecha, pero no Alt + Flecha ni Comando + flecha. Estas son combinaciones de teclas para ir a la página anterior o siguiente del historial web de la pestaña del navegador. Si el autor no tiene cuidado, se comerá la barra de menú. Este tipo de error ocurre con mucha frecuencia, y todavía no empezamos con ARIA.

Acceso de los lectores de pantalla a nuestra barra de menú

La barra de menú se creó con cinta adhesiva y elementos divs. Como resultado, un lector de pantalla no tiene idea de qué es. El color de fondo del elemento activo es solo un color. Los elementos de menú div son solo objetos simples sin ningún significado en particular. En consecuencia, un usuario de nuestra barra de menú no recibe instrucciones sobre qué teclas presionar ni qué elemento está usando.

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

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

La primera mentira de ARIA es usar el atributo aria-activedescendant y configurarlo con el ID del elemento de menú activo actualmente, con cuidado de actualizarlo cada vez que cambia. Por ejemplo, aria-activedescendant="settings-menuitem". Esta pequeña mentira blanca 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.

Explicación de ancestor, parent y descendant

El término subordinado se refiere al hecho de que un elemento está contenido en algún lugar dentro de otro. El término opuesto es principal, que significa que los principales contienen un elemento. Para el siguiente contenedor hacia arriba o hacia abajo, se pueden usar los términos más específicos superior/secundario. Por ejemplo, imagina un documento con un párrafo que incluye un vínculo en su interior. El elemento superior del vínculo es un párrafo, pero también tiene el documento como principal. En cambio, el documento puede tener muchos párrafos secundarios, cada uno con vínculos. Todos los vínculos son descendientes del documento principal.

Volver a aria-activedescendant Cuando se usa para apuntar de la barra de menú enfocada a un elemento de menú específico, el lector de pantalla ahora sabe dónde se movió el usuario, pero nada más sobre el objeto. ¿Qué es este elemento div? Aquí es donde entra en juego el atributo de rol. Usamos role="menubar" en el elemento que lo contiene para todo el elemento, 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 conducir a un menú secundario? El usuario necesita saberlo, ¿verdad? Para un usuario vidente, puede que haya 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 punto. Podemos agregar aria-expanded="false" en cada elemento de menú expandible para indicar que 1) hay algo que se puede expandir y 2) que actualmente no se puede expandir. Como toque adicional, el autor debe colocar role="none" en el triángulo img para indicar que solo tiene fines de refuerzo. De esta manera, se evita que el lector de pantalla diga algo sobre la imagen que sería redundante en el mejor de los casos y posiblemente molesto.

Cómo tratar errores

Errores del teclado (HTML)

Si bien el acceso al teclado es parte del HTML principal, los autores lo arruinan todo el tiempo, ya sea porque no usan tanto la navegación con el teclado o porque hay muchos matices para hacerlo bien.

Ejemplos de errores:

• Una casilla de verificación usa la barra espaciadora para activar o desactivar, pero el autor olvidó llamar a preventDefault(). Ahora, la barra espaciadora activará la casilla de verificación y la tecla AvPág, que es el comportamiento predeterminado del navegador para la barra espaciadora.
• Un diálogo modal ARIA quiere capturar la navegación de pestañas dentro de él, y el autor se olvida de permitir específicamente que se use Control + Tab en el navegador. Ahora, Control + Tab solo navega por su diálogo y no cambia de pestaña en el navegador como debería. ¡Uf!
• Un autor crea una lista de selección e implementa las acciones hacia arriba y hacia abajo, pero no implementa la navegación hacia la pantalla principal, el final, la páginaup/pagedown ni la navegación de primera letra.

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

Si tienes problemas de acceso solo al teclado, resulta útil probarlo también sin un lector de pantalla o con el modo de navegador virtual desactivado. Por lo general, los lectores de pantalla no son necesarios para descubrir errores del teclado, y el acceso al teclado se implementa en realidad con HTML, no con ARIA. Después de todo, ARIA no afecta elementos básicos, como el comportamiento del teclado o del mouse, solo le muestra al lector de pantalla el contenido de la página web, lo que se enfoca en ese momento, etc.

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.

Errores de ARIA: ¿por qué hay tantos?

Hay muchos casos en los que los autores pueden equivocarse en ARIA, y cada uno de ellos provocará una rotura completa o diferencias sutiles. Los sutiles probablemente sean peores, ya que el autor no los reconocerá antes de publicarlo.

Después de todo, a menos que el autor sea un usuario experimentado de lector de pantalla, algo va a salir mal en ARIA. En el ejemplo de la barra de menú, el autor podría pensar que la función "option" se usaría cuando "menuitem" era correcto. Podrían olvidarse de usar aria-expanded, de establecer y borrar aria-activedescendant en los momentos correctos, o de tener una barra de menú que contenga los otros menús. ¿Y qué sucede con los recuentos de elementos del menú? Por lo general, los lectores de pantalla presentan los elementos de menú con algo como "elemento 3 de 5" para que el usuario sepa dónde están. El navegador suele contar esto automáticamente, pero en algunos casos y en algunas combinaciones de navegadores (lectores de pantalla), es posible que se calculen los números incorrectos, y el autor deberá anular esos números con aria-posinset y aria-setsize.

Y esto es solo barras de menú. Piensa cuántos tipos de widgets hay. Echa un vistazo a las especificaciones de ARIA o las prácticas de creación si quieres. Para cada patrón, hay una docena de formas en las que ARIA podría usarse 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 enviados. Hay demasiados matices. Idealmente, todo se probaría con varias combinaciones diferentes de lector de pantalla y navegador, debido a las numerosas peculiaridades de implementación, además de algunas implementaciones incompletas.

Resumen

En resumen, la magia de ARIA se puede usar para anular o agregar algo y todo lo que dice el HTML. Se puede usar para hacer pequeños cambios pequeños en la presentación de accesibilidad o para crear una experiencia completa. Por eso, ARIA es increíblemente potente y, a la vez, peligroso en manos de nuestros amigables autores web locales, que no suelen utilizar lectores de pantalla ellos mismos.

ARIA es solo una capa de lenguaje de marcado de anulación de verdad directa. Cuando un lector de pantalla pregunta qué está sucediendo, si ARIA existe, obtiene la versión ARIA de la verdad en lugar de la verdad subyacente real.

Anexo 1: Recursos adicionales

Referencia híbrida con información del teclado y ejemplos de código

• Prácticas de creación de ARIA de W3C: Se documentan las características importantes de navegación con el teclado de cada ejemplo y se proporciona código JS/CSS/ARIA funcional. Los ejemplos se centran en lo que funciona en la actualidad y no abarcan los dispositivos móviles.

Anexo 2: ¿Para qué se usa más ARIA?

Dado que ARIA puede reemplazar o complementar verdades pequeñas o grandes, suele ser útil para decir cosas que le interesan al lector de pantalla.

Estos son algunos de los usos comunes de ARIA.

• Widgets especiales que no existen en HTML, como una barra de menú, autocompletar, árbol u hoja de cálculo
• Widgets que existen en HTML, pero que el autor inventó los suyos de todas formas, posiblemente porque necesitaba ajustar el comportamiento o la apariencia del widget normal. Por ejemplo, un elemento HTML <input type="range"> es básicamente un control deslizante, pero los autores quieren que se vea diferente. En la mayoría de los casos, se puede usar CSS, pero para input type="range", CSS es incómodo. Un autor puede crear su propio control deslizante y usar role="slider" en él con aria-valuenow para decir cuál es el valor actual.
• Las regiones activas indican a los lectores de pantalla “en esta área de la página, vale la pena contarle al usuario todo aquello sobre lo que cambie”.
• Puntos de referencia (ahora, HTML tiene equivalentes). Estos son similares a los encabezados, en el sentido de que ayudan a los usuarios de lectores de pantalla a encontrar lo que buscan más rápido. Sin embargo, son diferentes porque contienen toda el área relacionada. Por ejemplo, "este contenedor es el área principal de la página" y "este contenedor de aquí es un panel de navegación".

Anexo 3: ¿Qué es una API de Accessibility?

Una API de accesibilidad es la manera en que un lector de pantalla o cualquier otra AT sabe lo que hay en la página y lo que sucede en el momento. Algunos ejemplos son MSAA, IA2 y UIA. ¡Y eso es solo Windows! Una API de accesibilidad tiene dos partes:

• Es un "árbol" de objetos que representa una jerarquía de contenedores. Son como muñecas rusas, pero cada muñeca puede contener muchas otras. Por ejemplo, un documento puede contener muchos párrafos, y un párrafo puede tener texto, imágenes, vínculos, negrita, etc. Cada elemento del árbol de objetos puede tener propiedades como un rol (¿qué soy?), un nombre o una etiqueta, un valor ingresado por el usuario y una descripción, así como estados booleanos, como enfocable, enfocado, obligatorio, marcado. ARIA puede anular cualquiera de estas propiedades. El lector de pantalla usa el árbol para ayudar al usuario a navegar en el modo de búfer virtual, como "ir al siguiente encabezado, por favor".
• Una serie de eventos que ocurren que describen cambios en el árbol, como "¡el enfoque ya está por aquí!". El lector de pantalla usa los eventos para indicarle al usuario lo que acaba de suceder. Cuando cambia el lenguaje de marcado HTML o ARIA importante, se activa un evento para indicarle al lector de pantalla que se produjo un cambio.

Por lo general, los autores solo usan HTML, que se asigna bien a estas APIs de accesibilidad. Cuando HTML no es suficiente, se usa ARIA y el navegador anula la semántica de HTML antes de enviar el árbol de objetos o los eventos al lector de pantalla.