Cómo leer WCAG 2.2 para tu sitio, corregir los fallos que más se repiten, hacer una prueba manual de 30 minutos y entender los puntos en común entre accesibilidad y usabilidad.
Umair Ali Sadaqat|Última actualización: 27 de septiembre de 2026|8 min de lectura
We.Inc es nuestro propio producto. Cómo investigamos y actualizamos esta página
Accesibilidad web: guía práctica de WCAG 2.2
Cómo leer WCAG 2.2 para tu sitio, corregir los fallos que más se repiten, hacer una prueba manual de 30 minutos y entender los puntos en común entre accesibilidad y usabilidad.
Preguntas frecuentes
¿Qué significa que un sitio web cumpla con WCAG?
Significa que el sitio satisface los criterios de éxito de las Pautas de Accesibilidad para el Contenido Web en un nivel determinado, normalmente el nivel AA de WCAG 2.1 o 2.2. El nivel AA incluye todos los criterios de nivel A y AA. La mayoría de las leyes y políticas de contratación que mencionan WCAG exigen el nivel AA.
¿Cómo interpreto las pautas WCAG para mi sitio?
Empieza por la referencia rápida «How to Meet WCAG» del W3C, filtra por los niveles A y AA y, para cada criterio, lee la página «Understanding», que explica su intención en lenguaje sencillo. Después, prueba tus plantillas principales (inicio, página de contenido, formulario y pago), en lugar de cada página por separado.
¿Una superposición o un complemento de accesibilidad puede hacer que mi sitio cumpla?
No hay una herramienta que por sí sola consiga que un sitio cumpla. Las superposiciones que añaden una barra de herramientas no corrigen el código subyacente y muchas personas con discapacidad y especialistas en accesibilidad dicen que les estorban. Corrige directamente el HTML, el contraste, las etiquetas y la compatibilidad con teclado.
¿Cuál es la diferencia entre usabilidad y accesibilidad?
La accesibilidad significa que las personas con discapacidad pueden percibir, comprender, navegar e interactuar con el sitio. La usabilidad significa que el sitio es fácil y eficiente para todos. Se superponen mucho: las etiquetas claras, el buen contraste y la navegación predecible ayudan a todos los visitantes, no solo a las personas con discapacidad.
¿Los verificadores automáticos detectan todos los problemas de accesibilidad?
No. Herramientas como WAVE, axe y Lighthouse detectan problemas como texto alternativo ausente, bajo contraste y etiquetas faltantes, pero muchos criterios —por ejemplo, si el texto alternativo es útil o el orden de enfoque tiene sentido— requieren una revisión humana.
Un sitio web conforme con WCAG cumple las Pautas de Accesibilidad para el Contenido Web en un nivel determinado; para casi todas las empresas eso significa WCAG 2.2 nivel AA. En la práctica, muchos sitios fallan en los mismos aspectos: poco contraste de color, imágenes sin texto alternativo, campos de formulario sin etiquetar, enlaces y botones vacíos, y elementos inaccesibles con teclado. Corrige esos problemas y prueba el sitio con teclado y lector de pantalla para solucionar una gran parte de las dificultades que encuentran los usuarios.
Esta guía explica cómo leer WCAG sin perderse, qué correcciones importan más y cómo hacer una prueba de 30 minutos por tu cuenta.
Cómo se estructura WCAG
El W3C publica WCAG, que está organizada en capas:
Cuatro principios, conocidos por sus siglas en inglés POUR: el contenido debe ser perceptible, operable, comprensible y robusto.
Pautas dentro de cada principio (por ejemplo, «Alternativas textuales» o «Accesible mediante teclado»).
Criterios de éxito dentro de cada pauta. Son reglas comprobables, numeradas (como 1.4.3 Contraste) y clasificadas en nivel A, AA o AAA.
El nivel A es el mínimo. AA es el objetivo habitual para requisitos legales y de contratación. AAA es más estricto y normalmente no se exige para sitios enteros.
WCAG 2.2 se convirtió en recomendación del W3C en octubre de 2023. Añadió criterios como tamaño mínimo de objetivos, enfoque no oculto y autenticación accesible, y eliminó 4.1.1 Parsing por considerarlo obsoleto.
Cómo interpretar WCAG para tu sitio
La especificación parece un estándar porque lo es. Esta forma práctica de abordarla ayuda:
Abre la «How to Meet WCAG (Quick Reference)» del W3C.
Filtra por los niveles A y AA solamente.
Para cada criterio, lee la página enlazada «Understanding». Explica su objetivo en lenguaje sencillo y ofrece ejemplos de cumplimiento e incumplimiento.
En lugar de probar cada página, prueba tus plantillas: inicio, una página de contenido estándar, una entrada de blog, un formulario y una página de producto o pago. Si corriges una plantilla, corriges todas las páginas creadas con ella.
Registra cada problema con el número del criterio, la página y una descripción de la corrección.
Correcciones que resuelven la mayoría de los fallos reales
1. Contraste de color (1.4.3 y 1.4.11)
Texto normal: al menos 4.5:1 respecto del fondo.
Texto grande (aproximadamente 24 px normal o 18.66 px en negrita o más): al menos 3:1.
Componentes de interfaz y gráficos con significado (bordes de botones, contornos de campos e iconos informativos): al menos 3:1.
El texto de marcador gris claro y el texto blanco sobre colores de marca pálidos suelen causar problemas. Comprueba el contraste con la herramienta de WebAIM o las herramientas de desarrollo del navegador.
2. Alternativas textuales para imágenes (1.1.1)
Las imágenes informativas llevan texto alternativo que describe lo importante: alt="Técnico que cambia el filtro de un horno".
Las imágenes decorativas llevan texto alternativo vacío: alt="", para que los lectores de pantalla las omitan.
El texto que aparece dentro de imágenes (por ejemplo, la captura de un volante o un menú en JPG) también debe estar disponible como texto real.
Las imágenes enlazadas —como un logotipo que lleva a inicio— describen el destino: alt="Inicio de Acme Plumbing".
3. Etiquetas y errores de formularios (1.3.1, 3.3.1, 3.3.2)
Cada campo necesita una etiqueta <label> visible y vinculada. El texto de marcador no es una etiqueta: desaparece al escribir.
Los mensajes de error explican qué salió mal y cómo corregirlo («Escribe un teléfono con código de área»), mediante texto y no solo un borde rojo.
Los campos obligatorios se indican con texto o una señal accesible, no solo con color.
4. Acceso con teclado (2.1.1, 2.4.3, 2.4.7)
Todos los enlaces, botones, menús y controles de formulario deben funcionar con Tab, Mayús+Tab, Intro y Espacio.
El orden de enfoque debe seguir el orden visual.
Un indicador visible de enfoque muestra dónde estás. Quitar el contorno del navegador con outline: none sin reemplazarlo es un fallo común.
Los menús desplegables y las ventanas modales deben poder abrirse, usarse y cerrarse con teclado; las ventanas modales deben mantener el enfoque dentro hasta cerrarse.
5. Enlaces y botones con nombre accesible (2.4.4, 4.1.2)
Los botones que solo muestran un icono (menú hamburguesa, lupa de búsqueda o iconos de redes sociales) necesitan un nombre accesible, mediante texto visible, aria-label o texto oculto.
Evita que toda la página tenga enlaces «Haz clic aquí» o «Leer más». Describe el destino en el texto del enlace o asígnale un nombre accesible único.
6. Estructura y encabezados (1.3.1, 2.4.6)
Un solo <h1> por página que describa el contenido.
Encabezados en orden lógico (h2 para secciones y h3 dentro de ellas), no elegidos por el tamaño de letra.
Usa listas reales, tablas con celdas de encabezado y regiones semánticas (<header>, <nav>, <main>, <footer>).
Establece el idioma de la página: <html lang="es">.
7. Novedades de WCAG 2.2 que conviene conocer
2.5.8 Tamaño del objetivo (mínimo), AA: los objetivos interactivos deben medir al menos 24 por 24 píxeles CSS o tener espacio suficiente alrededor si son más pequeños.
2.4.11 Enfoque no oculto (mínimo), AA: encabezados fijos, avisos de cookies y ventanas de chat no deben ocultar por completo el elemento enfocado.
3.3.8 Autenticación accesible (mínimo), AA: no exijas resolver acertijos ni recordar información para iniciar sesión sin ofrecer una alternativa; permite gestores de contraseñas y pegar texto.
3.3.7 Entrada redundante, A: no obligues a volver a introducir información que la persona ya proporcionó durante el mismo proceso.
8. Medios y movimiento
Los videos necesitan subtítulos (1.2.2); los videos pregrabados requieren audiodescripción o una alternativa textual para el contenido visual importante.
Cualquier elemento que se mueva automáticamente durante más de cinco segundos necesita una opción para pausarlo (2.2.2).
Respeta la configuración prefers-reduced-motion para animaciones intensas.
Prueba manual de 30 minutos
Las herramientas automáticas solo detectan una parte de los problemas. Sigue esta rutina para cada plantilla principal.
Minutos 0 a 5: análisis automático. Ejecuta WAVE (extensión del navegador), axe DevTools o la sección de accesibilidad de Lighthouse. Corrige errores claros, como texto alternativo o etiquetas faltantes y problemas de contraste.
Minutos 5 a 15: solo teclado. Aparta el ratón. Recorre la página desde arriba usando Tab.
¿Puedes ver dónde está el enfoque en todo momento?
¿Puedes abrir y cerrar el menú, usar cada campo y enviar el formulario?
¿Hay un enlace «Saltar al contenido» y funciona?
¿Desaparece el enfoque detrás de un encabezado fijo o un aviso?
Minutos 15 a 25: lector de pantalla. Usa VoiceOver (integrado en macOS e iOS) o NVDA (gratuito en Windows).
Escucha la lista de encabezados. ¿Describe la página?
Recorre las imágenes y los botones. ¿Se entienden fuera de contexto?
Completa el formulario. ¿Se anuncia cada campo con su etiqueta? ¿Se anuncian los errores?
Minutos 25 a 30: ampliación y redistribución. Amplía el navegador al 200% y luego al 400%. Con el 400%, el contenido debería reorganizarse en una columna sin desplazamiento horizontal (1.4.10 Redistribución), y nada debería quedar cortado.
Coincidencias entre usabilidad y accesibilidad
Quienes buscan «usabilidad y accesibilidad web» tienen razón al relacionarlas. Casi toda mejora de accesibilidad también mejora la usabilidad:
Mejora de accesibilidad
A quién más ayuda
Buen contraste
A cualquiera que use el teléfono al sol
Etiquetas visibles
A quien completa un formulario con prisa
Subtítulos
A quien mira un video sin sonido
Compatibilidad con teclado
A usuarios expertos y personas con el panel táctil averiado
Objetivos táctiles más grandes
A todas las personas que usan el móvil
Mensajes de error claros
A todas las personas que cometen un error al escribir
Superposiciones, declaraciones y legislación
Superposiciones: los widgets que prometen cumplimiento con un solo clic no modifican el código subyacente. Corrige el sitio directamente.
Declaración de accesibilidad: publica una página breve que indique el estándar al que aspiras, los problemas conocidos y cómo contactarte para pedir ayuda o formatos alternativos.
Contexto legal: los requisitos varían según el país. La Ley Europea de Accesibilidad se aplica a muchos productos y servicios de la UE desde junio de 2025; en Estados Unidos, la ADA suele aplicarse a los sitios web; y los organismos del sector público a menudo tienen reglas específicas. Busca asesoramiento legal para tu situación.
Lista de verificación
[ ] Contraste: 4.5:1 para texto y 3:1 para texto grande y elementos de interfaz
[ ] Texto alternativo en imágenes informativas y texto vacío en las decorativas
[ ] Etiqueta visible y vinculada en cada campo
[ ] Todo el sitio funciona con teclado y muestra el enfoque
[ ] Los botones con iconos tienen nombres accesibles
[ ] Encabezados y regiones en orden lógico; idioma de página definido
[ ] Objetivos táctiles de al menos 24 por 24 píxeles CSS
[ ] Subtítulos en videos y control de pausa para el movimiento
[ ] Redistribución del contenido con ampliación al 400%
[ ] Declaración de accesibilidad publicada
La accesibilidad también ayuda al posicionamiento: los encabezados, textos alternativos y enlaces descriptivos son fundamentos de SEO en la página, incluidos en nuestra lista de verificación de SEO on-page.
We.Inc genera sitios con código estándar de HTML, CSS y React que puedes editar directamente, así puedes corregir etiquetas, textos alternativos y contraste o pedir cambios por chat. Ejecuta siempre las pruebas manuales anteriores en lo que publiques.
