¿Cómo hacer accesible tu sitio web? La checklist WCAG 2.2 para 2026

¿A qué estándar apuntas?

A WCAG 2.2 en nivel AA — y ser preciso con ese objetivo ahorra mucho esfuerzo desperdiciado. WCAG 2.2 se volvió el estándar definitivo de accesibilidad web el 5 de octubre de 2023, y en 2026 es la base que las leyes de accesibilidad del mundo de verdad referencian: la European Accessibility Act y su estándar técnico EN 301 549, la guía del Departamento de Justicia de EE. UU. para la ADA, y la Section 508 actualizada apuntan todas a WCAG 2.2 nivel AA (Web Accessibility Checker, 2026). Si aún auditas contra la antigua WCAG 2.1, trabajas con una checklist desactualizada.

Vale la pena conocer la estructura porque organiza todo lo que sigue. WCAG 2.2 contiene 87 criterios de éxito agrupados bajo los cuatro principios POUR, en tres niveles de conformidad — A, AA y AAA (Web Accessibility Checker, 2026). La gran mayoría de las organizaciones debe apuntar al nivel AA, que es el tramo aceptado globalmente y legalmente relevante; el nivel AAA no es obligatorio por ley ni aplica a todo tipo de contenido (Level Access, 2026). Y no hay prisa por esperar lo que viene: WCAG 3.0 sigue en borrador inicial y no se espera que sea estándar por años, así que WCAG 2.2 seguirá siendo el objetivo práctico hasta al menos 2028 a 2030 (Web Accessibility Checker, 2026).

Perceptible: ¿puede todo el mundo recibir el contenido?

El primer principio pregunta si la información está disponible para cada sentido, y no únicamente para la vista. Dale a cada imagen con significado un texto alternativo apropiado, y marca las imágenes decorativas como decorativas con un alt="" vacío para que el lector de pantalla las salte en vez de leer un nombre de archivo (WebAIM, 2026). Provee subtítulos para el video y una transcripción descriptiva para el audio, de modo que el contenido esté disponible para quien no puede oírlo (WebAIM, 2026).

Luego maneja la capa visual. El texto necesita contraste de color suficiente contra su fondo —una proporción de al menos 4,5:1 para texto normal en nivel AA— y nunca debes usar el color por sí solo para transmitir significado, porque un usuario con daltonismo lo perderá (Webability, 2026). El texto debe poder ampliarse y reajustarse sin romper el diseño, para que quien hace zoom al 200% aún pueda leer y usar la página. Nada de esto es exótico; es la base que vuelve perceptible una página para la audiencia más amplia.

Operable: ¿puede todo el mundo usarlo sin ratón?

El segundo principio es sobre la interacción, y la prueba más reveladora es el teclado. Cada función debe poder operarse solo con el teclado, sin trampas de teclado donde el foco se atasca, porque muchas personas navegan por completo con teclado o con tecnología asistiva que lo emula (WebAIM, 2026). Acompaña eso con un indicador de foco visible para que un usuario de teclado siempre vea dónde está, un orden de foco lógico que siga el flujo visual, y un enlace de “saltar al contenido” para que no lo obligues a pasar por todo el menú en cada página (WebAIM, 2026).

El resto de la operabilidad es sobre claridad y seguridad. El texto de los enlaces debe tener sentido por sí solo —“lee la guía de accesibilidad”, no “haz clic aquí”— y cada página necesita un título descriptivo e informativo (WebAIM, 2026). Dale a los usuarios tiempo suficiente para completar tareas en vez de expirarlas de golpe, y evita contenido que destelle más de tres veces por segundo, que puede provocar convulsiones. La operabilidad es donde un sitio bonito falla más en silencio, porque todo funciona con el ratón y nadie revisó el teclado.

Comprensible: ¿es predecible y claro?

El tercer principio cubre la comprensión y la previsibilidad. Define el idioma de la página en el marcado para que el lector de pantalla use la pronunciación correcta, mantén la navegación consistente de página en página, y haz que la interfaz se comporte de forma predecible — los componentes que se ven iguales deben actuar igual (WebAIM, 2026). La previsibilidad importa en silencio para las personas con discapacidades cognitivas, que se ven desproporcionadamente afectadas cuando un diseño cambia o un control se comporta de forma inesperada.

Los formularios son donde este principio más trabaja. Cada campo necesita una etiqueta clara y asociada de forma programática y las instrucciones que requiera; cuando un usuario comete un error, identifícalo con claridad y sugiere cómo arreglarlo en vez de solo rechazar el envío (WebAIM, 2026). Para cualquier cosa de peso —envíos legales, financieros o de datos— haz que la acción sea reversible, verificada o confirmada, de modo que un error se pueda recuperar. El buen diseño de formularios es, en la práctica, la mayor parte de la accesibilidad comprensible.

Robusto: ¿la tecnología asistiva podrá interpretarlo?

El cuarto principio es sobre si las máquinas pueden interpretar tu página, que es donde la accesibilidad y la legibilidad para la IA se solapan. El cimiento es el HTML semántico: usa elementos reales para su propósito real —un <button> para un botón, un encabezado para un encabezado, una lista para una lista— para que la tecnología asistiva entienda la estructura sin adivinar (WebAIM, 2026). Es la misma disciplina semántica que vuelve una página legible para los buscadores y los asistentes de IA, por lo que este principio aparece tanto en nuestro trabajo de accesibilidad como en el de legibilidad para la IA.

Donde el HTML nativo no basta, usa ARIA correctamente para dar un nombre, un rol y un valor a los componentes a medida — y solo donde el HTML no pueda hacer el trabajo, porque un ARIA incorrecto es peor que ninguno (WebAIM, 2026). Un requisito específico que se pasa por alto seguido: cuando aparece un mensaje de estado importante sin mover el foco —“mensaje enviado”, “artículo agregado al carrito”— debe anunciarse a los usuarios de lector de pantalla mediante una región activa de ARIA, para que reciban la misma retroalimentación que todos (GetWCAG, 2026).

¿Qué hay de nuevo en WCAG 2.2 — los criterios a añadir?

WCAG 2.2 añadió nueve criterios de éxito y quitó uno obsoleto, dirigidos a tres grupos que la versión anterior atendía mal: personas con baja visión, con discapacidades cognitivas y de aprendizaje, y usuarios móviles con limitaciones motrices (Web Accessibility Checker, 2026). Los que más importan en nivel AA son concretos y dirigidos por el diseño. Foco no oscurecido exige que un elemento enfocado no quede oculto tras un encabezado fijo o un aviso de cookies. Movimientos de arrastre exige que cualquier cosa que se pueda arrastrar —un control deslizante, una lista de arrastrar y soltar— también funcione con una acción de un solo puntero, como un clic en un punto de inicio y otro de fin (Accessible.org, 2026).

Los demás añadidos son igual de prácticos. Tamaño del objetivo (mínimo) exige que los objetivos interactivos midan al menos 24 por 24 píxeles CSS, para que las personas con limitaciones motrices no toquen el control equivocado (GetWCAG, 2026). Autenticación accesible significa que un inicio de sesión no puede depender de una prueba de función cognitiva como recordar una contraseña o resolver un rompecabezas, salvo que haya una alternativa — un enlace por correo o un gestor de contraseñas que pueda pegar la cumple (Accessible.org, 2026). Dos añadidos de nivel A lo redondean: Ayuda consistente, mantener el soporte en el mismo lugar en todas las páginas, y Entrada redundante, no hacer que los usuarios reingresen información que ya dieron en el mismo proceso. Casi todos se resuelven mejor durante el diseño que parcheándose en las pruebas (Level Access, 2026).

¿Cómo lo pruebas — y por qué no bastan los escaneos automáticos?

Pruebas en dos capas, y el orden importa. Empieza con herramientas automáticas como axe DevTools, WAVE y Lighthouse, que afloran rápido los problemas detectables por máquina, como atributos alt ausentes y contraste bajo (Accessibility Innovations, 2026). Pero son un punto de partida, no un veredicto: los escáneres automáticos captan apenas una parte de los criterios WCAG —según la mayoría de las estimaciones, cerca de un tercio— porque el resto exige juicio humano (Webability, 2026).

La segunda capa es donde la accesibilidad de verdad se confirma. Navega el sitio solo con teclado, después con un lector de pantalla, después en un dispositivo móvil real con toque, para probar lo que una máquina no puede juzgar — el orden lógico del foco, si el texto alternativo tiene sentido, si un widget a medida de verdad funciona (Accessibility Innovations, 2026). Los errores más comunes son depender solo de escaneos automáticos, revisar la página de inicio pero no las plantillas, los formularios y los componentes dinámicos, y olvidar el contenido heredado como los PDF viejos (Webability, 2026). Algo que la prueba manual no es, es un widget de overlay — para entender por qué la herramienta de accesibilidad de un clic falla y crea riesgo legal, mira nuestra guía sobre si los overlays de accesibilidad son una trampa legal.

¿Cómo lo pruebas? Declaración de Accesibilidad y VPAT

Documentas la conformidad, porque no hay nada que certificar. No existe un organismo oficial de certificación WCAG —el W3C no emite certificados de conformidad— así que la prueba toma la forma de documentación que tú produces (Web Accessibility Checker, 2026). La base es una Declaración de Accesibilidad autodeclarada que registra tu nivel de conformidad, los problemas conocidos, y una forma de que los usuarios reporten barreras — que además es un requisito legal en algunas jurisdicciones, incluido el marco español.

Para contextos más formales, dos documentos tienen peso. Un VPAT (Voluntary Product Accessibility Template) lista tu estado de conformidad criterio por criterio, y suele exigirse en compras B2B y de gobierno; un informe firmado por un auditor profesional es la evidencia más fuerte, y muchos procesos de compra lo aceptan (Web Accessibility Checker, 2026). Vale la pena dejar claro que la conformidad WCAG no es lo mismo que el cumplimiento legal — pero en el panorama legal actual es la mejor práctica recomendada para reducir el riesgo de una demanda de accesibilidad (Level Access, 2026).

Constrúyelo dentro, no lo pegues encima

El hilo que recorre cada principio es que la accesibilidad es más barata y mejor cuando va integrada, no añadida después. Casi todos los criterios nuevos de WCAG 2.2 se resuelven mejor durante el diseño que remendándose en las pruebas, y la accesibilidad bien hecha es una práctica continua —revisada en cada plantilla y cada lanzamiento— en vez de un ejercicio de una sola vez (Level Access, 2026). Un sitio que la trata como una checklist de lanzamiento se sale de conformidad con la siguiente función.

Si la lista completa se siente larga, empieza donde el impacto es más alto y el esfuerzo más bajo: añade texto alternativo real y etiquetas de formulario bien asociadas, arregla el contraste de color, haz todo el sitio operable por teclado con un indicador de foco visible, y define el idioma de la página en el marcado. Esos pocos arreglos resuelven una gran parte de los fallos más comunes, y son los que un usuario de lector de pantalla o de teclado nota primero — así que compran la mayor accesibilidad real por hora invertida antes de que recorras el resto de los criterios.

Hay un beneficio que vale la pena nombrar: este trabajo se paga solo más allá del cumplimiento. La misma estructura semántica, el texto alternativo claro y las páginas más rápidas y limpias que hacen accesible un sitio también mejoran su SEO y su usabilidad para todos (Webability, 2026). Ese solape es todo el argumento para construir la accesibilidad en el código desde el inicio — el caso que hace nuestro pilar sobre si la accesibilidad web es obligatoria desde el lado regulatorio. La checklist de arriba es cómo actúas sobre él.