Guías técnicas

Accesibilidad web WCAG 2.2: checklist técnico para cumplir sin excusas

La accesibilidad web dejó de ser opcional. La European Accessibility Act (EAA) entró en vigor en junio de 2025 y exige que productos digitales en la UE sean accesibles. La referencia técnica es WCAG 2.2 nivel AA: un conjunto de criterios concretos y testeables que determinan si una web es usable para personas con discapacidad. Esta guía es el checklist que usamos internamente en cada proyecto para cumplirlo.

Niveles de conformidad: A, AA y AAA

Nivel	Qué cubre	¿Obligatorio?
A	Barreras graves que impiden el acceso básico	Sí (mínimo legal en casi toda regulación)
AA	Barreras significativas que dificultan el uso	Sí (estándar exigido por EAA, ADA, EN 301 549)
AAA	Mejoras avanzadas para máxima inclusión	No obligatorio (aspiracional)

1. Perceptible

El contenido debe poder percibirse por todos los sentidos disponibles.

Alternativas textuales (1.1)

Todas las imágenes informativas tienen alt descriptivo.
Imágenes decorativas llevan alt="" o role="presentation".
Iconos funcionales (botones, links) tienen aria-label o texto oculto accesible.
Vídeos tienen subtítulos y, idealmente, audiodescripción.

tsx

// ✅ Imagen informativa
<img src="/equipo/carlos.webp" alt="Carlos Torija, CEO de Think! Madrid" />

// ✅ Imagen decorativa
<img src="/decoracion.svg" alt="" role="presentation" />

// ✅ Botón con icono
<button aria-label="Abrir menú de navegación">
  <svg>...</svg>
</button>

Contraste de color (1.4.3 / 1.4.6)

AA: ratio mínimo 4.5:1 para texto normal, 3:1 para texto grande (≥18px bold o ≥24px).
AAA: 7:1 para texto normal, 4.5:1 para texto grande.
Componentes interactivos (bordes de inputs, iconos funcionales): mínimo 3:1 contra el fondo.

Herramientas: WebAIM Contrast Checker, Stark para Figma.

Redimensionado y reflow (1.4.4 / 1.4.10)

El contenido es legible al hacer zoom al 200% sin scroll horizontal.
Reflow correcto hasta 320px de ancho (sin contenido cortado ni overflow).
No usar unidades fijas (px) para tipografía del body — preferir rem.

2. Operable

Todos los componentes interactivos deben poder usarse con cualquier input.

Navegación por teclado (2.1)

Toda la funcionalidad accesible con Tab, Enter, Escape y flechas.
Sin trampas de teclado: si entras a un modal con Tab, puedes salir con Escape.
Foco visible en todo momento (:focus-visible con outline claro).

css

/* Focus visible para todos los interactivos */
:focus-visible {
  outline: 2px solid #fa3a00;
  outline-offset: 2px;
}

/* No eliminar nunca el outline sin reemplazarlo */
/* ❌ */ :focus { outline: none; }
/* ✅ */ :focus:not(:focus-visible) { outline: none; }

Focus Not Obscured — nuevo en 2.2 (2.4.11 / 2.4.12)

AA (2.4.11): el foco no debe quedar totalmente oculto por sticky headers, banners o modales.
AAA (2.4.12): el foco no debe quedar parcialmente oculto.
Usa scroll-margin-top en elementos focusables bajo headers sticky.

Target Size Minimum — nuevo en 2.2 (2.5.8)

AA: áreas de clic mínimo de 24×24 CSS pixels.
Excepciones: enlaces inline dentro de texto, elementos con target equivalente cercano.
En la práctica: botones, checkboxes, radios y links de navegación deben tener padding suficiente.

Dragging Movements — nuevo en 2.2 (2.5.7)

Cualquier acción que requiera arrastrar debe tener alternativa sin arrastre (clic, tap, teclado).
Afecta a: sliders, carruseles draggables, drag & drop de listas, mapas.

3. Comprensible

El contenido y la interfaz deben ser entendibles.

Idioma de la página (3.1)

html

<!-- Idioma principal de la página -->
<html lang="es-ES">

<!-- Cambio de idioma en fragmentos -->
<p>Contacta en <span lang="en">Think! Madrid</span></p>

Formularios accesibles (3.3)

Cada input tiene <label> asociado (visible, no solo placeholder).
Errores identificados con texto (no solo color rojo).
Sugerencias de corrección cuando el formato es incorrecto.
Confirmación antes de enviar datos financieros o legales.

tsx

// ✅ Label asociado + error accesible
<div>
  <label htmlFor="email">Email</label>
  <input
    id="email"
    type="email"
    aria-describedby="email-error"
    aria-invalid={!!error}
  />
  {error && (
    <p id="email-error" role="alert" className="text-red-400 text-sm">
      Introduce un email válido
    </p>
  )}
</div>

Consistent Help — nuevo en 2.2 (3.2.6)

Si hay mecanismo de ayuda (chat, FAQ, teléfono), debe estar en la misma posición relativa en todas las páginas.

4. Robusto

El contenido debe funcionar con tecnologías asistivas actuales y futuras.

HTML semántico y ARIA (4.1)

HTML semántico primero: <nav>, <main>, <header>, <footer>, <section>, <article>.
ARIA solo cuando HTML semántico no alcanza. Primera regla de ARIA: no usar ARIA si puedes usar HTML nativo.
Roles, estados y propiedades correctos en componentes custom (tabs, accordions, modales).

tsx

// ✅ Modal accesible
<dialog
  open={isOpen}
  aria-modal="true"
  aria-labelledby="modal-title"
  onClose={handleClose}
>
  <h2 id="modal-title">Confirmar envío</h2>
  <p>¿Estás seguro de enviar el formulario?</p>
  <button onClick={handleClose}>Cancelar</button>
  <button onClick={handleSubmit}>Confirmar</button>
</dialog>

Herramientas de auditoría

Herramienta	Tipo	Qué detecta	Precio
axe DevTools	Extensión navegador	Violaciones WCAG automáticas	Gratis (versión pro de pago)
Lighthouse	Integrada en Chrome	Score de accesibilidad + detalles	Gratis
WAVE	Extensión navegador	Errores + alertas + estructura	Gratis
NVDA / VoiceOver	Lectores de pantalla	Experiencia real de usuario ciego	Gratis
pa11y	CLI / CI pipeline	Auditoría automática en builds	Gratis (open source)

Las herramientas automáticas detectan un 30-50% de los problemas. El resto requiere revisión manual: navegar toda la web solo con teclado, probar con lector de pantalla y revisar que el flujo de lectura tenga sentido lógico.

Normativa vigente en 2026

European Accessibility Act (EAA) — vinculante desde junio 2025 para e-commerce, banca, telecomunicaciones, transporte y servicios digitales. Referencia: WCAG 2.1 AA mínimo, WCAG 2.2 AA recomendado.
EN 301 549 — estándar técnico europeo que mapea WCAG a requisitos concretos de software y web.
Real Decreto 1112/2018 (España) — obliga al sector público español. Referencia: WCAG 2.1 AA.
ADA / Section 508 (EEUU) — si tu web tiene audiencia en USA, aplica. Referencia: WCAG 2.0 AA como mínimo.

Checklist final WCAG 2.2 AA

☐ Todas las imágenes informativas tienen alt descriptivo
☐ Contraste texto/fondo ≥ 4.5:1 (normal) / 3:1 (grande)
☐ Componentes interactivos con contraste ≥ 3:1
☐ Zoom al 200% sin scroll horizontal ni contenido cortado
☐ Toda la funcionalidad accesible con teclado
☐ Foco visible en todo momento
☐ Foco no oculto por sticky headers o banners
☐ Áreas de clic mínimo 24×24px
☐ Alternativa a drag para todas las acciones de arrastre
☐ lang correcto en <html> y fragmentos
☐ Labels visibles en todos los inputs
☐ Errores de formulario con texto (no solo color)
☐ HTML semántico (nav, main, header, footer, section)
☐ ARIA solo donde HTML nativo no alcanza
☐ Ayuda consistente (mismo lugar en todas las páginas)
☐ Auditoría automática (axe, Lighthouse) + manual (teclado, lector)

Conclusión

La accesibilidad no es un parche que se añade al final: es una disciplina que se integra desde diseño, se implementa en desarrollo y se valida antes de lanzar. WCAG 2.2 no es una lista infinita de requisitos: son reglas concretas y testeables que, si se siguen desde el principio, añaden un sobrecoste mínimo y cubren obligaciones legales que ya están en vigor.

Si quieres seguir por el lado técnico, lee la guía de Core Web Vitals (rendimiento) y la guía de sistemas de diseño (donde la accesibilidad se integra como capa). Y si necesitas que auditemos tu web, escríbenos a /contacto.

Preguntas frecuentes

¿Qué es WCAG 2.2?

WCAG 2.2 (Web Content Accessibility Guidelines) es la versión más reciente del estándar internacional de accesibilidad web publicado por el W3C en octubre de 2023. Define criterios técnicos para que las webs sean usables por personas con discapacidad visual, auditiva, motriz o cognitiva. Tiene tres niveles: A (mínimo), AA (estándar recomendado) y AAA (máximo).

¿Es obligatorio cumplir WCAG 2.2?

En la UE, la European Accessibility Act (EAA) exige que productos y servicios digitales sean accesibles desde junio de 2025. La referencia técnica es WCAG 2.1 nivel AA como mínimo, pero WCAG 2.2 es la versión recomendada. En España, el Real Decreto 1112/2018 ya obliga al sector público. Para sector privado, la EAA amplía el alcance a e-commerce, banca, telecomunicaciones y transporte.

¿Cuál es la diferencia entre WCAG 2.1 y 2.2?

WCAG 2.2 añade 9 criterios nuevos sobre 2.1, enfocados en usuarios con baja visión, discapacidad cognitiva y usuarios de dispositivos móviles. Los más relevantes: Focus Not Obscured (el foco no debe quedar oculto), Dragging Movements (alternativas a arrastrar), Target Size Minimum (áreas de clic mínimo 24×24px) y Consistent Help (ayuda siempre en el mismo lugar).

¿Qué nivel de WCAG debo cumplir?

Nivel AA es el estándar que la mayoría de legislaciones exige y la industria acepta como referencia. Nivel A es el mínimo funcional pero insuficiente para cumplimiento regulatorio. Nivel AAA es aspiracional y muy difícil de aplicar al 100% en webs comerciales. En la práctica: apunta a AA completo y aplica AAA donde sea razonable.

¿Cómo audito la accesibilidad de mi web?

Combinación de herramientas automáticas (axe DevTools, Lighthouse, WAVE) y revisión manual. Las herramientas automáticas detectan un 30-50% de los problemas. El resto requiere revisión humana: navegación con teclado, pruebas con lector de pantalla (NVDA, VoiceOver), revisión de contraste y flujo lógico de lectura.

¿Cuánto cuesta hacer una web accesible?

Si se diseña accesible desde el principio, el sobrecoste es del 5-15% sobre el presupuesto de desarrollo. Si hay que adaptar una web existente, puede costar entre 2.000 y 20.000€ según complejidad y número de URLs. La clave: hacerlo bien desde el diseño es siempre más barato que remediarlo después.

¿Tienes un proyecto en mente?

Cuéntanos qué necesitas y te proponemos la mejor solución sin compromiso.

Hablar con el equipo →

Guías técnicas

Accesibilidad web WCAG 2.2: checklist técnico para cumplir sin excusas

Niveles de conformidad: A, AA y AAA

Nivel	Qué cubre	¿Obligatorio?
A	Barreras graves que impiden el acceso básico	Sí (mínimo legal en casi toda regulación)
AA	Barreras significativas que dificultan el uso	Sí (estándar exigido por EAA, ADA, EN 301 549)
AAA	Mejoras avanzadas para máxima inclusión	No obligatorio (aspiracional)

1. Perceptible

El contenido debe poder percibirse por todos los sentidos disponibles.

Alternativas textuales (1.1)

Todas las imágenes informativas tienen alt descriptivo.
Imágenes decorativas llevan alt="" o role="presentation".
Iconos funcionales (botones, links) tienen aria-label o texto oculto accesible.
Vídeos tienen subtítulos y, idealmente, audiodescripción.

tsx

// ✅ Imagen informativa
<img src="/equipo/carlos.webp" alt="Carlos Torija, CEO de Think! Madrid" />

// ✅ Imagen decorativa
<img src="/decoracion.svg" alt="" role="presentation" />

// ✅ Botón con icono
<button aria-label="Abrir menú de navegación">
  <svg>...</svg>
</button>

Contraste de color (1.4.3 / 1.4.6)

AA: ratio mínimo 4.5:1 para texto normal, 3:1 para texto grande (≥18px bold o ≥24px).
AAA: 7:1 para texto normal, 4.5:1 para texto grande.
Componentes interactivos (bordes de inputs, iconos funcionales): mínimo 3:1 contra el fondo.

Herramientas: WebAIM Contrast Checker, Stark para Figma.

Redimensionado y reflow (1.4.4 / 1.4.10)

El contenido es legible al hacer zoom al 200% sin scroll horizontal.
Reflow correcto hasta 320px de ancho (sin contenido cortado ni overflow).
No usar unidades fijas (px) para tipografía del body — preferir rem.

2. Operable

Todos los componentes interactivos deben poder usarse con cualquier input.

Navegación por teclado (2.1)

Toda la funcionalidad accesible con Tab, Enter, Escape y flechas.
Sin trampas de teclado: si entras a un modal con Tab, puedes salir con Escape.
Foco visible en todo momento (:focus-visible con outline claro).

css

/* Focus visible para todos los interactivos */
:focus-visible {
  outline: 2px solid #fa3a00;
  outline-offset: 2px;
}

/* No eliminar nunca el outline sin reemplazarlo */
/* ❌ */ :focus { outline: none; }
/* ✅ */ :focus:not(:focus-visible) { outline: none; }

Focus Not Obscured — nuevo en 2.2 (2.4.11 / 2.4.12)

AA (2.4.11): el foco no debe quedar totalmente oculto por sticky headers, banners o modales.
AAA (2.4.12): el foco no debe quedar parcialmente oculto.
Usa scroll-margin-top en elementos focusables bajo headers sticky.

Target Size Minimum — nuevo en 2.2 (2.5.8)

AA: áreas de clic mínimo de 24×24 CSS pixels.
Excepciones: enlaces inline dentro de texto, elementos con target equivalente cercano.
En la práctica: botones, checkboxes, radios y links de navegación deben tener padding suficiente.

Dragging Movements — nuevo en 2.2 (2.5.7)

Cualquier acción que requiera arrastrar debe tener alternativa sin arrastre (clic, tap, teclado).
Afecta a: sliders, carruseles draggables, drag & drop de listas, mapas.

3. Comprensible

El contenido y la interfaz deben ser entendibles.

Idioma de la página (3.1)

html

<!-- Idioma principal de la página -->
<html lang="es-ES">

<!-- Cambio de idioma en fragmentos -->
<p>Contacta en <span lang="en">Think! Madrid</span></p>

Formularios accesibles (3.3)

Cada input tiene <label> asociado (visible, no solo placeholder).
Errores identificados con texto (no solo color rojo).
Sugerencias de corrección cuando el formato es incorrecto.
Confirmación antes de enviar datos financieros o legales.

tsx

// ✅ Label asociado + error accesible
<div>
  <label htmlFor="email">Email</label>
  <input
    id="email"
    type="email"
    aria-describedby="email-error"
    aria-invalid={!!error}
  />
  {error && (
    <p id="email-error" role="alert" className="text-red-400 text-sm">
      Introduce un email válido
    </p>
  )}
</div>

Consistent Help — nuevo en 2.2 (3.2.6)

Si hay mecanismo de ayuda (chat, FAQ, teléfono), debe estar en la misma posición relativa en todas las páginas.

4. Robusto

El contenido debe funcionar con tecnologías asistivas actuales y futuras.

HTML semántico y ARIA (4.1)

HTML semántico primero: <nav>, <main>, <header>, <footer>, <section>, <article>.
ARIA solo cuando HTML semántico no alcanza. Primera regla de ARIA: no usar ARIA si puedes usar HTML nativo.
Roles, estados y propiedades correctos en componentes custom (tabs, accordions, modales).

tsx

// ✅ Modal accesible
<dialog
  open={isOpen}
  aria-modal="true"
  aria-labelledby="modal-title"
  onClose={handleClose}
>
  <h2 id="modal-title">Confirmar envío</h2>
  <p>¿Estás seguro de enviar el formulario?</p>
  <button onClick={handleClose}>Cancelar</button>
  <button onClick={handleSubmit}>Confirmar</button>
</dialog>

Herramientas de auditoría

Herramienta	Tipo	Qué detecta	Precio
axe DevTools	Extensión navegador	Violaciones WCAG automáticas	Gratis (versión pro de pago)
Lighthouse	Integrada en Chrome	Score de accesibilidad + detalles	Gratis
WAVE	Extensión navegador	Errores + alertas + estructura	Gratis
NVDA / VoiceOver	Lectores de pantalla	Experiencia real de usuario ciego	Gratis
pa11y	CLI / CI pipeline	Auditoría automática en builds	Gratis (open source)

Normativa vigente en 2026

European Accessibility Act (EAA) — vinculante desde junio 2025 para e-commerce, banca, telecomunicaciones, transporte y servicios digitales. Referencia: WCAG 2.1 AA mínimo, WCAG 2.2 AA recomendado.
EN 301 549 — estándar técnico europeo que mapea WCAG a requisitos concretos de software y web.
Real Decreto 1112/2018 (España) — obliga al sector público español. Referencia: WCAG 2.1 AA.
ADA / Section 508 (EEUU) — si tu web tiene audiencia en USA, aplica. Referencia: WCAG 2.0 AA como mínimo.

Checklist final WCAG 2.2 AA

☐ Todas las imágenes informativas tienen alt descriptivo
☐ Contraste texto/fondo ≥ 4.5:1 (normal) / 3:1 (grande)
☐ Componentes interactivos con contraste ≥ 3:1
☐ Zoom al 200% sin scroll horizontal ni contenido cortado
☐ Toda la funcionalidad accesible con teclado
☐ Foco visible en todo momento
☐ Foco no oculto por sticky headers o banners
☐ Áreas de clic mínimo 24×24px
☐ Alternativa a drag para todas las acciones de arrastre
☐ lang correcto en <html> y fragmentos
☐ Labels visibles en todos los inputs
☐ Errores de formulario con texto (no solo color)
☐ HTML semántico (nav, main, header, footer, section)
☐ ARIA solo donde HTML nativo no alcanza
☐ Ayuda consistente (mismo lugar en todas las páginas)
☐ Auditoría automática (axe, Lighthouse) + manual (teclado, lector)