Desde el 28 de junio de 2025, probar la accesibilidad de una web dejó de ser un "estaría bien hacerlo" para convertirse en una obligación legal en España y en el resto de la Unión Europea. Y la mayoría de suites de test, checklists de QA y planes de prueba del sector todavía no la incluyen.
No es una norma nueva sin dientes. Trae sanciones económicas reales, un plazo que ya se cumplió y un alcance que va mucho más allá de las administraciones públicas: ahora afecta a la mayoría de empresas privadas que venden algo online. Si haces QA en 2026, es un criterio de aceptación más, no un extra.
En este artículo te cuento qué cambió exactamente, qué tiene que cumplir una web para pasar el corte, con qué herramientas se testea y qué parte se puede automatizar y cuál no.
Qué cambió: la ley que ahora obliga a testear accesibilidad
La base es la Ley Europea de Accesibilidad (European Accessibility Act), la directiva de la UE que amplía la obligación de accesibilidad digital más allá del sector público, donde ya existía desde hace años, y la extiende a la mayoría de empresas privadas: ecommerce, banca, transporte, telecomunicaciones y cualquier servicio digital ofrecido al público.
Fecha en la que entró en vigor la exigibilidad de la Ley Europea de Accesibilidad para el sector privado. Los productos y servicios ya en el mercado antes de esa fecha tienen de plazo hasta el 28 de junio de 2030 o su próxima actualización relevante, lo que ocurra antes.
Fuente: European Accessibility Act, calendario de cumplimiento 2025
En España, esta directiva se traspone a través del Real Decreto 193/2023, de 21 de marzo (BOE núm. 69, 22 de marzo de 2023), que regula las condiciones básicas de accesibilidad y no discriminación para el acceso y uso de bienes y servicios a disposición del público, incluyendo webs y aplicaciones móviles.
La excepción son las microempresas: menos de 10 empleados y menos de 2 millones de euros de facturación anual quedan fuera de la obligación. Si tu empresa o la de tu cliente no entra en ese umbral, la web tiene que cumplir.
Qué tiene que cumplir una web para pasar el corte
El estándar técnico de referencia son las WCAG 2.1 (Web Content Accessibility Guidelines), nivel AA, el mismo que exige la norma europea UNE-EN 301549 para el sector público y que se usa como referencia técnica en el sector privado. Se organizan en cuatro principios, conocidos por sus siglas en inglés como POUR.
La información tiene que poder percibirse de más de una forma: texto alternativo en imágenes, subtítulos en vídeo, contraste de color suficiente.
Toda la interfaz tiene que poder usarse sin ratón: solo con teclado, sin límites de tiempo imposibles, sin contenido que provoque convulsiones.
El texto y el comportamiento de la interfaz tienen que ser predecibles: idioma declarado, errores de formulario explicados, navegación consistente.
El código tiene que interpretarse bien por tecnologías de apoyo: HTML válido, roles ARIA correctos, compatibilidad con lectores de pantalla.
Cómo testear accesibilidad como QA, paso a paso
No hace falta ser experto en accesibilidad para empezar a incluirla en tu ciclo de pruebas. La mayoría de problemas graves se detectan con un flujo de tres pasos: escaneo automático, navegación por teclado y comprobación con lector de pantalla.
| Herramienta | Qué comprueba | Cuándo usarla |
|---|---|---|
| axe DevTools | Extensión de navegador, detecta contraste, alt, ARIA y estructura HTML | Revisión rápida de cualquier página, primer filtro |
| WAVE | Similar a axe, con overlay visual sobre la propia página | Alternativa a axe o segunda opinión |
| Lighthouse | Puntuación general de accesibilidad integrada en Chrome DevTools | Chequeo rápido dentro de una auditoría de rendimiento más amplia |
| NVDA / VoiceOver | Lectores de pantalla gratuitos (Windows / macOS-iOS) para navegación real | Casos de prueba manuales sobre flujos críticos: login, checkout, formularios |
| Solo teclado | Tabulador, flechas, Intro y Escape sin tocar el ratón | Comprobar que el foco es visible y que nada queda atrapado (ej. un modal) |
Las herramientas automáticas son el primer filtro, no el único. Detectan bien problemas objetivos como contraste insuficiente o imágenes sin atributo alt, pero no pueden juzgar si un texto alternativo describe bien la imagen o si el orden de tabulación tiene sentido para alguien que no ve la pantalla. Eso solo se comprueba probando de verdad.
Antes de escribir un solo caso de prueba de accesibilidad, prueba el flujo de login o de checkout de tu propia web solo con el teclado, sin tocar el ratón. En la mayoría de webs que no se han testeado nunca así, el foco desaparece en algún punto o un botón queda inalcanzable. Es el hallazgo más rápido y más convincente para justificar meter accesibilidad en el plan de pruebas.
Automatizar parte del testing de accesibilidad
Si ya tienes una suite de tests end to end, añadir una capa de accesibilidad automática es barato. La combinación más habitual es axe-core integrado en Playwright: en cada test que ya navega por la web, se lanza además un escaneo de accesibilidad y el test falla si aparece una violación.
- Abrir la extensión axe en el navegador
- Escanear página por página a mano
- Anotar los fallos en una hoja aparte
- Repetir en cada release, si te acuerdas
"El escaneo de accesibilidad corre en cada pull request junto al resto de tests, y el build falla si hay una violación nueva."
Esto no sustituye la revisión manual con lector de pantalla, pero convierte la accesibilidad en una puerta de calidad continua en vez de una auditoría puntual que se hace una vez al año y se olvida. Si ya trabajas con automatización de tests, añadir este escaneo suele ser cuestión de una tarde.
Qué pasa si no cumples
El régimen sancionador en España viene del Real Decreto Legislativo 1/2013, de 29 de noviembre (texto refundido de la Ley General de derechos de las personas con discapacidad). Según el Ministerio de Derechos Sociales, Consumo y Agenda 2030, la ley distingue tres niveles de infracción: leves (de 301 a 30.000 euros), graves (de 30.001 a 90.000 euros) y muy graves (de 90.001 hasta 1.000.000 de euros).
Más allá de la multa, el riesgo real para la mayoría de empresas es otro: quedar fuera del mercado público (la administración exige accesibilidad en sus contrataciones) y el daño de reputación si un usuario denuncia públicamente que no puede usar tu web.
La perspectiva honesta
Esto no va a convertir a todos los QA en especialistas en accesibilidad de la noche a la mañana, y tampoco hace falta. Lo que sí cambia es que ya no es opcional tenerla en el radar: un checklist de QA de 2026 sin un apartado de accesibilidad se está dejando fuera un criterio legal, no solo uno de calidad.
Si vienes del testing de una web hecha con IA, la buena noticia es que el flujo se parece: escaneo automático primero, revisión manual de los flujos críticos después. La diferencia es que aquí sí hay una ley detrás con fecha y sanción concretas.
Preguntas frecuentes
¿Todas las webs están obligadas a ser accesibles en España?
No todas. La Ley Europea de Accesibilidad exime a las microempresas: menos de 10 empleados y menos de 2 millones de euros de facturación anual. El resto de empresas que ofrecen bienes o servicios al público (ecommerce, banca, apps, webs de reservas, entre otras) sí están obligadas desde el 28 de junio de 2025.
¿Qué diferencia hay entre el Real Decreto 193/2023 y la Directiva Europea de Accesibilidad?
El Real Decreto 193/2023 (BOE núm. 69, 22 de marzo de 2023) regula en España las condiciones básicas de accesibilidad para bienes y servicios a disposición del público. La Ley Europea de Accesibilidad (European Accessibility Act) es la directiva de la UE que la origina y que fija el 28 de junio de 2025 como fecha límite de cumplimiento para el sector privado.
¿Qué herramientas se usan para testear accesibilidad web?
Las más habituales son axe DevTools y WAVE como extensiones de navegador para una revisión rápida, Lighthouse (integrado en Chrome DevTools) para una puntuación general, y lectores de pantalla como NVDA (gratuito, Windows), JAWS y VoiceOver (integrado en macOS/iOS) para probar la experiencia real de navegación sin ratón ni vista.
¿Puedo automatizar el 100% del testing de accesibilidad?
No. Las herramientas automáticas como axe-core detectan bien problemas objetivos (contraste insuficiente, imágenes sin atributo alt, etiquetas ARIA mal usadas), pero no pueden evaluar si el orden de tabulación tiene sentido, si un texto alternativo describe bien la imagen o si un lector de pantalla anuncia un formulario de forma comprensible. Eso sigue necesitando revisión manual.
¿Cuánto puede costar no cumplir la ley de accesibilidad en España?
El Real Decreto Legislativo 1/2013 distingue tres niveles según el Ministerio de Derechos Sociales, Consumo y Agenda 2030: infracciones leves (de 301 a 30.000 euros), graves (de 30.001 a 90.000 euros) y muy graves (de 90.001 hasta 1.000.000 de euros).
¿Necesito saber usar un lector de pantalla para testear accesibilidad?
No hace falta ser experto, pero sí saber navegar una web con NVDA o VoiceOver sin mirar la pantalla, además de con solo el teclado (tabulador, flechas, Intro, Escape). Es la única forma de detectar problemas que las herramientas automáticas no ven, como un foco que desaparece o un menú que no se puede cerrar sin ratón.
¿Quieres entrar al sector?
Aprende QA desde cero, con formación práctica y orientada al mercado español.