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

Rate this content
Bookmark

Crear aplicaciones web puede ser desafiante. Crear aplicaciones accesibles - aún más. Sin embargo, el verdadero desafío radica en mantener la accesibilidad en tu proyecto, ya que requiere conocimientos y habilidades más allá de los de desarrollo web tradicional. Para lograr esto, debes elegir las herramientas adecuadas para mantener un alto nivel de accesibilidad cuando se refactoriza el código, monitorear el estado de accesibilidad y probarlo automáticamente durante la integración continua. Para abordar estos desafíos, presentaré un enfoque diferente que entrelaza la accesibilidad en el núcleo de la aplicación web mediante la creación de una biblioteca de componentes accesibles en React. Discutiré los principios, herramientas y técnicas que utilizo para probar y mantener el nivel de accesibilidad a lo largo del tiempo, y te proporcionaré la receta inicial para impulsar el cambio de accesibilidad en tu organización.

23 min
24 Oct, 2022

Video Summary and Transcription

La charla discute el viaje del orador en la creación de aplicaciones accesibles y la importancia de evitar que se envíe código inaccesible. Explora el proceso de construcción y creación de componentes accesibles, enfatizando el uso de etiquetas HTML apropiadas y realizando pruebas funcionales y de accesibilidad. La charla también destaca los beneficios de la automatización en la prueba y solución de problemas de accesibilidad. En general, enfatiza la importancia de la accesibilidad y proporciona consejos prácticos para incorporarla en el desarrollo de software.

Available in English

1. Mi Viaje en Accesibilidad

Short description:

La primera vez que tuve una prueba de accesibilidad, fue un éxito en un aspecto, pero un completo fracaso en el otro. Trabajamos duro para hacer que la aplicación fuera accesible, pero cada vez que hacíamos cambios, la accesibilidad quedaba atrás. El código estaba lleno de parches y trucos, no era mantenible a largo plazo.

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

2. Mi Viaje en Accesibilidad: Introducción

Short description:

En mi otro proyecto, hicimos las cosas de manera diferente para hacerlo accesible desde el principio y de manera mantenible. Esta charla trata sobre mi viaje en accesibilidad y la búsqueda de una biblioteca de componentes accesibles. La accesibilidad se trata de inclusión y permitir que todos usen tu aplicación. Queremos evitar que se envíe código inaccesible. Comenzamos probando la accesibilidad paso a paso, como los flujos de inicio de sesión, olvidé mi contraseña, registro, cierre de sesión, compra y contacto de soporte.

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

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

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

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

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

3. Building Accessible Components

Short description:

Otra opción es ir página por página y cubrir todo el aspecto de accesibilidad de la página de inicio. Podemos pensar en componentes y descomponer la aplicación en componentes más pequeños. Luego, nos enfocamos en construir cada componente de la manera más accesible posible utilizando las etiquetas HTML adecuadas. Finalmente, automatizamos las pruebas funcionales y las pruebas de accesibilidad.

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

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

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

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

4. Creating Accessible Components

Short description:

Identifiquemos algunos componentes: menús desplegables, selector de fechas y un botón de búsqueda. Estos componentes pueden tener diferentes estados y apariencias. Los separamos en un repositorio común y nos enfocamos en pruebas funcionales y de accesibilidad. Nuestra pila de tecnología incluye React, TypeScript, Storybook, Cypress y CircusCI. Ahora, creemos un botón accesible que se pueda enfocar usando el teclado.

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

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

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

5. Creando Botones Accesibles

Short description:

Al crear botones accesibles, es importante proporcionar indicación de enfoque, admitir pulsaciones de teclas alternativas y utilizar el atributo de rol para informar a los lectores de pantalla. La etiqueta de botón HTML proporciona estas características de accesibilidad de forma gratuita, ahorrando tiempo y esfuerzo. Este enfoque se aplica no solo a los botones, sino también a otras etiquetas HTML como campos de entrada, etiquetas y encabezados.

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

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

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

6. Añadiendo Automatización y Pruebas de Accesibilidad

Short description:

Para agregar pruebas de componentes de accesibilidad, creamos un componente de botón utilizando la etiqueta de botón. Utilizamos Storybook para crear historias primarias y secundarias para el botón. Aislamos el componente en una pestaña separada para realizar pruebas funcionales y de accesibilidad. Utilizando Cypress, visitamos la URL, hacemos clic en el botón y verificamos que se registre el clic. Esperamos que un marco de trabajo de accesibilidad encuentre texto alternativo faltante, botones no enfocables, ventanas emergentes inaccesibles y contraste de color insuficiente. En Events, utilizamos nuestras propias herramientas y un SDK para Cypress para recopilar problemas de accesibilidad y ejecutar validaciones.

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

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

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

7. Ejecutando Pruebas Funcionales y Solucionando Problemas

Short description:

Así es como se ve. Ejecutamos la prueba funcional, verificamos problemas de accesibilidad y corregimos cualquier error. Reemplazamos el problema de contraste de color con negro. Este proceso ocurre en nuestro pipeline. Nuestra biblioteca de componentes consta de más de 40 componentes utilizados en cuatro proyectos. La biblioteca y nuestro enfoque nos salvaron durante un esfuerzo de rebranding. Lecciones aprendidas: dividir y conquistar, ser amigos de HTML y automatizar tanto como sea posible.

La parte central de la prueba, puedes identificarla desde antes. Esta es la misma prueba, la prueba funcional. Ahora, antes de ejecutar la prueba funcional, llamamos a evstart, para que comience a obtener problemas de accessibility y después de que se haya realizado el clic, esperamos que no haya problemas de accessibility en absoluto. Así que vamos a intentarlo.

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

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

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

8. Conclusiones sobre la Accesibilidad

Short description:

La accesibilidad no se enseña en la academia o en los bootcamps, pero es importante. No lo pienses demasiado, comienza con un componente a la vez. Gracias por escuchar, fue divertido hablar en la conferencia. Estaré disponible para preguntas y no dudes en contactarme en LinkedIn o en mi blog. La accesibilidad es más accesible de lo que piensas.

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

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

Muchas gracias. Me retiro.

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 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2022React Summit 2022
17 min
Composition vs Configuration: How to Build Flexible, Resilient and Future-proof Components
Top Content
There are many ways of authoring components in React, and doing it right might not be that easy, especially when components get more complex. In this talk, you will learn how to build future-proof React components. We will cover two different approaches to building components - Composition and Configuration, to build the same component using both approaches and explore their advantages and disadvantages.
React Advanced Conference 2021React Advanced Conference 2021
21 min
Building Cross-Platform Component Libraries for Web and Native with React
Top Content
Building products for multiple platforms such as web and mobile often requires separate code-based despite most of the components being identical in look and feel. Is there a way where we could use shared React component library on different platforms and save time? In this presentation I'll demonstrate one way to build truly cross-platform component library with a unique approach of using React & React Native in combination.
TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Top Content
Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.

Workshops on related topic

React Summit 2023React Summit 2023
137 min
Build a Data-Rich Beautiful Dashboard With MUI X's Data Grid and Joy UI
WorkshopFree
Learn how to put MUI’s complete ecosystem to use to build a beautiful and sophisticated project management dashboard in a fraction of the time that it would take to construct it from scratch. In particular, we’ll see how to integrate the MUI X Data Grid with Joy UI, our newest component library and sibling to the industry-standard Material UI.
Table of contents:- Introducing our project and tools- App setup and package installation- Constructing the dashboard- Prototyping, styling, and themes - Joy UI features- Filtering, sorting, editing - Data Grid features- Conclusion, final thoughts, Q&A
React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
Workshop
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Workshop
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Workshop
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)
React Summit Remote Edition 2021React Summit Remote Edition 2021
91 min
Creating Accessible React Native Apps
Workshop
React Native is a framework used to create native iOS and Android apps in a way web developers may already be familiar with. But how do you ensure your React Native apps are inclusive and usable everyone? Scott will share tips on how to test and build React Native apps with accessibility baked-in!