Cómo hacer el bien sin hacer nada

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.

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.

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.

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.

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.

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.

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.

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.

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.