Mi Viaje de Accesibilidad: en busca de una Biblioteca de Componentes Accesibles

Hola. La primera vez que tuve una prueba de accesibilidad hace unos años, fue un éxito en un aspecto, pero un completo fracaso en el otro. Teníamos una aplicación y trabajamos muy duro para hacerla accesible, aplicando muchos parches y técnicas específicas de accesibilidad y código accesible, pero cada vez que teníamos que cambiar algo en el código, por ejemplo, un esfuerzo de rebranding, nuevos colores o una nueva interacción, la accesibilidad simplemente se quedaba atrás porque nadie se acordaba de probarla. Por eso, la mayoría de las veces estaba rota, algo así como esto. Quiero decir, el código funcionaba en cuanto a funcionalidad, pero si mirabas bajo el capó, estaba lleno de parches, lleno de trucos, no era algo de lo que estuviéramos muy orgullosos. Y no era algo que se pudiera mantener durante mucho tiempo.

Así que por eso, en mi otro proyecto, cuando comenzamos un nuevo proyecto de accesibilidad y en una empresa diferente, hicimos las cosas de manera diferente. Queríamos hacerlo accesible desde el principio y de manera mantenible. Y si estás abordando el mismo problema hoy o estás intentando hacer que tu aplicación sea accesible de una manera que dure, esta charla es para ti.

Así que déjame comenzar. Esta charla se llama mi viaje en accesibilidad, la búsqueda de una biblioteca de componentes accesibles, o como debería ser el nombre completo, mi viaje en accesibilidad, la búsqueda de una biblioteca de componentes accesibles que refleje, rediseñe y sea mantenible y testeable. Son pequeños puntos, pero son muy importantes para nosotros tener código accesible.

Así que déjame presentarme. Soy Asaf. Soy el padre de Sahr, Naziv, y he estado en el campo del desarrollo web durante más de una década en varios roles y actualmente soy el líder técnico de frontend para Avinst, una startup que se especializa en brindar a los desarrolladores excelentes herramientas de desarrollo para accesibilidad. Por ejemplo, tenemos algoritmos basados en visión por computadora y aprendizaje automático que ayudan a detectar y encontrar problemas de accesibilidad. Creamos extensiones para Chrome y otras extensiones para dispositivos móviles que ayudan a los desarrolladores y probadores a encontrar problemas en sus aplicaciones. Y desarrollamos SDK que amplían los marcos de prueba como Cypress o Selenium y les brindan complementos de accesibilidad para sus pruebas. Voy a profundizar en este último punto en breve en esta presentación.

Antes de comenzar, ¿qué es la accesibilidad? La accesibilidad se trata de inclusión. Se trata de permitir que todos entren. Permitir que todas las personas usen tu increíble aplicación. Por ejemplo, una persona con discapacidad física que no puede usar el mouse aún necesitará una forma de navegar por tu sitio web y hacer clic en tu menú desplegable y seleccionar la tercera opción que abre otro submenú, y luego seleccionar la cuarta opción desde allí. Entonces, si tienes algún tipo de navegación o interacción para los usuarios que todos tenemos en nuestras aplicaciones, quieres asegurarte de que esto también sea accesible para alguien que no puede usar el mouse. Y no es trivial. Debería serlo, pero no lo es. Entonces, lo que hacemos es evitar que este tipo de cosas salgan de nuestro código. Queremos enviar solo código que sea accesible desde el principio.

Cuando queremos hacer que nuestra propia aplicación sea accesible, pensamos en dónde deberíamos comenzar este esfuerzo. Tuvimos varias ideas. Todo provino del lado de las pruebas. Quiero decir, estas ideas son muy similares a las discusiones que tuvimos sobre las pruebas. Podemos probar el producto o probar la accesibilidad del flujo del producto. Por ejemplo, podemos cubrir el flujo de inicio de sesión, comenzar con la pantalla de inicio de sesión y luego confirmar que el cuadro de diálogo de inicio de sesión es válido, que el flujo de olvidé mi contraseña funciona y que el registro y el cierre de sesión también funcionan con el teclado y con el lector de pantalla, que es una tecnología accesible, por ejemplo. Lo mismo para el flujo de compra y el flujo de contacto de soporte. Disculpa mi voz. Tengo un poco de resfriado.

Gracias por completarlo en tu cabeza. Otra opción es ir página por página. Si vamos página por página, por ejemplo, cubramos todo el aspecto de accessibility de la página de inicio. Asegurémonos de que cada imagen en la página de inicio tenga un texto alternativo. Cada botón puede ser accesible mediante el teclado. Cada formulario tiene una etiqueta que un lector de pantalla puede decirle a la persona que está viendo el sitio web cuál es la etiqueta.

Pero hay una tercera forma que nos resulta más natural como desarrolladores. Esto es pensando en componentes porque como desarrolladores de front-end modernos tendemos a pensar en el mundo o en las aplicaciones como construidas a partir de componentes. Por ejemplo, mi sitio web está construido a partir de botones, forms, popups, etiquetas, campos de entrada, tal vez menús desplegables, cajas de selección, casillas de verificación. Estamos haciendo composición, estamos tomando este componente y ese componente y los ensamblamos forms, o ensamblamos gráficos o ensamblamos páginas. Tengamos una gran tabla y un menú y algunos campos de texto. Y como empresa de accesibilidad, queríamos asegurarnos de que nuestra propia aplicación sea accesible y decidimos comenzar desde el nivel de componente. Quiero decir, los flujos son una forma válida. Ensamblar páginas, pero los componentes nos encantan. Y esta es la receta que nos funciona cuando creamos nuestra propia biblioteca de componentes accesibles.

Entonces, el primer paso es descomponer la aplicación en componentes más pequeños. En nuestro caso, teníamos cuatro aplicaciones y necesitábamos identificar los componentes comunes y tal vez cambiar la API para que sea la misma para todos ellos y coincida con todos los casos de uso. Y luego los colocamos en un repositorio Git separado. Pero primero comienza identificando qué componentes son comunes a todos los proyectos. En segundo lugar, nos enfocamos en los componentes uno por uno e intentamos construirlos de la manera más accesible posible utilizando el texto HTML adecuado. Profundizaré en eso en un momento. Y en tercer lugar, automatizamos todo lo que pudimos. Estamos automatizando las pruebas funcionales y las pruebas de accessibility. Profundicemos en ello.

Entonces, la primera parte es descomponerlo en componentes más pequeños. Tomemos esta aplicación imaginaria como ejemplo. Imagina que es como un sitio web. Puedes reservar un personaje de Harry Potter, y vendrá a ti. Vendrá a tu casa, o a un lugar que desees, y te visitará por una pequeña tarifa. Es un gran sitio web.

Si encuentras el real, por favor avísame. Seguro lo usaré para el cumpleaños de mi hija. Ahora, identifiquemos algunos de los componentes aquí. Aquí, me refiero a un menú desplegable donde puedes seleccionar el personaje. También hay otro menú desplegable aquí donde puedes seleccionar la ubicación, y hay un selector de fechas. Ahora está marcado en rosa. Puedes seleccionar la fecha en la que el personaje vendrá. Y hay un botón de búsqueda, que es un botón. Y este botón, por ejemplo, puede tener un estado habilitado, un estado deshabilitado. Tiene un estado de hover. Como cuando pasas el cursor sobre él, o cuando te enfocas en él con el teclado, tal vez muestra algún tipo de tooltip. Tal vez el tooltip tenga un diseño o una apariencia específica en casos específicos. Lo mismo para el menú desplegable y el selector de fechas. Puede ser un componente bastante complejo.

Ahora, después de identificar estos componentes, los estamos separando de nuestros repositorios, de nuestros repositorios de productos, a un repositorio común, cuyo único propósito es ser un repositorio designado para estos componentes. En nuestro caso, lo llamamos el Repositorio Común de Componentes, no muy único, pero bastante directo, lo cual es un buen nombre. Y luego consumimos esto en todos los productos. Y este componente tiene bloques de construcción de diferentes tamaños. Puede tener un botón pequeño o un campo de entrada. Puede tener una tabla completa que tenga filtros y tenga la capacidad de comunicarse con el servidor o trabajar localmente y tener un mecanismo de ordenamiento y tener algún tipo de manejo de errores dentro de él. Quiero decir, también puede ser un componente bastante complejo. Y debido a que optamos por este enfoque, también decidimos enfocarnos en pruebas funcionales y de accesibilidad para estos componentes. La pila de tecnología que funciona para nosotros y también es adecuada para esta conferencia es React y TypeScript para construir los componentes. Y usamos Storybook para visualizar los componentes y también como base para nuestras pruebas, lo cual te mostraré en un momento. Y usamos Cypress para las pruebas y CircusCI para la implementación continua.

De acuerdo, la segunda parte, ahora queremos crear un componente accesible. Así que creemos un botón accesible. ¿Qué significa que un botón sea accesible? Pensemos en ello. Bueno, algunas de las características que hacen que un botón sea accesible es que si no puedes usar un mouse como dijimos antes, debes poder enfocarte en ese botón usando tu teclado.

Y después de que el botón esté enfocado, imagina que tienes como cinco botones en una fila, necesitas dar una indicación de cuál de los botones está enfocado. Y luego, si te enfocas en él, necesitas admitir la tecla Enter o la tecla Espacio como una alternativa al clic. Y lo último, queremos indicar a la tecnología de asistencia que el elemento es un botón. Así que le dirá a los lectores de pantalla u otras herramientas de asistencia que esto es un botón.

De acuerdo, ahora que tenemos estas demandas en mente, vamos a ver el código. Entonces, esto es un comienzo básico para un botón. Es un Div, tiene una clase y un ID, para poder usarlo para el estilo. Tiene un OnClick que abre una alerta, y dice, Soy un botón. Ahora hagámoslo enfocable con el teclado. Para hacerlo, usaremos el atributo TabIndex. El atributo TabIndex le dice al navegador que este elemento está en la lista de tabulación. Entonces, cuando el usuario hace clic en la tecla Tab, eventualmente se enfocará en este elemento. Ahora queremos asegurarnos de que funcione la tecla Enter. No hay una forma fácil de hacerlo, sino agregar un escucha de eventos que escuche las pulsaciones de teclas. Y ahora necesitamos filtrar estas pulsaciones de teclas para ver, si es un Enter, debemos activar la función. Si no es Enter, no debemos hacer nada. Tal vez si es una barra espaciadora, también deberíamos activarlo, depende del sistema operativo, no estoy seguro. Pero también se deben hacer algunas cosas allí. Y ahora queremos decirle a los lectores de pantalla que este elemento es un botón, así que usaremos el atributo de rol.

De acuerdo, lo que tenemos aquí es un botón funcional, pero es solo el comienzo de un botón porque nuestro botón necesitará tener un estado habilitado, un estado deshabilitado, un modo primario, un modo secundario, tal vez un modo para un botón con imágenes, tal vez debería tener un estado específico para una página específica. Quiero decir, el código solo aumentará a partir de aquí. Y este código en realidad ni siquiera cubre todos los aspectos de accessibility. Se necesita mucho código. ¿Qué tal si te digo que hay una forma diferente, una fácil? ¿Qué tal si simplemente usamos la etiqueta de botón de HTML? Entonces, ¿qué sucederá si usamos la etiqueta de botón de HTML? Obtendremos todas estas cosas de forma gratuita porque HTML tiene algunas excelentes características de accessibility integradas. Así que obtendremos el enfoque del teclado, con alguna indicación. Puedes darle estilo si quieres. Obtendremos el evento de pulsación de teclas y obtendremos el rol de forma gratuita, y no tenemos que preocuparnos por ello. Entonces, lo primero que aprendimos al construir nuestra propia Accessibility Component Library es que debemos amar las etiquetas de HTML y no solo los divs para todo. Nos ahorrará mucho tiempo en testing, y nos dará características de forma gratuita. Esto es cierto para los botones, pero también es cierto para los campos de entrada, las etiquetas, los encabezados y otros atributos.

De acuerdo, hablemos de agregar un nivel de automatización. Para agregar las pruebas automatizadas de componentes de accesibilidad, primero creemos un componente. Este es un componente, es un botón. Aprendimos de la diapositiva anterior que el botón debe tener la etiqueta de botón. Así que usamos la etiqueta de botón. Lo que nos interesa aquí es la propiedad primaria, que indica si es un botón primario o secundario. Ahora, seleccionamos este botón y creamos dos historias en Storybook, la historia primaria y la historia secundaria. Si no estás familiarizado con Storybook, no importa realmente. Es una gran herramienta, pero no es el tema de esta charla. Pero pruébalo, es realmente genial.

Si ejecutas Storybook, obtendrás, en realidad obtendrás dos pantallas que muestran solo los botones, y se ve así. Tiene el botón primario, se ve así, y el botón secundario que se ve así. Un poco diferentes en colores. Ahora, usaremos esto como base para nuestras pruebas. En Storybook, hay un botón mágico, puse un montón de flechas para que no lo pasemos por alto. Si haces clic en él, se abrirá el componente en una pestaña separada, en realidad sin todo el envoltorio de la interfaz de usuario de Storybook. Entonces, se abrirá sin las barras de herramientas y aislará solo el componente que queremos en un estado específico con propiedades específicas. Usaremos eso como base para nuestras pruebas funcionales y de accesibilidad.

Entonces, esta es nuestra prueba funcional. La realizaremos con Cypress y la prueba es bastante simple. Vemos dos pruebas que son idénticas, una para el botón primario y otra para el botón secundario. Visitan la URL que Storybook creó. Hacen clic en el botón y verificamos que se registre el clic. Y si queremos ejecutarlo con Cypress, vemos que todo funciona y es genial, está en verde nuevamente. De acuerdo, ahora agreguemos la accesibilidad a la mezcla. Entonces, ¿qué deberíamos esperar que encuentre un marco de trabajo de accesibilidad? Algunas de las cosas que queremos que nos indique es que falta texto alternativo en una imagen, o tenemos un botón pero no se puede enfocar con el teclado, o tenemos una ventana emergente pero no es accesible, o tenemos texto con algún color y algún color de fondo, pero el contraste de color es insuficiente, por lo que es difícil de ver para personas con baja visibilidad. Todas estas cosas y más son las cosas en las que estamos trabajando en Events. Estas son algunas de las cosas que detectamos utilizando nuestras herramientas. Como trabajamos en Events, queremos usar nuestras propias herramientas, por lo que también utilizamos nuestras propias herramientas para la automatización de pruebas. Y lo hacemos proporcionando un SDK para Cypress que nos permite recopilar problemas de accesibilidad. Entonces, si llamamos a evstart, este es el comando, dice: Events, por favor comienza a recopilar problemas de accesibilidad, y luego hacemos algunas cosas y llamamos a evstop, y luego recopila todos estos problemas y podemos ejecutar nuestras validaciones en base a estos problemas, realizar expectativas o aserciones en nuestras pruebas.

De acuerdo, ahora lo ejecutamos y vemos que las cosas no van muy bien. Quiero decir, hay un error. Así que veamos el informe y vemos que hay un problema de contraste de color y la imagen indica que está relacionado y el selector indica que está relacionado con el contraste entre el color del texto y el color de fondo. Para ser más específicos, hay una contradicción, un mal contraste entre RGB 104, 100, 100, 06, 09 y blanco. Bueno, como no soy un diseñador calificado, lo siento, hago lo que haría cualquier buen desarrollador y decimos reemplacémoslo con negro y funciona. Ahora el contraste de color es excelente. En la vida real, consultaría a un diseñador pero esto es una charla y estoy solo aquí.

Y ahora esto es para un solo componente y hacemos esto para todos nuestros componentes y este proceso ocurre durante nuestro pipeline. Así que cada vez que enviamos nuevo código, iniciamos Storybook, ejecutamos todas las pruebas de accessibility y nuestras pruebas funcionales y si todo va bien, implementamos una nueva versión de la biblioteca de componentes para ser utilizada en otros productos. Así es como se ve en la vida real. Lo siento. Entonces, nuestra biblioteca de componentes consta de más de 40 componentes, más de 170 historias y pruebas. Cada historia está cubierta con pruebas funcionales y de accessibility. Se utiliza en cuatro proyectos. Somos un equipo de seis personas, casi siete personas. Depende de cómo cuentes. Y esta biblioteca y este enfoque nos salvaron, nos salvaron en cuanto a accessibility durante un gran esfuerzo de rebranding que acabamos de hacer. Así que cambiamos. Básicamente, ambos componentes fueron cambiados, pero el nivel de accessibility se mantuvo alto porque tenemos el conjunto de pruebas para mantenernos accesibles en todo momento.

Antes de terminar, lecciones aprendidas. Si quieres hacer lo mismo o si quieres aprovechar el mismo enfoque, primero, divide y conquista. Divide tu código en pequeños componentes. Sé amigo de HTML, conoce tus etiquetas de HTML. y automatiza tanto como puedas. Automatiza accessibility, automatiza tu pipeline de implementación. Te ahorrará mucho tiempo.

Para resumir, la accesibilidad no es algo que se enseñe en la academia o en los bootcamps. Y es una lástima porque hace que los desarrolladores se sientan incómodos al principio, pero es muy importante. Así que mi consejo para ti es que no lo pienses demasiado. No necesitas tener un doctorado en accessibility para comenzar tu esfuerzo de accessibility. Puedes hacerlo componente por componente. Simplemente comienza.

Quiero agradecerles por escuchar. Fue muy divertido hablar aquí en la conferencia. Estaré disponible en la sesión de preguntas y respuestas en breve y no dudes en contactarme en LinkedIn o a través de mi blog. Y si tienes dudas, recuerda que la accessibility es mucho más accesible de lo que piensas.

Muchas gracias. Me retiro.