La mayoría de los desarrolladores están familiarizados con el lenguaje de marcado de hipertexto (HTML) estándar de nuestra Web moderna. Sin embargo, es posible que no estés familiarizado con las aplicaciones de Internet enriquecidas accesibles (ARIA) (formalmente denominadas WAI-ARIA): qué son, cómo se usan y cuándo (y cuándo no) usarlas.
HTML y ARIA cumplen una función importante para hacer que los productos digitales sean accesibles, especialmente cuando se trata de tecnología de accesibilidad (AT), como los lectores de pantalla. Ambas se usan para convertir contenido a un formato alternativo, como braille o texto a voz (TTS).
Repasemos una breve historia de ARIA, por qué es importante y cuándo y cómo usarla.
Introducción a ARIA
ARIA se desarrolló por primera vez en 2008 por el grupo de la Iniciativa de accesibilidad web (WAI), un subconjunto del Consorcio World Wide Web (W3C) general, que administra y regula Internet.
ARIA no es un verdadero lenguaje de programación, sino un conjunto de atributos que puedes agregar a elementos HTML para aumentar su accesibilidad. Estos atributos comunican la función, el estado y la propiedad a las tecnologías de accesibilidad mediante las APIs de accesibilidad que se encuentran en los navegadores modernos. Esta comunicación se realiza a través del árbol de accesibilidad.
"WAI-ARIA, el paquete de aplicaciones de Internet enriquecidas y accesibles, define una manera de hacer que el contenido y las aplicaciones web sean más accesibles para las personas con discapacidades. Además, es muy útil con el contenido dinámico y los controles avanzados de la interfaz de usuario que se desarrollaron con HTML, JavaScript y tecnologías relacionadas".
El grupo de WAI
Árbol de accesibilidad
ARIA modifica el código incorrecto o incompleto con el objetivo de crear una mejor experiencia para quienes usan AT mediante el cambio, la exposición y el aumento de partes del árbol de accesibilidad.
El navegador crea el árbol de accesibilidad, que se basa en el árbol estándar del Modelo de objetos del documento (DOM). Al igual que el árbol del DOM, el árbol de accesibilidad contiene objetos que representan todos los elementos de lenguaje de marcado, atributos y nodos de texto. Las APIs de accesibilidad específicas de la plataforma también usan el árbol de accesibilidad para proporcionar una representación que las tecnologías de accesibilidad puedan comprender.
ARIA por sí solo no cambia la funcionalidad ni la apariencia visual de un elemento. Eso significa que solo los usuarios de AT verán diferencias entre un producto digital con ARIA y uno que no lo tiene. Eso también significa que los desarrolladores solos son responsables de realizar los cambios de estilo y código apropiados para que un elemento sea lo más accesible posible.
Las tres características principales de ARIA son los roles, las propiedades y los estados o valores.
Los roles definen lo que un elemento es o hace en la página o app.
<div role="button">Self-destruct</div>
Las propiedades expresan características o relaciones con un objeto.
<div role="button" aria-describedby="more-info">Self-destruct</div>
<div id="more-info">This page will self-destruct in 10 seconds.</div>
Los estados/valores definen las condiciones actuales o los valores de datos asociados con el elemento.
<div role="button" aria-describedby="more-info" aria-pressed="false">
Self-destruct
</div>
<div id="more-info">
This page will self-destruct in 10 seconds.
</div>
Si bien los tres elementos de ARIA se pueden usar en una sola línea de código, esto no es obligatorio. En su lugar, aplica capas de funciones, propiedades y estados o valores de ARIA hasta que logres tu objetivo de accesibilidad final. La incorporación correcta de ARIA a tu base de código garantiza que los usuarios de AT tendrán toda la información que necesitan para usar tu sitio web, app o algún otro producto digital de manera exitosa y equitativa.
Recientemente, las Herramientas para desarrolladores de Chrome crearon una forma de ver el árbol de accesibilidad completo, lo que facilita a los desarrolladores comprender cómo su código afecta la accesibilidad.
Cuándo usar ARIA
En 2014, el W3C publicó oficialmente la recomendación HTML5. Con él, se produjeron algunos cambios importantes, incluida la adición de elementos de referencia, como <main>, <header>, <footer>, <aside>, <nav>, y atributos como hidden y required. Con estos nuevos elementos y atributos HTML5, junto con una mayor compatibilidad con los navegadores, algunas partes de ARIA ahora son menos críticas.
Cuando el navegador admite una etiqueta HTML con una función implícita con un valor de ARIA equivalente, por lo general, no es necesario agregar ARIA al elemento. Sin embargo, ARIA aún incluye muchos roles, estados y propiedades que no están disponibles en ninguna versión de HTML. Esos atributos siguen siendo útiles por el momento.
Esto nos lleva a la pregunta final: ¿cuándo deberías usar ARIA? Afortunadamente, el grupo de WAI desarrolló las cinco reglas de ARIA para ayudarte a decidir cómo hacer que los elementos sean accesibles.
Regla 1: No uses ARIA
Sí, leíste bien. Agregar ARIA a un elemento no hace que sea más accesible de forma inherente. En el informe anual de accesibilidad de WebAIM Million, se descubrió que las páginas principales con ARIA presentes tenían, en promedio, un 70% más de errores detectados que aquellas sin ARIA, principalmente debido a la implementación inadecuada de los atributos de ARIA.
Hay excepciones a esta regla. ARIA es necesario cuando un elemento HTML no es compatible con la accesibilidad. Esto podría deberse a que el diseño no permite un elemento HTML específico o a que la función o el comportamiento deseado no está disponible en HTML. Sin embargo, estas situaciones deben ser escasas.
<a role="button">Submit</a>
<button>Submit</button>
Si tienes dudas, usa elementos HTML semánticos.
Regla 2: No agregues ARIA (innecesario) a HTML
En la mayoría de las circunstancias, los elementos HTML funcionan bien de inmediato y no necesitan agregar ARIA adicionales. De hecho, los desarrolladores que usan ARIA a menudo tienen que agregar código adicional para que los elementos sean funcionales en el caso de los elementos interactivos.
<h2 role="tab">Heading tab</h2>
<div role="tab"><h2>Heading tab</h2></div>
Trabaja menos y obtén un código de mejor rendimiento cuando usas los elementos HTML según lo previsto.
Regla 3: Siempre admite la navegación con teclado
Se debe poder acceder con el teclado a todos los controles ARIA interactivos (no inhabilitados). Puedes agregar tabindex= "0" a cualquier elemento que necesite un enfoque que normalmente no recibe el foco del teclado. Evita usar índices de tabulación con números enteros positivos siempre que sea posible para evitar posibles problemas en el orden del enfoque del teclado.
<span role="button" tabindex="1">Submit</span>
<span role="button" tabindex="0">Submit</span>Por supuesto, si puedes, usa un elemento
<button> real en este caso.
Regla 4: No ocultes los elementos enfocables
No agregues role= "presentation" ni aria-hidden= "true" a los elementos que necesitan estar enfocados, incluidos los elementos con un tabindex= "0". Cuando agregas estas funciones o estados a los elementos, se envía un mensaje a AT que estos elementos no son importantes y que se deben omitir. Esto puede generar confusión o interrumpir a los usuarios que intentan interactuar con un elemento.
<div aria-hidden="true"><button>Submit</button></div>
<div><button>Submit</button></div>
Regla 5: Usa nombres de accesibilidad para los elementos interactivos
El propósito de un elemento interactivo debe transmitirse al usuario antes de que sepa cómo interactuar con él. Asegúrate de que todos los elementos tengan un nombre accesible para las personas que usan dispositivos AT.
Los nombres accesibles pueden ser el contenido encerrado por un elemento (en el caso de un <a>), texto alternativo o una etiqueta.
Para cada una de las siguientes muestras de código, el nombre de accesibilidad es "Botas de cuero rojas".
<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>
<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>
<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>
Existen muchas formas de comprobar el nombre de accesibilidad de un elemento, como inspeccionar el árbol de accesibilidad con las herramientas para desarrolladores de Chrome o probarlo con un lector de pantalla.
ARIA en HTML
Si bien se recomienda usar elementos HTML por su cuenta, se pueden agregar elementos ARIA en ciertas situaciones. Por ejemplo, puedes vincular ARIA con HTML en patrones que necesiten un nivel más alto de compatibilidad con AT debido a restricciones del entorno o como un método de resguardo para elementos HTML que no son del todo compatibles con todos los navegadores.
Por supuesto, existen recomendaciones para implementar ARIA en HTML. Lo más importante es que no anules las funciones predeterminadas de HTML, reduzcas la redundancia ni tengas en cuenta los efectos secundarios no deseados.
Veamos algunos ejemplos.
<a role="heading">Read more</a>Se asignó el rol incorrecto.
<a aria-label="Read more about some awesome article title">Read More</a>Rol correcto y descripción adicional del vínculo
<ul role="list">...</ul>Función redundante.
<ul>...</ul>Se quitó la redundancia
<details> <summary role="button">more information</summary> ... </details>Posibles efectos secundarios.
<details> <summary>more information</summary> ... </details>Sin efectos secundarios no deseados.
Complejidades de ARIA
ARIA es complejo y siempre debes tener cuidado cuando lo uses. Si bien los ejemplos de código de esta lección son bastante sencillos, la creación de patrones personalizados accesibles puede resultar complicado.
Hay muchos aspectos a los que se debe prestar atención, como las interacciones con el teclado, las interfaces táctiles, la compatibilidad con AT o el navegador, las necesidades de traducción, las restricciones del entorno, el código heredado y las preferencias del usuario. Un poco de conocimiento sobre programación puede ser perjudicial, o simplemente molesto, si se usa de manera incorrecta. Recuerda mantener un código simple.
Dejando de lado esas advertencias, la accesibilidad digital no es una situación de todo o nada, es un espectro que permite algunas áreas grises como esta. Varias soluciones de programación pueden considerarse "correctas" según la situación. Lo importante es que sigas aprendiendo, probando y haciendo que nuestro mundo digital sea más abierto para todos.
Verifica tus conocimientos
Pon a prueba tus conocimientos sobre ARIA y HTML
¿Cuál de las siguientes es la práctica recomendada para crear un botón accesible?
<div id="saveChanges" aria-role="button" aria-pressed="false" tabindex="0">Go to shop</div><a id="saveChanges" aria-label="Some awesome article title">Go to shop</a><button id="saveChanges" type="button">Go to shop</button>