Fallo común Fallos comunes WCAG 2.2
F15Fallo 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 resumen
Este fallo se produce cuando se crean controles personalizados (deslizadores, botones dibujados, menús propios) sin exponer su nombre, función, estado y valor a través de la API de accesibilidad de la plataforma. Los lectores de pantalla y otras tecnologías de asistencia no saben qué es el control ni cómo manejarlo, o ni siquiera detectan que existe. Si no puede usar controles nativos, complete el control con WAI-ARIA y compruébelo con un inspector de accesibilidad.
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 fallo es uno de los que buscamos en cada auditoría de accesibilidad de ADDAW: lo documentamos con capturas y el código afectado, indicamos el criterio que incumple y la técnica suficiente con la que se corrige. Los informes siguen la metodología del Observatorio de Accesibilidad y la norma UNE-EN 301 549.
Fuente y licencia
Traducción al español, no oficial, realizada por ADDAW a partir de la técnica F15 del documento «Techniques for WCAG 2.2» del W3C (versión del repositorio público del W3C a 22/10/2026). Copyright © W3C® (MIT, ERCIM, Keio, Beihang). Se publica conforme a la licencia de documentos del W3C. El texto normativo de referencia es el original en inglés; si detecta un error en la traducción, escríbanos.
