Cómo hacer tu web conforme a WCAG 2.2

Hacer que tu sitio web sea conforme a WCAG 2.2 es un proceso, no una corrección puntual. La conformidad es el resultado de un flujo de trabajo repetible: comprender el estándar, medir dónde estás, corregir las cosas correctas en el orden correcto, validar con tecnología de asistencia real y usuarios reales, documentar el resultado y evitar que retroceda. Esta guía convierte ese flujo de trabajo en una hoja de ruta concreta y paso a paso que tu equipo puede empezar a usar hoy — sin recurrir a los «overlays» de accesibilidad, que enmascaran los problemas en el DOM en lugar de corregirlos y han sido nombrados repetidamente en demandas judiciales.

Paso 1: Entender qué exige realmente WCAG 2.2

Antes de auditar nada, ten claro el objetivo. Las Pautas de Accesibilidad para el Contenido Web se organizan en torno a cuatro principios, resumidos en el acrónimo POUR:

Perceptible (Perceivable) — los usuarios deben poder percibir el contenido. Piensa en alternativas textuales para las imágenes, subtítulos y transcripciones para los medios, y contraste de color suficiente.
Operable — toda función debe funcionar sin ratón. La operabilidad completa con teclado, los indicadores de foco visibles y la ausencia de trampas de teclado son requisitos fundamentales.
Comprensible (Understandable) — el contenido y el comportamiento deben ser predecibles. Aquí entran las etiquetas claras, la navegación coherente, los mensajes de error útiles y un lenguaje legible.
Robusto (Robust) — el marcado debe poder ser interpretado por la tecnología de asistencia actual y futura, lo que en la práctica significa HTML válido y un uso correcto de los nombres, roles y valores de ARIA.

Cada principio se desglosa en criterios de éxito comprobables, y a cada criterio se le asigna un nivel de conformidad: A (esencial), AA (la base legal y práctica que la mayoría de las organizaciones persiguen) y AAA (mejorado). Cuando se dice «WCAG 2.2 AA», se refiere a cumplir todos los criterios de éxito de nivel A y nivel AA. WCAG 2.2 añade nueve nuevos criterios respecto a 2.1 — incluidos Foco no oscurecido, Movimientos de arrastre, Tamaño del objetivo (mínimo) y Autenticación accesible — la mayoría de los cuales mejoran la experiencia para usuarios de teclado, con baja visión y con discapacidad motora.

Ayuda saber por qué este es el objetivo. La conformidad AA es la referenciada por las leyes y normativas que muy probablemente te apliquen: infórmate sobre la conformidad con WCAG como estándar técnico, y luego observa cómo se relaciona con la Ley Europea de Accesibilidad, la ADA para entidades públicas y privadas de EE. UU., y la Section 508 para agencias federales estadounidenses y sus proveedores. Si la terminología te confunde por el camino, mantén nuestro glosario de accesibilidad abierto en una pestaña.

Dos conceptos más dan forma a cualquier declaración de conformidad honesta. El primero es el alcance de la conformidad: la conformidad WCAG se aplica a páginas completas, no a componentes aislados, y a procesos completos (p. ej., todo un flujo de compra) — no puedes afirmar que una página es conforme si falla un paso de una tarea de varios pasos. El segundo es la tecnología compatible con la accesibilidad: solo puedes apoyarte en formas de usar una función que estén realmente soportadas por la tecnología de asistencia que usan tus usuarios. En la práctica, esto significa probar con lectores de pantalla y navegadores actuales en lugar de asumir que el marcado válido por sí solo garantiza un resultado utilizable. Ten ambos en mente al delimitar tu trabajo en los pasos siguientes; determinan lo que puedes afirmar con argumentos que has logrado.

Paso 2: Ejecutar un escaneo automatizado de referencia

No puedes corregir lo que no puedes medir, así que establece una línea base. Las pruebas automatizadas son rápidas, repetibles y excelentes para detectar los fallos mecánicos y de gran volumen que afectan a la mayoría de los sitios: textos alternativos ausentes, contraste de color bajo, enlaces y botones vacíos, campos de formulario sin etiquetar, idioma del documento ausente e IDs duplicados.

Las herramientas basadas en el motor de código abierto axe-core — incluido el software de escaneo de accesibilidad de QualiBooth — producen una lista priorizada de problemas en minutos. Si solo quieres una lectura rápida de tu situación, empieza con un escaneo de accesibilidad gratuito de unas pocas páginas clave.

Algunas reglas para mantener tu línea base honesta:

Escanea plantillas representativas, no todo tu sitio. Prueba tu página de inicio, una plantilla de contenido/artículo, una página de producto o categoría, un formulario (registro, compra, contacto) y cualquier panel autenticado. Corregir una plantilla suele corregir cientos de páginas.
Prueba estados reales, no solo la carga inicial. Abre menús, despliega acordeones, activa modales y envía formularios con errores. Muchas infracciones solo aparecen en estados interactivos.
Registra las cifras. Captura el número de problemas por gravedad y por criterio de éxito. Este es tu referente antes/después y la base de tu backlog de remediación.

Sé honesto sobre el límite: las herramientas automatizadas detectan de forma fiable solo el 30–40 % de los problemas WCAG. Un escaneo automatizado limpio es necesario, pero nunca suficiente para una declaración de conformidad real.

Paso 3: Complementar la automatización con una auditoría manual

El 60–70 % restante de los criterios WCAG requiere juicio humano. ¿Este texto alternativo transmite realmente el significado de la imagen, o solo describe píxeles? ¿Es lógico el orden de lectura y de foco? ¿Los mensajes de error le dicen al usuario cómo recuperarse? ¿Se anuncia correctamente un desplegable personalizado, y puedes alcanzarlo y operarlo solo con el teclado? Ningún motor puede responder esto de forma fiable.

Una auditoría manual estructurada suele cubrir:

Operación solo con teclado — recorre con el tabulador cada elemento interactivo; confirma un indicador de foco visible, un orden lógico, la ausencia de trampas, y que todo lo que puedes hacer con el ratón lo puedes hacer sin él.
Estructura semántica — encabezados en una jerarquía con sentido, landmarks, listas marcadas como listas, tablas con encabezados adecuados.
Formularios — etiquetas programáticas, campos agrupados, indicación clara de los campos obligatorios y mensajes de error vinculados a las entradas que describen.
Contenido dinámico — modales que atrapan y restauran el foco correctamente, regiones activas que anuncian las actualizaciones y ARIA usado solo donde el HTML nativo no puede hacer el trabajo.
Calidad del contenido — texto de enlace significativo, contraste suficiente en contextos reales y contenido que no dependa solo del color o la forma.

Nuestra guía de auditorías manuales de accesibilidad recorre la metodología completa, y los problemas comunes de accesibilidad que evitar son una lista de comprobación rápida de los fallos que los auditores encuentran con más frecuencia. Si prefieres que lo hagan por ti, el equipo de consultoría de accesibilidad de QualiBooth realiza auditorías manuales expertas frente a los criterios de WCAG 2.2 AA.

Paso 4: Priorizar y remediar

Una lista larga de infracciones resulta abrumadora hasta que la ordenas. Triája combinando el impacto en el usuario y el alcance:

Primero los bloqueantes. Cualquier cosa que haga imposible una tarea para un grupo de usuarios — trampas de teclado, una compra inaccesible, un formulario de inicio de sesión sin etiquetar — va a lo más alto, independientemente de cuántas instancias existan.
Después los problemas de alta frecuencia, en todo el sitio. Un problema de contraste o de foco en tu cabecera, pie de página o componente del sistema de diseño se multiplica en cada página. Corregirlo una vez ofrece el mayor retorno.
Después los problemas específicos de página y de contenido. Un texto alternativo ausente concreto, un único control mal etiquetado o un salto de encabezado puntual.

Cuando remedies, corrige la fuente, no el síntoma. Prefiere los elementos HTML nativos a los <div> parcheados con ARIA; corrige el componente del sistema de diseño en lugar de cada página que lo usa; y aborda las causas raíz en las plantillas y los componentes compartidos para que la corrección escale. Vuelve a escanear tras cada lote para que puedas ver caer las cifras y evitar introducir regresiones. Este es también el momento adecuado para integrar la accesibilidad en tus design tokens — establece colores con contraste seguro, un tamaño de objetivo mínimo de 24×24 px y estilos de foco visibles como valores por defecto, de modo que el trabajo nuevo nazca conforme.

Algunos patrones de remediación se repiten lo suficiente como para mencionarlos explícitamente:

Usa la plataforma. Un <button>, <a href>, <input>, <select> y <dialog> nativos traen consigo, de forma gratuita, comportamiento de teclado, gestión del foco y un nombre accesible correcto. Recurre a ARIA solo para cubrir lagunas reales — y recuerda la primera regla de ARIA: no uses ARIA si un elemento nativo sirve.
Nombra las cosas programáticamente. Cada control necesita un nombre accesible desde un <label>, aria-label o aria-labelledby — no solo el texto visual cercano. Los botones que solo tienen icono son el infractor más común.
Gestiona el foco deliberadamente. Cuando se abre un modal, mueve el foco hacia dentro, atrápalo mientras esté abierto y devuélvelo al disparador al cerrarse. Cuando el contenido se actualiza sin una navegación, usa una región activa para que los usuarios de lector de pantalla escuchen qué cambió.
No codifiques el significado solo en el color o la forma. Combina el color con texto, iconos o patrones para que la información sobreviva para usuarios daltónicos y con baja visión.

Haz seguimiento de la remediación en tu gestor de incidencias habitual, etiquetado por criterio de éxito, para que el trabajo de accesibilidad sea visible junto a todo lo demás en lugar de vivir en una hoja de cálculo aparte que se queda obsoleta.

Paso 5: Probar con tecnología de asistencia y personas con discapacidad

La conformidad consiste, en última instancia, en si las personas reales pueden usar tu sitio. Aquí importan dos capas de validación, y no son intercambiables.

Pruebas con lector de pantalla. Verifica tus correcciones frente a la tecnología de asistencia que la gente usa realmente: NVDA o JAWS con Chrome/Firefox en Windows, y VoiceOver con Safari en macOS e iOS. Escucha que los nombres sean precisos, los roles correctos, los cambios de estado anunciados y un orden de lectura sensato. Una evaluación con lector de pantalla te ofrece un repaso profesional de las principales combinaciones si a tu equipo le falta experiencia.

Pruebas de usabilidad con usuarios con discapacidad. Cumplir todos los criterios de éxito es el suelo, no el techo — un sitio puede ser técnicamente conforme y aun así resultar frustrante de usar. La señal más fiable proviene de las auditorías realizadas por personas con discapacidad, que prueban con su propia tecnología de asistencia y sus hábitos y sacan a la luz barreras que las listas de comprobación pasan por alto. Esta es la diferencia entre cumplir la letra del estándar y ofrecer una verdadera accesibilidad digital.

Paso 6: Documentar la conformidad (declaración y VPAT/ACR)

Una vez que has remediado y validado, captura el resultado. La documentación es lo que convierte un «lo intentamos» en una declaración defendible y comunicable.

Declaración de accesibilidad. Una página pública que indica tu objetivo de conformidad (p. ej., WCAG 2.2 AA), describe lo que has hecho, enumera cualquier limitación conocida y ofrece a los usuarios una vía para informar de problemas. Muchas normativas, incluida la EAA, esperan una.
VPAT / Accessibility Conformance Report. Una Voluntary Product Accessibility Template, cumplimentada, se convierte en un ACR — el artefacto estándar que los equipos de compras y los compradores corporativos solicitan como evidencia. Nuestra guía sobre qué es un VPAT/ACR explica el documento, y el servicio de informes VPAT produce un informe preciso y respaldado por auditoría que puedes entregar a clientes y equipos legales.

Redacta estos documentos a partir de la evidencia de tus resultados de auditoría reales, no de aspiraciones. Un VPAT que exagera la conformidad es un pasivo, no un activo.

Paso 7: Mantener la conformidad a lo largo del tiempo

La accesibilidad retrocede en el momento en que un sitio cambia — un nuevo componente, un formulario rediseñado, un widget de terceros o una edición de contenido pueden reintroducir barreras de forma silenciosa. La conformidad es un estado que mantienes, no un hito que superas una vez.

Integra la accesibilidad en tu ciclo de vida del software:

Shift left. Añade comprobaciones automatizadas a tu pipeline con la integración de accesibilidad en CI/CD para que las infracciones se detecten en las pull requests, antes de publicarse — el lugar más barato posible para corregirlas.
Monitoriza producción. Programa auditorías de accesibilidad recurrentes para detectar regresiones y la deriva de contenido que las comprobaciones previas al lanzamiento no verán.
Capacita a tu equipo. Dota a diseñadores, desarrolladores y autores de contenido de un kit de herramientas de accesibilidad y estándares compartidos para que la accesibilidad sea el valor por defecto de todos, no algo secundario de un especialista.
Gobierna a escala. Para organizaciones grandes o multisitio, una plataforma como Agora centraliza el seguimiento, la elaboración de informes y la remediación entre equipos.

Errores que descarrilan los esfuerzos de conformidad

Los equipos que se estancan suelen hacerlo por razones predecibles. Vigila estas:

Confiar solo en la automatización. Un informe automatizado en verde cubre solo un tercio de los criterios. Tratarlo como prueba de conformidad es el error más común — y el más arriesgado legalmente.
Comprar un overlay. Los overlays y los «widgets de accesibilidad» prometen conformidad instantánea inyectando JavaScript que sobrescribe la página. No corrigen el código subyacente, con frecuencia interfieren con la propia tecnología de asistencia de los usuarios y han sido nombrados en un número creciente de reclamaciones. Son un atajo al riesgo, no a la conformidad.
Corregir páginas en lugar de sistemas. Remediar páginas individuales mientras se deja roto el sistema de diseño significa que cada página nueva reintroduce los mismos defectos. Corrige primero los componentes compartidos y las plantillas.
Tratarlo como un proyecto puntual. Sin comprobaciones de CI/CD y auditorías recurrentes, un sitio conforme se desvía de la conformidad en unos pocos ciclos de lanzamiento.
Saltarse a los usuarios reales. La conformidad técnica sin pruebas de usabilidad puede dejar igualmente a los usuarios con discapacidad sin poder completar tareas esenciales.

Evitar estos errores impide que tu inversión se diluya en el momento en que el proyecto «se publica».

Poniéndolo todo junto

Un camino realista hacia WCAG 2.2 AA se ve así: aprende los principios POUR y el objetivo AA, ejecuta un escaneo automatizado de referencia, añade encima una auditoría manual, remedia por impacto y alcance, valida con lectores de pantalla y usuarios con discapacidad, documenta tu conformidad en una declaración y un VPAT, y luego mantenlo sano con comprobaciones de CI/CD y auditorías recurrentes. Cada paso refuerza al anterior — y nada de ello depende de un overlay que tape el código real.

Empieza poco a poco y gana impulso: escanea un puñado de plantillas esta semana, corrige los estilos de contraste y de foco de tu sistema de diseño y pon una comprobación automatizada en tu pipeline. A partir de ahí, la hoja de ruta anterior te lleva el resto del camino. Cuando estés listo para acelerar, explora nuestros precios, solicita una demo o habla con un experto sobre un plan de remediación adaptado a tu stack.