WCAG 2.2: errores de accesibilidad y cómo corregirlos

En febrero de 2026, el proyecto WebAIM Million revisó las páginas de inicio del millón de sitios más populares según el ranking Tranco. El 95,9 % tenía fallas de WCAG 2 detectables de forma automática, con 56,1 errores por página en promedio. El 96 % de esos errores cae en seis categorías.

Casi todos se corrigen con HTML y CSS básicos. Pero afectan a quien navega con teclado, con lector de pantalla o con baja visión, y rara vez se notan en una revisión visual.

Esta guía resume qué es WCAG 2.2, cómo corregir los errores más frecuentes, cómo probar y qué exige la normativa en Chile y en la Unión Europea, según textos oficiales revisados en noviembre de 2026.

Qué es WCAG 2.2

Las Pautas de Accesibilidad para el Contenido Web (WCAG) son un estándar del W3C. La versión 2.2 se publicó el 5 de octubre de 2023, con una actualización el 12 de diciembre de 2024. La versión de 2023 es también la norma ISO/IEC 40500:2025.

Tiene cuatro principios (perceptible, operable, comprensible y robusto), 13 pautas y criterios verificables en tres niveles: A es el mínimo; AA exige los criterios A y AA, y es el objetivo de esta guía; AAA exige los tres, y el W3C no recomienda pedirlo como política general para sitios completos.

Qué cambió frente a WCAG 2.1

Agrega nueve criterios:

Y elimina uno: 4.1.1 Procesamiento (Parsing), que el W3C declara obsoleto porque las tecnologías de apoyo ya no necesitan analizar el HTML directamente. En WCAG 2.0 y 2.1 se agregó una nota: el criterio se considera siempre cumplido en contenido HTML o XML. El resto de los criterios de 2.1 no cambia.

¿Y WCAG 3?

Es un borrador de trabajo; la última versión es del 10 de septiembre de 2026. Según el W3C, no será un estándar terminado hasta dentro de algunos años, no reemplazará a WCAG 2, y la mejor forma de prepararse es cumplir WCAG 2.2 ahora.

Los errores más frecuentes

Porcentaje de páginas de inicio con cada error, según WebAIM Million 2026:

Sumamos tres temas que conviene revisar a mano: foco visible, orden del foco y tamaño de los objetivos táctiles.

Contraste insuficiente

El criterio 1.4.3 (AA) pide 4,5:1 entre texto y fondo, y 3:1 para texto grande (18 puntos, o 14 en negrita; unos 24 px y 18,5 px según el W3C). No se redondea: 4,499:1 no cumple. El placeholder también cuenta; los controles deshabilitados están exentos. Los componentes de interfaz y gráficos necesarios, como bordes de campos e íconos, piden 3:1 (criterio 1.4.11, AA).

WebAIM encontró 34 textos con bajo contraste por página en promedio: conviene corregir la paleta del sistema de diseño, no página por página.

Imágenes sin texto alternativo

El criterio 1.1.1 (A) pide una alternativa de texto con el mismo propósito. Según WebAIM, al 16,2 % de las imágenes le faltaba. Si la imagen informa, describe lo que aporta; si es enlace o botón, describe la función; si es decorativa, usa alt="". Omitir el atributo es una falla documentada (F65).

<img src="proceso.png" alt="Proceso de compra en tres pasos: elegir, pagar y recibir">
<a href="/"><img src="logo.svg" alt="Inicio de Empresa Ejemplo"></a>
<img src="separador.svg" alt="">

Campos sin etiqueta

El criterio 3.3.2 (A) pide etiquetas o instrucciones cuando el usuario ingresa datos; la asociación en el código se evalúa en 1.3.1 y el nombre accesible en 4.1.2. Usa <label> con for e id, y <fieldset> con <legend> para grupos. El placeholder no reemplaza la etiqueta: desaparece al escribir y los lectores de pantalla no lo tratan como etiqueta.

<label for="email">Correo electrónico</label>
<input id="email" name="email" type="email">

<fieldset>
  <legend>Forma de contacto</legend>
  <input type="radio" id="c-correo" name="contacto" value="correo">
  <label for="c-correo">Correo</label>
  <input type="radio" id="c-fono" name="contacto" value="telefono">
  <label for="c-fono">Teléfono</label>
</fieldset>

Enlaces y botones vacíos

Un enlace o botón que solo tiene un ícono se anuncia sin nombre. En un enlace cuyo único contenido es una imagen sin nombre accesible, es la falla F89 (criterios 2.4.4, 2.4.9 y 4.1.2); en un botón, la F68 (criterio 4.1.2). Usa texto visible, alt en la imagen o aria-label. Un "Leer más" puede cumplir si el párrafo explica el destino, pero el W3C prefiere enlaces que se entiendan solos. Si usas aria-label, reemplaza el texto visible para el lector de pantalla, así que empieza con ese texto.

<a href="/noticias/nueva-sucursal" aria-label="Leer más sobre la nueva sucursal">Leer más</a>

<button type="button" aria-label="Cerrar menú">
  <svg aria-hidden="true">…</svg>
</button>

Ojo con ARIA: las páginas que la usaban tenían más errores detectados (59,1 en promedio) que las que no (42), según WebAIM. Es una asociación, no una causa. La guía de prácticas ARIA del W3C recuerda que un rol ARIA no agrega comportamiento de teclado; prefiere <button> y <a href> antes que un <div> con roles.

Página sin idioma

El criterio 3.1.1 (A) pide que el idioma principal pueda determinarse por programa: lang en <html>, con un código BCP 47. Los pasajes en otro idioma también se marcan (criterio 3.1.2, AA).

<html lang="es">
  …
  <p>El estándar se llama <span lang="en">Web Content Accessibility Guidelines</span>.</p>

Foco invisible u oculto

El criterio 2.4.7 (AA) busca que quien usa teclado sepa dónde está el foco. El error clásico, :focus { outline: none }, es el ejemplo literal de la falla F78. Reemplaza el contorno; no lo borres. :focus-visible lo muestra al navegar con teclado y no al hacer clic con el mouse en un botón, y funciona en los navegadores principales desde marzo de 2022.

El criterio nuevo 2.4.11 (AA) pide que el elemento con foco no quede totalmente tapado por encabezados fijos, avisos de cookies o diálogos no modales. Una técnica reconocida es scroll-padding (C43).

:focus-visible {
  outline: 3px solid #1a56db;  /* verifica 3:1 contra el fondo */
  outline-offset: 2px;
}

html {
  scroll-padding-top: 80px;     /* alto del encabezado fijo */
  scroll-padding-bottom: 64px;  /* alto del aviso de cookies */
}

Orden de foco ilógico

El criterio 2.4.3 (A) pide un orden de foco que preserve el significado. MDN recomienda usar solo tabindex="0" y "-1", evitar valores positivos y evitar CSS que reordene elementos enfocables: el HTML debe venir en orden lógico. Un <div> con tabindex no reemplaza a un botón, porque no aparece como control en el árbol de accesibilidad.

<!-- Evita -->
<div tabindex="1" onclick="enviar()">Enviar</div>

<!-- Usa -->
<button type="submit">Enviar</button>

Objetivos táctiles pequeños

El criterio 2.5.8 (AA), nuevo en 2.2, pide objetivos de al menos 24 × 24 píxeles CSS. Hay excepciones: un objetivo menor cumple si tiene espacio libre equivalente a un círculo de 24 px, si otro control de la página hace lo mismo y cumple, si es un enlace dentro de una oración, si su tamaño lo define el navegador o si esa presentación es esencial o exigida por ley. Para controles importantes, el W3C sugiere apuntar a 44 × 44 px (criterio 2.5.5, AAA).

.paginacion a,
.redes a {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 24px;   /* técnica C42 */
  min-height: 24px;
}

Cómo probar

1. Teclado. Recorre la página con Tab y Shift+Tab; activa enlaces con Enter, botones con Enter o Espacio, y cierra diálogos con Esc. Comprueba que el foco siempre se vea, que avance en orden lógico y que nunca quede atrapado (criterio 2.1.2, A).
2. Lector de pantalla. NVDA es gratuito y de código abierto para Windows; VoiceOver viene incluido en macOS.
3. Herramientas automáticas. Son un buen primer filtro, pero el W3C advierte que no pueden verificar todo, que requieren juicio humano y que a veces dan resultados engañosos. WebAIM agrega que no detectar errores no significa que la página sea accesible. Una herramienta ve un alt ausente, pero no puede juzgar si el que existe describe bien la imagen.

Qué exige la normativa en Chile

• Órganos del Estado. El Decreto 1 de 2015 del Ministerio Secretaría General de la Presidencia aprueba la norma técnica sobre sistemas y sitios web de los órganos de la Administración del Estado, salvo las empresas públicas creadas por ley. Su artículo 5 exige aplicar las directrices sobre accesibilidad universal, considerando la Convención sobre los Derechos de las Personas con Discapacidad, la Ley 20.422 y "los estándares internacionales definidos por la W3C". No fija versión de WCAG ni nivel. La BCN lo registra como no derogado.
• Ley 21.180 de Transformación Digital. Modificó la Ley 19.880, cuyo artículo 19 obliga a los órganos de la Administración a usar plataformas electrónicas para los expedientes y encarga a un reglamento fijar sus estándares, considerando "condiciones de accesibilidad para los interesados". También obliga al Estado, no a privados.
• Ley 20.422. Regula la igualdad de oportunidades e inclusión de las personas con discapacidad, define la accesibilidad universal y encarga al Estado establecer exigencias de accesibilidad (artículo 8). No encontramos en su texto una obligación específica para sitios web privados.

En síntesis: no encontramos una norma vigente que obligue a una empresa privada chilena a cumplir WCAG en su sitio. Para el Estado existe un mandato, sin versión ni nivel definidos.

Si vendes en Europa

La Directiva (UE) 2019/882, o European Accessibility Act, se aplica desde el 28 de junio de 2025. Cubre, entre otros, el comercio electrónico, los servicios bancarios para consumidores, los libros electrónicos y sitios y apps de varios servicios de transporte de pasajeros.

Puede importarte desde Chile porque define como prestador de servicios a quien presta un servicio en el mercado de la Unión o que ofrece prestarlo a consumidores en la Unión. Si tu tienda en línea vende a consumidores europeos, podrías quedar dentro.

Pide que sitios y apps sean perceptibles, operables, comprensibles y robustos, los mismos principios de WCAG, y que la identificación y el pago en comercio electrónico sean accesibles. Las microempresas de servicios (menos de 10 personas y hasta 2 millones de euros de facturación o balance anual) están exentas. Cada país la aplica con su ley nacional, así que conviene revisar con asesoría local.

Lista de verificación

Fuentes

• W3C · WCAG 2.2, WCAG 2 Overview y What's New in WCAG 2.2
• W3C WAI · WCAG 2 FAQ y Understanding 4.1.1 Parsing
• W3C WAI · WCAG 3 Introduction y WCAG 3.0 Working Draft
• W3C WAI · Understanding 1.4.3, 1.1.1, 3.3.2, 2.4.4 y 3.1.2
• W3C WAI · Understanding 2.4.7, 2.4.11, 2.5.8, 2.5.5 y 2.1.2
• W3C WAI · Técnicas F78, F89, F68, ARIA8, H57 y C42
• W3C WAI · Forms Tutorial: Instructions
• W3C WAI · ARIA Authoring Practices Guide: Read Me First
• W3C WAI · Selecting Web Accessibility Evaluation Tools
• WebAIM · The WebAIM Million (2026) y Keyboard Accessibility
• MDN · tabindex y :focus-visible
• NV Access · About NVDA y Apple · VoiceOver User Guide for Mac
• BCN · Decreto 1 de 2015, Segpres, Ley 21.180, Ley 19.880 y Ley 20.422
• EUR-Lex · Directiva (UE) 2019/882 y Comisión Europea · European Accessibility Act

Si quieres revisar la accesibilidad de tu sitio y ordenar qué corregir primero, conversemos.