Los fallos de accesibilidad más frecuentes
Casi todas las webs fallan en las mismas cosas. La buena noticia es que la mayoría son baratas de arreglar y no exigen rehacer nada: son descuidos, no decisiones de arquitectura.
Cada fallo lleva su criterio WCAG entre paréntesis. Son la referencia que usa la norma UNE-EN 301549, y por tanto la que aparecerá en cualquier auditoría formal, sea del RD 1112/2018 o de la Ley 11/2023.
1. Contraste insuficiente (1.4.3)
El clásico. Texto gris claro sobre fondo blanco porque queda elegante en la maqueta. El mínimo es 4,5:1 para texto normal y 3:1 para texto grande, entendiendo por grande a partir de 24 px, o 18,66 px si va en negrita.
Los sitios donde más se escapa: textos de apoyo, marcadores de posición dentro de los campos, estados deshabilitados, y texto encima de imágenes. Ese último es el peor, porque el contraste cambia según la zona de la foto.
Cómo se arregla: oscurecer el color del texto, no aclarar el fondo. Y para texto sobre imagen, una capa de color semitransparente por debajo.
2. Imágenes sin alternativa textual (1.1.1)
Aquí hay dos errores opuestos y ambos son fallo. Uno es no poner alt. El otro es ponerlo en todo, incluidas las imágenes decorativas, que entonces obligan al lector de pantalla a leer ruido.
Cómo se arregla: si la imagen aporta información, descríbela por lo que comunica, no por lo que se ve. Si es puramente decorativa, alt="" vacío, que le dice al lector de pantalla que la salte. Un alt que diga «imagen» o el nombre del archivo es peor que nada.
3. Formularios sin etiqueta asociada (3.3.2)
El campo se ve claro porque tiene un placeholder dentro, pero el marcador de posición desaparece al escribir y muchos lectores de pantalla no lo anuncian como etiqueta. Quien navega con teclado y voz llega a un campo que no sabe qué pide.
Cómo se arregla: un <label> real con for apuntando al id del campo. Si el diseño no admite etiqueta visible, aria-label. El placeholder es una ayuda, nunca la etiqueta.
4. El foco del teclado no se ve (2.4.7)
Alguien puso outline: none para quitar el borde azul del navegador y no puso nada en su lugar. Resultado: puedes tabular por la página pero no sabes dónde estás.
Cómo se arregla: un indicador propio con :focus-visible, que solo se muestra en navegación por teclado y no molesta al clic con ratón. Dos píxeles de contorno en un color con contraste suficiente bastan.
5. Encabezados usados como estilo (1.3.1)
Un <h3> elegido porque tenía el tamaño que quedaba bien, saltos de h2 a h4, o varios <h1> en la misma página. Quien navega con lector de pantalla usa la lista de encabezados como índice, y con la jerarquía rota ese índice no sirve.
Cómo se arregla: un solo h1, sin saltar niveles, y el tamaño se decide con CSS. La etiqueta describe la estructura; el estilo es otra cosa.
6. Funciones que solo existen con ratón (2.1.1)
Menús que se abren al pasar por encima, carruseles que solo avanzan arrastrando, ventanas que se cierran únicamente pinchando fuera. Con teclado, esas funciones no existen.
Cómo se arregla: todo lo accionable tiene que serlo con Tab, Enter y Espacio. Y una ventana modal debe poder cerrarse con Escape y devolver el foco a donde estaba.
7. Enlaces que no dicen a dónde van (2.4.4)
Veinte enlaces que ponen «leer más». Un lector de pantalla puede listar los enlaces de una página fuera de contexto, y entonces son veinte destinos idénticos e indistinguibles.
Cómo se arregla: que el texto del enlace describa el destino. «Ver la auditoría de accesibilidad» en lugar de «leer más». Si el diseño exige el texto corto, aria-label con la versión completa.
8. Vídeo sin subtítulos (1.2.2)
Afecta a mucha más gente de la que se piensa: no solo a personas sordas, también a cualquiera que vea el vídeo sin sonido, que en móvil es la mayoría.
Cómo se arregla: subtítulos sincronizados. La transcripción automática de la plataforma sirve de punto de partida, pero hay que repasarla: en español se come los nombres propios y la puntuación.
9. Idioma no declarado (3.1.1)
Sin lang en el <html>, el lector de pantalla pronuncia el español con fonética inglesa y no hay quien lo entienda.
Cómo se arregla: <html lang="es">. Un atributo. Y marcar con lang los fragmentos que estén en otro idioma.
10. Movimiento que no se puede parar (2.2.2)
Carruseles automáticos, animaciones en bucle, fondos que se mueven. Para personas con trastornos vestibulares o déficit de atención pueden hacer la página inutilizable.
Cómo se arregla: respetar prefers-reduced-motion, que es la preferencia que el usuario ya ha configurado en su sistema, y dar un control de pausa a lo que se mueva más de cinco segundos.
Qué detecta una herramienta y qué no
De esta lista, un análisis automático encuentra con fiabilidad el contraste, los alt que faltan, las etiquetas de formulario, la jerarquía de encabezados y el idioma. Es aproximadamente la mitad.
La otra mitad —si el teclado llega a todo, si el foco tiene un orden lógico, si el alt dice algo útil, si los subtítulos están bien— solo se comprueba a mano. Por eso ninguna herramienta, gratuita o de pago, puede certificar que una web cumple.
Empieza por el analizador gratuito para el barrido inicial, y si quieres la parte que la máquina no ve, aquí está lo que incluye una auditoría completa.
Pásale el analizador gratuito y, si el resultado no te gusta, cuéntame el caso. Te digo qué alcance tiene el problema antes de presupuestar nada.
Ver la auditoría
