Accesibilidad web: qué arreglar primero
El trabajo de accesibilidad tiene una lista larga y un conjunto corto de cosas que explican casi todas las barreras reales. Empezar por la lista corta pone usuarios reales en su sitio rápido; empezar por una auditoría completa suele producir un documento que nadie ejecuta.
Esta guía cubre qué arreglar primero, cómo probarlo usted mismo en una tarde y por qué los widgets de superposición no son el atajo que venden.
Los arreglos de mayor efecto#
Son las barreras que impiden completar tareas por completo, en vez de hacerlas un poco más difíciles. Arréglelas antes que nada de una lista más larga.
- Acceso por teclado. Cada elemento interactivo alcanzable con Tab y operable con Intro o Espacio, en un orden sensato y con un anillo de foco visible. Si el sitio solo se puede usar con ratón, nada más de esta lista importa.
- Alternativas textuales. Texto alternativo con sentido en las imágenes que aportan información; alt vacío en las decorativas. Un alt ausente no es lo mismo que uno vacío.
- Etiquetas de formulario. Un <label> real conectado a cada campo. El texto de marcador no es una etiqueta: desaparece al escribir y no se anuncia de forma fiable.
- Contraste. Texto corrido a 4,5:1, texto grande y controles a 3:1, comprobado sobre el fondo real.
- Encabezados. Un H1, sin saltarse niveles. Quien usa lector de pantalla navega por encabezados más que por ninguna otra cosa.
- Texto de los enlaces. «Leer más» repetido catorce veces le da a un lector de pantalla catorce destinos idénticos. Diga adónde lleva.
- Mensajes de error. Junto al campo, en texto, describiendo qué hacer; no solo color, no solo un borde rojo.
Pruébelo usted mismo en una tarde#
No necesita software especializado para encontrar casi todos los problemas. Estas cinco pasadas llevan una o dos horas en un sitio mediano y encuentran la mayoría de las barreras reales.
| Prueba | Cómo | Qué detecta |
|---|---|---|
| Solo teclado | Desenchufe el ratón y tabule por cada página | Trampas, foco invisible, controles inalcanzables |
| Zoom al 200 % | Tamaño de texto del navegador, no zoom de página | Texto cortado, desplazamiento horizontal, maquetaciones rotas |
| Lector de pantalla | VoiceOver o NVDA en las plantillas principales | Etiquetas ausentes, enlaces sin sentido, cambios no anunciados |
| Análisis automático | axe o Lighthouse en el navegador | Contraste, alt ausente, mal uso de ARIA: alrededor del 30 % de los problemas |
| Escala de grises | Filtro del navegador o ajuste del sistema | Todo lo que se transmite solo con color |
Las herramientas automáticas encuentran aproximadamente un tercio de los problemas de accesibilidad. Son un punto de partida, no un aprobado: un sitio con 100 en Lighthouse puede seguir siendo inutilizable con teclado.
Los patrones que más problemas causan#
Los componentes a medida son donde la accesibilidad suele romperse, porque los elementos nativos vienen con un comportamiento que los propios tienen que reimplementar.
- Desplegables a medida hechos con divs, sin soporte de teclado ni roles. Un <select> nativo es gratis y funciona en todas partes.
- Ventanas modales que no atrapan el foco, no se cierran con Escape y dejan el fondo desplazable.
- Carruseles que avanzan solos sin control de pausa: son hostiles para casi todo el mundo, no solo para personas con discapacidad.
- Botones solo con icono sin nombre accesible. Una X sin etiqueta se anuncia como «botón».
- Desplazamiento infinito sin forma de llegar al pie de página.
- Sopa de divs: divs clicables en vez de botones y enlaces, lo que elimina soporte de teclado y semántica de una vez.
- Movimiento que ignora prefers-reduced-motion.
La estrategia de accesibilidad más barata es usar el elemento HTML nativo para cada tarea. Cada sustituto a medida es la promesa de reimplementar un comportamiento que venía gratis.
Por qué los widgets de superposición no son una solución#
Las superposiciones de accesibilidad prometen cumplimiento con un único script. No pueden entregarlo, porque los problemas de fondo son estructurales: un script no puede saber qué muestra una imagen, no puede escribir una etiqueta que coincida con el propósito del campo y no puede reparar una trampa de teclado en un componente a medida.
Además interfieren con la tecnología de asistencia que las personas ya usan y han configurado, razón por la que varias organizaciones de personas con discapacidad desaconsejan su uso. Conviene conocerlas sobre todo para poder rechazarlas con un motivo defendible.
- No pueden generar texto alternativo preciso, porque no saben qué significa la imagen en contexto.
- No pueden arreglar trampas de teclado en componentes que no construyeron.
- Con frecuencia entran en conflicto con los ajustes del propio lector de pantalla del usuario.
- No eliminan la exposición legal: las barreras de fondo siguen ahí.
- El dinero se aprovecha mejor en los siete arreglos del principio de esta página.
Preguntas frecuentes
¿La accesibilidad es obligatoria por ley?
En muchas jurisdicciones sí, para organismos públicos y cada vez más para empresas privadas: la Ley Europea de Accesibilidad, la ADA en Estados Unidos aplicada a sitios web y equivalentes en otros lugares. Las obligaciones varían por país y por sector, así que consúltelo localmente. La postura práctica es que WCAG 2.2 AA es el estándar al que apunta casi toda la normativa.
¿Cuánto añade la accesibilidad a un proyecto?
Pensada desde el principio, muy poco: sobre todo disciplina en semántica, contraste y estados de foco. Añadida a un sitio a medida ya terminado puede ser un proyecto considerable, porque los arreglos son estructurales y no cosméticos. Esa diferencia es todo el argumento para plantearla en el encargo y no después del lanzamiento.
¿Cuál es la diferencia entre WCAG A, AA y AAA?
Son niveles de conformidad. A es el mínimo y deja barreras reales en pie; AA es lo que la normativa exige en general y a lo que apuntan casi todas las organizaciones; AAA incluye criterios que no son alcanzables para todo contenido, por ejemplo un requisito de contraste 7:1 que algunas paletas de marca no pueden cumplir. Apunte a AA y trate AAA como una mejora criterio a criterio, no como un objetivo.
¿La accesibilidad ayuda al SEO?
De forma indirecta y real. Una estructura de encabezados correcta, texto de enlace descriptivo, atributos alt, semántica de verdad y páginas rápidas y estables ayudan a ambos. Pero el solape es parcial: un sitio puede posicionar bien y seguir siendo inutilizable con teclado. Haga accesibilidad porque si no hay personas que no pueden usar el sitio, y tome el beneficio de SEO como efecto secundario.
accesibilidad webwcagdiseño web accesiblelector de pantallanavegación por tecladopruebas de accesibilidad
