¿Qué son las WCAG (Pautas de Accesibilidad para el Contenido Web)?

¿Qué son las Pautas de Accesibilidad para el Contenido Web (WCAG)?

Las Pautas de Accesibilidad para el Contenido Web (WCAG) son el estándar internacional para la accesibilidad digital, publicado por el W3C a través de la Web Accessibility Initiative (WAI). WCAG define cómo deben diseñarse y construirse los sitios web, aplicaciones web y documentos digitales para que las personas con discapacidades puedan percibirlos, operarlos, comprenderlos y navegar por ellos.

WCAG no es solo orientación — es la base técnica referenciada por las leyes de accesibilidad en todo el mundo. La Ley Europea de Accesibilidad, los casos de la Americans with Disabilities Act (ADA), la Sección 508 de la U.S. Rehabilitation Act, la Directiva de Accesibilidad Web de la UE, la Ley de Igualdad del Reino Unido, la ACA de Canadá y la DDA de Australia, todos remiten a WCAG como la definición de facto de "accesible".

Los cuatro principios POUR

WCAG está estructurado alrededor de cuatro principios fundamentales, capturados en el acrónimo POUR:

• Perceivable (Perceptible) — Los usuarios deben poder percibir el contenido a través de sus sentidos disponibles. Esto significa alternativas de texto para imágenes, subtítulos para vídeo, contraste de color suficiente y contenido que pueda presentarse de diferentes maneras sin perder significado.
• Operable (Operable) — Los usuarios deben poder operar la interfaz. La funcionalidad debe estar disponible vía teclado, el contenido no debe causar convulsiones (no parpadear más de 3 veces por segundo), los usuarios deben tener tiempo suficiente para leer y la navegación debe ser predecible.
• Understandable (Comprensible) — Los usuarios deben entender tanto el contenido como la operación de la interfaz. El texto debe ser legible, el contenido debe aparecer y operar de formas predecibles, y a los usuarios se les debe ayudar a evitar y corregir errores.
• Robust (Robusto) — El contenido debe ser lo suficientemente robusto para funcionar con agentes de usuario actuales y futuros, incluyendo tecnologías de asistencia. El código debe ser válido, ARIA debe usarse correctamente y los componentes deben comunicar su nombre, rol y valor a la tecnología asistiva.

Los tres niveles de conformidad

WCAG define tres niveles de conformidad, expresando accesibilidad creciente:

Nivel A — mínimo (el suelo)

Los requisitos más básicos. Fallar el Nivel A significa que el contenido es inutilizable para algunos grupos de usuarios discapacitados. Ejemplos: cada <img> necesita texto alt, el vídeo necesita subtítulos, la navegación por teclado debe funcionar. Ningún sitio debería enviar nunca sin cumplimiento de Nivel A.

Nivel AA — el objetivo legal/práctico

La mayoría de leyes y regulaciones de accesibilidad requieren Nivel AA. Añade criterios matizados: ratio de contraste 4.5:1 para texto normal, subtítulos para vídeo en directo, indicadores de foco visibles, tamaños de objetivo cumplen mínimos (24×24 en WCAG 2.2). El Nivel AA es el objetivo práctico para sitios de producción.

Nivel AAA — el estándar mejorado

El nivel más alto, a menudo impráctico para sitios enteros porque algunos criterios requieren reorganización radical. AAA requiere: contraste 7:1, interpretación en lengua de señas para vídeo, sin límites de tiempo en ningún lugar, lectura en lenguaje sencillo a nivel secundario inferior. La mayoría de sitios apuntan a AAA solo para flujos específicos de alto riesgo (registro, checkout, formularios gubernamentales) en lugar de en todo el sitio.

Línea de tiempo de versiones de WCAG

• WCAG 1.0 (1999) — Original, ahora obsoleto.
• WCAG 2.0 (2008) — Introdujo los principios POUR. Aún legalmente válido en muchas jurisdicciones.
• WCAG 2.1 (2018) — Añadió 17 criterios de éxito para móvil, baja visión y discapacidades cognitivas. La versión más citada en la ley actual.
• WCAG 2.2 (Octubre 2023) — Añade 9 criterios de éxito para accesibilidad cognitiva, móvil y usuarios de baja visión. Adiciones notables: tamaño mínimo de objetivo (Nivel AA, 24×24px), apariencia de foco mejorada, autenticación accesible, alternativa a movimientos de arrastre.
• WCAG 3.0 (en desarrollo) — Una reestructuración completa en lugar de una actualización incremental. Usa puntuación basada en resultados en lugar de criterios pasa/falla. Aún no estable; los equipos de producción deberían seguir apuntando a WCAG 2.2.

Los 13 criterios WCAG más fallados (por frecuencia)

Según el reporte WebAIM Million 2024, estos criterios fallan en la mayoría de páginas de inicio:

1. 1.4.3 Contraste (Mínimo) — 81% de páginas tienen texto de bajo contraste. El mayor problema individual de accesibilidad en la web.
2. 1.1.1 Contenido No-textual — 54% de páginas tienen imágenes sin texto alt.
3. 4.1.2 Nombre, Rol, Valor — 44% de páginas tienen inputs de formulario sin etiquetas adecuadas o botones sin nombres accesibles.
4. 2.4.4 Propósito del Enlace — 45% de páginas tienen texto de enlace ambiguo ("haz clic aquí", "leer más").
5. 1.3.1 Info y Relaciones — 30% tienen estructura de encabezado inadecuada o campos de formulario sin etiqueta.
6. 3.1.1 Idioma de la Página — 17% sin el atributo lang en <html>.
7. 4.1.1 Parsing — IDs duplicados, etiquetas no cerradas, etc. (Nota: removido en WCAG 2.2.)
8. 2.4.6 Encabezados y Etiquetas — Encabezados que no describen su tema.
9. 1.4.5 Imágenes de Texto — Texto renderizado como imagen en lugar de texto seleccionable.
10. 2.4.7 Foco Visible — CSS personalizado oculta el anillo de foco sin reemplazarlo.
11. 3.3.2 Etiquetas o Instrucciones — Campos de formulario sin etiquetas o con el antipatrón placeholder-como-etiqueta.
12. 1.4.4 Redimensionar Texto — El layout se rompe cuando se hace zoom en el texto.
13. 2.5.3 Etiqueta en Nombre — El texto de etiqueta visible no coincide con el nombre accesible.

Arreglar solo estos 13 problemas aborda el 95%+ de las quejas de accesibilidad en la mayoría de los sitios.

Evidencia de conformidad WCAG: VPAT, ACR, auditorías de accesibilidad

Documentar tu cumplimiento WCAG es cada vez más requerido por equipos de procurement empresarial, RFPs gubernamentales y demandas de accesibilidad. El flujo estándar de documentación:

• VPAT — la plantilla vacía proporcionada por la ITI. La rellenas para tu producto.
• ACR (Reporte de Conformidad de Accesibilidad) — el VPAT completado. "Tenemos un ACR" significa "rellenamos un VPAT".
• Auditoría de tercera parte — un consultor de accesibilidad certificado prueba tu producto manualmente + con tecnología asistiva y produce un reporte de remediación.
• Re-auditoría anual — la mayoría de procurement empresarial requiere que los VPATs/auditorías no tengan más de 12 meses.

Errores comunes de implementación WCAG

• Tratar la accesibilidad como una checklist de paso final. WCAG es más caro cuando se atornilla al final. Hornéalo en el diseño (sistemas de color, estados de foco), componentes (HTML semántico, etiquetas adecuadas) y CI (axe-core, Pa11y, Lighthouse).
• Confiar únicamente en pruebas automatizadas. Las herramientas automatizadas atrapan el 30-40% de las violaciones WCAG. El otro 60-70% (texto alt significativo, orden de tabulación lógico, experiencia de lector de pantalla) requiere pruebas manuales con tecnología asistiva real.
• Confundir cumplimiento legal con accesibilidad usable. Pasar verificaciones automatizadas no es lo mismo que ser accesible. Prueba con lectores de pantalla (NVDA, JAWS, VoiceOver), navegación solo por teclado e idealmente usuarios con discapacidades.
• ARIA donde funciona el HTML semántico. La primera regla de ARIA: no uses ARIA. Los nativos <button>, <label> y <nav> superan al role="button" personalizado en <div> el 100% del tiempo.
• Ignorar la accesibilidad cognitiva. WCAG 2.2 añadió criterios cognitivos por una razón. El lenguaje sencillo, los patrones predecibles y la recuperación útil de errores no son opcionales.
• Burlarse del verificador de contraste. 4.5:1 no es excesivo — es el suelo para usuarios con discapacidad visual leve. "Se ve bien para mí" no es una prueba de contraste.

FAQ: WCAG

¿Es WCAG legalmente requerido?

En muchas jurisdicciones, sí. La Ley Europea de Accesibilidad (efectiva junio 2025) requiere WCAG 2.1 AA. La ADA en EE.UU. ha sido interpretada por tribunales federales que requieren conformidad WCAG. La Sección 508 de la Rehabilitation Act manda WCAG 2.0 AA para agencias federales de EE.UU. Verifica la ley local para obligaciones específicas.

¿Qué versión de WCAG debería apuntar en 2026?

WCAG 2.2 Nivel AA es el mejor objetivo actual. Es la última versión estable con amplia adopción regulatoria. WCAG 3.0 aún está en desarrollo; la mayoría de equipos aún no deberían apuntarlo.

¿Cómo sé si mi sitio cumple con WCAG?

Tres capas: (1) herramientas automatizadas (axe DevTools, WAVE, Lighthouse) atrapan las violaciones fáciles; (2) prueba manual con teclado y lectores de pantalla atrapa problemas operacionales; (3) auditoría de tercera parte atrapa todo lo demás y produce un ACR.

¿Cuánto cuesta el cumplimiento WCAG?

Altamente variable. Un sitio de marketing simple puede llevarse a AA por 5K-15K $ de tiempo de diseño + dev. Una aplicación web grande podría necesitar 50K-500K $ de remediación. Construir accesibilidad desde el inicio añade ~10-15% a los costes de desarrollo; atornillarla más tarde añade 200-400%.

¿Cuál es la diferencia entre WCAG y ADA?

WCAG es el estándar técnico. ADA es ley de EE.UU. (Americans with Disabilities Act). Los tribunales de EE.UU. han sostenido repetidamente que los sitios web de acomodación pública deben ser accesibles, y usan WCAG como la definición técnica de "accesible". Las leyes de otros países citan WCAG de manera similar.

¿Cubre WCAG las apps móviles?

WCAG fue diseñado para contenido web pero se aplica ampliamente también a apps móviles. WCAG 2.1 añadió criterios específicos de móvil (orientación, accionamiento por movimiento, tamaños de objetivo), y WCAG 2.2 fue más allá. Las apps nativas iOS/Android también tienen guías específicas de plataforma (Apple Accessibility, Google Accessibility) que complementan WCAG.

Cómo encaja LoadFocus en las pruebas de accesibilidad

La accesibilidad va de la mano con el rendimiento — las páginas lentas impactan desproporcionadamente a los usuarios con discapacidades (dispositivos más antiguos, tecnología asistiva con sobrecarga). Las pruebas de velocidad de sitio web LoadFocus validan que tu sitio accesible también carga rápido en todos los dispositivos. La monitorización sintética atrapa regresiones de accesibilidad cuando envías — incluyendo texto alt perdido, estados de foco rotos y fallos de contraste introducidos por cambios CSS.