Si quieres un producto accesible, tu mejor amigo no es una auditoría de último minuto. Es tu estrategia de testing — y si tus tests reflejan cómo los usuarios reales experimentan tu producto.
La accesibilidad real no es solo arreglar problemas. Es prevenirlos.
Testing Library tiene un principio de accesibilidad escondido
Kent C. Dodds y el equipo de Testing Library tienen un principio guía:
Cuanto más se parezcan tus tests a la forma en que se usa tu software, más confianza pueden darte.
La mayoría de los equipos lo leen como consejo de testing. También es un principio de accesibilidad — y esa conexión es lo que la mayoría de los equipos no ve.
Una pregunta diferente
Testing Library no es solo una API diferente. Es una pregunta diferente.
Los tests viejos preguntaban:
¿Esto se renderizó correctamente?
Los tests con Testing Library preguntan:
¿El usuario realmente puede usar esto?
Ese cambio cambia lo que los tests detectan.
Por qué los tests de integración cargan más peso
Kent C. Dodds también defiende el Testing Trophy — una contrapropuesta a la vieja Pirámide de Testing. La pirámide ponía los tests unitarios en la base; el trofeo pone los tests de integración en el centro.
Ese cambio de pesos importa para la accesibilidad.
Un test unitario de una función de validación de formularios te dice que la función funciona. Un test de integración del formulario te dice que el formulario funciona — que los inputs tienen labels, el botón de submit tiene un nombre, los mensajes de error se anuncian, el foco se mueve a donde debe.
La superficie de accesibilidad vive en la integración, no en las unidades.
Cuanto más se incline tu suite hacia la integración, más regresiones de accesibilidad atrapa antes de llegar a producción.
Por qué eso atrapa problemas de accesibilidad
Testing Library consulta los elementos de la misma forma que lo hace la tecnología asistiva — por rol, por nombre accesible, por etiqueta. Un botón sin nombre no tiene getByRole('button', { name: /continue/i }) al cual conectarse. El test no puede encontrarlo. El test falla.
Ese es el mecanismo de prevención. No es un checklist. No es una auditoría. La regresión de accesibilidad se detecta en el mismo paso en que se detecta cualquier otra regresión — cuando el test se rompe.
Si tu UI es difícil de testear, probablemente es difícil de usar
Si no puedes escribir screen.getByRole('button', { name: /continue/i }) limpiamente, algo está mal. Tal vez el botón no es semántico, el nombre es poco claro, la intención no es obvia, o la UI depende demasiado de lo visual.
Eso no es solo un problema de testing. Es un problema de producto.
Si tu test puede comprar el producto, tus usuarios probablemente también
Si tu test puede comprar el producto, tus usuarios probablemente también.
Si tu test puede encontrar un producto, entenderlo, agregarlo al carrito y completar el flujo, estás más cerca de una experiencia usable de lo que cualquier auditoría podría verificar. Si no puede, presta atención — esa fricción es real, y tus usuarios la están sintiendo.
Cómo se ve la prevención de verdad
Testing Library no hará que tu producto sea accesible por sí solo. No reemplaza el testing con lector de pantalla, el testing con teclado, ni el juicio humano.
Pero cambia dónde sucede el trabajo. Los problemas que antes salían en auditorías empiezan a salir en pull requests. Los problemas que antes salían en pull requests dejan de lanzarse.
La auditoría detecta problemas. El PR detecta más. El test nunca los deja entrar.