La accesibilidad web es fundamental para garantizar que todos los usuarios, incluidas las personas con discapacidades, puedan interactuar correctamente con los elementos de una página. Un problema recurrente en el desarrollo web es la implementación de controles personalizados sin el uso adecuado de una API de accesibilidad.
El fallo F15 ocurre cuando los desarrolladores crean controles interactivos personalizados (botones, deslizadores, reproductores multimedia, entre otros) que no están correctamente expuestos a las tecnologías de asistencia a través de la API de accesibilidad de la plataforma. Esto impide que los usuarios de lectores de pantalla u otras herramientas de asistencia puedan percibir y operar estos controles correctamente.
La API de accesibilidad actúa como un puente entre la interfaz de usuario y las tecnologías de asistencia. Cuando se usan controles HTML estándar, la compatibilidad con la API es automática, pero en controles personalizados es responsabilidad del desarrollador asegurarse de que sean accesibles mediante el uso de WAI-ARIA y eventos de teclado.
Acerca de este fallo
Este fallo incumple el criterio de conformidad 4.1.2: Nombre, Rol, Valor (Nivel A) de WCAG 2.1, que exige que los controles de usuario expongan su:
- Nombre: Cómo se identifica el control.
- Rol: Su función dentro de la interfaz (botón, casilla de verificación, deslizador, etc.).
- Valor: Estado o contenido del control.
Cuando un control personalizado no usa una API de accesibilidad adecuada, las tecnologías de asistencia no pueden identificarlo, lo que genera una barrera para los usuarios con discapacidad visual o motora.
Escenarios comunes en los que ocurre este fallo:
- Uso de elementos
<div>o<span>para crear botones o controles sin roles y atributos accesibles. - Creación de controles personalizados con JavaScript sin exponer su función mediante WAI-ARIA.
- Falta de compatibilidad con el teclado en controles interactivos.
Ejemplos
Ejemplo incorrecto 1: Uso de elementos sin roles y atributos accesibles.
Código incorrecto: Un botón personalizado hecho con <div> sin rol accesible:
<div onclick="submitForm()" style="width: 100px; height: 40px; background: blue; color: white; text-align: center;">Enviar</div>🔴 Problema:
- El elemento
<div>no tiene un rol semántico. - Los lectores de pantalla no lo reconocen como un botón.
- No se puede enfocar con el teclado ni activar con «Enter» o «Espacio».
Solución correcta: Usar elementos con roles y atributos accesibles.
Código accesible con WAI-ARIA:
<button onclick="submitForm()" aria-label="Enviar formulario">Enviar</button>✅ ¿Qué mejora?:
- Se usa un
<button>, que es accesible por defecto. - Se añade
aria-labelpara una mejor identificación. - Es compatible con el teclado y tecnologías de asistencia.
Ejemplo incorrecto 2: Uso de elementos sin atributos accesibles.
Código incorrecto: Un deslizador de volumen personalizado sin atributos accesibles:
<div class="slider" onmousedown="adjustVolume(event)"></div>🔴 Problema:
- No tiene
role="slider"para ser identificado como un control de volumen. - No informa su valor actual a los lectores de pantalla.
- No se puede operar con el teclado.
Solución correcta: Usar elementos con atributos accesibles.
Código accesible con ARIA:
<div role="slider" aria-valuemin="0" aria-valuemax="100" aria-valuenow="50" tabindex="0" onkeydown="adjustVolumeWithKeyboard(event)"></div>✅ ¿Qué mejora?:
- Se define el rol
slider. - Se especifican los valores mínimo, máximo y actual con
aria-valuemin,aria-valuemaxyaria-valuenow. - Se permite la navegación con el teclado.
Ejemplo correcto: Uso de controles estándar
Uso de controles estándar en lugar de personalizados:
<input type="range" min="0" max="100" value="50" aria-label="Control de volumen">Este control ya es accesible sin necesidad de añadir atributos extra.
Errores comunes y cómo evitarlos
Errores frecuentes:
- Usar elementos
<div>o<span>como botones sin roles accesibles. - Implementar controles personalizados sin
aria-label,aria-roleu otros atributos. - No permitir la navegación por teclado.
- No probar los controles con tecnologías de asistencia.
Cómo evitar estos errores:
- Usar siempre que puedas controles HTML estándar, ya que la compatibilidad con la API es automática.
- Implementar WAI-ARIA en controles personalizados requiere de conocimientos avanzados y suele ser fuente de numerosos conflictos que generan barreras de accesibilidad.
- Probar con herramientas como VoiceOver, NVDA o JAWS.
- Validar con Accessibility Insights o el inspector de accesibilidad del navegador.
Preguntas frecuentes
¿Por qué los controles personalizados pueden ser inaccesibles?
Porque no están conectados a la API de accesibilidad, lo que impide que sean detectados por lectores de pantalla.
¿Cuándo debería usar WAI-ARIA?
Cuando un control no tiene una alternativa semántica en HTML estándar.
¿Cómo puedo probar si un control es accesible?
Usando herramientas como Accessibility Insights, el inspector de accesibilidad del navegador o un lector de pantalla.
¿Es obligatorio usar ARIA en todos los controles?
No, solo cuando sea necesario. Siempre es mejor usar elementos HTML nativos.
¿Qué pasa si un control no tiene soporte de teclado?
No será usable para personas con discapacidades motoras. Se debe agregar tabindex y eventos keydown.
¿Cuáles son las herramientas más recomendadas para validar accesibilidad?
WAVE, axe DevTools, NVDA y la pestaña «Accesibilidad» en las herramientas de desarrollador del navegador.
Recursos relacionados
- Guía oficial WCAG 2.1 para el fallo común F15: Incumplimiento del Criterio de Conformidad 4.1.2 debido a la implementación de controles personalizados que no utilizan una API de accesibilidad para la tecnología, o lo hacen de manera incompleta
- Comprender el criterio de éxito 4.1.2: Nombre, Rol, Valor
- Comprobador de accesibilidad activa (AccExplorer)
- Aplicaciones de Internet enriquecidas y accesibles (WAI-ARIA)
- Guía de prácticas de creación de contenido WAI-ARIA
- ARIA en HTML
Pruebas y validación
Procedimiento:
- Revisar los controles personalizados con herramientas de accesibilidad (o si no está disponible, inspeccionar el código usando las herramientas para desarrolladores de un navegador o probar con una tecnología de asistencia).
- Verificar que los controles admiten la API de accesibilidad.
- Probar la navegación con teclado y lectores de pantalla.
Resultados esperados:
- ❌ Si los controles no están expuestos correctamente, la prueba falla.
- ✅ Si las tecnologías de asistencia pueden identificar y operar los controles, la prueba es exitosa.
Implementar controles personalizados sin API de accesibilidad crea barreras para los usuarios con discapacidades. Asegúrate de que todos los controles sean accesibles usando HTML semántico o WAI-ARIA.
¿Necesitas ayuda con la accesibilidad web? Contáctanos y optimiza tu sitio para todos.