Cómo hacer el bien sin hacer nada

Rate this content
Bookmark

No hay discusión de que construir sitios web accesibles es una fuerza para el bien. Pero asegurarse de que nuestros sitios web y aplicaciones de React funcionen para todos puede llevar tiempo y no siempre es fácil hacerlo correctamente. Afortunadamente, invertir un poco de tiempo en tu flujo de trabajo de accesibilidad y configurar una serie de herramientas automatizadas te ahorrará toneladas de tiempo y energía a largo plazo.

En esta charla, demostraré cómo puedes aprovechar las herramientas automatizadas, los estándares de código claramente documentados y un proceso de desarrollo bien definido para hacer que la construcción y prueba de aplicaciones de React accesibles sea pan comido. Discutiré las formas en que automatizo ciertos aspectos de mis flujos de trabajo de desarrollo para detectar errores de accesibilidad, definir y configurar pruebas y recorrer todo el ciclo de vida del desarrollo de funciones de accesibilidad utilizando un ejemplo del mundo real.

32 min
25 Oct, 2021

Video Summary and Transcription

La accesibilidad se trata de asegurarse de que todos puedan participar en la web, independientemente de su discapacidad. Las herramientas automatizadas como Lighthouse y React Axe ayudan a identificar errores de accesibilidad y brindan orientación para solucionarlos. Las pruebas unitarias validan los atributos ARIA y la navegación por teclado, mientras que las pruebas de integración y de extremo a extremo se centran en los resultados y simulan las experiencias de los usuarios. Cypress.io es un marco de pruebas de código abierto con un excelente soporte de accesibilidad. Implementar pequeños cambios conduce a una comprensión profunda de la accesibilidad web y la resistencia a errores.

Available in English

1. Introducción a la Accesibilidad y su Importancia

Short description:

Hola React Advanced, soy Uraima Estevez, una gerente de desarrollo front-end en Shopify. La accesibilidad se trata de asegurarse de que todos puedan participar en la web, independientemente de su discapacidad. La accesibilidad web mantiene la web inclusiva y evita la exclusión. Va más allá de la fase de construcción, requiriendo mantenimiento, corrección de errores y desarrollo de funciones. Las pruebas y la automatización ayudan a proteger la experiencia del usuario y a ahorrar tiempo. Construir suites de pruebas y automatización de accesibilidad es una inversión inicial que vale la pena a largo plazo.

Muy bien, aquí vamos, hola React Advanced, muy emocionada de estar aquí hoy con ustedes de forma remota. Mi nombre es Uraima Estevez. Soy una gerente de desarrollo front-end en Shopify en el equipo del Sistema de Diseño Polaris. Si en algún momento quieres seguir estas diapositivas, siéntete libre de visitar a11y-testing.uraima.com. Y si en algún momento quieres mostrarme algo de amor en Twitter o si quieres hacer alguna pregunta, siéntete libre de encontrarme en URAM04.

Así que vamos directo al grano. Voy a empezar por entender qué es la accesibilidad. En mi opinión, la accesibilidad se trata de nuestros usuarios. Y me refiero a todos nuestros usuarios, cada uno de ellos. Se trata de asegurarse de que todos tengan la oportunidad de participar en la web, en nuestras aplicaciones móviles y más generalmente en la sociedad. Y la accesibilidad garantiza esto independientemente de la circunstancia, habilidad o discapacidad de una persona. La accesibilidad web se trata realmente de mantener la web inclusiva. Tim Berners-Lee, padre de internet, dice aquí que el poder de la web está en su universalidad. La inclusión de personas con discapacidad es un aspecto esencial de ello. Así que para nosotros, como ingenieros, la accesibilidad web se trata de asegurarnos de que no excluimos a ciertas poblaciones de personas de poder acceder a la web. Y esto es exactamente lo que podría suceder si no somos intencionales en cómo construimos nuestras aplicaciones para que funcionen para todos.

Y al igual que cualquier otro aspecto de nuestro trabajo, la accesibilidad va más allá de la fase de construcción de una aplicación o un sitio web. Tu trabajo simplemente no termina justo después de lanzar a producción. Hay mantenimiento, corrección de errores y desarrollo de funciones que vienen justo después de que lanzas a producción. Y realmente, cada vez que hacemos un cambio en el código en el que trabajamos, podríamos exponernos a errores y regresiones. Y de alguna manera, este es un problema bastante resuelto. Hemos encontrado algunas formas bastante buenas de protegernos de crear errores de forma no intencional o de degradar nuestras experiencias de usuario. Y lo hacemos a través de las pruebas y la automatización. Hemos logrado reducir el tiempo de ejecución de estas pruebas y otros procesos y hemos encontrado formas de ayudar a proteger las experiencias que estamos construyendo en la web. Entonces, si construimos nuestros componentes y aplicaciones de la forma más accesible posible, escribimos pruebas para validar que su comportamiento esté protegido contra errores y luego encontramos esas oportunidades para automatizar algunos de esos procesos en nuestro ciclo de desarrollo de accesibilidad, ahorramos tiempo y construimos confianza en nuestros sistemas para que funcionen para todos y, en consecuencia, hagamos la web mejor para todos. Y podemos dormir tranquilos sabiendo que hemos construido y mantenido nuestras aplicaciones inclusivas con muy poco esfuerzo a largo plazo. Y esa última oración es la advertencia aquí, a largo plazo. Como saben, construir suites de pruebas de accesibilidad, construir suites de automatización, estas son cosas que llevan tiempo y esfuerzo al principio, pero una vez que las tienes en su lugar, realmente obtienes un gran retorno de la inversión que estás haciendo. Entonces, de alguna manera, podrás decir que estás haciendo mucho bien sin hacer nada una vez que hagas esa inversión. Más o menos.

2. Herramientas Automatizadas para Accesibilidad y Lighthouse

Short description:

Discutiremos herramientas automatizadas para accesibilidad, incluyendo el plugin JSX Accessibility ESLint y Lighthouse. El plugin ayuda a detectar errores comunes de accesibilidad durante el desarrollo y se puede automatizar utilizando GitHooks y pipelines de CI/CD. Lighthouse permite realizar auditorías de accesibilidad en páginas web, proporcionando información y una puntuación de 100 para medir el cumplimiento de la accesibilidad.

Vamos a dividir esto en dos partes. Tenemos nuestras herramientas, que serán las herramientas automatizadas que utilizaremos en diferentes etapas de nuestro proceso de desarrollo. Vamos a obtener ayuda para automatizar las tareas más difíciles que muchas veces terminamos haciendo, y esto nos ayudará a mantener nuestros códigos libres de errores de accesibilidad. Luego hablaremos de las pruebas. Discutiremos qué tipos de pruebas escribimos y qué queremos validar cuando se trata de el soporte de accesibilidad en nuestros componentes y aplicaciones.

Ahora, una advertencia rápida antes de empezar. Supongo que tienes un buen conocimiento de los conceptos de accesibilidad y los conceptos de pruebas, por lo que asumiré que tienes un buen dominio de las mejores prácticas, el lenguaje común y cualquier sintaxis que mencione. Si necesitas una introducción a la accesibilidad, tengo algunas charlas grabadas que he enlazado en esta diapositiva y si quieres algunos recursos introductorios sobre los fundamentos de las pruebas, también puedo publicar algunos recursos útiles que he encontrado muy útiles a lo largo del camino. Dicho esto, vamos directamente a las herramientas.

Me gusta empezar con este plugin de ESLint, JSX Accessibility. Este es un conjunto de reglas de linter de accesibilidad que verificarán tus elementos JSX y React durante el desarrollo. Es muy fácil de usar porque la mayoría de las personas, especialmente aquí, probablemente ya tienen algún tipo de linter en su código base, y probablemente estén utilizando algo como ESLint. Esto te ayudará a detectar los errores de accesibilidad más comunes en tu código mientras lo estás escribiendo. Otra ventaja es que puedes automatizar todo esto utilizando GitHooks para evitar que se comprometa código inaccesible. También puedes integrarlo en tu pipeline de CI/CD y fallar cualquier compilación si se producen errores, de modo que puedas evitar que los errores de accesibilidad lleguen a producción.

Siguiendo adelante, vamos a hablar de Lighthouse. Esta es una herramienta automatizada de código abierto para mejorar la calidad de tus páginas web. Más específicamente, Lighthouse te permite realizar auditorías de accesibilidad en tu sitio web. Esto te dará una buena comprensión de lo accesible que es tu sitio web. Te ayudará a descubrir cualquier problema que necesites resolver. Lighthouse viene en diferentes versiones, como Chrome DevTools, línea de comandos, sistemas de CI, y una interfaz web muy útil. Todas estas son excelentes para diferentes etapas de tu proceso de desarrollo y se pueden adaptar a tu forma de trabajar. Por ahora, vamos a echar un vistazo a Lighthouse y a las Chrome DevTools porque así es como me gusta usarlo, pero realmente hay mucha documentación disponible para cualquier otro caso de uso que quieras explorar. En las Chrome DevTools, simplemente vamos a la pestaña de auditorías. Ahora verás que Lighthouse nos ofrece una lista de auditorías que podemos ejecutar con algunas opciones diferentes que podemos configurar. Aquí tengo la categoría de accesibilidad, y la vamos a ejecutar en un dispositivo de escritorio. Al hacer clic en generar informe, tomará un par de minutos y luego veremos que Lighthouse nos proporciona una auditoría completa de la página web que acabamos de analizar. Esto nos dará una puntuación de 100. Esta puntuación nos indicará qué tan accesible es nuestro sitio web, comprobando si cumplimos con los estándares y las mejores prácticas de accesibilidad. Queremos acercarnos lo más posible a 100.

3. Herramientas Automatizadas para Pruebas de Accesibilidad

Short description:

Ahora, junto con nuestra puntuación, también obtendremos una lista de dónde perdimos puntos cuando no cumplimos exactamente con las mejores prácticas o estándares. Lighthouse no solo es compatible con la accesibilidad, sino que también se utiliza para ejecutar diferentes auditorías. React Axe prueba la accesibilidad de las aplicaciones de React y muestra los resultados en la consola de herramientas para desarrolladores de Chrome. Lighthouse y React Axe identifican errores de accesibilidad y brindan orientación para solucionarlos. Axe-core es una API potente utilizada por Lighthouse y React Axe para pruebas de accesibilidad automatizadas.

Ahora, junto con nuestra puntuación, también obtendremos una lista de dónde perdimos puntos cuando no cumplimos exactamente con las mejores prácticas o estándares. Si ves aquí, lo ejecuté en la página web de documentación de Polaris DevTool. Y en la página anterior, obtuvimos 100 de 100, realmente genial, navegamos a otra página en la documentación de Polaris. Y perdimos algunos puntos aquí. Otra cosa genial de Lighthouse es que cuando perdemos puntos de esa puntuación de 100 puntos, nos dará algunos consejos bastante útiles sobre cómo podemos solucionar esos errores. Aquí, puedes ver que en realidad tenemos algunos elementos de encabezado que no están en orden secuencial descendente. Si hago clic en este error, me dará un poco más de detalles sobre cómo puedo solucionar exactamente este error y volver a obtener una puntuación de 100. Me gusta mucho usar esta herramienta Lighthouse mientras hago cambios en mi código, básicamente para asegurarme de que no estoy degradando involuntariamente mi accesibilidad de soporte y para mantenerme lo más cerca posible de esos 100 de 100.

Ahora, algo que realmente me encanta de Lighthouse es que no solo es para el soporte de accesibilidad. También podemos usarlo para ejecutar muchas auditorías diferentes. Tenemos rendimiento, mejores prácticas, SEO, aplicaciones web progresivas, realmente cualquier cosa que podamos imaginar para tener un sitio web de alta calidad. Todo esto está integrado en una sola herramienta para asegurarnos de que estamos construyendo el mejor sitio web posible. Y un dato curioso es que si obtienes 100 de 100 en múltiples categorías diferentes, obtendrás una pequeña sorpresa al final. Entonces, nuestra próxima herramienta de la que siempre me gusta hablar cuando se trata de accesibilidad en React es React Axe. Esta es otra herramienta de código abierto que probará la accesibilidad de nuestras aplicaciones de React y mostrará esos resultados en la consola de herramientas para desarrolladores de Chrome. Aquí estoy utilizando el Desafío de Bienestar de 30 días del New York Times como demostración. Voy a abrir la consola de herramientas para desarrolladores y de inmediato veremos que React Axe está resaltando todos los errores de accesibilidad en la página. Estos errores incluirán algo llamado una calificación de gravedad. Variará desde menor hasta moderada hasta grave y estas calificaciones básicamente nos darán una comprensión rápida de qué tan mal afecta esto a mi experiencia de usuario y cómo debería priorizar la solución de esos errores. Junto con esos errores, nos proporcionará un enlace a un recurso realmente útil para obtener detalles sobre qué es exactamente el error y algunas formas en las que podemos solucionarlo. En muchos aspectos, Lighthouse y React Axe son bastante similares. Básicamente nos dicen dónde hemos cometido errores en nuestro soporte de accesibilidad y cómo solucionarlos. Una diferencia clave a tener en cuenta aquí es que viste que Lighthouse solo verifica después de que se haya cargado una página y esencialmente verifica estáticamente esa página. Para React Axe, aquí ves que estoy haciendo clic e interactuando con la página y a medida que interactúo, me muestra nuevos errores. Se va renderizando a medida que avanzo y a medida que interactúo dinámicamente con este sitio web. Entonces, React Axe es una excelente manera de probar no solo en la carga inicial de la página que nuestro sitio web sea lo más accesible posible, sino también a medida que el usuario recorre el sitio web o la aplicación para asegurarnos de que estemos cubriendo todas nuestras bases.

La última herramienta de la que quiero hablar hoy y en la que no me adentraré demasiado, pero es realmente importante mencionar, es axe-core. Este es un motor de accesibilidad para pruebas automatizadas de interfaz de usuario web. Entonces, axe-core es esencialmente una API de nivel inferior muy potente que ayuda a ejecutar pruebas automatizadas de accesibilidad y procesos. Y un dato curioso sobre axe-core es que, debido a que es una API tan potente y de bajo nivel, tanto Lighthouse como React-Axe están construidos utilizando la API de axe-core.

4. Pruebas Automatizadas con Pruebas Unitarias

Short description:

Vamos a cubrir los tres tipos principales de pruebas: pruebas unitarias, pruebas de integración y pruebas de extremo a extremo. Para las pruebas unitarias, validamos la API y el comportamiento de un componente, como los atributos ARIA y la navegación por teclado. Las herramientas recomendadas son React Testing Library y Jest. Comencemos con un botón accesible. Nos aseguraremos de que se renderice correctamente el atributo aria-label y manejaremos los casos en los que no deba renderizarse.

Entonces, básicamente eso debería indicarte que esto te permitirá tener un control total sobre los flujos de trabajo, los procesos y las pruebas que deseas construir para adaptarse a tus casos de uso específicos. Y eso es todo lo que quiero cubrir en cuanto a herramientas. Hablamos de algunas, y esa lista no es exhaustiva en absoluto en cuanto a las herramientas disponibles para tus aplicaciones de JavaScript cuando se trata de pruebas de accesibilidad, pero creo que es un buen comienzo para que al menos pienses en tus procesos de desarrollo de accesibilidad y en dónde puedes comenzar a automatizar algunas tareas.

Ahora pasemos a nuestras pruebas, vamos a hablar sobre algunas pruebas automatizadas que podemos realizar para asegurarnos de que nuestras aplicaciones sean accesibles. Un pequeño descargo de responsabilidad, voy a compartir las herramientas que uso, pero los marcos y bibliotecas que menciono aquí realmente no importan tanto. Lo que quiero que prestes atención es a qué estoy probando y por qué es importante probarlos. Vamos a cubrir los tres tipos principales de pruebas que son relevantes para nosotros, y estos son pruebas unitarias, pruebas de integración y pruebas de extremo a extremo.

Comencemos con las pruebas unitarias, estas pruebas van a examinar componentes individuales independientes. Validaremos la API y el comportamiento de un componente. Esto puede incluir la prueba de nuestros atributos ARIA y asegurarnos de que estén presentes y que sus valores sean correctos. También podemos probar la navegación por teclado dentro de ese componente en sí. Nuevamente, las herramientas no importan mucho aquí, o las herramientas específicas no importan mucho aquí. Pero en caso de que quieras un punto de partida, me gusta usar React Testing Library y Jest juntos. Funcionan muy bien juntos y tienen un excelente soporte de accesibilidad. Comencemos con un componente muy simple. Vamos a crear un botón accesible. En mi botón, me aseguraré de pasar una prop de etiqueta accesible y renderizar condicionalmente esa etiqueta accesible. Esa etiqueta aparecerá como el atributo aria-label en realidad. Y esto proporcionará una etiqueta descriptiva para el elemento al que se aplica, para que algo como un lector de pantalla u otras tecnologías de asistencia puedan anunciarlo a nuestros usuarios o hacerlo más accesible, en esencia.

Entonces, aquí está nuestra prueba. Vamos a sumergirnos en ella. Comenzaremos verificando que se renderice el atributo aria-label cuando le pasamos la prop de etiqueta accesible. Crearemos un componente de botón y lo renderizaremos en la página. Finalmente, afirmaré que nuestro botón tiene ese atributo aria-label presente y que está configurado con el valor correcto de aria-label que pasamos a nuestra prop. Esta prueba asegurará que siempre tengamos el aria-label correcto para nuestro componente. Y esto es clave porque realmente puede protegernos de cualquier regresión si alguien llega un día y refactoriza el componente de botón. Es posible que eliminen accidentalmente esa prop de etiqueta accesible sin saberlo o simplemente olviden renderizarla, y si eso sucede, esta prueba gritará, oye, olvidaste algo realmente importante aquí, tal vez vuelvas atrás y revises lo que escribiste. También queremos validar cuándo no se debe renderizar ese aria-label. Y solo queremos renderizar este aria-label si no se pasa la prop de etiqueta accesible.

5. Pruebas de Atributos ARIA y Enfoque de Teclado

Short description:

Renderizamos el componente accessible-button y nos aseguramos de que no se renderice ningún aria-label cuando no se pasa la prop accessible-label. Esta prueba protege contra la introducción de errores de accesibilidad.

Entonces, igual que en nuestra última prueba, vamos a renderizar nuestro componente accessible-button y luego vamos a buscar ese componente de botón. Y ahora, aquí está la clave. Queremos asegurarnos de que, debido a que no pasamos una prop accessible-label a nuestro accessible-button, no estamos renderizando un aria-label, ni siquiera una cadena vacía en ese atributo aria. Y la razón por la que queremos hacer esto es porque si tenemos un aria-label que está configurado como vacío o tal vez configurado como nulo, o algo que no es la etiqueta específica que queremos, esto podría tener algunos efectos secundarios inesperados cuando se trata de tecnologías de asistencia, como algo como un lector de pantalla entra en juego. Entonces, nuevamente, esta no es una prueba demasiado difícil. Es bastante sencillo, pero a largo plazo, realmente nos ayuda a protegernos contra la introducción de cualquier tipo de errores de accesibilidad que puedan degradar nuestra experiencia de usuario.

6. Pruebas de Enfoque de Teclado y Atributos ARIA

Short description:

Probar el enfoque de teclado es crucial para garantizar el soporte de la navegación mediante teclado. Al utilizar el método de enfoque en elementos interactivos, como botones, podemos asegurarnos de que tengan el enfoque esperado. Esta prueba ayuda a detectar errores que pueden afectar la navegación mediante teclado en el futuro. Es importante validar los atributos ARIA y asegurarse de que estén presentes y sean correctos en el código.

Entonces hablemos de otra prueba, esta vez, descubriendo nuestro enfoque de teclado. Asegurarnos de que estamos probando que nuestros componentes puedan obtener el enfoque es una muy buena forma de probar la navegación mediante teclado. Ahora, todos nuestros elementos interactivos deben admitir usuarios que solo utilizan el teclado. Y solo los elementos que pueden recibir el enfoque son interactivos con el teclado. Entonces, aquí vamos a tomar ese mismo botón accesible y luego llamar al método de enfoque en él. Y luego, vamos a afirmar que después de haber enfocado en este botón, ese botón debería tener realmente el enfoque. Ahora, esta prueba realmente nos protege en el futuro de introducir errores que rompan la navegación mediante teclado. Entonces, para nuestro botón accesible que hemos escrito aquí, hemos utilizado el elemento de botón HTML como el elemento principal. Y los botones HTML por defecto son navegables mediante teclado porque pueden recibir el enfoque. Pero digamos que en algún momento, probablemente, honestamente, seis meses después de haber escrito esto, vienes y cambias de nuestro elemento de botón HTML a un div. Ahora, aquí está el problema, los divs no son elementos que se pueden enfocar por defecto. No son interactivos por defecto y, por lo tanto, no necesitan recibir el enfoque. Debido a eso, no van a admitir la navegación mediante teclado. Así que eso es un problema. Pero debido a que tenemos nuestra prueba, ahora esta va a fallar. Y nos va a informar que probablemente hemos introducido un error no intencional en nuestro código que rompe la navegación mediante teclado para nuestros usuarios. Y este tipo de cosas es lo que queremos asegurarnos de probar. Queremos encontrar esos casos de prueba que destilen exactamente cómo se ven los resultados a través de una perspectiva accesible para nuestros componentes. Si tienes un componente que es interactivo, esto me indica que debo verificar el enfoque de teclado para asegurarme de que se admita la navegación mediante teclado. Cuando mis componentes dependen de los atributos ARIA, por ejemplo, quiero asegurarme de que esté validando esos atributos ARIA. Asegurándome de que estén presentes en el código y que tengan el valor correcto cuando están presentes.

7. Pruebas de Integración y Pruebas de Extremo a Extremo

Short description:

Las pruebas de integración validan cómo interactúan los componentes, centrándose en los resultados. Probamos los atributos ARIA y la navegación mediante teclado en varios componentes. Un ejemplo es el formulario de registro de Slack, donde la validación desencadena un mensaje de error y un indicador visual. Nos aseguramos de que las tecnologías de asistencia reciban una señalización adecuada. Las pruebas de extremo a extremo simulan las experiencias de los usuarios dentro de un flujo completo.

Así que, suficiente con las pruebas unitarias. Hablemos de las pruebas de integración. Las pruebas de integración nos ayudan a validar cómo interactúan los componentes individuales entre sí. Y gran parte de lo que acabamos de cubrir al hablar de las pruebas unitarias se puede aplicar a las pruebas de integración. Nos preocupa menos las API de los componentes. Nos preocupa más los resultados de cómo estos componentes se unen y trabajan entre sí.

Entonces, aunque aún podemos probar los atributos ARIA y la navegación mediante teclado, esta vez queremos probarlos en varios componentes que se unen. Aquí, tengo un ejemplo utilizando el sitio web de reuniones de React. Tenemos un formulario de registro de Slack en el sitio donde puedes enviar tu correo electrónico y unirte a nuestro grupo de Slack. Entonces, aquí, cuando me enfoco en el campo de correo electrónico y luego salgo de él, se ejecuta una validación. Y cuando se ejecuta esa validación y no hay una dirección de correo electrónico válida, ves que se agrega un contorno rojo a este campo para indicarme que necesito agregar un correo electrónico válido. También necesito asegurarme de que mis usuarios de lectores de pantalla sean notificados de este error de alguna manera, y eso es lo que vamos a probar ahora. Vamos a probar que estamos señalizando correctamente a cualquier tecnología de asistencia de este flujo específico.

Entonces, echemos un vistazo a este componente. Nuestro contenedor de registro de Slack está compuesto por varios componentes, y el contenedor va a pasar algunas props a todos los componentes. Aquí, tenemos un campo de entrada accesible como vimos antes, y esto va a tomar una función onBlur, y también tenemos un componente de alerta accesible. Y este componente va a aceptar algún tipo de mensaje, probablemente un mensaje de error, que se ejecutará con validación. Entonces, al examinar nuestro componente accessibleAlert, podemos ver que está oculto visualmente para que no aparezca en la página, porque este es un componente que solo está aquí para las tecnologías de asistencia. Aquí tengo el atributo role establecido en alert, y este es un atributo ARIA que va a anunciar cualquier cambio en este componente, por lo que cuando agregamos un mensaje de error, algo como un lector de pantalla podrá anunciar ese mensaje a nuestro usuario, y lo he dejado vacío para comenzar, porque esto solo va a alertar a nuestro usuario de cualquier cambio en este nodo de párrafo.

Entonces, veamos qué tipo de prueba realmente simple podríamos hacer para un componente de contenedor de registro de Slack. Vamos a probar que myAlert se actualiza cuando el campo de entrada pierde el enfoque y no se agrega una dirección de correo electrónico válida. Voy a renderizar mi componente de contenedor de registro y obtener referencias a los componentes myInput y myAlert. Voy a enfocar en mi campo de entrada y afirmar que theAlert no contiene ningún texto, porque nuevamente la alerta debe estar vacía cuando se renderiza en la página. Luego voy a salir de ese componente de entrada y ahora voy a afirmar que myerrorMessage debe tener el contenido de texto que coincida con el valor de myerrorMessage que le he pasado. Tal vez haya muchas partes móviles, pero los principios rectores son los mismos en este caso. Estamos comprobando que los comportamientos de estos componentes, a medida que se unen, son accesibles en las diferentes etapas. Podemos comprobar que nuestros componentes contengan los atributos ARIA correctos, la navegación adecuada mediante teclado, aunque haya varios componentes que se unan para una funcionalidad.

Ahora hablaremos de las pruebas de extremo a extremo. Estas son pruebas que probablemente se acerquen más a cómo nuestro usuario va a experimentar nuestros sitios web o aplicaciones. Básicamente vamos a evaluar las mismas cosas que con nuestras pruebas de usuario e integración, pero ahora lo haremos dentro del contexto de un flujo de usuario completamente desarrollado.

8. Pruebas con Cypress.io y Conclusiones Finales

Short description:

Cypress.io es un marco de pruebas de extremo a extremo de código abierto con un excelente soporte de accesibilidad. El complemento Cypress Acts verifica los errores de accesibilidad e se integra en su conjunto de pruebas. Usando Cypress, podemos probar el flujo del usuario, la navegación y el soporte de accesibilidad. Nuestras herramientas ayudan a prevenir errores de accesibilidad y generar auditorías para mejorar el soporte de accesibilidad. Realice cambios incrementales para solucionar los errores de accesibilidad.

Cualquier tipo de páginas completas o incluso nuestras aplicaciones completas. Me gusta usar Cypress.io. Este es un marco de pruebas de extremo a extremo de código abierto. Es realmente excelente para las pruebas impulsadas por el navegador y tiene un excelente soporte de accesibilidad.

Otro beneficio es que Cypress tiene este complemento llamado Cypress Acts que me gusta mucho. Es bastante similar a Lighthouse y React Acts en el sentido de que verifica los errores de accesibilidad, excepto que está integrado directamente en su conjunto de pruebas. Mantiene todas sus validaciones en un solo lugar y permite una integración sencilla en su canal de CI/CD.

Usando Cypress, escribamos una prueba muy simple para el mismo formulario de registro de Slack que acabamos de mencionar. Queremos saber si nuestro componente de registro de Slack funciona solo con el teclado. Vamos a buscar nuestro campo de entrada accesible. Vamos a escribir una dirección de correo electrónico válida, presionar Tab para llegar al botón Enviar y luego presionar la tecla Enter para enviar nuestra dirección de correo electrónico. Por último, vamos a comprobar que nuestra alerta accesible se actualice con ese mensaje de éxito.

Ahora, eso fue realmente rápido, simple y muy pequeño, pero esto prueba todo el flujo del usuario de nuestro formulario de registro de Slack cuando enviamos correctamente una dirección de correo electrónico a este formulario. Podemos hacer esto simulando el uso solo del teclado. Eso es lo que queremos comprobar en nuestras pruebas de extremo a extremo, específicamente. Queremos comprobar cómo interactúa el usuario con mi aplicación o mi sitio web. ¿Cómo puedo traducir eso en una prueba y validar que funcione, y cómo lo hago a través de una perspectiva de accesibilidad?

También podemos probar que estamos alertando de errores de la misma manera que lo hicimos en nuestra prueba de integración, asegurándonos de que los errores se anuncien correctamente a nuestros usuarios. O podemos ir un paso más allá y preguntarnos, ¿qué sucede si quiero probar todo mi flujo de navegación? ¿Qué sucede cuando un usuario utiliza una aplicación de una sola página? ¿Y cuáles son las implicaciones para la navegación y el soporte de accesibilidad? En las pruebas de extremo a extremo, estamos pensando en nuestros usuarios, pensando en el flujo de nuestros sitios web y luego nuestras aplicaciones, y descubriendo cómo queremos validar todos estos conceptos a medida que se van uniendo.

Y eso es todo para las pruebas. Eso fue mucho para cubrir utilizando solo los tres tipos de pruebas en los que generalmente nos enfocamos. Nuestras pruebas unitarias serán para las API y los comportamientos de nuestros componentes. Las pruebas de integración serán para los componentes que interactúan entre sí o dependen de otros componentes, y las pruebas de extremo a extremo son para validar flujos de usuario completos. Entonces, juntando todo eso, nuestras herramientas nos ayudan a prevenir que se introduzcan errores de accesibilidad mientras escribimos código, lo comprometemos en bases de código y lo implementamos en producción. Nos ayudarán a generar auditorías y descubrir dónde podemos mejorar nuestro soporte de accesibilidad. Y luego, en nuestras pruebas, cubrimos las pruebas unitarias, de integración y de extremo a extremo, cuándo es apropiado usar cada tipo y qué probar cuando trabajamos en cada categoría.

Ahora, eso fue admitidamente mucho para cubrir en un tiempo muy corto. Y aún hay mucho que no hemos descubierto, que será realmente fundamental para crear un flujo de desarrollo de accesibilidad que beneficiará a sus proyectos y sus equipos. Entonces, si puedo dejarles solo un consejo que quiero que se lleven, es que, admitidamente, puede ser abrumador si es la primera vez que piensan en la accesibilidad de sus proyectos. Y están evaluando el trabajo que se necesita para llevarlo a los estándares y crear procesos realmente confiables en torno a ellos. Por lo tanto, no se espera que tengan un sitio completamente accesible o una cobertura de pruebas del 100% el primer día. Les insto a realizar cambios incrementales donde puedan y a eliminar consistentemente los errores de accesibilidad.

9. Implementando Pequeños Cambios para la Accesibilidad Web

Short description:

Implementar pequeños cambios conduce a una comprensión profunda de la accesibilidad web y la resistencia a errores. Los procesos de automatización y pruebas facilitan la construcción de una mejor web para todos. Gracias, React Advanced, por tenerme aquí. No dudes en hacer preguntas o conectarte en Twitter.

Eventualmente, implementar esos pequeños cambios va a sumar para tener una comprensión realmente profunda de lo que se necesita para hacer que tu sitio web sea accesible. Y cómo hacerlo resistente a los errores que están rondando. Y una vez que tengas esa comprensión, y tengas tus procesos de automatización y pruebas en su lugar, será más fácil hacer que tus sitios web funcionen para todos. Y eso significa que será más fácil construir una mejor web para todos.

Así que con un poco de trabajo al principio y eliminando lentamente todos estos diferentes errores, eventualmente podrás decir que estás haciendo mucho bien sin hacer nada en absoluto. Más o menos.

Muchas gracias, React Advanced. Realmente aprecio que me hayan invitado aquí hoy. Mi nombre es Yorayma Estevez. No dudes en revisar estas diapositivas o encontrarme en Twitter. Probablemente me quedaré un rato después de esta charla. Así que si tienes alguna pregunta, no dudes en encontrarme y preguntar. Gracias de nuevo.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn