Solución:
Esto se describe en la especificación de aria. Proporciona la identificación de un elemento que proporciona información adicional sobre el elemento actual que algunos usuarios pueden necesitar.
A continuación se muestra un ejemplo de cómo podría utilizar la propiedad aria-describedby. Se usa cuando tienes un texto que tiene información sobre el elemento. Aria-describedby debe ser el mismo que el id del texto que lo describe.
First name: <input aria-describedby="name" type="text">
<em id="name">Your first name must be correct.</em>
A primera vista diría aria-describedby
es probable que se ignore aquí porque está definido en <td>
. La mayoría de los navegadores y lectores de pantalla ignorarán aria-describedby
información cuando se establece en un elemento que no es interactivo (enfocable).
Pero el ejemplo específico es un poco más complejo debido a role="gridcell"
que anula la semántica de <td>
y por lo tanto, el ejemplo proporcionado es válido si sigue la especificación ARIA para gridcell. Es un componente personalizado.
En general, el atributo aria-describedby
proporciona al lector de pantalla la información adicional que se anunciará a lo largo del contenido del elemento (no es el único caso de uso, sino el más común).
Por ejemplo en lugar de solo "Logout"
el lector de pantalla anunciará "Logout, John Doe"
:
Logged-in as <span id="user">John Doe</span>.
<a aria-describedby="user" href="https://foroayuda.es/logout">Logout</a>
O ejemplo con una información sobre herramientas (Pista: falta la parte de Javascript aquí):
<button type="button" aria-describedby="my-tooltip">Snipping Tool</button>
<div hidden id="my-tooltip" role="tooltip">
It can take still screenshots of an open window,
rectangular areas, a free-form area,
or the entire screen.
</div>
O ejemplo con un elemento de formulario, otro caso de uso común:
<form ...>
<label for="my-name">Full name</label>
<input aria-describedby="my-name-desc" id="my-name" type="text"/>
<p id="my-name-desc">
Please tell us your full name.
</p>
</form>
El ejemplo anterior anunciará tanto <label>
y la descripción adicional (definida por aria-describedby
) inmediatamente cuando un usuario enfoca el campo de entrada. No solo elimina la necesidad de leer el entorno para poder comprender lo que se espera que ingrese, sino también leer todos los elementos que no sean los controles de formulario cuando se encuentra dentro del <form>
puede ser más complejo para un usuario de lector de pantalla. Es una experiencia diferente a la de leer el resto de la página. Porque los eventos de teclado pueden interactuar con lectores de pantalla o con controles de formulario, pero difícilmente con ambos al mismo tiempo. Sin mencionar que los lectores de pantalla ofrecen un montón de atajos de teclado útiles, por ejemplo, presionar “H” saltará al siguiente encabezado, pero obviamente no cuando <input>
el campo está enfocado. Entonces se ingresará “H” en <input>
.
Acerca de ARIA:
- ARIA se usa comúnmente para mejorar la accesibilidad de los lectores de pantalla (no solo, sino principalmente cajeros automáticos).
-
¡Usar ARIA no necesariamente mejora las cosas! Fácilmente, ARIA puede conducir a una accesibilidad significativamente peor si no se implementa y se prueba correctamente. No use ARIA solo para tener algunas “cosas interesantes en el código” que no comprende completamente. Lamentablemente, con demasiada frecuencia, las implementaciones de ARIA presentan más problemas que soluciones en términos de accesibilidad. Esto es bastante común, ya que es menos probable que los usuarios y desarrolladores videntes pongan un esfuerzo adicional en pruebas exhaustivas con lectores de pantalla, mientras que, por otro lado, las especificaciones y validadores ARIA están actualmente lejos de ser perfectos e incluso confusos en algunos casos. Además de eso, cada navegador y lector de pantalla implementan el soporte ARIA de manera no uniforme, lo que provoca las principales inconsistencias en el comportamiento. A menudo, es mejor evitar ARIA por completo cuando no está claro exactamente qué hace, cómo se comporta y no se probará intensamente con todos los lectores de pantalla y navegadores (o al menos con las combinaciones más comunes). Descargo de responsabilidad: Mi intención no es deshonrar a ARIA, sino más bien sus malas implementaciones de ARIA. De hecho, no es tan infrecuente que HTML5 no ofrezca otras alternativas en las que la implementación de ARIA traiga importantes beneficios para la accesibilidad, por ejemplo.
aria-hidden
oaria-expanded
. ¡Pero solo si se implementa y se prueba correctamente!
Acerca de aria-describedby
- Proporciona información adicional a lo largo del contenido del elemento.
- Funciona como se esperaba en elementos enfocables (por ejemplo, botón, entrada, a). Mayormente inútil en otros elementos (“principalmente” hay excepciones)
- IE 11 es un poco complicado. A veces se ignora. Podría marcar la diferencia si se implementa en
a
obutton
también si el elemento referenciado está oculto (display:none
), su posición (¿se hace referencia al elemento interno?) o si tienetabindex="-1"
orole
(p.ejrole="none"
) en él, etc. Asegúrese de probar todos los lectores de pantalla - Puede comportarse de manera diferente si se usa un lector de pantalla en un modo de enfoque (tecla TAB) o en modo virtual (leer el contenido con las teclas de FLECHA)
- Tanto Firefox como Internet Explorer respetan
aria-describedby
solo en modo de enfoque. Como tal, no tiene sentido agregarlo a elementos no enfocables. Desde: ADG - Si bien NVDA anuncia descripciones de inmediato, JAWS a veces solicita presionar manualmente MANDÍBULAS+Alt+R para anunciarlo. Desde: ADG
- Si el elemento referenciado está oculto, no se puede buscar con
Ctrl+F
(que es una forma común en la que a los usuarios les gusta navegar por el sitio web para encontrar rápidamente lo que buscan). Desde: ADG - El único caso en el que realmente recomendamos el uso de
aria-describedby
, consiste en adjuntar información adicional a elementos interactivos (por ejemplo, para relacionar información visible, por ejemplo, con controles de formulario). Desde: ADG - Buena idea: usar una combinación de
aria-describedby
(en un control de formulario) yrole="alert"
(en un SPAN) para un error de control de formulario. De: W3.org