La mayoría de los desarrolladores conocen el lenguaje de marcación estándar de nuestros Web y Lenguaje de marcado de hipertexto (HTML). Sin embargo, es posible que estés menos familiarizado con Aplicaciones de Internet enriquecidas accesibles (ARIA) (anteriormente llamada WAI-ARIA): qué es, cómo se usa y cuándo (y cuándo no) usarla.
HTML y ARIA desempeñan un papel importante en hacer que los productos digitales sean accesibles, especialmente en lo que respecta a la tecnología de asistencia (AT), como los lectores de pantalla. Ambos se usan para convertir el contenido a un formato alternativo, como braille o Text‐to‐Speech (TTS)
Repasemos una breve historia de ARIA, por qué es importante, y cuándo y cómo mejor usarla.
Introducción a ARIA
ARIA fue desarrollado por primera vez en 2008 por el Grupo de la Iniciativa de Accesibilidad Web (WAI): del World Wide Web Consortium (W3C) general, que administra y regula la Internet.
ARIA no es un verdadero lenguaje de programación, sino un conjunto de atributos que puedes agregar elementos HTML para aumentar su accesibilidad. Estos atributos comunican a través de APIs de accesibilidad, como el rol, el estado y la propiedad de las tecnologías de accesibilidad. que se encuentran en los navegadores modernos. Esta comunicación se produce a través del entorno de imágenes.
"WAI-ARIA, el Conjunto de aplicaciones de Internet enriquecidas accesibles, define una forma de hacer que la Web contenido y aplicaciones web más accesibles para las personas con discapacidades. Integra especialmente ayuda con el contenido dinámico y los controles avanzados de la interfaz de usuario desarrollado 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 la AT al cambiar, exponer y aumentar partes de la accesibilidad de imágenes.
El navegador crea el árbol de accesibilidad y se basa en el Árbol del modelo de objetos del documento (DOM) Como el árbol del DOM, el árbol de accesibilidad Contiene objetos que representan todos los elementos de lenguaje de marcado, atributos y texto nodos. La accesibilidad específica de la plataforma también usa el árbol de APIs 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 notarán diferencias entre un producto digital con ARIA y otra sin él. Eso también significa que solo los desarrolladores son responsables para realizar los cambios de estilo y código adecuados para realizar un elemento como accesible posible.
Las tres funciones principales de ARIA son los roles, las propiedades y los estados/valores.
Los roles definen lo que un elemento hace o hace en la página o aplicación.
<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 o 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 pueden usarse en una sola línea de código, no es necesario como en los productos necesarios. En su lugar, coloca los roles, las propiedades y los estados o valores de ARIA hasta que lograste tu objetivo final de accesibilidad. La incorporación correcta de ARIA en tu base de código garantiza que los usuarios de AT tengan toda la información que necesitan para usar tu sitio web, aplicación o cualquier otro producto digital de manera 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 la comprensión del impacto de su código accesibilidad.
Cuándo usar ARIA
En 2014, el W3C publicó oficialmente la recomendación HTML5. Con él, vino.
algunos cambios importantes, como 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
mayor compatibilidad con el navegador, ciertas partes de ARIA ahora son menos críticas.
Cuando el navegador admite una etiqueta HTML con un rol implícito con un ARIA equivalente, por lo general no es necesario agregar ARIA al elemento. Sin embargo, ARIA todavía incluye muchos roles, estados y propiedades que no están disponibles en ningún versión de HTML. Esos atributos siguen siendo útiles por el momento.
Esto nos lleva a la última pregunta: ¿cuándo deberías usar ARIA? Por suerte el grupo WAI ha desarrollado cinco reglas de ARIA para ayudarte a decidir para hacer que los elementos sean accesibles.
Regla 1: No usar ARIA
Sí, leíste bien. Agregar ARIA a un elemento no implica que más accesible. El informe anual de accesibilidad de WebAIM Million reveló que las páginas principales con ARIA presentaron, en promedio, un 70% más de errores detectados que aquellos sin ARIA, principalmente debido a la implementación inadecuada de los atributos de ARIA.
Esta regla tiene excepciones. ARIA es obligatorio cuando se usa un elemento HTML no es compatible con accesibilidad. Esto podría deberse a que el diseño permiten un elemento HTML específico o la función o el comportamiento deseados no disponible en HTML. Sin embargo, estas situaciones deberían ser escasas.
<a role="button">Submit</a>
<button>Submit</button>
Si tienes dudas, usa elementos semánticos de HTML.
Regla 2: No agregues ARIA (innecesario) al HTML
En la mayoría de los casos, los elementos HTML funcionan bien desde el primer momento y no es necesario que se agreguen 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>
Hagan menos trabajo y tengan un código con mejor rendimiento cuando usen elementos HTML como lo previsto.
Regla 3: Siempre admite la navegación con teclado
Todos los controles de ARIA interactivos (no inhabilitados) deben ser accesibles con el teclado. Tú puedes agregar tabindex= "0" a cualquier elemento que necesite un enfoque que normalmente para recibir el enfoque del teclado. Evita usar índices de pestañas con valores positivos números enteros siempre que sea posible para evitar posibles problemas con el orden de enfoque del teclado.
<span role="button" tabindex="1">Submit</span>
<span role="button" tabindex="0">Submit</span>
<button> real en este caso.
Regla 4: No ocultes los elementos enfocables
No agregues role= "presentation" ni aria-hidden= "true" a elementos que lo necesiten
tenga el foco, incluidos los elementos con tabindex= "0". Cuando agregas
estas funciones o estados a los elementos, envía un mensaje a la AT de que estos
elementos no son importantes y omitirlos. 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 accesibles para los elementos interactivos
El propósito de un elemento interactivo se debe transmitir a un usuario antes de saben cómo interactuar con ellos. Asegúrate de que todos los elementos tengan nombre accesible para personas que usan AT dispositivos.
Los nombres accesibles pueden ser el contenido rodeado de 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 "Cuero rojo" botas".
<!-- 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, 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 usar elementos HTML por sí solos es una práctica recomendada, los elementos ARIA se pueden agregado en ciertas situaciones. Por ejemplo, puedes vincular ARIA con HTML en patrones que necesitan un mayor nivel de apoyo de AT debido a la o como método de resguardo para elementos HTML que no estén completamente compatibles con todos los navegadores.
Por supuesto, existen recomendaciones para implementar ARIA en HTML Lo más importante es no anular roles de HTML predeterminados, reducir la redundancia y estar al tanto de los efectos secundarios no deseados.
Veamos algunos ejemplos.
<a role="heading">Read more</a>
<a aria-label="Read more about some awesome article title">Read More</a>
<ul role="list">...</ul>
<ul>...</ul>
<details> <summary role="button">more information</summary> ... </details>
<details> <summary>more information</summary> ... </details>
Complejidades de ARIA
Los ARIA son complejos, por lo que siempre debes usarlos con precaución. Si bien el ejemplos de código de esta lección son bastante sencillos y permiten crear los patrones personalizados pueden complicarse rápidamente.
Hay muchas cuestiones a las que debes prestar atención, incluidos, sin limitaciones, los siguientes: interacciones con teclado, interfaces táctiles, compatibilidad con AT/navegador, necesidades de traducción, restricciones del entorno, código heredado y preferencias del usuario. Un poco de el conocimiento de codificación puede ser perjudicial, o simplemente molesto, si se usa incorrectamente. Recuerda mantener tu código simple.
Dejando de lado las advertencias, la accesibilidad digital no es un modelo de "todo o nada" es un espectro que permite algunas áreas grises como esta. Múltiples soluciones de programación pueden considerarse “correctas”, según la situación. Lo importante es que sigan aprendiendo, probando e intentando hacer nuestros digital más abierto a todos.
Verifica tus conocimientos
Pon a prueba tus conocimientos sobre ARIA y HTML
¿Cuál de las siguientes es la práctica recomendada para compilar 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>