5 ejemplos que muestran lo que sucede si no agrega atributos ARIA a sus sitios web.
Recientemente, me encontré con una pregunta en un foro de discusión para mi curso de Diseño de experiencia de usuario de otro estudiante.
Estoy un poco familiarizado con la idea de los atributos de ARIA , pero como alguien que nunca ha usado un lector de pantalla u otro tipo de tecnología de asistencia, siempre he tenido curiosidad sobre qué impactos específicos tienen los diferentes atributos de ARIA en la forma en que presentan el contenido a los usuarios. .
¿Son la mayoría de ellos simplemente una prueba de futuro en caso de que las tecnologías de asistencia decidan utilizar esa información en el futuro, o la mayoría de los atributos tienen un efecto tangible ahora?
¿Exagerar con los atributos de ARIA puede dañar la experiencia del usuario en algunos casos?
Aprender sobre cosas como esa parece ser importante para construir sitios web que sean accesibles en la práctica y no solo en la teoría.
Creo que la mayoría de los desarrolladores tienen este alto nivel de comprensión de que los atributos de ARIA son importantes para los usuarios con discapacidades. Pero como alguien que nunca ha necesitado usar un lector de pantalla, no tengo una gran comprensión de cuáles son las consecuencias cuando no configura sus atributos correctamente. Es por eso que quiero explorar ejemplos del mundo real de lo que escucharía un usuario con discapacidad visual cuando un sitio web no está configurado correctamente con los atributos ARIA. Pero primero, debemos entender cómo funciona exactamente un lector de pantalla.
¿Qué son los lectores de pantalla y quién los usa?
Los lectores de pantalla utilizan la síntesis de texto a voz y otros métodos para leer en voz alta el contenido y los elementos de una pantalla, como texto, botones, enlaces e imágenes, y permiten a los usuarios navegar e interactuar con el contenido mediante comandos de teclado u otros. métodos de entrada. Este simple ciclo navegar-escuchar-interactuar permite a los usuarios utilizar todas las funciones de un sitio web si está diseñado con este tipo de interacción con el usuario en mente.
Hay opciones integradas como VoiceOver (incluido en los sistemas operativos macOS e iOS de Apple) y Narrador (que se incluye en Microsoft Windows), así como el complemento del navegador que generalmente brinda características adicionales y personalización.
Aunque la mayoría piensa que los lectores de pantalla son malos para los usuarios con baja o nula visión. También son utilizados por personas con deficiencias cognitivas o de movilidad y por personas que no tienen discapacidades, pero que necesitan acceso a información electrónica y sitios web en situaciones en las que el acceso visual no es posible o práctico.
Ejemplo 1: una imagen
Tomemos esta simple imagen de un pug.
<img src="assets/images/8193903121.png"/>
A pug wearing a red party hat with white dots
8193903121.png, imagen
Que no proporciona información a un usuario de lector de pantalla más que el hecho de que hay una imagen. Para solucionar esto, agregue una alt
etiqueta a las imágenes.
<img
src="assets/images/8193903121.png"
alt="A pug wearing a red party hat with white dots"
/>
Como nota al margen, cuando un elemento html admite esa alt
etiqueta, debe usarse sobre aria-label
. Aria-label
solo debe usarse en casos especiales como cuando a div
tiene la propiedad role=”img”
.
Ejemplo 2: un botón de envío deshabilitado
<button disabled>Let's Go!</button>
A disabled button labeled “Let’s Go!” at the end of form
¡Vamos!, botón
Esto no le dice al usuario qué hará al presionar el botón, o el hecho de que está deshabilitado. Arreglemos eso:
<button aria-label="Submit email" aria-disabled="true" disabled>Let's Go!</button>
Aquí aria-label
describe cuál es el propósito del botón y el aria-disabled
atributo permite que el lector de pantalla describa que el botón está atenuado y actualmente deshabilitado.
Ejemplo 3: un cuadro de comentarios con una etiqueta
Comment:
<textarea></textarea>
<p> Your comment will be visible to all members of your organization.</p>
A highlighted text area with the label “Comment:” and a description below it: “Your comment will be visible to all member of your organization.”
Editar texto, en blanco
Para solucionar esto, debemos asociar el área de texto con la etiqueta y la descripción.
<label id="comment-label" for="comment-box">Comment:</label>
<textarea
id="comment-box"
aria-labelledby="comment-label"
aria-describedby="comment-desc"
></textarea>
<p id="comment-desc">Your comment will be visible to all members of your organization.</p>
Aquí aria-labelledby
conecta el textarea
con el label
, lo que permite que el lector de pantalla entienda que el campo está solicitando un comentario. Observe también que la for
propiedad en la etiqueta hace lo contrario, de modo que cuando el lector de pantalla se enfoca en el label
, sabe que es una etiqueta para el textarea
. Por último, aria-describedby
el atributo vincula la descripción con el textarea
.
Ejemplo 4: Tabla Simple
<table>
<thead>
<tr>
<th>Name</th>
<th>Quantity</th>
<th>Rating</th>
</tr>
</thead>
<tbody>
<tr>
<th>Product 1</th>
<td>5</td>
<td>4.5</td>
</tr>
<tr>
<th>Product 2</th>
<td>3</td>
<td>3.7</td>
</tr>
</tbody>
</table>
A 3x3 table listing the name, quantity, and rating of Product 1 and Product 2
Nombre: (Columna 1 de 3)-> Cantidad: (Columna 2 de 3)-> Calificación: (Columna 3 de 3)-> Producto 1 -> 5 -> 4.5 -> Producto 2->3-> 3.7
Eso podría ser suficiente para algunos usuarios, especialmente cuando la mesa es corta. Sin embargo, podemos agregar atributos de Aria para mejorar significativamente esta experiencia.
<table role="table" aria-label="Product Comparison">
<thead>
<tr>
<th scope="col" aria-label="Product Name">Name</th>
<th scope="col" aria-label="Product Quantity">Quantity</th>
<th scope="col" aria-label="Product Rating">Rating</th>
</tr>
</thead>
<tbody>
<tr>
<th scope="row" aria-label="Product 1">Product 1</th>
<td>5</td>
<td>4.5</td>
</tr>
<tr>
<th scope="row" aria-label="Product 2">Product 2</th>
<td>3</td>
<td>3.7</td>
</tr>
</tbody>
</table>
Ahora, al pasar por la tercera columna, un lector de pantalla podría decir:
Nombre del producto: Producto 2->Cantidad del producto: 3-> Calificación del producto: 3.7
Por supuesto, la verbosidad de esto se puede ajustar en la mayoría de los lectores de pantalla para evitar decir los títulos de las columnas si después de x repeticiones, pero agregar estas etiquetas le da este control al usuario y le permite elegir cuánto quiere escuchar.
Ejemplo 5: uso excesivo de los atributos de Aria
Por supuesto, como con la mayoría de las cosas en la vida, demasiado de algo bueno puede ser malo.
<div
role="dialog"
aria-labelledby="modal-title"
aria-describedby="modal-description"
aria-modal="true"
aria-hidden="false"
aria-live="polite"
aria-atomic="true"
>
<h2 id="modal-title">Modal Title</h2>
<p id="modal-description">This is a modal window that contains important information for the user.</p>
{...}
</div>
El futuro de ARIA
A medida que la web continúa evolucionando y se vuelve más compleja, ARIA seguirá desempeñando un papel crucial para hacer que las aplicaciones web sean accesibles y fáciles de usar para los usuarios de tecnologías de asistencia, como lectores de pantalla y navegación con teclado.
Una de las áreas clave donde es probable que ARIA experimente un mayor desarrollo es en el soporte de nuevas tecnologías web y patrones de diseño . Por ejemplo, a medida que más aplicaciones web utilicen arquitecturas de una sola página y JavaScript asíncrono, ARIA deberá proporcionar nuevos atributos y técnicas para hacer que estas aplicaciones sean accesibles para los usuarios de tecnología de asistencia.
Otra área importante para el futuro de ARIA es mejorar la interoperabilidad y la compatibilidad de los atributos de ARIA en diferentes navegadores y tecnologías de asistencia . Actualmente, existen algunas incoherencias y diferencias en la forma en que los diferentes navegadores y las tecnologías de asistencia interpretan y usan los atributos de ARIA. Trabajar hacia una implementación más consistente y estandarizada de ARIA en la web será fundamental para mejorar la experiencia del usuario para los usuarios de tecnología de asistencia.
Finalmente, el futuro de ARIA también implicará la colaboración y el diálogo continuos entre desarrolladores web, expertos en accesibilidad y usuarios de tecnología de asistencia . A medida que surgen nuevos desafíos y oportunidades en el mundo de la accesibilidad web, será importante que estas partes interesadas trabajen juntas para identificar y abordar posibles problemas y desarrollar nuevas soluciones que puedan beneficiar a todos los usuarios de la web.
En general, el futuro de ARIA parece brillante y prometedor. A medida que la web continúa evolucionando, ARIA desempeñará un papel crucial para hacerla más accesible y fácil de usar para todos. Los desarrolladores web deben:
- Utilice atributos y técnicas de ARIA para proporcionar contexto y funcionalidad adicionales para las tecnologías de asistencia.
- Proporcione etiquetas y descripciones claras y descriptivas para todos los elementos y controles.
- Use elementos HTML semánticos para transmitir con precisión la estructura y el contenido de la página.
- Asegúrese de que el contenido esté correctamente estructurado y organizado, con una clara jerarquía y relaciones entre los elementos.
- Utilice el color y el contraste con prudencia para asegurarse de que el contenido sea legible y visible para los usuarios con problemas de visión.
- Proporcione accesibilidad al teclado, lo que permite a los usuarios navegar e interactuar con la página usando solo un teclado u otro dispositivo de entrada.
- Pruebe la aplicación con tecnologías de asistencia para asegurarse de que se pueda utilizar y sea accesible.
Hay muchos más atributos de ARIA que no mostré aquí. Vea una lista completa de ellos aquí:https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes
Tenga en cuenta que ChatGPT se utilizó para la investigación y para escribir algunas partes de este artículo.