El testing de accesibilidad es uno de los temas que más está creciendo en el mundo del QA en 2026. La nueva normativa europea de accesibilidad hace obligatorio que las aplicaciones web sean accesibles para personas con discapacidad, y eso convierte al QA Engineer en una pieza clave para garantizar el cumplimiento.
En este artículo te explico qué es, por qué importa y cómo empezar a hacerlo.
Qué es la accesibilidad web
La accesibilidad web significa que las aplicaciones y sitios web pueden ser usados por cualquier persona, independientemente de sus capacidades físicas, cognitivas o sensoriales.
Esto incluye personas con discapacidad visual que usan lectores de pantalla, personas con discapacidad motriz que navegan solo con teclado, personas con daltonismo que no distinguen ciertos colores, personas con discapacidad auditiva que necesitan subtítulos en los vídeos y personas con dificultades cognitivas que necesitan interfaces claras y predecibles.
Por qué es obligatorio en 2026
La Directiva Europea de Accesibilidad Web y la Ley Española de Accesibilidad obligan a las administraciones públicas y a las empresas privadas que ofrecen servicios esenciales a garantizar que sus aplicaciones sean accesibles.
En 2026 estas obligaciones se han extendido significativamente. Las empresas que no cumplan pueden enfrentarse a sanciones y los QA Engineers que entienden de accesibilidad son cada vez más demandados en el mercado laboral.
Los estándares WCAG
Las Web Content Accessibility Guidelines — WCAG — son el estándar internacional de referencia para la accesibilidad web. Están organizadas en cuatro principios:
Perceptible — la información debe poder percibirse por todos los usuarios. Ejemplo: las imágenes deben tener texto alternativo para que los lectores de pantalla las describan.
Operable — la interfaz debe poder operarse de diferentes formas. Ejemplo: toda la funcionalidad debe poder usarse solo con teclado, sin ratón.
Comprensible — el contenido y la interfaz deben ser fáciles de entender. Ejemplo: los errores de formulario deben explicar claramente qué hay que corregir.
Robusto — el contenido debe ser interpretable por tecnologías asistivas. Ejemplo: el HTML debe ser semánticamente correcto para que los lectores de pantalla lo interpreten bien.
Las WCAG tienen tres niveles de conformidad — A, AA y AAA. El nivel AA es el requerido por la normativa europea.
Cómo hacer testing de accesibilidad
Testing manual con teclado
La prueba más básica y efectiva es navegar la aplicación completamente con el teclado, sin usar el ratón. Usa Tab para moverte entre elementos, Enter para activarlos y las flechas para navegar dentro de componentes como menús y listas.
Si hay alguna funcionalidad que no puedes usar solo con teclado, hay un fallo de accesibilidad.
Testing con lectores de pantalla
Los lectores de pantalla convierten el texto de la pantalla en voz o en braille para personas con discapacidad visual.
NVDA es gratuito y el más usado en Windows. VoiceOver viene incluido en macOS y iOS. TalkBack viene incluido en Android.
Navega tu aplicación con el lector de pantalla activado y verifica que toda la información importante se anuncia correctamente.
Testing del contraste de colores
Las WCAG requieren una relación de contraste mínima entre el texto y su fondo. El nivel AA requiere 4.5:1 para texto normal y 3:1 para texto grande.
Herramientas gratuitas como el Colour Contrast Checker o el DevTools de Chrome permiten verificar el contraste de cualquier elemento.
Herramientas de testing de accesibilidad automatizado
axe-core
axe-core es la librería de testing de accesibilidad más usada del mundo. Analiza el DOM de la página y detecta automáticamente violaciones de accesibilidad.
Para usarla con Playwright en Python:
bash
pip install axe-playwright-python
python
from playwright.sync_api import Page
from axe_playwright_python.sync_playwright import Axe
def test_accesibilidad_home(page: Page):
page.goto("https://miweb.com")
axe = Axe()
results = axe.run(page)
# Verificar que no hay violaciones críticas
violations = results.response["violations"]
assert len(violations) == 0, f"Se encontraron {len(violations)} violaciones de accesibilidad"
Lighthouse
Lighthouse es la herramienta de auditoría de Google integrada en Chrome DevTools. Genera un reporte completo de accesibilidad con puntuación y recomendaciones específicas.
Para ejecutarlo abre Chrome DevTools, ve a la pestaña Lighthouse y ejecuta una auditoría de accesibilidad en tu aplicación.
WAVE
WAVE es una extensión del navegador que visualiza directamente sobre la página los problemas de accesibilidad que encuentra — errores, alertas y elementos estructurales.
Los errores de accesibilidad más comunes
Los fallos de accesibilidad más frecuentes que encontrarás en testing son imágenes sin atributo alt, formularios sin labels asociados a los campos, botones sin texto descriptivo, contraste de color insuficiente, contenido que no puede operarse con teclado y páginas sin estructura de encabezados lógica.
Cómo integrar el testing de accesibilidad en tu flujo de trabajo
La forma más efectiva es integrar axe-core en tu suite de tests de Playwright para que las violaciones de accesibilidad se detecten automáticamente en cada ejecución de CI/CD. Así ningún cambio que introduzca un fallo de accesibilidad puede llegar a producción sin que el equipo lo sepa.
Complementa la automatización con testing manual periódico con teclado y lector de pantalla, porque hay aspectos de la experiencia de usuario que las herramientas automáticas no pueden evaluar.
Si quieres saber más sobre testing con Playwright puedes leer cómo usar locators en Playwright o cómo hacer cross-browser testing.
Y si necesitas ayuda para implementar testing de accesibilidad en tu proyecto puedes ver mis servicios en fatimaqa.com.
