aria-braille-equivalent
aria-braillelabel y aria-brailleroledescription deben tener un equivalente para tecnologías no braille
Comprueba que los elementos que usan aria-braillelabel también tengan un nombre accesible normal, y que los elementos que usan aria-brailleroledescription también tengan aria-roledescription.
Ámbito de aplicación. Elementos con un atributo aria-braillelabel no vacío y/o un atributo aria-brailleroledescription no vacío.
Resultado esperado. Según la especificación ARIA, aria-braillelabel es un COMPLEMENTO específico de braille (no un sustituto) del nombre accesible normal del elemento, y aria-brailleroledescription es un complemento de aria-roledescription. Por lo tanto, un elemento también debe tener:
- un nombre accesible no vacío procedente de un mecanismo no braille, si declara
aria-braillelabel; - un
aria-roledescriptionno vacío, si declaraaria-brailleroledescription.
Usar cualquiera de los atributos específicos de braille como ÚNICO mecanismo de nombrado deja a las tecnologías de asistencia que no utilizan braille (la mayoría de lectores de pantalla, control por voz, etc.) sin ningún nombre accesible/descripción de rol. Devuelve cantTell en lugar de fail: aria-brailleroledescription sin aria-roledescription no se expone a las tecnologías de asistencia afectadas, y un nombre accesible ausente es una decisión de las reglas de nombrado para los roles que lo requieren. Que el atributo braille quede sin emparejar merece señalarse, pero no constituye en sí mismo un criterio que falle.
Qué informa un hallazgo.
attr: el atributo de braille que no tiene equivalente:aria-braillelabeloaria-brailleroledescription.requires: lo que el elemento necesita además: "an accessible name" (un nombre accesible) paraaria-braillelabel,aria-roledescriptionparaaria-brailleroledescription.
Estos campos de data.details ayudan a leer y reproducir un hallazgo. Salvo reasonCode y los pocos campos que Esquema de salida indica como estables, no son un contrato estable: un campo puede cambiar de nombre o desaparecer en una versión menor, así que no construyas sobre ellos.
Ejemplos
<button aria-braillelabel="SAVE">Save changes</button>
La etiqueta braille complementa un nombre accesible real ("Save changes"); las tecnologías de asistencia que no utilizan braille siguen obteniendo un nombre.
<button aria-braillelabel="SAVE"></button>
aria-braillelabel es el único mecanismo de nombrado presente; las tecnologías de asistencia que no utilizan braille no obtienen ningún nombre accesible.
Cómo comprobarlo
Cuando esta regla no puede decidir, informa cantTell y deja la pregunta a una persona. Cada pregunta que puede plantear aparece aquí bajo su código de motivo, con los pasos para responderla. Un hallazgo lleva los mismos pasos en howToCheck, en el idioma del análisis. Consulta Esquema de salida.
BRAILLE_ATTR_WITHOUT_EQUIVALENT
- Inspeccionar el elemento que indica el informe y anotar si tiene aria-braillelabel o aria-brailleroledescription.
- Si tiene aria-braillelabel, abrir el panel Accesibilidad de las herramientas para desarrolladores del navegador y leer el nombre accesible del elemento.
- Si el rol es de los que necesitan un nombre (botón, enlace, imagen, casilla de verificación y similares), confirmar que existe un nombre además de la etiqueta braille; escucharlo con un lector de pantalla en modo de voz.
- Si tiene aria-brailleroledescription, comprobar si también tiene aria-roledescription; si no, confirmar que el rol nativo se sigue anunciando y que no se pretendía otra cosa.
Se cumple. El elemento tiene un nombre hablado (y una roledescription donde se da una en braille), o su rol no necesita nombre y no se pierde nada.
No se cumple. Un control o una imagen solo tiene una etiqueta braille, así que quienes usan voz no reciben ningún nombre, lo que incumple WCAG 4.1.2.