MSSM
Volver al blog
AccesibilidadMSSM

Cómo auditamos mssm.es para cumplir la EAA: de 95/100 a 100/100 con datos verificados

Caso de estudio técnico: auditoría completa de mssm.es con axe-core 4.13, decisiones de diseño WCAG 2.1 AA, y por qué no afirmamos WCAG 2.2 AA sin herramienta capaz.

  • wcag
  • eaa
  • axe-core
  • accesibilidad
  • diseno-web

La European Accessibility Act (EAA) entró en vigor el 28 de junio de 2025. En España se transpuso mediante el Real Decreto 193/2023 (BOE-A-2023-7417). Las sanciones pueden llegar al 6 % de la facturación o 15 M €, lo que convierte el cumplimiento en una prioridad real para cualquier producto digital con clientes en la UE.

En MSSM no solo vendemos accesibilidad: la aplicamos a nuestra propia web. Este post documenta exactamente cómo auditamos mssm.es, qué problemas encontramos y cómo los resolvimos.

Qué exige la ley realmente (España, 2026)

La cadena normativa es:

  1. Directiva (UE) 2019/882 — marco europeo.
  2. Real Decreto 193/2023 — transposición española (BOE 22/03/2023).
  3. RD 1112/2018 — accesibilidad del sector público (referencia para productos privados).
  4. UNE-EN 301 549:2022 V3.2.1 — norma armonizada que cita WCAG 2.1 AA.
  5. Commission Implementing Decision (EU) 2021/1339 — referencia oficial.

El estándar legal exigible en España hoy es WCAG 2.1 AA. WCAG 2.2 existe como publicación técnica del W3C (octubre 2023) pero no está armonizado en el OJEU — no podemos afirmarlo como cumplimiento legal sin auditoría específica con herramienta capaz.

Solo afirmamos lo que hemos verificado. Por eso decimos "WCAG 2.1 AA", no "WCAG 2.2".

Metodología: axe-core + auditoría manual

Usamos axe-core 4.13.0 corriendo en headless Chromium contra cada ruta de mssm.es. La configuración activa reglas wcag2a, wcag2aa, wcag21a, wcag21aa y best-practice. Cada ruta se audita en light y dark mode.

Limitación importante: axe-core audita automáticamente WCAG 2.1 AA, pero no WCAG 2.2 AA (cobertura parcial). Tampoco cubre:

  • Navegación completa por teclado (manual).
  • Gestión de focus en iframes y shadow DOM.
  • Contenido dinámico con JavaScript asíncrono.
  • Compatibilidad con lectores de pantalla (manual).

Para auditoría 2.2 completa y manual harían falta herramientas premium (Axe Pro, Equal Access, AccessScan Pro) o un auditor humano certificado.

Resultados: 24/24 rutas en 0 violaciones

Auditamos 24 rutas (públicas, privadas y dashboard) en light y dark mode donde aplica.

Categoría Rutas Resultado
Marketing /, /por-que-mssm, /planes, /servicios 0/0 ✓
Autenticación /login 0/0 ✓
Legal /aviso-legal, /privacidad, /cookies 0/0 ✓
Dashboard /dashboard + 12 sub-rutas 0/0 ✓

Punto de partida: 16 violaciones de color-contrast en la home, 11 en /servicios, 22 en /dashboard/integrations-guide. Todas resueltas sin workarounds locales: cambios globales de tokens cuando el bug afectaba a varias páginas, ajustes específicos cuando era un caso aislado.

El bug más importante: el color --primary global

El --primary original era teal #0d9488 con ratio 3.58:1 sobre fondo claro. Falla WCAG 2.1 AA (mínimo 4.5:1 para texto normal). El bug afectaba a todas las páginas: botones, badges, enlaces, KPI labels.

Lo cambiamos a #0f766e (5.24:1, AA) y #115e59 para hover (7.26:1, AAA). El cambio fue global en app/globals.css para mantener coherencia con la regla de hierro del proyecto: no patches locales para problemas globales.

:root {
  --primary: #0f766e;        /* 5.24:1 AA sobre fondo claro */
  --primary-hover: #115e59;  /* 7.26:1 AAA */
  --ring: #0f766e;
}

El dark mode ya pasaba (#2dd4bf sobre #0c0a09 = 5.34:1, AA).

Tres lecciones aprendidas

1. axe-core marca color contrast también para elementos decorativos

Los números "01-04" decorativos del home con text-primary/20 (ratio 1.31:1) fallaban aunque fueran visualmente decorativos. WCAG 1.4.3 no aplica a texto decorativo, pero axe marca contraste del píxel computed independientemente. Solución: subir opacity a text-primary/80 (3.62:1, pasa AA no-text) + aria-hidden="true" para excluirlo del árbol de accesibilidad.

2. Los badges "tinted" engañan al ojo

Badges tipo bg-accent/10 text-accent se ven legibles en la pantalla, pero el ratio real ronda 2.5-3.5:1 — falla AA. La mezcla de bg-accent/10 con text-accent produce un color final con poco contraste. Cambiamos a text-foreground sobre el bg tintado: ratio 17:1. El tinte visual del bg sigue dando semántica (amber = estado pendiente), pero la legibilidad queda garantizada.

3. axe-core y skip-links son estrictos

Un <a href="#main-content"> con target ausente falla. El target debe ser focusable: <main id="main-content" tabIndex={-1}> con tabindex="-1" lo hace programáticamente enfocable sin entrar en el flujo de tabulación. Sin ese tabindex, axe marca skip-link y region (porque el contenido no está en landmark alcanzable).

Qué NO audita axe-core (y por qué no afirmamos 2.2)

  • 2.4.11 Focus Not Obscured (WCAG 2.2) — axe 4.13 no lo implementa completamente.
  • 2.4.12 Focus Appearance (WCAG 2.2) — parcialmente.
  • 2.5.7 Dragging Movements (WCAG 2.2) — no implementado.
  • 2.4.13 Focus Appearance (Enhanced) (WCAG 2.2 AAA) — no.

Por eso afirmamos 2.1 AA, no 2.2 AA, aunque WCAG 2.2 es en gran parte superset de 2.1 y es probable que cumplamos. Decir "cumplimos 2.2" sin haberlo auditado es marketing engañoso. Lo correcto: auditar primero, decir después.

Próximo paso: auditoría 2.2 con herramienta premium

Para afirmar WCAG 2.2 AA completo, MSSM evalúa incorporar Equal Access (IBM) o Axe Pro. Coste estimado: USD 100-500/año para una web SaaS. ROI: poder afirmar legalmente "cumple también 2.2 AA" en copy de marketing, y detectar regressions que axe-core ignora.

Si eres una agencia española y necesitas este mismo nivel de rigor en tu sitio, escríbenos: hola@mssm.es. Hacemos el audit completo, no vendemos humo.

Auditoría realizada el 10 de agosto de 2026 con axe-core 4.13.0. Cita legal verificable en BOE-A-2023-7417 y Commission Implementing Decision (EU) 2021/1339.