La mayoría de los desarrolladores están familiarizados con el lenguaje de marcado estándar de la Web moderna, el lenguaje de marcado de hipertexto (HTML). Sin embargo, es posible que no estés tan familiarizado con las aplicaciones de Internet enriquecidas y accesibles (ARIA) (antes llamadas WAI-ARIA): qué son, cómo se usan y cuándo (y cuándo no) usarlas.
HTML y ARIA desempeñan funciones importantes para hacer que los productos digitales sean accesibles, en especial cuando se trata de tecnología de accesibilidad (AT), como lectores de pantalla. Ambos se usan para convertir contenido en un formato alternativo, como braille o texto a voz (TTS).
Revisa una breve historia de ARIA, por qué es importante y cuándo y cómo usarla de la mejor manera.
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), que rige y regula Internet.
ARIA no es un lenguaje de programación verdadero, sino un conjunto de atributos que puedes agregar a los elementos HTML para aumentar su accesibilidad. Estos atributos comunican el rol, el estado y la propiedad a las tecnologías de asistencia 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 conjunto de aplicaciones de Internet enriquecidas y accesibles, define una forma de hacer que el contenido web y las aplicaciones web sean más accesibles para las personas con discapacidades. En especial, ayuda con el contenido dinámico y los controles avanzados de la interfaz de usuario desarrollados con HTML, JavaScript y tecnologías relacionadas".
El grupo WAI
El árbol de accesibilidad
ARIA modifica el código incorrecto o incompleto para crear una mejor experiencia para quienes usan AT, ya que cambia, expone y aumenta partes del árbol de accesibilidad.
El árbol de accesibilidad lo crea el navegador y 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 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 asistencia puedan comprender.
ARIA por sí sola no cambia la funcionalidad ni la apariencia visual de un elemento. Eso significa que solo los usuarios de AT notarán las diferencias entre un producto digital con ARIA y uno sin él. También significa que solo los desarrolladores son responsables de realizar los cambios de código y estilo adecuados para que un elemento sea lo más accesible posible.
Las tres funciones principales de ARIA son los roles, las propiedades y los estados o valores.
Los roles definen qué es o qué hace un elemento en la página o la 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 y 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 línea de código, no es obligatorio. En su lugar, coloca en capas los roles, las propiedades y los estados o valores de ARIA hasta que hayas alcanzado tu objetivo final de accesibilidad. Incorporar ARIA correctamente en tu base de código garantiza que los usuarios de AT tengan toda la información que necesitan para usar tu sitio web, app o cualquier otro producto digital de forma correcta 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 de HTML5. Con ella, 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 de HTML5, junto con una mayor compatibilidad con el navegador, ciertas partes de ARIA ahora son menos importantes.
Cuando el navegador admite una etiqueta HTML con un rol implícito con un equivalente de ARIA, 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 ahora.
Esto nos lleva a la pregunta final: ¿Cuándo debes usar ARIA? Afortunadamente el grupo 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 lo hace más accesible. El informe anual de accesibilidad de WebAIM Million descubrió que las páginas principales con ARIA presente tenían un promedio de 70% más errores detectados que las que no tenían ARIA, principalmente debido a la implementación inadecuada de los atributos de ARIA.
Hay excepciones a esta regla. Se requiere ARIA cuando un elemento HTML no tiene compatibilidad 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 deseados no están disponibles en HTML. Sin embargo, estas situaciones deberían ser escasas.
No hagas lo siguiente: Asigna un rol.
<a role="button">Submit</a>
Haz lo siguiente: Usa el elemento semántico.
<button>Submit</button>
En caso de duda, 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 tal como están y no necesitan que se les agregue ARIA adicional. De hecho, los desarrolladores que usan ARIA suelen tener que agregar código adicional para que los elementos funcionen en el caso de los elementos interactivos.
No hagas lo siguiente: Asigna un rol engañoso.
<h2 role="tab">Heading tab</h2>
Haz lo siguiente: Asigna roles correctamente.
<div role="tab"><h2>Heading tab</h2></div>
Haz menos trabajo y obtén un código de mejor rendimiento cuando uses elementos HTML según lo previsto.
Regla 3: Siempre admite la navegación con el teclado
Todos los controles ARIA interactivos (no inhabilitados) deben ser accesibles con el teclado. Puedes agregar tabindex= "0" a cualquier elemento que necesite un enfoque que normalmente no reciba el enfoque del teclado. Evita usar índices de tabulación con números enteros positivos siempre que sea posible para evitar posibles problemas de orden de enfoque del teclado.
No hagas lo siguiente: Agrega un tabindex.
<span role="button" tabindex="1">Submit</span>
Haz lo siguiente: Establece el tabindex en `0`.
<span role="button" tabindex="0">Submit</span>
Por supuesto, si puedes, usa un elemento <button> real en este caso.
Regla 4: No ocultes elementos enfocables
No agregues role= "presentation" ni aria-hidden= "true" a los elementos que deben
tener enfoque, incluidos los elementos con un tabindex= "0". Cuando agregas estos roles y estados a los elementos, se envía un mensaje a la AT de 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.
No hagas lo siguiente: Oculta elementos enfocables.
<div aria-hidden="true"> <button>Submit</button> </div>
Haz lo siguiente: Expón elementos enfocables.
<div> <button>Submit</button> </div>
Regla 5: Usa nombres accesibles para elementos interactivos
El propósito de un elemento interactivo debe transmitirse a un usuario antes de que sepa cómo interactuar con él. Asegúrate de que todos los elementos tengan un nombre de accesibilidad para las personas que usan dispositivos AT.
Los nombres accesibles pueden ser el contenido que rodea 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>
Hay muchas formas de verificar el nombre de accesibilidad de un elemento, incluida la inspección del árbol de accesibilidad con las Herramientas para desarrolladores de Chrome o la prueba con un lector de pantalla.
ARIA en HTML
Si bien usar elementos HTML por sí solos es una práctica recomendada, se pueden agregar elementos ARIA en ciertas situaciones. Por ejemplo, puedes combinar ARIA con HTML en patrones que necesiten un nivel más alto de compatibilidad con AT debido a restricciones ambientales o como método de resguardo para elementos HTML que no son totalmente compatibles con todos los navegadores.
Por supuesto, hay recomendaciones para implementar ARIA en HTML. Lo más importante es no anular los roles HTML predeterminados, reducir la redundancia y tener en cuenta los efectos secundarios no deseados.
Echa un vistazo a algunos ejemplos.
No hagas lo siguiente: Asigna el rol incorrecto.
<a role="heading">Read more</a>
Haz lo siguiente: Usa el rol correcto y una descripción de vínculo adicional.
<a aria-label="Read more about some awesome article title">Read More</a>
No hagas lo siguiente: Agrega un rol redundante.
<ul role="list">...</ul>
Haz lo siguiente: Reduce la redundancia.
<ul>...</ul>
No hagas lo siguiente: No te pierdas los posibles efectos secundarios.
<details> <summary role="button">more information</summary> ... </details>
Haz lo siguiente: Aborda los efectos secundarios.
<details> <summary>more information</summary> ... </details>
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, crear patrones personalizados accesibles puede complicarse rápidamente.
Hay muchas cosas a las que debes prestar atención, incluidas, entre otras, las interacciones con el teclado, las interfaces táctiles, la compatibilidad con AT o el navegador, las necesidades de traducción, las restricciones ambientales, el código heredado y las preferencias del usuario. Un poco de conocimiento de programación puede ser perjudicial o simplemente molesto si se usa de forma incorrecta.
Dejando de lado esas advertencias, la accesibilidad digital no es una situación de todo o nada, sino un espectro que permite algunas áreas grises como esta. Se pueden considerar varias soluciones de codificación como "correctas", según la situación. Lo importante es que sigas aprendiendo, probando y tratando de hacer que nuestro mundo digital sea más abierto para todos.