Diseño de tests de componentes que tienen en cuenta la accesibilidad

Los requisitos de accesibilidad se deberían tener en cuenta durante las pruebas de componentes web. Si bien plugins de frameworks de testing como chai-a11y-axe ermiten comprobar una API para revisar que funcionan, el diseño de pruebas de componentes que tienen en cuenta la accesibilidad puede ayudar aún más ofreciendo todos los elementos semánticos que los lectores de pantalla y otras tecnologías de accesibilidad requieren. Primero, en lugar de usar test-ids o clases para encontrar y seleccionar elementos que se quieren validar, se usa el principio de identificar elementos usando roles ARIA u otros atributos semánticos que usan las tecnologías de accesibilidad. Algunas librerías de pruebas como Testing Library, incluso lo recomiendan en su documentación. Segundo, no hay que limitarse solo a probar interacciones de click; sino también considerar a las personas que no pueden usar el ratón o ver la pantalla, así como añadir pruebas adicionales para el teclado y otras interacciones. La técnica descrita está muy establecida entre nuestros equipos y deberíamos de haberla puesto en el área de Trial hace tiempo.

Uno de los muchos lugares en el proceso de entrega de software para considerar los requisitos de accesibilidad desde el principio, es al probar componentes web. Plugins de frameworks para pruebas como chai-a11y-axe proveen aserciones en sus API para verificar los conceptos básicos. Pero además de usar lo que ofrecen los frameworks de pruebas, el diseño de pruebas de componentes conscientes de la accesibilidad ayuda aún más a proporcionar todos los elementos semánticos que necesitan los lectores de pantalla y otras tecnologías de asistencia.

Primeramente, en lugar de usar ID de prueba o clases para encontrar y seleccionar los elementos que desea validar, use un principio de identificacion de elementos por roles ARIA u otros atributos semanticos que son usados por las tecnologias de asistencia. Algunas librerias de pruebas, como Testing Library, incluso recomiendan esto en su documentación. En segundo lugar, no solo pruebe las interacciones con click; también considere a los usuarios que no pueden usar un ratón, o ver la pantalla, y considere agregar pruebas adicionales para el teclado y otras interacciones.