Fallo común WCAG 2.2
F15Controles personalizados que el lector de pantalla no reconoce
Nombre oficial en el W3C: Fallo del criterio de conformidad 4.1.2 debido a implementar controles personalizados que no utilizan la API de accesibilidad de la tecnología, o la utilizan de forma incompleta
En pocas palabras
Este error ocurre al crear un control propio, como un interruptor, una pestaña o un deslizador, sin indicar qué es. El lector de pantalla no conoce su nombre, su función ni su estado. La persona no puede usarlo, o ni siquiera sabe que existe.
Por qué es importante
Los controles nativos de HTML, como <button>, <input> o <select>, ya informan al navegador de qué son. El navegador pasa esa información a los lectores de pantalla y otros productos de apoyo.
Un <div> con estilos y JavaScript no informa de nada. Por ejemplo, el interruptor «Recibir avisos por SMS» de un área personal se oye como un texto suelto. La persona no sabe que puede activarlo ni si ya está activado.
Cómo evitarlo
- Use siempre que pueda el elemento nativo:
<button>,<input type="checkbox">,<select>o<a href>. Ya traen todo lo necesario. - Si necesita un control propio, indique su función con un
rolede ARIA, por ejemplorole="switch"orole="tab". - Dele un nombre: texto visible,
aria-labeloaria-labelledby. - Indique su estado o valor con atributos como
aria-checked,aria-expandedoaria-valuenow. Actualícelos con JavaScript cada vez que cambien. - Haga que funcione con teclado. Siga la Guía de prácticas de autoría de ARIA (APG) del W3C para ese tipo de control.
Cómo comprobarlo
- Abra las herramientas del navegador (F12), seleccione el control y mire el panel «Accesibilidad». Deben aparecer una función (role), un nombre y, si lo tiene, un estado.
- Cambie el control (actívelo, despliéguelo o mueva el deslizador). Compruebe que el estado se actualiza en ese panel.
- Con NVDA o VoiceOver, llegue al control con el tabulador. Debe oír qué es, cómo se llama y en qué estado está.
- Pase axe DevTools o WAVE. Detectan algunos casos, como controles sin nombre, pero no todos.
Ejemplo
Interruptor para activar los avisos por SMS en un área personal.
<!-- Incorrecto: un div que el lector no reconoce -->
<div class="interruptor" onclick="cambiar(this)">
Avisos por SMS
</div>
<!-- Correcto: botón con función y estado -->
<!-- cambiar() también actualiza aria-checked -->
<button type="button" role="switch" aria-checked="false"
onclick="cambiar(this)">Avisos por SMS</button>
Ver el texto completo del W3C (traducción al español)
Esta es una traducción no oficial al español de la técnica F15 de Techniques for WCAG 2.2, del W3C. Puede contener errores. El único documento oficial y normativo es la versión original en inglés, publicada en el sitio web del W3C.
Aplicabilidad
Se aplica a todas las tecnologías que admiten una API de accesibilidad.
Descripción
Cuando se utilizan los controles estándar de tecnologías accesibles, normalmente están programados de forma que usan y admiten la API de accesibilidad. Sin embargo, cuando se crean controles personalizados, es responsabilidad de quien desarrolla el control garantizar que este se exponga correctamente a los usuarios a través de la API de accesibilidad de la plataforma. Si no se hace así, las tecnologías de asistencia no podrán entender qué es el control ni cómo manejarlo, o puede que ni siquiera sepan que existe.
En las tecnologías que lo admiten, puede usarse WAI-ARIA para exponer la función, el nombre, el valor, los estados y las propiedades de un control personalizado a través de la API de accesibilidad de la tecnología.
Además de garantizar que los controles personalizados se expongan correctamente a los usuarios a través de la API de accesibilidad de la plataforma, hay que tener en cuenta muchas otras consideraciones para que el control sea accesible para el mayor número posible de personas. La funcionalidad con teclado, el tamaño del objetivo y los requisitos de contraste de color son solo algunas de las consideraciones adicionales que deben tenerse en cuenta, y todas ellas van más allá de lo que cubren el criterio de conformidad 4.1.2 Nombre, función y valor y esta técnica.
Ejemplos
Un reproductor de música se diseña con controles personalizados que parecen notas musicales que se estiran para ajustar el volumen, el tono, etc. El programador no hace que el nuevo control admita la API de accesibilidad. Como resultado, los controles no pueden identificarse ni manejarse desde la tecnología de asistencia.
Pruebas
Procedimiento
- Usando el comprobador de accesibilidad de la tecnología (o, si no está disponible, inspeccionando el código con las herramientas para desarrolladores de un navegador, o probando con una tecnología de asistencia), comprobar los controles para ver si admiten la API de accesibilidad.
Resultados esperados
- Si la comprobación n.º 1 es falsa, se da esta condición de fallo y el contenido falla este criterio de conformidad.
Recursos
Cómo lo comprobamos en ADDAW
Este error es uno de los que buscamos en cada auditoría de ADDAW. Se lo entregamos con capturas y la forma de corregirlo.
Basado en la técnica F15 del W3C (WCAG 2.2). Explicación y ejemplos: ADDAW. Traducción no oficial del texto del W3C © W3C, licencia de documentos del W3C. ¿Ha visto un error? Escríbanos.