Las WCAG 2.2 explicadas con claridad

Las WCAG son la referencia mundial para las webs accesibles y la base de lo que el EAA —y transposiciones como el BFSG alemán o la Ley 11/2023 española— te exige. Aquí descubrirás cómo está estructurado el estándar y qué novedades trae la versión 2.2.

¿Qué son las WCAG y quién las publica?

Las Web Content Accessibility Guidelines (WCAG) son el estándar internacionalmente reconocido para los contenidos web accesibles. Las publica el World Wide Web Consortium (W3C), más concretamente su Web Accessibility Initiative (WAI), la organización que también estandariza HTML y CSS. La versión actual, WCAG 2.2, apareció en octubre de 2023 y se apoya en las WCAG 2.1: todo lo que valía antes sigue valiendo; solo se añadieron nuevos requisitos (y uno desapareció, de eso hablamos más adelante).

Importante de entender: las WCAG en sí no son una ley, sino una directriz técnica. Su relevancia jurídica les llega porque las leyes de todo el mundo remiten a ellas; en Europa, a través de la norma EN 301 549, en la que se basan los requisitos del European Accessibility Act (EAA) y de sus transposiciones nacionales, como el BFSG alemán o la Ley 11/2023 española.

Los cuatro principios: POUR

Todos los requisitos de las WCAG cuelgan de cuatro principios, abreviados en inglés como POUR: Perceivable, Operable, Understandable, Robust. Quien ha entendido estas cuatro ideas entiende la lógica de todo el estándar.

1. Perceptible

Todos los contenidos deben ser accesibles para todos los sentidos, si hace falta mediante una vía alternativa. Ejemplos:

• Las imágenes necesitan textos alternativos para que los lectores de pantalla puedan describirlas (más sobre esto en el artículo Cómo escribir buenos textos alternativos).
• Los vídeos necesitan subtítulos para las personas que no oyen (bien).
• El texto necesita un contraste suficiente con el fondo: gris claro sobre blanco es, para muchas personas, sencillamente ilegible.

2. Operable

Cada función debe poder alcanzarse sin ratón y no puede poner a nadie bajo presión de tiempo. Ejemplos:

• Toda la web se puede manejar con el teclado: con Tab, Intro y las teclas de flecha.
• El elemento que tiene el foco en cada momento está resaltado de forma visible, para saber dónde te encuentras.
• Los botones y enlaces son lo bastante grandes para acertar en ellos también con manos temblorosas o en el smartphone.

3. Comprensible

Los contenidos y el manejo deben resultar comprensibles. Ejemplos:

• Los formularios explican los errores en concreto: «Introduce tu fecha de nacimiento en el formato DD.MM.AAAA» en lugar de «Entrada no válida».
• La navegación funciona igual en todas las páginas y los elementos se comportan de forma previsible.
• Los textos están redactados con claridad: la jerga se explica o se evita.

4. Robusto

Los contenidos deben funcionar con el mayor número posible de navegadores y tecnologías de apoyo. Ejemplos:

• HTML limpio y semántico: un botón es un button, no una caja div clicable.
• Los mensajes de estado (como «El producto se ha añadido a la cesta») se marcan de forma que también los lectores de pantalla se enteren.

Niveles de conformidad: A, AA y AAA

Cada criterio de éxito de las WCAG está asignado a uno de tres niveles:

• A: el mínimo absoluto. Si no se alcanza, los contenidos resultan completamente inaccesibles para algunos grupos.
• AA: el estándar establecido. Es el nivel que exigen prácticamente todas las leyes del mundo, también el EAA y el BFSG a través de la EN 301 549.
• AAA: el nivel más alto, por ejemplo vídeos en lengua de signos para todos los contenidos de audio. Como objetivo global para webs completas no suele ser realista y tampoco se exige legalmente.

Novedades de las WCAG 2.2: nueve criterios de éxito

Las WCAG 2.2 añaden nueve criterios de éxito nuevos. Se dirigen sobre todo a las personas con limitaciones motoras, con dificultades cognitivas y al uso en el móvil:

Al mismo tiempo se eliminó un criterio antiguo: el 4.1.1 Procesamiento (sintaxis sin errores) desaparece en las WCAG 2.2, porque los navegadores y las tecnologías de apoyo modernos se han vuelto lo bastante tolerantes a los errores y el criterio ya no aportaba un beneficio propio.

WCAG, EN 301 549 y BFSG/EAA: ¿cómo encaja todo?

La cadena es más sencilla de lo que parece: el EAA es la directiva europea; el BFSG, su transposición alemana (en España, la Ley 11/2023). Todas exigen accesibilidad conforme a la norma europea armonizada EN 301 549, y esta adopta para los contenidos web, en esencia, las WCAG en el nivel AA. Actualmente, la EN 301 549 todavía remite a las WCAG 2.1; la actualización a la 2.2 está en marcha. Quien trabaja hoy directamente hacia las WCAG 2.2 AA va, por tanto, sobre seguro: cubre todos los requisitos de la 2.1 y, de paso, los que vienen.

Quién está afectado por estas leyes, qué plazos rigen y qué multas amenazan lo lees en el artículo BFSG y EAA: ¿quién debe ser accesible y para cuándo?

Malentendidos típicos

• «Un widget superpuesto hace conforme mi página». No. Las ayudas de uso, como los conmutadores de contraste o las funciones de lectura en voz alta, son un complemento útil, pero no pueden arreglar los problemas de fondo del código: textos alternativos ausentes, manejo con teclado roto, formularios sin etiquetar. La accesibilidad nace en los cimientos, no como capa añadida.
• «La accesibilidad solo afecta a las personas ciegas». Las WCAG también cubren las limitaciones motoras, auditivas y cognitivas, y de paso ayudan a todo el mundo: mejores contrastes a pleno sol, botones más grandes en el smartphone, formularios más claros para cualquiera.
• «Con una prueba automática basta». La experiencia muestra que las herramientas automáticas solo encuentran una parte de los problemas. Si un texto alternativo tiene sentido o si existe una trampa de teclado solo lo revela la prueba manual.

Empezar de forma pragmática

No tienes que abordar todos los criterios de golpe. Un punto de partida realista:

1. Inventario: revisa las páginas y procesos más importantes (inicio, contacto, checkout) con una herramienta automática y con el teclado. Encontrarás una guía en Cómo probar la accesibilidad de tu web.
2. Primero las victorias rápidas: los contrastes, los textos alternativos, las etiquetas de los formularios y el foco visible suelen arreglarse con poco esfuerzo, y cubren muchos criterios AA.
3. Planificar los nuevos criterios de la 2.2: revisa los tamaños de los objetivos, las alternativas al arrastrar y soltar y tu proceso de inicio de sesión.
4. Constancia: ancla la accesibilidad en los procesos de redacción y desarrollo, para que los contenidos nuevos no creen barreras nuevas.