La accesibilidad en React ha sido un tema candente en los últimos años, pero en esta charla iremos más allá de lo básico. Discutiremos qué significa discapacidad más allá de lo que has escuchado antes, y luego usaremos ejemplos de código para aprender por qué HTML semántico es útil y cuándo no es suficiente. Luego veremos las herramientas y hablaremos sobre cómo puedes introducir pruebas de accesibilidad en tus equipos y código existente. Saldrás con las herramientas y el conocimiento para marcar la diferencia a partir de hoy.
Accesibilidad en React: Más allá de lo básico
Video Summary and Transcription
La charla de hoy sobre la accesibilidad en React aborda la importancia de las pruebas manuales, los desafíos que se enfrentan al abordar la accesibilidad, el impacto de la accesibilidad en la experiencia del usuario y el uso de subtítulos y configuraciones de usuario para la accesibilidad. Se enfatiza la necesidad de pruebas manuales además de pruebas automatizadas, el papel de la capacitación en empatía para comprender los desafíos de accesibilidad y la importancia de abordar los problemas de accesibilidad para todos los usuarios. La charla también destaca los beneficios de implementar características de accesibilidad, como aumentar la accesibilidad del sitio web para mercados discapacitados y mejorar la experiencia del usuario para todos.
1. Introducción a la Accesibilidad en React
Hola a todos. Hoy vamos a repasar la Accesibilidad en React más allá de lo básico. Jen Luker es una tejedora, acolchadora, fanática de la ciencia ficción, defensora de la accesibilidad e ingeniera de software. Recomienda ver la charla de Sophie sobre la accesibilidad como ciudadana de primera clase como introducción. Chrome y Firefox tienen herramientas incorporadas para pruebas de accesibilidad, que incluyen funciones para personas con daltonismo y comparaciones de contraste. La extensión AXE para Chrome y Firefox es una herramienta educativa que proporciona descripciones de violaciones, resalta su ubicación y sugiere soluciones. Las pruebas manuales son necesarias para asegurarse de que las cosas correctas sean fáciles y las cosas incorrectas sean difíciles de hacer.
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.
2. La Importancia de las Pruebas Manuales para la Accesibilidad
Cuidar de las tareas sencillas utilizando pruebas automatizadas es útil. Las pruebas automatizadas pueden evitar el resentimiento y la ira entre los miembros del equipo. X no es solo una herramienta web, sino también una CLI que se puede integrar en los conjuntos de pruebas existentes. Sin embargo, las pruebas automatizadas no son suficientes para garantizar una accesibilidad completa. Incluso con una puntuación de Lighthouse del 100%, un sitio web aún puede ser inaccesible. Hacer clic y realizar pruebas manuales son esenciales para la accesibilidad. Las herramientas de Axe pueden proporcionar recordatorios, pero no pueden reemplazar las pruebas manuales. La accesibilidad va más allá de la funcionalidad tecnológica e incluye la legibilidad para usuarios diversos.
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?
3. Pruebas y Desarrollo de Componentes
Se trata de la legibilidad. Se trata de cómo las personas pueden usar el sitio web de la manera que necesitan para alcanzar sus objetivos. Los recursos de prueba incluyen listas de verificación, como la lista de verificación de WebAIM, que proporciona explicaciones detalladas para cada sección. Ejemplos de código, como los que se encuentran en la página YARIA, pueden ayudar con el desarrollo de componentes. La accesibilidad de React y las bibliotecas de componentes como Material UI, React Kit y Reach UI proporcionan componentes accesibles. Recuerda que todos están luchando con JavaScript.
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
4. Abordando los Desafíos de Accesibilidad
Gracias por las charlas sobre accesibilidad. Las pruebas manuales pueden abordar problemas que no son detectados por las pruebas automatizadas. Utiliza las herramientas incorporadas en Chrome y Firefox para simular problemas de color. Para manos pequeñas y pantallas grandes, involucra a otras personas o contrata a un auditor. El entrenamiento en empatía puede brindar información sobre los desafíos de accesibilidad.
5. Pruebas de Accesibilidad y Modo Oscuro
Mencionaste un linter llamado JSX A11y plugin extension que verifica las etiquetas alt y los problemas de accesibilidad. Es independiente de Axe pero se puede encontrar en linters como Airbnb. Para las pruebas de componentes individuales, verifica las prácticas de accesibilidad web que proporcionan ejemplos de código. Las interfaces de modo oscuro pueden introducir complicaciones con la accesibilidad, ya que los diferentes usuarios tienen diferentes preferencias de color. Las pruebas manuales son cruciales para garantizar una visibilidad y contraste adecuados.
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í
6. Desafíos de Accesibilidad y Apoyo del Gerente
Sin embargo, lo que pregunté fue qué utilizas, no qué deberías usar. Lo más común que veo es que las personas usan un div en lugar de un botón. La primera regla de ARIA es no usar ARIA. 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 accesibilidad 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. Entonces, ¿por qué es diferente cuando alguien con un requisito de accesibilidad no puede comprar algo? ¿Por qué eso no es un error? Esa es una pregunta justa.
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?
7. El Impacto de la Accesibilidad en la Experiencia del Usuario
Podrías duplicar, triplicar, cuadruplicar, quintuplicar, octuplicar el número de personas que acceden a tu sitio web al atender a los mercados discapacitados. Implementar características de accesibilidad hace que el sitio web sea más fácil de usar para todos. No se trata solo de arreglar una etiqueta alt, se trata de hacer que el sitio web sea más amigable para el usuario. Cuanto más a menudo las personas se ven obstaculizadas para usar el sitio web, menos probable es que vuelvan y realicen una compra. Ofrecer opciones de accesibilidad puede marcar una gran diferencia en la experiencia del usuario.
8. Subtítulos y Configuraciones de Usuario para Accesibilidad
Como padre, uso subtítulos para ver películas en silencio. Los subtítulos también son útiles para personas que no hablan inglés como lengua materna y para entender diálogos intensos. No es necesario tener versiones separadas de tu sitio web, pero proporcionar configuraciones de usuario y aprovechar las funciones del navegador puede mejorar la accesibilidad. Comienza por las soluciones más sencillas y asegúrate de que tu propio código sea accesible antes de ampliar los esfuerzos de accesibilidad. Las bibliotecas de componentes y las revisiones entre compañeros también pueden mejorar la accesibilidad. Probar los componentes para la accesibilidad, especialmente con VoiceOver, puede ser un desafío.
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?
9. VoiceOver, Axe-Core y el Estándar 508
Parte de VoiceOver es asegurarse de que no estés usando roles de ARIA. Axe-Core es una excelente opción para las pruebas. El estándar 508 garantiza la accesibilidad de los sitios web del gobierno de Estados Unidos. Es importante considerar los problemas de accesibilidad y priorizar la inclusión. La frustración para las personas con discapacidades es sentirse ignoradas y borradas. Gracias por la charla y la sesión de preguntas y respuestas. Jen está disponible para más discusiones.