Accesibilidad en React: Más allá de lo básico

Hola a todos. Hoy vamos a repasar la Accesibilidad en React más allá de lo básico.

Permítanme contarles un poco sobre mí, mi nombre es Jen Luker. Soy una tejedora y acolchadora, una fanática de la ciencia ficción, una defensora de la accesibilidad y también soy ingeniera de software. Me gusta jugar con dispositivos IOT. Y como pueden ver en todas estas fotos, soy amante de los vestidos bonitos.

Antes de adentrarnos demasiado en las partes avanzadas de la accesibilidad, si desean más información sobre una introducción, deberían ver la charla de Sophie sobre la accesibilidad como ciudadana de primera clase. Ella hace un trabajo fantástico al brindarles esa introducción.

Una de las cosas que van de la mano con la accesibilidad son varias herramientas web. Ahora, Chrome tiene varias herramientas incorporadas que solíamos tener que usar complementos para, pero realmente no necesitamos hacerlo. En este momento, tenemos las herramientas de desarrollo que nos permiten hacer cosas como emular las funciones para personas con daltonismo, o podemos ver las comparaciones entre diferentes colores de contraste. Y realmente nos da una gran idea de cómo modificar esas reglas CSS que necesitamos. Firefox también tiene sus propias herramientas, pero es un poco más complicado acceder a ellas. Deberán modificar su configuración para poder acceder a ellas. Y una vez que activen esa opción de simulación, podrán hacer lo mismo. Ahora, no olviden que cuando hagan eso, en realidad deberán cerrar todas las ventanas de Firefox y volver a abrirlas. Actualizar no es suficiente. Así que asegúrense de desactivarlo y volver a activarlo. También me gusta mucho usar la extensión AXE para Chrome y Firefox, aunque Chrome y Firefox ya tienen esto incorporado. De hecho, Chrome utiliza AXE para su extensión Lighthouse, que no solo brinda una visión general de la accesibilidad, sino también una visión general de toda su aplicación. Sin embargo, esta herramienta es más educativa para mí porque no solo muestra las violaciones, sino que también proporciona una descripción de dónde se encuentran. Las resalta y brinda una mejor idea de cuál es el impacto. También ofrece muchas ideas diferentes sobre cómo resolver esto. Ningún problema tiene una única solución. Por lo tanto, comprender cuál es el problema en primer lugar es muy importante. Me encanta AXE porque te brinda la oportunidad de aprender. No solo te dice qué está mal, sino por qué está mal y cómo solucionarlo. Una herramienta fantástica.

Ahora, más allá de realizar pruebas manuales utilizando esas herramientas, queremos hacer que las cosas correctas sean fáciles y las cosas incorrectas sean difíciles de hacer. Puede ser difícil cuando la única forma de manejar las funciones y problemas de accesibilidad es mediante pruebas y correcciones manuales.

Entonces, cuidar de muchas de las tareas sencillas utilizando pruebas automatizadas es útil. Otra razón para las pruebas automatizadas es porque cuando tú, como persona, le dices a tu compañero de trabajo que algo necesita mejorar, que debe estar en un formato diferente, que necesita etiquetas alt o roles ARIA, o incluso que sus props están en el orden incorrecto, puede generar resentimiento y enojo entre el equipo. Si tu conjunto de pruebas automatizadas o tu linter le dice a alguien que se necesitan estas cosas, simplemente lo solucionan. Entonces, si es una colina en la que estás dispuesto a morir, escribe una regla de lint. Ahorrará a todos en el equipo mucha tensión, enojo y frustración. X va más allá de ser solo una herramienta web. También es una CLI y puedes implementarla en tus conjuntos de pruebas existentes. Ahora, las herramientas de pruebas, como las herramientas de pruebas de React, ya lo tienen incorporado, por lo que no tienes que lidiar con tratar de configurarlo por tu cuenta. Pero estos son algunos ejemplos de cómo puedes usarlo en Selenium, Jest, Cypress, Express o una variedad de formatos. De hecho, puedes configurar todas estas DevTools dentro de tu conjunto de pruebas existente sin tener que cambiar a otra cosa. Pero una vez que hemos integrado las pruebas automatizadas, ¿dónde estamos? ¿Estamos bien? Absolutamente no. Y el problema más profundo es algo como esto. Tenemos aquí un sitio web que es 100% inaccesible. Y este es un hermoso artículo que te guía sobre cómo querían mantener una puntuación de accesibilidad del 100% y cómo comenzaron a excluir a las personas eliminando varias características o convirtiendo el código. Y cuando llegamos al final de esto y ejecutamos la última prueba en CodePen, verás que el cursor desaparece cuando estás sobre él. Pero cuando no estás sobre él, está bien. Nada se puede hacer clic. No puedes navegar por nada. No puedes hacer nada con él. Pero de hecho, es un sitio web válido. Te brinda información. Simplemente no puedes verlo en absoluto. Y esto aún te da una puntuación de Lighthouse del 100%. Entonces, solo porque hayas utilizado todas tus herramientas automatizadas, hayas recibido todos tus recordatorios de que la funcionalidad debe estar disponible dentro del código, no cambia el hecho de que este código aún no es accesible. No hay nada en este punto que vaya a reemplazar hacer clic y mirar tu sitio web. Lo que nos lleva de nuevo a las herramientas de Axe que pueden ayudarte a examinar esas cosas y darte recordatorios, pero no lo harán todo por ti. Hay mucho que implica la accesibilidad. No se trata solo de si puedo hacer clic en algo. ¿Puedo verlo? ¿Puede un lector de pantalla verlo? También es tan profundo como si alguien que tiene el inglés como segundo idioma puede leerlo claramente. ¿O si alguien que es autista puede entender qué está sucediendo?

No se trata solo de la funcionalidad tecnológica. Se trata de la legibilidad. Se trata de cómo las personas pueden usar el sitio web de la manera que necesitan para alcanzar los objetivos que están tratando de obtener. Entonces, ¿qué deberías testing cuando estás mirando un sitio web? Voy a darte un par de recursos diferentes. Uno de ellos es una lista de verificación. Estas son geniales porque cuando vas a cada una, te darás cuenta de que tienen una lista de lo que es cada una, lo que estás buscando. Así que puedes recorrer esta lista y entender lo que necesitas testing.

Identificar claramente los errores de entrada o asegurarse de que todos los elementos estén construidos para la accessibility. Pero, ¿qué significa eso? Cuando vas a algo como la lista de verificación de WebAIM, tiene una opción similar pero de hecho te brinda un poco más de detalle sobre lo que significa cada sección y puedes marcarlos como completados. Te brinda muchos más detalles sobre cómo puedes recorrer esa testing manualmente o incluso crear pruebas automatizadas.

Incluso si estás tratando de entender tus componentes cuando estás codificando, puede ser más fácil tener ejemplos de código y esta es una página YARIA difícil de encontrar, pero te brinda referencias, como un diálogo modal, cómo debería lucir el código de un modal y ejemplos. Significa que puedes ir aquí y comenzar a construir tus propios componentes que incluyan estas características, como qué sucede cuando presionas la tecla Tab, qué sucede cuando presionas Shift + Tab, qué sucede cuando presionas Escape. Estas cosas se esperan. Entonces, no te estás desviando de esa expectativa de funcionalidad.

React La accesibilidad es el sitio web real de React, o no hoy, que te guía a través de los formatos específicos de React y las sugerencias sobre cómo mantener accesibles sus componentes. Material UI, React Kit, Reach UI, todas son bibliotecas de componentes que te brindan componentes accesibles para comenzar. Y puedes tomar esos componentes y construir sobre ellos o componerlos para crear los sitios web con los que estás trabajando. Es una forma maravillosa de desarrollar un sitio web con componentes que ya existen, que ya han sido evaluados y solucionados y que además son de código abierto. Y sobre todo, recuerda mientras trabajas con todas estas características accesibles y

características inaccesibles con las que todos luchamos, de hecho, es JavaScript. Gracias. Hola, ¿cómo va todo? Bastante bien, bastante bien. Está oscuro y sombrío en Zurich, ¿cómo está en tu lugar? Soleado. Se ve muy bien, oh Dios mío, oh Dios mío. Ah, es una habitación bonita en la que estar, eso es agradable. Jen, estoy muy contento de que hayamos tenido no solo una, sino dos charlas sobre accesibilidad en esta conferencia, y que hayas ido más allá del tema de introducción que creo que algunas personas ya conocen, pero la mayoría aún no lo sabe, pero lo resolveremos con suerte eventualmente y no tendremos que poner a muchas personas al día. Pero realmente me gusta que hayas abordado diferentes cosas, y una cosa que llamó mi atención, porque yo mismo he caído en esto muy específicamente, fue si nuestras pruebas automatizadas no detectan todo y nunca lo hacen, y mostraste eso de manera muy hermosa, ¿cómo puedo detectar manualmente cosas en las que no estoy afectado, como ciertos problemas de color en los que no estoy en el grupo afectado o problemas para acceder a la información o interactuar con pantallas táctiles cuando los teléfonos son grandes pero mis manos son pequeñas porque tengo manos bastante grandes, ¿qué harías con estas cosas que no puedo detectar en las pruebas manuales? Para cosas como el contraste de color o problemas de daltonismo, tanto Chrome como Firefox tienen herramientas incorporadas que te permiten simular cómo se ven esas cosas. Eso te da una mejor idea de qué problemas de contraste estás encontrando o si estás encontrando similitudes de color que están demasiado cerca para estar cómodos. Para manos pequeñas y pantallas grandes, algunas personas piden a sus hijos que intenten realizar una tarea en particular. Otra opción realmente importante es contratar a un auditor. Una vez que hayas manejado la capacidad tecnológica básica, en ese momento debes involucrar a personas capacitadas y con experiencia en el uso de las tecnologías. Muchas empresas están implementando entrenamiento en empatía. Te hacen usar gafas que te dificultan la visión o guantes que te dificultan el movimiento. El problema con esto es que hace que las cosas sean mucho más difíciles para ti que para alguien que está familiarizado con las herramientas con las que está trabajando. No es tu experiencia diaria, por lo que todo te resulta incómodo. No solo se trata del flujo esperado y si el proceso que has implementado se ajusta a ese flujo esperado. Contratar a un auditor y hacer que personas con diversas discapacidades lo prueben será una parte realmente importante para agregar a ese lado de pruebas manuales de accesibilidad.

Eso suena fantástico. Mencionaste también un linter que puede detectar muchas cosas. Choco está preguntando, ¿cuál era ese linter que mencionaste para verificar las etiquetas alt y los problemas de accesibilidad? Está incorporado en muchas de las herramientas que ya utilizamos. Creo que es el complemento de JSX A11y. Voy a buscarlo. ¿Forma parte de Axe o es independiente de Axe?

Es independiente de Axe, pero lo encontrarás en muchos linters que estás utilizando como Airbnb u otros similares. Es el complemento de eslint JSX A11y que detectará muchos aspectos tecnológicos de la accesibilidad mientras estás codificando. Y además de ese linter, Lighthouse y Axe, como desarrollador, ¿hay algo más que pueda hacer para asegurarme y probar mi sitio web y mis componentes individualmente para la accesibilidad? Esa es una pregunta de Paul.

En cuanto a probar tus componentes individuales, agregué un enlace a mi presentación de diapositivas, y definitivamente lo publicaré en Discord. Hay prácticas de accesibilidad web que te permiten ver no solo los comportamientos esperados para cada tipo de componente, sino que también proporcionan código para que puedas ver cómo se implementa eso dentro del elemento HTML. Te da una idea mucho mejor de qué tipos de características debes agregar al JavaScript para que esas funcionalidades interactivas funcionen. Correcto, genial. ¿Y vas a publicar la presentación de diapositivas en Discord? Eso también es bastante impresionante porque alguien preguntó si las diapositivas están disponibles en algún lugar también. Sí. Además, ¿has visto alguna complicación en cuanto a la accesibilidad con el aumento de las interfaces de modo oscuro para que puedas cambiar entre claro y oscuro? Hay mucha información contradictoria cuando se trata de accesibilidad. Por ejemplo, alguien con TDAH necesita colores brillantes y directos con muy pocas distracciones. Mientras que alguien con autismo puede necesitar colores más suaves porque los colores brillantes intensos son demasiado. Tienes el modo oscuro que significa que tus colores claros deben ser más brillantes y audaces y más grandes para destacar sobre ese fondo negro, tienden a desvanecerse. Mientras que en un fondo claro los negros son realmente fuertes y audaces por naturaleza. Así que sí, definitivamente ves cosas que desaparecen tan pronto como cambias a modo claro y oscuro. Puede ser una lucha interesante. Otra cosa es cuando las cosas están sobre imágenes de fondo y cambias de modo claro a oscuro, a veces los colores cambian a un color que no se puede ver en realidad. Como pasar de un texto negro sobre un fondo blanco a un texto blanco sobre un fondo blanco. Por lo tanto, ser consciente de cómo se ven afectadas es definitivamente algo a tener en cuenta. Y nuevamente, gran parte de eso se reduce a las pruebas manuales. Cambia al modo oscuro. Observa qué sucede. Pero ¿dirías que si el modo oscuro se implementa correctamente también puede resolver algunos problemas de accesibilidad porque ofrece a aquellos que pueden necesitar los colores más suaves un poco más de comodidad? O... No tiene que ser necesariamente que los colores más suaves sean lo que estás buscando. Puedes tener negro con texto blanco y aún así

tener un contraste muy alto. ¿Verdad? Sin embargo, alguien con problemas de fotosensibilidad como yo, los fondos oscuros duelen menos. No es tan brillante para mis ojos. La cantidad de brillo se reduce a pequeñas cosas como el texto en lugar de todo el fondo blanco brillante. Eso hace que tenga sentido. Y también me lleva a algo interesante. Porque me pareció muy interesante. No he escuchado o pensado tanto sobre las diferentes necesidades de los diferentes grupos en cuanto a colores y menos contraste versus aquellos que necesitan un mayor contraste y colores más vibrantes. ¿Cuáles dirías que son los peores infractores en términos de problemas de accessibility en los sitios web que ves y qué podemos hacer para combatirlos? ¿Cuáles son los más prevalentes en la práctica? Esto podría sesgar la encuesta.

Sin embargo, lo que pregunté fue qué utilizas, no qué deberías usar. Y veo que la gente usa un div para todo. Un div para containers, un div para botones, un div para enlaces, un div para literalmente todo. Tenemos estos puntos de referencia como main y content y article y estas diversas opciones que brindan contexto a los lectores de pantalla o a la plataforma web en su conjunto que permite a las personas interactuar de manera más fluida. Sin embargo, cuando usamos un div para todo y simplemente agregamos clics a las cosas, se rompe ese proceso. Entonces, lo más común que veo es que las personas usan un div en lugar de un botón. Hay momentos en los que quieres usar un div en lugar de un botón y eso es cuando intentas incluir un div dentro de un botón y eso no está permitido. O puedes hacerlo, pero no es semánticamente correcto. En ese punto es cuando quieres comenzar a agregar las características de accesibilidad del botón. Pero es extremadamente raro que debas hacer eso. Como dicen, la primera regla de ARIA es no usar ARIA. Cuando hay una mejor alternativa disponible. Sí, creo que rara vez es necesario salir de lo que el navegador te ofrece. Y si lo haces, debes tener mucho, mucho cuidado y desafortunadamente la mayoría de las personas no lo tienen. Eso definitivamente es un problema.

Y otro problema que he estado viendo es que a veces es genial convencer a los desarrolladores de hacer las cosas correctamente, pero luego no encuentran respaldo en el gerente o en el equipo con el que trabajan o en toda la organización en la que trabajan. Sé que algunos países están penalizando los problemas de accessibility en los sitios web, especialmente si son sitios web gubernamentales y cosas así. Pero fuera de estos países, digamos en Alemania, digamos en Suiza, ¿qué le dirías a un gerente que dice que no necesitamos accesibilidad? Está bien, simplemente omítelo. Si tuvieras un error en tu flujo de compra que impidiera que un usuario realmente compre tu producto, lo solucionarías de inmediato. Las cabezas girarían tan rápido basado en la solución rápida. Entonces, ¿por qué es diferente cuando alguien con un requisito de accessibility no puede comprar algo? ¿Por qué eso no es un error?

Esa es una pregunta justa. Y la respuesta que he escuchado de los gerentes en el pasado fue algo así como, bueno, esos no son nuestros clientes. Nuestros clientes son jóvenes, saludables y deportistas, y no necesitamos eso. ¿Cómo los convences, cómo solucionas ese pensamiento? Hay varias opciones diferentes. Hay tantos lugares a los que mi mente va ahora mismo. Uno de ellos es argumentar que estás vendiendo cosas para personas jóvenes y deportistas. Sin embargo, hay tías, tíos, abuelos, primos y amigos y hermanos que compran cosas para personas jóvenes y deportistas. No todos son jóvenes, deportistas y físicamente capaces. Algunos tienen discapacidades y son jóvenes y deportistas. De cualquier manera, necesitan poder comprar estas cosas o perderás ventas. No solo eso, como mencionó Sophie en su charla anterior a la mía, tienes el potencial de llegar al 15% de la población mundial que se considera discapacitada. Ahora, si tienes una base de código o un producto que llega a, digamos, 10 millones de personas, tienes 10 millones de usuarios, pero tenemos alrededor de 9 mil millones de personas y el 15% de ellas son discapacitadas. Son discapacitadas, pero solo 1 de cada 10 sitios web es accesible en parte, lo que significa que tienes la capacidad de acaparar ese mercado de tantas personas. Muchas más de las que tienes actualmente como usuarios, si tu sitio web es accesible. Entonces estás lidiando con el hecho de que podrías duplicar, triplicar, cuadruplicar, quintuplicar, octuplicar, el número de personas que pueden acceder a tu sitio web simplemente atendiendo a los mercados discapacitados. No solo eso, cuando implementas características de accessibility, facilita que todos usen el sitio web. No se trata solo de arreglar una etiqueta alt, se trata de hacer que el sitio web sea más fácil de usar. Entonces, si tienes al bebé dormido en tu mano del ratón, puedes usar el teclado en tu mano izquierda para navegar por el sitio web. O estás en una habitación ruidosa y estás tratando de mostrarle a tu amigo un video y quieres que aparezcan los subtítulos para que puedan ver qué está pasando. No es una situación estándar en la que son sordos o les falta un brazo. Es que son personas comunes que hacen cosas cotidianas y también utilizan estas características. Y cuanto más a menudo se les impide hacer eso, menos probable es que vuelvan a tu sitio y menos probable es que realicen la compra en primer lugar. Y esto es algo que me sorprende que no pensemos más. Y muchas gracias por darnos argumentos para tener esta conversación con nuestros gerentes. Porque especialmente el ejemplo de estar parcialmente incapacitado durante nuestra vida diaria. Conozco muchos momentos en los que estaba en un lugar público, no tenía mis auriculares conmigo y luego quería leer algo. Me presentaron un video que tenía todo en sonido y pensé, sí, no me sirve de nada. Adiós. Y luego ir a otro lugar y probablemente hacer la compra allí también, si tenían información textual o simplemente subtítulos. Las pequeñas cosas a veces pueden

hacen una gran diferencia. Sí, es un buen punto. Como padre, uso subtítulos todo el tiempo. Estoy viendo una película más tarde por la noche. Y ya sabes cómo es, las explosiones son realmente, realmente, realmente fuertes, pero los momentos tranquilos son tan silenciosos que no puedes escuchar y estás ajustando constantemente el volumen, de esta manera puedo dejar el volumen bajo en algo razonable, y luego simplemente ver los subtítulos para las partes realmente silenciosas que no puedo escuchar lo que están diciendo sin despertar al niño. Sí, sí. Y también si el inglés no es tu lengua materna, y luego tienes a alguien con un fuerte dialecto en una película en inglés, es posible que también necesites los subtítulos. No tiene nada que ver con tener una opción en este punto realmente, porque simplemente no entiendes lo que se dice en esa parte de la conversación, lo que también lo hace muy frustrante cuando los subtítulos son diálogos intensos. Yo digo, sí, pero ¿qué están diciendo? Exactamente. Nantunes nos pregunta, con toda esa diversidad en las opciones que mencionamos, ¿tendría sentido tener diferentes versiones separadas de tu sitio web o aplicación para satisfacer estos diferentes requisitos? No estoy seguro de que necesites versiones completamente separadas, pero algunas opciones serían geniales, poder ingresar a tus propias configuraciones de usuario y seleccionar esas opciones. Ten en cuenta que los propios navegadores tienen algunas de esas funciones para aumentar el contraste de tu sitio, reducir el contraste de tu sitio, modo claro, modo oscuro. Comprender lo que el navegador te ofrece y luego asegurarte de que cualquier configuración que elijan siga funcionando con tu sitio web, te brinda una buena parte de eso para comenzar. Y luego, después de eso, puedes comenzar a agregar opciones de configuración individuales. Sin embargo, no te lances directamente a esas opciones de configuración cuando aún estás luchando con el hecho de que todos tus botones y enlaces son inaccesibles. Comienza por las soluciones más sencillas. Haz que las cosas funcionen para todos y luego comienza a reducir a medida que avanzas.

Sé que siempre debemos comenzar a trabajar en la accessibility antes de comenzar a construir un producto, pero muy pocos tienen ese lujo. Y estamos tratando de agregar accessibility a un sitio web existente. Y digo que comiences con tu propia definición de finalizado. Asegúrate de que como desarrollador, has decidido que ningún código pasará sin ser accesible. Tu propio código será accesible. Y luego puedes comenzar a extender eso a través de revisiones entre compañeros. Oye, esto no será accesible. ¿Puedes agregar esa etiqueta alt? ¿Puedes convertirlo en un botón? Y luego, más allá de eso, comienza a mirar tus bibliotecas de componentes. El componente que se reutiliza más, trabaja en eso. Una vez que ese componente sea accesible, su uso en todas partes será accesible, luego puedes analizar páginas individuales y ver cómo se utilizan en combinación esos componentes y cómo eso puede crear algunas inaccesibilidades en tu sitio. Y luego comienza a trabajar en cómo puedes ampliarlo para hacerlo más accesible para las personas que necesitan diferentes opciones de configuración. Pero definitivamente comienza por las soluciones más sencillas. Tiene sentido. Y hablando de componentes, hay una pregunta de, espera, déjame ver, GJ pregunta, ¿hay alguna herramienta no solo para pruebas de integración como hace X, sino también para pruebas unitarias de componentes accessibility, y específicamente VoiceOver aparentemente es muy difícil de probar?

VoiceOver es muy difícil de probar. Parte de VoiceOver es asegurarse de que no estés usando roles de ARIA en diferentes elementos. Axe-Core puede ser utilizado en pruebas unitarias, funcionales y de extremo a extremo. Axe-Core es la base o el fundamento detrás de Lighthouse en Chrome y el complemento Axe Firefox en Chrome, por lo que es una excelente opción para comenzar. De acuerdo, bien. Axe-Core también es muy bueno saberlo. Una última pregunta. B. Benedict pregunta cuál es tu opinión sobre el estándar 508, nunca había escuchado eso antes, ¿y qué tan importante es la certificación para el estándar? El estándar es muy importante para garantizar que los sitios web en Estados Unidos sean accesibles, ya sea que estés trabajando en terrenos gubernamentales o dentro de un sitio web gubernamental, porque necesitan ser accesibles. Como entidad gubernamental, necesitan tener acceso, o todos necesitan poder acceder a su información. Es importante porque tiene en cuenta muchos problemas de accesibilidad con los que nos encontramos en la web como estándar. Y no se trata solo de ser demandado si no lo haces. También es simplemente lo correcto. Al hablar con muchas personas con discapacidades, su mayor frustración no siempre es que el sitio web no funcione para ellos. Pero lo más importante es que sienten que no importan. Su experiencia no cuenta. Se considera que no son importantes. Y a veces ni siquiera se los considera en absoluto. Su existencia ni siquiera se te ocurre. Y eso es literalmente la definición de ser borrado. Genial. Muchas gracias por estar con nosotros y dar esta increíble charla y responder todas estas preguntas fantásticas. Creo que también estarás en la sala de Zoom después si alguien quiere unirse y tener una sesión de preguntas y respuestas formales e informales contigo. Eso es totalmente posible. Echemos un vistazo rápido a nuestra encuesta antes de tomar un descanso. Así que gracias. Muchas gracias, Jen, por unirte a nosotros. Y nuevamente, gracias a todos los que enviaron preguntas. Jen está definitivamente disponible y también publicará sus diapositivas en el canal de Discord si estás interesado. Fue una gran charla. Fue una gran sesión de preguntas y respuestas. Fue fantástico estar aquí contigo. Gracias a todos.