Accesibilidad web: cómo auditar y arreglar tu sitio hasta WCAG 2.2 AA
El 95,9 % de las home pages más visitadas de la web falla al menos una prueba automática de accesibilidad y Europa acaba de mover el listón a WCAG 2.2 AA. La solución no es una herramienta: es una auditoría de accesibilidad web en tres capas.
Por qué septiembre de 2026 movió el listón
La accesibilidad dejó de ser una recomendación de buena voluntad para convertirse en una obligación técnica con fechas. En pocas semanas se juntaron un cambio normativo europeo, una prórroga estadounidense y un informe de industria que confirma lo peor: la web no mejora, empeora.
EN 301 549 v4.1.1: Europa cambia WCAG 2.1 por WCAG 2.2 AA (y qué falta para que sea referencia legal)
El 2 de septiembre de 2026 se publicó la versión 4.1.1 de la norma europea EN 301 549, que adopta WCAG 2.2 como referencia técnica para sitios web, software y documentos digitales en lugar de WCAG 2.1. Es el estándar que se usa para demostrar conformidad con la European Accessibility Act, aplicable desde el 28 de junio de 2025.
El matiz importa: una norma técnica armonizada no es ley por sí sola. Su efecto legal pleno llega cuando se cita en el Diario Oficial de la Unión Europea, así que hoy la referencia legal sigue siendo la versión anterior mientras se completa la transición. Para un equipo que planifica a un año, la dirección ya está fijada: auditar contra WCAG 2.2 AA, no contra 2.1.
Lee también
El otro reloj: ADA Title II y las fechas de 2027 y 2028
En Estados Unidos, la regla del Departamento de Justicia de 2024 exige WCAG 2.1 AA a las entidades estatales y locales. En abril de 2026 el DOJ publicó una regla final interina que corrió los plazos un año: las entidades con población igual o superior a 50.000 habitantes tienen hasta el 26 de abril de 2027, y las más pequeñas y los distritos especiales hasta el 26 de abril de 2028. Una prórroga no cambia qué hay que hacer, solo cuándo.
El dato incómodo: WebAIM Million 2026 dice que estamos peor que el año pasado
El análisis anual de WebAIM sobre un millón de home pages encontró fallos detectables en el 95,9 % de ellas, frente al 94,8 % de 2025. La media subió a 56,1 errores por página, un 10,1 % más que los 51 del año anterior, con más de 56 millones de errores distintos. El texto con contraste insuficiente apareció en el 83,9 % de las páginas. Son fallos detectados automáticamente en home pages, no un veredicto de que esos sitios sean inutilizables, pero la tendencia no admite interpretación optimista.
Qué exige WCAG 2.2 AA, en la práctica
Las guías del W3C se organizan en cuatro principios: contenido perceptible, operable, comprensible y robusto. Cada criterio de éxito tiene un nivel: A, AA o AAA. Las normas legales que citamos arriba piden AA, porque equilibra el impacto real sobre las personas usuarias con un esfuerzo razonable de implementación. Apuntar a AAA en todo no es el objetivo; cubrir AA de forma consistente sí.
Los 9 criterios nuevos de WCAG 2.2 (y el que se eliminó)
WCAG 2.2, recomendación del W3C desde octubre de 2023, añade nueve criterios respecto a 2.1 y retira uno. Los nuevos, con su nivel:
- 2.4.11 Focus Not Obscured (Minimum) — AA.
- 2.4.12 Focus Not Obscured (Enhanced) — AAA.
- 2.4.13 Focus Appearance — AAA.
- 2.5.7 Dragging Movements — AA.
- 2.5.8 Target Size (Minimum) — AA.
- 3.2.6 Consistent Help — A.
- 3.3.7 Redundant Entry — A.
- 3.3.8 Accessible Authentication (Minimum) — AA.
- 3.3.9 Accessible Authentication (Enhanced) — AAA.
El criterio eliminado es 4.1.1 Parsing: los navegadores modernos ya no dependen de un marcado perfectamente anidado, así que la exigencia se retiró en lugar de mejorarse.
Los 6 fallos que aparecen en casi todas las auditorías
Si resuelves solo esto, cubres la mayor parte de lo que reporta un informe:
- Imágenes sin texto alternativo o con un
altinútil. - Contraste de texto por debajo de 4,5:1.
- Campos de formulario sin etiqueta asociada.
- Encabezados desordenados o usados por tamaño, no por jerarquía.
- Botones y enlaces sin nombre accesible.
- Foco del teclado invisible o eliminado con CSS.
Capa 1: la auditoría automática
La primera capa lee el DOM y comprueba reglas objetivas. Es rápida, barata y repetible, y por eso es la única que tiene sentido dejar corriendo sola de forma continua. También es la más engañosa si se usa como única verdad: cubre una parte de los criterios, no todos.
Qué detecta axe-core y qué deja pasar
axe-core, el motor de reglas de código abierto de Deque, es la base de muchas extensiones y herramientas. Encuentra bien lo mecánico: un alt ausente, un contraste calculable entre dos colores sólidos, un label que no está asociado a ningún campo, atributos ARIA prohibidos para un rol. Se le escapan las cosas que dependen de la intención: que el orden de tabulación tenga sentido, que un mensaje de error sea comprensible o que un componente anunciado como menú se comporte como menú.
Lighthouse y Chrome DevTools: cómo leer el informe sin confiarse
Lighthouse trae una sección de accesibilidad dentro de Chrome DevTools. Su puntuación pondera reglas automáticas y no mide cobertura total, así que un 100 en el informe significa "no se detectaron problemas automáticos", no "es accesible". Úsalo como primer filtro y como evidencia de partida, nunca como certificado.
Dejarlo en CI con pa11y: umbral, rutas y fallar el build
La forma de evitar que los errores vuelvan es convertir la capa automática en una prueba que rompa la integración continua. Herramientas como pa11y permiten apuntar a las rutas principales y marcar un umbral de fallos: si el número de problemas sube, el pipeline se detiene. La sintaxis exacta cambia entre versiones, así que conviene fijarla en la documentación oficial del proyecto y no copiarla de un blog. Empieza por las rutas críticas —portada, listado, ficha y formulario de contacto— y amplía después.
Capa 2: pruebas manuales, sin lector de pantalla
La segunda capa la hace una persona, con un teclado y con el navegador. Es donde aparecen los fallos que rompen la experiencia real y que ninguna máquina puede juzgar.
Recorrido completo solo con teclado: foco visible, orden y trampas
Navega toda la página sin tocar el ratón, usando Tab, Shift+Tab, Enter y espacio. Comprueba tres cosas: que el foco se ve siempre (nunca lo elimines con outline: none), que el orden de tabulación sigue el orden visual y lógico, y que puedes salir de cada componente. Un menú desplegable que atrapa el foco y no se cierra con teclado es un fallo grave. El patrón correcto para saltarse la navegación es un enlace "saltar al contenido" que se hace visible al recibir el foco.
Zoom al 200 %, reflujo a 320 px y texto espaciado
Agranda la página al 200 %: el contenido debe seguir funcionando sin perder información ni obligarte a hacer scroll horizontal. Reduce la ventana a 320 píxeles de ancho: el diseño debe refluir a una sola columna sin cortarse. Aumenta el espaciado de línea, párrafo y letra con una extensión de usuario: el texto no debe solaparse ni desaparecer.
Contraste y tamaño de objetivo: medir, no estimar
El nivel AA pide 4,5:1 de contraste en texto normal, 3:1 en texto grande (criterio 1.4.3) y 3:1 para componentes de interfaz y elementos gráficos (1.4.11). Usa un verificador de contraste con los valores exactos, no el ojo. En WCAG 2.2, el criterio 2.5.8 Target Size (Minimum) pide objetivos de al menos 24 por 24 píxeles CSS, con excepciones por espaciado, equivalencia en línea, esencialidad o control del agente de usuario. Botones diminutos pegados entre sí fallan aquí.
Capa 3: lector de pantalla y semántica
La tercera capa es la que cierra la semántica: alguien navega el sitio con un lector de pantalla y escucha lo que se anuncia. Es la dimensión que las otras dos no ven, porque depende de la estructura interpretada.
Qué anuncian NVDA y VoiceOver y qué se pierden
NVDA es gratuito en Windows; VoiceOver viene con macOS e iOS; JAWS es la opción comercial. Al recorrer con ellos aparecen fallos que las herramientas automáticas no señalan: encabezados mal anidados que rompen el índice del rotor, un botón que solo dice "clic", una tabla que se lee como una lista de números. Prueba el salto por encabezados con el rotor o la lista de encabezados para verificar que el orden tiene sentido.
HTML semántico antes que ARIA: los arreglos que resuelven más fallos
La regla que ahorra más trabajo es sencilla: usa el elemento correcto antes de recurrir a ARIA. Un <button> ya es un botón, se enfoca y se activa con teclado. Un <div> con onclick no es nada de eso, y añadir role="button" sin manejar el teclado no lo arregla. Lo mismo con <nav>, <main> y <label>. ARIA es para lo que el HTML no expresa, no un parche para marcado pobre.
Formularios, mensajes de error y contenido dinámico
Asocia cada campo a su etiqueta con for e id. Muestra los errores con texto, no solo con color de borde: "el correo no tiene un formato válido" es útil, un borde rojo no. Cuando un bloque de contenido cambia sin recargar la página, envuélvelo en un contenedor con aria-live="polite" para que el lector lo anuncie. Y no marques campos obligatorios solo con un asterisco visual: indícalo también con texto o con el atributo correspondiente.
Lo que no arregla una superposición de accesibilidad
Los widgets y superposiciones automáticas prometen conformidad con una línea de código. No la entregan. La conformidad se demuestra con evidencia técnica —código accesible, pruebas documentadas, declaración— no con un script instalado encima. Una superposición puede tapar algunos síntomas visibles mientras deja intacta la causa: el marcado de base sigue siendo el mismo. Si un proveedor te vende "accesibilidad garantizada con un widget", ese es el momento de pedir las pruebas, no el sello.
La declaración de accesibilidad: el documento que te van a pedir
El marco europeo exige publicar una declaración de accesibilidad, y las auditorías la piden como evidencia. Es un documento breve: el nivel de conformidad alcanzado, los problemas conocidos y las partes que no son accesibles, el canal de contacto para reportar barreras y la fecha de la última revisión. Escribirla en serio obliga a tener el resultado de las tres capas, así que conviene tratarla como la salida del proceso, no como el adorno final.
Conclusión
Una auditoría de accesibilidad web no es una lista de 87 criterios: es un proceso de tres capas donde cada una ve lo que las otras no. La máquina lee el código y detecta lo mecánico; el teclado y el zoom comprueban el comportamiento; el lector de pantalla juzga la estructura anunciada. Arreglar los patrones de base —semántica, foco, contraste, formularios— rinde más que perseguir criterios sueltos, y dejar la capa automática en integración continua evita que los mismos errores vuelvan con cada cambio.
Si te sirvió el enfoque, en el blog hay más guías de HTML y CSS de base: puedes seguir con el SEO técnico en Laravel 13, con las transiciones de página con la View Transitions API y con las animaciones ligadas al scroll en CSS puro, que aplican la misma idea: entender el mecanismo antes de escribir el código.
