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

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):

<!-- BIEN --> <img src="tienda.jpg" alt="Tienda de artesanía local con productos de madera"> <img src="logo.png" alt="Logo de MJora Studio"></p><p><!-- MAL --> <img src="tienda.jpg" alt="image1"> <img src="logo.png" alt="">  <!-- sin alt = screen reader lo ignora -->

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 pixeles; 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 <div> 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:

/* MAL - NUNCA hagas esto */ *:focus { outline: none; } button:focus { outline: 0; }</p><p>/* 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:

<body>   <a href="#main-content" class="skip-link">     Saltar al contenido principal   </a>   <header>...</header>   <main id="main-content">     <!-- contenido real -->   </main> </body>

.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)

<title>CRO para eCommerce: guía completa | MJora</title> <!-- NO --> <title>Inicio</title> <title>Blog</title>

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 lang="es-ES"> <!-- NO --> <html>  <!-- sin lang = screen reader asume inglés -->

3.2 Idioma de partes (3.1.2)

<p>La palabra <span lang="en">responsive</span> significa...</p>

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

<!-- MAL --> <input type="email" required> <span>Error</span></p><p><!-- BIEN --> <input type="email" required aria-describedby="email-error" aria-invalid="true"> <span id="email-error" role="alert">   Email inválido. Usa el formato nombre@dominio.com </span>

3.5 Labels o instrucciones (3.3.2)

<!-- MAL --> <input type="text" placeholder="Tu nombre"></p><p><!-- BIEN --> <label for="name">Tu nombre</label> <input type="text" id="name" name="name">

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)

<!-- BIEN - semántico --> <header>...</header> <nav>...</nav> <main>...</main> <article>...</article> <aside>...</aside> <footer>...</footer> <h1>Solo un h1 por página</h1> <button>Acción</button></p><p><!-- MAL - todo es div --> <div class="header">...</div> <div class="nav">...</div> <div onclick="...">Click</div>

4.2 Name, role, value (4.1.2)

Para componentes custom, usar ARIA:

<!-- Botón custom --> <div role="button" tabindex="0" aria-pressed="false" onclick="toggle()">   Activar </div></p><p><!-- Mejor: usar HTML real --> <button aria-pressed="false" onclick="toggle()">   Activar </button>

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
  /
• [ ] Tablas con
  • [ ] Sin role inválidos
  • [ ] aria-expanded en acordeones
  • [ ] aria-controls en modales
  • [ ] 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"

  • Checkboxes sin label asociado
  • Formularios sin error message accesibles
  • Submit que no anuncia el resultado a screen readers

  ❌ "Hemos hecho responsive pero no mobile-first"

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

  ❌ "Hemos añadido ARIA a todo"

  • role="button" en un <button> (redundante)
  • ARIA inválida (peor que no tenerla)
  • 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"

  <!-- MAL: alt describe la imagen decorativa --> <div class="hero-bg">   <img src="background.jpg" alt="Fondo abstracto con líneas rojas"> </div></p><p><!-- BIEN: alt="" para decorativas --> <div class="hero-bg">   <img src="background.jpg" alt="" role="presentation"> </div>

  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

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

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

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

  Semana 7-10: fixes importantes (P1)

  • [ ] Headings jerárquicos
  • [ ] Botones con HTML semántico
  • [ ] ARIA en componentes custom
  • [ ] Navegación por teclado completa
  • [ ] Contraste en todos los componentes

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

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

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

  Algunas herramientas que prometen "AA en 1 click":

  • UserWay: widget de accesibilidad con AI. Cumple parcialmente pero NO WCAG AA completo.
  • AccessiBe: similar. Marketing agresivo, accesibilidad cuestionada.
  • AccessiCart: para eCommerce (Shopify/WooCommerce).
  • 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:

  • Legal (multas EAA)
  • SEO (Google premia webs accesibles)
  • Negocios (15-20% más audiencia)
  • É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.