WCAG 2.2 y BITV 2.0 en la práctica: cómo aplicar la accesibi­lidad web

Un sitio web se aplica a WCAG 2.2 fijando el nivel AA como objetivo, revisando los recorridos de usuario más importantes, corrigiendo los hallazgos en componentes reutilizables e integrando las pruebas en cada versión. La BITV 2.0 obliga sobre todo a los organismos públicos y remite técnicamente a los mismos criterios; para las empresas se suma la BFSG.

Este artículo trata de la aplicación: qué exige de nuevo WCAG 2.2, quién es responsable de qué en el proyecto, cómo probar y cómo mantener el resultado. Si la ley se aplica a su oferta, y desde cuándo, se explica en el artículo sobre la accesibilidad según la BFSG. Ambos se complementan: allí lee si está obligado, aquí cómo lograrlo técnica y organizativamente.

WCAG, EN 301 549 y BITV: quién fija qué referencia

Las normas se apoyan unas en otras. Las Pautas de accesibilidad para el contenido web (WCAG) del W3C describen, como criterios de éxito, lo que debe cumplir un contenido web accesible, ordenados según los principios perceptible, operable, comprensible y robusto y según los niveles A, AA y AAA. Leyes y reglamentos recurren a estos criterios en lugar de crear reglas técnicas propias.

Norma	Función	Qué se deriva de ello
WCAG 2.2	Estándar internacional del W3C, recomendación desde octubre de 2023	Criterios técnicos; el objetivo de aplicación es el nivel AA
EN 301 549	Norma europea de TIC accesibles; para contenidos web remite a los criterios WCAG de los niveles A y AA	Referencia de auditoría; la versión habitual V3.2.1 remite a WCAG 2.1
BITV 2.0	Reglamento de la ley alemana de igualdad de las personas con discapacidad para los organismos públicos federales; los estados federados tienen normas propias	Diseñar sitios web, aplicaciones móviles e intranets según la EN 301 549 y publicar una declaración de accesibilidad
BFSG	Ley para determinados productos y servicios del sector privado	Comprobar si le afecta (véase el artículo); técnicamente el mismo listón

La BITV 2.0 se aplica desde hace tiempo a los organismos públicos: conforme a la Directiva europea de accesibilidad web, los sitios nuevos debían cumplirla desde 2019, los existentes desde 2020 y las aplicaciones móviles desde 2021. Para las empresas resulta relevante cuando trabajan para entidades contratantes públicas, donde la accesibilidad se exige con frecuencia por contrato. Además, los organismos públicos deben publicar una declaración de accesibilidad y ofrecer una vía para comentarios.

Quien construye de forma consecuente según WCAG 2.2 AA cumple los criterios web de la norma actual y está preparado para futuras versiones: WCAG 2.2 es retrocompatible, de modo que una página conforme cumple también los criterios de 2.1 y 2.0. Un marcado limpio y válido sigue siendo una buena práctica aunque haya desaparecido el criterio 4.1.1 Análisis sintáctico, y en algunos métodos de auditoría se sigue revisando.

Qué exige de nuevo WCAG 2.2

WCAG 2.2 añade nueve criterios de éxito a la versión 2.1. Seis están en los niveles A y AA y forman parte, por tanto, del objetivo habitual de aplicación; tres, en el nivel AAA. Además desaparece 4.1.1 Análisis sintáctico.

Criterio	Nivel	Consecuencia en la práctica
2.4.11 Foco no oculto (mínimo)	AA	El elemento enfocado no puede quedar totalmente tapado por cabeceras fijas, banners de cookies o widgets de chat.
2.5.7 Movimientos de arrastre	AA	Todo lo que se puede arrastrar – deslizadores, listas ordenables, mapas – necesita una alternativa con un simple clic o toque.
2.5.8 Tamaño del objetivo (mínimo)	AA	Los objetivos de clic y toque miden al menos 24 × 24 píxeles CSS o tienen espacio suficiente; hay excepciones, por ejemplo para enlaces dentro del texto.
3.2.6 Ayuda coherente	A	El contacto, la ayuda o el chat aparecen en todas las páginas en el mismo lugar relativo.
3.3.7 Entrada redundante	A	Los datos ya introducidos se reutilizan en el mismo proceso o se ofrecen para elegir, por ejemplo la dirección de entrega como dirección de facturación.
3.3.8 Autenticación accesible (mínimo)	AA	El inicio de sesión no puede exigir una prueba cognitiva, como recordar una contraseña o resolver un acertijo, salvo que exista una alternativa. Deben funcionar pegar y los gestores de contraseñas.

Los obstáculos típicos son 2.4.11 y 2.5.8: las cabeceras fijas y los banners de cookies tapan el foco, los botones de icono pequeños no alcanzan el tamaño mínimo y los campos de acceso bloquean pegar contraseñas. Los tres se resuelven de forma central: con relleno de desplazamiento para cabeceras fijas, tamaños mínimos para los controles y un acceso sin bloqueo de pegado.

Quién es responsable de qué en el proyecto

La accesibilidad rara vez fracasa por una sola persona, sino por responsabilidades poco claras: diseño define los colores, desarrollo construye los componentes, redacción mantiene los contenidos, y cada uno supone que los demás se ocupan.

Rol	Responsable de	Ejemplos
Diseño	Contrastes, estados, maquetación, tamaños de objetivo, patrones de interacción comprensibles	Paleta con pares de contraste verificados, estilo de foco visible, mensajes de error con texto y no solo color
Desarrollo	Semántica, manejo con teclado, gestión del foco, lógica de formularios, componentes	Elementos HTML nativos antes que ARIA, diálogos con gestión del foco, etiquetas con label
Redacción	Contenidos, textos alternativos, encabezados, textos de enlace, medios	Textos alternativos con sentido, subtítulos, textos de enlace como “Descargar lista de precios” en lugar de “aquí”
Dirección del proyecto	Requisitos, aceptación, responsables, canal de comentarios	Criterios en tickets y aceptación, una persona de contacto para comentarios

La accesibilidad resulta más rentable cuando está en el sistema de diseño: un botón o diálogo bien construido una vez es correcto en todas las páginas. Por eso definimos colores, estados de foco, elementos de formulario y patrones de navegación ya en el sistema de diseño, junto con el equipo de diseño de nuestra agencia asociada LOMA DESIGN.

Barreras típicas y cómo corregirlas

Estructura y semántica

Utilice elementos HTML nativos: button para acciones, a para navegación, label para campos de formulario, nav y main como puntos de referencia y encabezados reales con una jerarquía sin saltos. ARIA añade semántica solo donde HTML no ofrece nada adecuado; un ARIA mal aplicado es peor que ninguno. Un div con un controlador de clic no es accesible con teclado ni lo reconoce un lector de pantalla como botón.

Teclado y foco

• Todas las funciones se alcanzan sin ratón y el orden de tabulación sigue el orden visual.
• El foco es siempre visible: no se elimina el marco de foco sin un sustituto equivalente.
• Un enlace “Saltar al contenido” al inicio de la página omite la navegación.
• Los diálogos, menús y superposiciones reciben el foco, lo mantienen dentro y lo devuelven al cerrarse.

Formularios y mensajes de error

Cada campo necesita una etiqueta visible y asociada mediante programación. Indique los campos obligatorios y los formatos antes de la entrada y describa los errores con texto junto al campo; un borde rojo por sí solo no basta. El atributo autocomplete ayuda a los navegadores y gestores de contraseñas a rellenar datos conocidos. Un buen mensaje de error dice: “Introduzca una dirección de correo válida, p. ej. nombre@empresa.com” y no solo “Entrada no válida”.

Contraste, zoom y presentación

El texto normal necesita una relación de contraste de al menos 4,5:1; el texto grande, los controles y los iconos, 3:1. La página debe poder ampliarse al 200 % sin perder contenido y funcionar con un ancho de 320 píxeles CSS sin desplazamiento horizontal. Los contenidos en movimiento se pueden pausar; respetar el ajuste del sistema “reducir movimiento” es una buena práctica.

Medios y contenidos

Las imágenes informativas llevan texto alternativo y las decorativas, un atributo alt vacío. Los vídeos grabados necesitan subtítulos y, si información importante solo aparece en la imagen, audiodescripción en el nivel AA; los contenidos solo de audio, una transcripción. Los PDF enlazados son documentos propios con requisitos propios: siempre que sea posible, ofrezca la información también como HTML.

Pruebas: automáticas, manuales y con usuarios

Herramientas como axe, Lighthouse o WAVE detectan con rapidez textos alternativos ausentes, campos sin etiqueta y contrastes insuficientes, y pueden integrarse en el pipeline de compilación. Pero solo cubren una parte de los criterios. Si un texto alternativo tiene sentido, si el orden del foco es lógico o si un mensaje de error se entiende, solo lo juzga una persona. Una prueba fiable sigue por ello cinco pasos:

1. Escaneo automático de las páginas clave y de la biblioteca de componentes
2. Prueba con teclado de los procesos principales (navegación, formulario, acceso, solicitud o compra) usando solo Tab, Intro, Espacio, flechas y Escape
3. Muestreo con lector de pantalla, por ejemplo con NVDA en Windows, VoiceOver en macOS e iOS o TalkBack en Android
4. Zoom al 200 %, visualización con 320 píxeles de ancho, contraste alto y movimiento reducido
5. Pruebas con personas que usan tecnologías de apoyo a diario: encuentran problemas que ninguna lista de control revela

Documente cada hallazgo como ticket con criterio, ubicación, gravedad y estimación de esfuerzo. Para los sitios web de organismos públicos está además extendido el método de auditoría BITV-Test; un informe estructurado por criterios es útil en cualquier caso.

Ejemplo práctico: fabricante de maquinaria con sitio web y portal de distri­bui­dores

Supongamos que un fabricante mediano de maquinaria gestiona un sitio web con catálogo de productos y un portal de distribuidores con acceso y formulario de pedido. La licitación de una entidad pública pregunta por la accesibilidad. Así se procede:

• Definir los recorridos clave: página de inicio, búsqueda de productos, ficha de producto con descarga de hoja técnica, formulario de consulta, acceso de distribuidores y formulario de pedido; después, escanear automáticamente.
• Agrupar hallazgos: se repiten en pocos componentes: la cabecera fija tapa el foco, los botones de icono son demasiado pequeños, los campos no tienen etiqueta y el campo de contraseña bloquea pegar.
• Corregir en componentes: corregir una vez cabecera, botón, campo de formulario y acceso; el efecto alcanza a todas las páginas.
• Comprobar manualmente: teclado, lector de pantalla y zoom en los recorridos clave; ofrecer las hojas técnicas además como HTML o revisar los PDF.
• Implicar a la redacción y documentar: guía para textos alternativos y de enlace, declaración de accesibilidad con vía de contacto, informe de auditoría con plan para los puntos pendientes.

Integrar en el día a día, evitar errores, lista de control

Integrar en el día a día

• Los criterios forman parte de la definición de terminado: un componente está listo cuando supera las pruebas de teclado, contraste y lector de pantalla.
• Una comprobación automática en el pipeline de compilación avisa de las nuevas infracciones.
• Una guía editorial con ejemplos de textos alternativos, textos de enlace, encabezados y tablas ayuda a todos los que mantienen contenidos.
• Los componentes de terceros, como banners de cookies, widgets de reserva o chat, se evalúan en cuanto a accesibilidad antes de adquirirlos.
• Una persona de contacto designada recoge los comentarios; los avisos pasan al backlog.

Errores típicos

• Revisar la accesibilidad poco antes del lanzamiento, cuando los cambios son más caros
• Confiar en un overlay o plugin en lugar de corregir código y componentes
• Revisar solo la página de inicio y omitir formularios, acceso o compra
• Comprobar contrastes en el archivo de diseño pero no los estados de foco, hover y error
• Añadir atributos ARIA sin probar teclado ni lector de pantalla

Lista de control antes del relanza­miento

• Todos los elementos interactivos son accesibles con teclado y el foco es visible y no queda tapado.
• Encabezados, puntos de referencia, listas y tablas están marcados semánticamente de forma correcta.
• Las imágenes informativas tienen textos alternativos adecuados y los vídeos, subtítulos.
• Los campos de formulario tienen etiquetas, los errores aparecen en texto y no se piden entradas dos veces.
• Los contrastes cumplen el nivel AA y los controles miden al menos 24 × 24 píxeles o tienen espacio.
• El acceso funciona con gestor de contraseñas y pegado, sin acertijos.
• El zoom al 200 % y el ancho de 320 píxeles funcionan sin pérdida de contenido.
• Existen declaración de accesibilidad y canal de comentarios, si le son exigibles.

Cómo le apoya Nano Concepts

Revisamos su situación a lo largo de los recorridos reales de los usuarios, priorizamos los hallazgos y los corregimos en componentes, plantillas y contenidos, junto con nuestra agencia asociada LOMA DESIGN en el diseño UI/UX. En proyectos nuevos integramos la accesibilidad desde el principio, por ejemplo en un sitio web accesible. En la primera consulta gratuita aclaramos situación, objetivo y esfuerzo realista. La valoración jurídica corresponde a su asesoramiento legal; nosotros aportamos la base técnica y la documentación.

Este artículo no sustituye el asesoramiento jurídico.