Web Accessibility Best Practices

En Evinced, llevamos a cabo una misión para hacer la web más accesible para todos. Aproximadamente una de cada seis personas en todo el mundo vive con discapacidades significativas, y en los EE. UU.

, esta cifra aumenta a más de una de cada cuatro. Estas discapacidades incluyen visión, audición, movilidad, cognición y más.

En nuestra era digital, donde compramos en línea, trabajamos en línea y nos desplazamos sin fin hasta dormirnos, es nuestro deber como desarrolladores asegurarnos de no excluir a un segmento tan sustancial de la población global. Además, este grupo representa una porción significativa de nuestro público objetivo de negocios. Esto podría sonar obvio. A todos les gustaría hacer sus aplicaciones accesibles, entonces ¿por qué son tan comunes los problemas de accesibilidad? Ejecuté el escáner del sitio de Evinced en 1,000 páginas del sitio web de una empresa Fortune 500. Esto es solo una muestra de los problemas que se encontraron, y había miles de violaciones de accesibilidad. Por ejemplo, 800 elementos solo podían ser accedidos por usuarios que pueden operar un ratón, excluyendo a usuarios que solo usan teclado y a muchos usuarios de tecnología asistiva. 1,800 elementos carecían de nombres accesibles, que son críticos para los lectores de pantalla. De hecho, en 2016, Domino's Pizza fue demandada por un hombre ciego llamado Guillermo Robles porque no podía pedir una pizza en su sitio, ya que no etiquetaron elementos clave. 1,100 elementos carecían de la semántica requerida, haciendo imposible que la tecnología asistiva interactuara con ellos, y así sucesivamente.

Lo interesante de esto es que estas empresas claramente estaban intentando construir sitios accesibles. De lo contrario, ni siquiera habrían usado atributos ARIA, cuyo propósito es mejorar la accesibilidad. Y sin embargo, es un ejemplo perfecto de cómo las intenciones no siempre conducen a resultados en accesibilidad.

Hoy, voy a hablar sobre un enfoque para codificar de manera accesible, que creo puede prevenir que este tipo de defectos lleguen a producción. Pero antes de hacer eso, permítanme presentarme rápidamente. Soy Daniel Gorin, un investigador apasionado dedicado a refinar procesos caóticos. Y ese soy yo en la foto, tratando de descifrar el contenido de un frasco en mi Airbnb. He estado trabajando durante los últimos seis años como investigador, y actualmente lidero el equipo de tecnologías de análisis en Evinst, donde nos enfocamos en desarrollar capacidades innovadoras para el análisis de accesibilidad.

Evinst es una empresa de software que construye herramientas para desarrolladores, diseñadores y otros profesionales que participan en el ciclo de vida del desarrollo de productos. Les ayudamos a hacer que sus sitios y aplicaciones móviles sean accesibles para todos, donde nuestro enfoque está en ayudar a nuestros usuarios a detectar y prevenir violaciones de accesibilidad lo antes posible. En esta charla, exploraremos el concepto de accesibilidad a través del desarrollo guiado por pruebas. Comenzaremos entendiendo qué es y cómo se aplica en el desarrollo front-end. Nos adentraremos en las complejidades de elegir el patrón correcto. Hay más de lo que parece a simple vista. Y finalmente, abordaremos los desafíos de frente, proporcionándoles herramientas y ejemplos para ayudar a comenzar.

TDD fue redescubierto en 2002 por Kent Beck. En sus propias palabras, la descripción original de TDD estaba en un libro antiguo sobre programación. Decía, tomas la cinta de entrada, escribes manualmente la cinta de salida que esperas, luego programas hasta que la salida real coincida con la salida esperada. Así que podemos pensar en ello como un enfoque atemporal para la ingeniería de software. Al escribir pruebas antes del código, TDD fomenta un mejor diseño, alienta un código más simple y ayuda a los desarrolladores a detectar defectos temprano en el ciclo de desarrollo. Este método proactivo no solo mejora la calidad del código, sino que también mejora la mantenibilidad, y facilita la refactorización. Ahora, podemos comenzar nuestro viaje con una prueba unitaria.

Y las pruebas unitarias no son solo para el código aplicativo. Ya se utilizan extensamente en el código front-end, especialmente al construir componentes. En esta diapositiva, demostraré las pruebas unitarias en React, usando VTest con JS DOM como el entorno del navegador. JS DOM es una herramienta increíblemente útil para probar aplicaciones web. Es una implementación parcial de un navegador web en puro JavaScript. Su principal ventaja es la velocidad, ya que omite el trabajo pesado de renderizado visual, cosas como calcular estilos y diseños, y en su lugar se enfoca en simular APIs del DOM como Document o Window, haciéndolo ideal para probar lógica e interacciones. En esta prueba unitaria, renderizo un componente Button, que espera recibir un oyente de clic. En este caso, se supone que el oyente de clic solo debe cambiar el valor de una variable llamada click de false a true.

Después de renderizar el Button, lo encuentro en la página y simulo un clic en él. Luego verifico que la variable click realmente haya cambiado a true. De manera similar, podemos escribir pruebas unitarias para asegurar que nuestras aplicaciones cumplan con los requisitos de accesibilidad. Podemos validar que nuestros componentes se ajusten a los estándares más ampliamente aceptados para accesibilidad, el WCAG y la ARIA Authoring Practices Guide de la organización W3C. Podemos asegurar que sean completamente operables por teclado y lectores de pantalla. Podemos obtener retroalimentación ultrarrápida incluso a gran escala. Esto se logra a través del poder de JSDOM, que mencioné antes. Sin embargo, es importante reconocer que una gran velocidad viene con ciertas limitaciones. La herramienta tiene capacidades restringidas para pruebas de accesibilidad visual, como evaluar un contraste de color suficiente o la indicación de enfoque. Además, la efectividad de estas pruebas depende en gran medida del conocimiento y la experiencia de la persona que las realiza.

Genial. Ahora que hemos cubierto los beneficios y limitaciones de ATDD, pongámoslo en práctica y construyamos un componente Toggle accesible. Pero lo primero que necesitamos entender es qué es realmente un componente Toggle. Por ejemplo, un switch o un botón Toggle son ideales para un elemento de control que toma efecto inmediatamente, proporcionando una retroalimentación clara y en tiempo real sobre elecciones o acciones binarias. En contraste, un checkbox se utiliza típicamente en formularios para marcar una selección o los cambios toman efecto una vez que el formulario es enviado. Elegir el patrón de escritura correcto es crucial para crear una experiencia accesible y amigable para el usuario. Piénsalo como un contrato con tus usuarios. La apariencia del componente debe indicar cómo debe ser usado y cuál sería su efecto. Así como esperas que los usuarios neurotípicos entiendan cómo interactuar con tu componente, cada patrón tiene semánticas de accesibilidad específicas, para que los usuarios de tecnologías asistivas puedan hacer lo mismo. Como desarrolladores, tenemos la obligación de desafiar los requisitos del producto para que sean tan precisos como puedan ser, desde el principio, para proteger nuestro valioso tiempo. Para ayudarte a familiarizarte con los patrones comúnmente usados y sus requisitos de accesibilidad, he añadido enlaces a las guías, especificaciones y blogs más populares para diseñar y desarrollar patrones de UI accesibles, para móvil y web. Quiero sumergirme en uno de los tutoriales más útiles. El APG sirve como un excelente punto de referencia para que las organizaciones seleccionen, definan, prueben y refinen la accesibilidad de sus componentes. Proporciona ejemplos prácticos y guías para implementar componentes de UI accesibles con ARIA, los Atributos de Soporte de Accesibilidad para Elementos Web. Ayuda a los desarrolladores a entender las interacciones, estados y propiedades requeridas para varios patrones. Aunque tiene sus inconvenientes, como pasar por alto el HTML semántico en favor de ARIA, sigue siendo nuestro mejor punto de referencia hasta ahora. Además, como un proyecto de código abierto, puedes contribuir a su mejora. Por ejemplo, cuando abres la entrada del componente button, encontrarás un breve resumen del patrón, junto con los requisitos de accesibilidad tanto para teclado como para lector de pantalla, así como implementaciones de ejemplo. De estas fuentes, he extraído los requisitos de accesibilidad para botones toggle. Con una lectura bastante corta y enfocada, puedes hacer lo mismo.

Para probar estos requisitos, podemos aprovechar las excelentes utilidades de código abierto creadas por Testing Library. Un gran reconocimiento para ellos. Están trabajando arduamente para hacer que las pruebas de accesibilidad sean simples. Así que comencemos.

No importa si estoy usando componentes que he construido yo mismo, aprovechando implementaciones de código abierto o incluso si aún no he escrito ningún código. Para asegurar la accesibilidad, puedo comenzar escribiendo mi primera prueba. Estoy construyendo un botón toggle, así que quiero asegurarme de que tenga un rol de button. Estoy usando la función getByRole de Testing Library para localizar el button. La prueba ya fallará si no se encuentra el button, pero como paso adicional, uso el Expectation Matcher para estar en el documento, para asegurarme de que el button ha sido renderizado en el documento JS DOM. Ahora los lectores de pantalla podrán determinar que esto es de hecho un button.

Pasando a nuestra segunda prueba. Un button debe tener un nombre accesible, para que los usuarios de lectores de pantalla puedan entender su función. Es fácil olvidarlo con un button de icono. Esto permitirá a los lectores de pantalla narrar algo significativo cuando lleguen al button. En esta prueba, estoy renderizando el button como antes, y usando getByRole para encontrarlo. Luego, estoy usando el Expectation Matcher para tener nombre accesible, con el fin de asegurar que el button tiene un nombre, incluyendo la palabra PAUSE, que corresponde al icono que estoy usando. Para mostrarte lo poderoso que es este Expectation Matcher, creé un ejemplo de una prueba que intenta verificar los atributos que componen el nombre accesible, como el contenido de texto o el atributo aria-label. Es largo, difícil de leer, y solo captura parcialmente el nombre final. El matcher para tener nombre accesible es una solución elegante y mucho más simple.

Para nuestra próxima prueba, nos aseguraremos de que el button sea accesible a través de presiones de tab. Esto es crucial para los usuarios que tienen dificultad para usar un mouse, permitiéndoles alcanzar e interactuar con el button. Imagina un caso donde un usuario de teclado no puede alcanzar un diálogo de consentimiento de cookies, haciéndolo imposible para ellos usar todo el sitio. Esta es una oportunidad perfecta para mostrar interacciones de usuario simuladas. Usaré la biblioteca UserEvent para simular un evento de tab. Mi button debería recibir foco, ya que es el único elemento en la página, así que puedo esperar que tenga foco. Aunque es posible probar esto estáticamente, verificando un atributo de tab index o una etiqueta que coloque el button en la secuencia de enfoque, disparar un evento es un enfoque mucho más seguro, ya que los event listeners de JavaScript podrían interferir con el orden normal de enfoque. Este enfoque ATDD me permite crear continuamente pruebas que aseguren el cumplimiento de cada requisito de accesibilidad. Estas pruebas sirven como mi red de seguridad, proporcionando pautas y confianza mientras modifico componentes, agrego nuevas características o refactorizo la base de código. Ahora puedo comenzar a crear mi botón toggle. Desarrollando hasta que todas las pruebas pasen, dándome confianza de que el componente está de hecho completo.

Añadiría un atributo de rol de Button, aseguraría que se proporcione la propiedad label y establecería el atributo tab index en 0. Puedo confiar en que las violaciones de accesibilidad no volverán a afectarme dentro de meses, mientras edito mi componente o agrego nuevas características.

Por supuesto, todavía hay un problema evidente aquí. Incluso los desarrolladores front-end más capacitados pueden no saber siempre qué requisito de accesibilidad probar para cada componente que construyen. Aunque un button es relativamente simple, el verdadero valor de las pruebas unitarias surge con componentes más complejos. Estos incluyen la gestión del enfoque en componentes compuestos como grupos de radio, ocultar el fondo inerte de las tecnologías de asistencia en superposiciones, y ni siquiera comencemos con los carruseles.

Además, crear una suite completa de pruebas es una tarea que consume mucho tiempo y que a menudo se deja de lado en favor del desarrollo real de componentes. Para abordar esto y realmente facilitar las pruebas de accesibilidad, en Advanced hemos desarrollado un SDK llamado Unit Tester. Automatiza la creación de pruebas de accesibilidad para los desarrolladores. Simplemente llamas a una función, como AnalyzeToggleButton, y el SDK se encarga de todo, encontrando el requisito correcto para ese patrón, asegurando que tu código soporte el lector de pantalla y la operación del teclado.

Obtienes el informe de accesibilidad instantáneamente en el IDE, asegurando que el componente sea accesible incluso antes de llegar a QA. Y actualmente, soportamos más de 25 patrones de componentes diferentes.