Accesibilidad web 2026: la guía completa para cumplir WCAG 2.1 AA sin morir en el intento

La accesibilidad web dejó de ser "nice to have" en 2025. Con el European Accessibility Act (EAA) en vigor desde junio 2025, las webs de empresas que venden productos o servicios en la UE deben cumplir WCAG 2.1 nivel AA por ley. No cumplirlo = multas + daño reputacional + perder el 15-20% de tu audiencia.

(Este artículo es parte de nuestro cluster CRO para eCommerce. Si buscas info de diseño, mira diseño web para PYMEs 2026.)

Por qué la accesibilidad web importa en 2026 (más allá de la ley)

4 razones reales

1. Es ley en la UE (EAA 2025)

Multas desde 100k € hasta 10M € según país

Aplicación desde junio 2025

Aplica a webs de eCommerce, SaaS, servicios, formación

2. Es SEO (Google lo usa)

Google indexa y rankea mejor webs accesibles

Core Web Vitals + accesibilidad = ranking top

Voice search y screen readers = SEO semántico

3. Es negocio

El 15-20% de la población mundial tiene alguna discapacidad

En España: 4.4M de personas con discapacidad (INE 2024)

Y todos envejecemos: el 100% de tu audiencia tiene accesibilidad temporal en algún momento

4. Mejora la UX para TODOS

Subtítulos → personas en transporte público viendo vídeos sin audio

Buen contraste → móvil bajo el sol

Navegación por teclado → power users

Texto claro → personas con dislexia, baja alfabetización, o simplemente prisa

Los 4 niveles de WCAG (y por qué AA es el obligatorio)

Niveles WCAG 2.1

| Nivel | Significado | Quién lo usa | Obligatorio en la UE | |---|---|---|---| | A | Mínimo | Nadie | Sí (base) | | AA | Estándar | Gobiernos, empresas | SÍ (obligatorio) | | AAA | Oro | Algunos sectores | No (recomendable) |

Objetivo 2026: cumplir AA en toda la web. AAA es aspiracional.

Los 25 criterios de éxito WCAG 2.1 AA (versión resumida)

Los organizo en 4 principios (POUR): Perceptible, Operable, Understandable, Robust.

1. Perceptible (la información debe presentarse de forma que los usuarios la perciban)

1.1 Alternativas de texto (no solo imágenes)

Textos alternativos en imágenes (1.1.1): `html

`

Casos especiales:

Imágenes decorativas: alt=""

Iconos con función: alt="Cerrar menú"

Imágenes complejas (gráficos): descripción larga en texto cercano

Imágenes de texto: el texto debe estar en la imagen (no en CSS) O en alt

Herramienta para verificar: WAVE, axe DevTools, Lighthouse.

1.2 Subtítulos en multimedia (vídeos, audios)

Vídeos con diálogo: subtítulos (automáticos o manuales)

Vídeos con audio descriptivo: pista de audio adicional

Podcasts: transcripción escrita

Live streams: subtítulos en tiempo real (o transcripción posterior)

Servicios de subtítulos: Rev.com, Otter.ai, YouTube auto-captions (revisar manualmente).

1.3 Contraste de color suficiente (1.4.3)

Mínimo AA:

Texto normal: 4.5:1 de contraste

Texto grande (18pt+ o 14pt+ bold): 3:1

Herramienta: WebAIM Contrast Checker.

Errores comunes:

Texto gris claro sobre fondo blanco (2:1, no pasa AA)

Botón "Comprar" con texto gris sobre fondo verde claro

Texto blanco sobre imagen de fondo (depende del fondo)

1.4 Texto redimensionable (1.4.4)

El texto debe poder ampliarse al 200% sin perder funcionalidad

NO uses tamaños fijos en pixels; usa em o rem

NO desactives zoom móvil (user-scalable=no es WCAG fail)

Cómo verificar: prueba con Ctrl+Plus (zoom navegador) y zoom móvil (pinch).

1.5 Imágenes de texto (1.4.5)

Evita imágenes con texto dentro (logos con texto, banners PNG con letra)

Usa texto real con CSS para mejor accesibilidad y SEO

2. Operable (los usuarios deben poder operar la interfaz)

2.1 Navegación por teclado (2.1.1)

TODO debe ser accesible con teclado:

Tab para navegar

Enter/Space para activar

Escape para cerrar modales

Flechas para submenús

Test rápido: desconecta el ratón, ¿puedes usar tu web?

Errores comunes:

Botones que son

con click handler (no son focusables)

Custom dropdowns sin soporte de teclado

Modales que no atrapan el foco

Sliders que solo funcionan con swipe

2.2 Sin trampas de teclado (2.1.2)

El usuario nunca debe quedar "atrapado" en un elemento

Escape siempre debe cerrar modales/dropdowns

Tab debe poder salir de cualquier submenú

2.3 Focus visible (2.4.7)

El indicador de focus (outline) NUNCA debe eliminarse: `css / MAL - NUNCA hagas esto / *:focus { outline: none; } button:focus { outline: 0; }

/ BIEN - estilo el outline / *:focus-visible { outline: 3px solid #3b82f6; outline-offset: 2px; border-radius: 4px; } `

2.4 Orden de foco lógico (2.4.3)

Tab debe seguir el orden visual

Si tienes elementos decorativos antes del CTA, el usuario tabula por ellos

Usa tabindex="0" solo cuando sea necesario

Usa tabindex="-1" para elementos que deben ser focusables programáticamente pero no en Tab

2.5 Skip navigation links (2.4.1)

Enlaza "Saltar al contenido principal" al principio: `html Saltar al contenido principal

...

`

`css .skip-link { position: absolute; top: -40px; left: 0; background: #000; color: #fff; padding: 8px 16px; z-index: 100; } .skip-link:focus { top: 0; } `

2.6 Múltiples formas de encontrar páginas (2.4.5)

Tu web debe tener al menos 2 de:

Búsqueda interna

Mapa del sitio

Tabla de contenidos

Breadcrumbs (también cuentan)

2.7 Títulos de página descriptivos (2.4.2)

`html `

2.8 Foco no oculto (2.4.11 y 2.4.12)

Modales: el foco debe estar DENTRO del modal

Después de cerrar modal: foco vuelve al elemento que lo abrió

Menús: foco se mueve al primer item del submenú

3. Understandable (información y operación comprensibles)

3.1 Idioma de la página (3.1.1)

`html `

3.2 Idioma de partes (3.1.2)

`html

La palabra responsive significa...

`

3.3 Navegación consistente (3.2.3)

El menú principal debe estar en el mismo lugar y orden en todas las páginas

Si el logo lleva a home, debe hacerlo en TODAS las páginas

3.4 Identificación de errores en formularios (3.3.1)

Mensaje de error específico, no genérico

Indicar qué campo tiene el error

Sugerir cómo solucionarlo

`html Error

Email inválido. Usa el formato nombre@dominio.com `

3.5 Labels o instrucciones (3.3.2)

`html

Tu nombre `

3.6 Prevención de errores (3.3.4)

Confirmación antes de acciones destructivas (borrar cuenta, etc.)

Auto-guardado en formularios largos

Resumen antes de enviar pedido

4. Robust (compatible con tecnologías asistivas)

4.1 HTML válido y semántico (4.1.1)

`html

...

...

...

Solo un h1 por página

Acción

`

4.2 Name, role, value (4.1.2)

Para componentes custom, usar ARIA: `html

Activar `

Checklist práctico por categoría (60 puntos)

Voy a darte un checklist ejecutable para auditoría AA:

Perceptible (15 puntos)

[ ] Todas las imágenes tienen alt text

[ ] Imágenes decorativas tienen alt=""

[ ] Contraste 4.5:1 en texto normal

[ ] Contraste 3:1 en texto grande

[ ] Vídeos con subtítulos

[ ] Audios con transcripción

[ ] No hay imágenes con texto (o está justificado)

[ ] Zoom 200% sin pérdida de funcionalidad

[ ] Audio controlable (pausa, volumen)

[ ] Sin flashes > 3x/seg

[ ] Color no es el único medio de información

[ ] Audio ajustable

[ ] Contraste de componentes UI

[ ] Texto redimensionable

[ ] Imágenes de texto evitadas

Operable (15 puntos)

[ ] Todo funciona con teclado

[ ] Sin trampas de teclado

[ ] Focus visible

[ ] Orden de foco lógico

[ ] Skip navigation link

[ ] Múltiples formas de encontrar páginas (búsqueda, sitemap, breadcrumb)

[ ] Títulos de página descriptivos

[ ] Foco no oculto

[ ] No focus order traps

[ ] Headings jerárquicos

[ ] Link purpose claro

[ ] Multiple ways

[ ] Headings and labels

[ ] Focus visible

[ ] Pointer cancellation

Understandable (15 puntos)

[ ] Lang declarado en HTML

[ ] Lang de partes declarado

[ ] Navegación consistente

[ ] Identificación de errores

[ ] Labels en formularios

[ ] Prevención de errores

[ ] Página de error 404 clara

[ ] Cambios de contexto no automáticos

[ ] Navegación consistente

[ ] Identificación de página actual

[ ] Secciones con headings

[ ] Idioma de partes

[ ] Errores específicos

[ ] Formularios con labels visibles

[ ] Confirmación de acciones destructivas

Robust (15 puntos)

[ ] HTML válido

[ ] HTML semántico (header, nav, main, etc.)

[ ] ARIA correcto en componentes custom

[ ] Sin errores de validación W3C

[ ] Compatible con screen readers (NVDA, JAWS, VoiceOver)

[ ] Status messages con role="alert" o aria-live

[ ] Botones con HTML

[ ] Forms con HTML

[ ] Headings jerárquicos (sin saltarse niveles)

[ ] Listas con

/
1. [ ] Tablas con
2. [ ] Sin role inválidos
3. [ ] aria-expanded en acordeones
4. [ ] aria-controls en modales
5. [ ] aria-modal en modales

Herramientas de auditoría gratuitas

Para auditoría automática

1. Lighthouse (Chrome DevTools → Lighthouse → Accessibility) - Score 0-100 - Lista de issues - Fácil y rápido

2. axe DevTools (extensión Chrome/Firefox) - Más detallado que Lighthouse - Categorizado por nivel (A, AA, AAA) - Recomendado para devs

3. WAVE (extensión o web) - Visual overlay en la página - Marca errores directamente - Recomendado para diseño

4. Accessibility Insights (extensión Chrome) - Tutorial paso a paso - Recomendado para empezar

Para testing manual

1. Solo teclado: desconecta ratón, prueba toda la web 2. Screen reader: NVDA (Windows, gratis), VoiceOver (Mac/iOS, built-in) 3. Zoom 200%: ¿se sigue viendo bien? 4. Contraste: WebAIM Contrast Checker 5. Lighthouse mobile: simula móvil con conexión lenta

Errores comunes que veo en webs de PYMEs

❌ "El cliente de email está mal programado"

6. Checkboxes sin label asociado
7. Formularios sin error message accesibles
8. Submit que no anuncia el resultado a screen readers

❌ "Hemos hecho responsive pero no mobile-first"

9. Botones de 28px (no 44px mínimo)
10. Texto 12px (no 16px mínimo)
11. Hover effects que no funcionan en touch

❌ "Hemos añadido ARIA a todo"

12. role="button" en un (redundante)
13. ARIA inválida (peor que no tenerla)
14. aria-label en elementos que no lo necesitan

Regla: usa HTML semántico primero. ARIA solo cuando no haya equivalente HTML.

❌ "Hemos puesto alt en todo, incluso decorativas"

`html



`

Cómo afecta la accesibilidad al SEO

Dato clave: Google usa muchas señales de accesibilidad como factores de ranking:

1. Title tags descriptivos → CTR en SERPs 2. Alt text en imágenes → Google Images SEO 3. HTML semántico → mejor entendimiento del contenido 4. Schema markup → rich snippets 5. Velocidad (relacionada) → Core Web Vitals 6. Mobile-friendly → mobile-first indexing 7. Video transcripts → contenido indexable

Caso real: cliente refactorizó su web con HTML semántico + alt + ARIA correcto. Tráfico orgánico +35% en 3 meses sin ningún otro cambio SEO. Google premia accesibilidad.

Plan de implementación: 30-60-90 días

Semana 1-2: auditoría inicial

15. [ ] Lighthouse + axe + WAVE en home y páginas top
16. [ ] Test con teclado (sin ratón)
17. [ ] Test con NVDA/VoiceOver en 3 páginas
18. [ ] Checklist de los 60 puntos
19. [ ] Lista priorizada de issues

Semana 3-6: fixes críticos (P0)

20. [ ] Contraste de color (1-2 días)
21. [ ] Alt text en todas las imágenes (1-2 días)
22. [ ] Formularios con labels y errores (1 día)
23. [ ] Focus visible (1-2 horas de CSS)
24. [ ] Skip navigation link (1-2 horas)
25. [ ] Lang en HTML (5 minutos)

Semana 7-10: fixes importantes (P1)

26. [ ] Headings jerárquicos
27. [ ] Botones con HTML semántico
28. [ ] ARIA en componentes custom
29. [ ] Navegación por teclado completa
30. [ ] Contraste en todos los componentes

Semana 11-12: validación final (P2)

31. [ ] Auditoría con herramienta externa (UserWay, AccessiBe, etc.)
32. [ ] Test con usuarios reales con discapacidad (5-10 usuarios)
33. [ ] Documentar accesibilidad en tu CMS (guía para editores)
34. [ ] Auditoría periódica (mensual)

Herramientas de remediación automática (con cuidado)

Algunas herramientas que prometen "AA en 1 click":

35. UserWay: widget de accesibilidad con AI. Cumple parcialmente pero NO WCAG AA completo.
36. AccessiBe: similar. Marketing agresivo, accesibilidad cuestionada.
37. AccessiCart: para eCommerce (Shopify/WooCommerce).
38. WP Accessibility: plugin WordPress que ayuda con issues básicos.

Mi opinión honesta: estas herramientas ayudan pero NO sustituyen el trabajo manual. Si dependes solo de un widget, NO cumples AA real. Son complemento, no solución.

Conclusión: accesibilidad es SEO + legal + ético

Cumplir WCAG 2.1 AA en 2026 no es opcional por:

39. Legal (multas EAA)
40. SEO (Google premia webs accesibles)
41. Negocios (15-20% más audiencia)
42. Ética (la web debe ser para todos)

Empieza con los 15 puntos críticos (los P0 del checklist). En 2-4 semanas puedes pasar de 40% a 95% AA. Y los beneficios en SEO y conversión se ven en 3-6 meses.

¿Necesitas ayuda con la accesibilidad de tu web? Escríbeme a hola@mjora.studio — primera consulta gratuita de 30 min.

---

Lee el diseño web para PYMEs 2026, el WordPress vs web a medida 2026 o la guía completa de CRO para eCommerce.