Elementos Interactivos Anidados: Una Pesadilla en Accesibilidad

Rate this content
Bookmark

Se han desarrollado numerosas y notables nuevas experiencias de UX a lo largo de los años, como tarjetas que muestran una variedad de productos e ítems de listas clickeables con opciones de menú dinámicas, entre otros. Sin embargo, solo unos pocos son conscientes de los desafíos involucrados en la construcción de estas estructuras teniendo en cuenta la accesibilidad, y desafortunadamente, algunas de ellas son completamente inaccesibles.


En la charla de hoy, exploraremos algunos de estos patrones de UX web prevalentes y nos adentraremos en los desafíos ocultos que presentan. Si bien podemos ser capaces de mitigar algunos de estos problemas, otros sirven como cuentos de advertencia en accesibilidad.

23 min
23 Oct, 2023

AI Generated Video Summary

Los elementos interactivos anidados pueden causar problemas de accesibilidad en los sitios web, y el orador comparte una experiencia personal con un error de accesibilidad que involucra un componente de lista. Mitigar las estructuras interactivas anidadas implica limitar estos patrones durante el desarrollo y reestructurar los elementos existentes. El orador proporciona recomendaciones para mejorar la accesibilidad, como ajustar las propiedades de los roles y recopilar comentarios de los usuarios. La conclusión enfatiza la importancia de las soluciones accesibles y fomenta la compartición de recursos para construir experiencias más inclusivas.

1. Introducción a los Elementos Interactivos Anidados

Short description:

Bienvenidos a mi charla de hoy. Vamos a hablar sobre elementos interactivos anidados y una pesadilla de accesibilidad. Mi nombre es Catherine Johnson, ingeniera de software en Microsoft especializada en accesibilidad. Permítanme compartir una historia sobre mi interacción con los componentos interactivos de Nesta. Me encontré con un error de accesibilidad en nuestro sitio que involucraba un componente de lista. Inicialmente, la fila de la lista tenía un rol de botón, pero necesitaba ser un elemento de lista. Sin embargo, más tarde, recibimos comentarios de que debería ser un botón de nuevo. A veces, la orientación sobre accesibilidad cambia.

Bueno, bienvenidos a todos. Bienvenidos a mi charla de hoy. Vamos a hablar sobre elementos interactivos anidados y una pesadilla de accesibilidad. Mi nombre es Catherine Johnson, y gracias por acompañarme hoy. Entonces, como mencioné, mi nombre es Cat Johnson. Soy ingeniera de software. Trabajo en Microsoft, y enfoco gran parte de mi trabajo en los componentes web de front-end, específicamente en los componentes de React, y me especializo en accesibilidad. Aquí, por ejemplo, es uno de los sitios web en los que trabajo mucho en mi trabajo diario. Esta es la página de Tu Información en account.Microsoft.com. Hoy, voy a comenzar con una pequeña historia sobre mi trabajo y mi interacción con los componentes interactivos de Nesta. Entonces, en mi trabajo diario, estaré trabajando y programando como uno lo hace, y un día estaba trabajando, y me encontré con un error de accesibilidad en nuestro sitio. Estaba hablando con el probador, y me estaban explicando que había un problema con una sección de código en nuestra página. Esta era más o menos el área de nuestra UX con la que estaba teniendo un problema. Entonces, este contenedor completo aquí es un componente de lista que construimos en React. Aquí, puedes ver que tiene el rol de lista en HTML. Y dentro de él, tenemos una fila de lista dentro de esa lista, y tiene el rol de un botón. Le dimos el rol de botón porque toda esa fila de la lista es clickeable y es muy interactiva. Pero el error de accesibilidad nos dijo que, hey, el rol de lista, como el rol de botón, ahora necesita ser una lista. No es accesible. Entonces, recibí esa retroalimentación. Pensé, genial, perfecto. Vamos a eliminarlo, vamos a cambiarlo, vamos a cambiarlo a un rol de elemento de lista. Entonces, vuelvo a mi estación de trabajo, tecleo, lo arreglo. Envío el código, lo dejo en mi cerebro, y continúo mi trabajo. Entonces, pasan unos meses, estoy trabajando de nuevo, me encuentro con otro error de accesibilidad. Esta vez el probador me está explicando que es muy similar o está en la misma experiencia. Entonces, podemos ver que es la misma lista, todo tiene un rol de lista. Y esa fila que cambiamos a un elemento de lista, el probador de accesibilidad dijo, hey, no, no podemos tener un rol de elemento de lista en esto, todo esto es un botón y es clickeable y tiene interacción del usuario. Entonces, para los usuarios de lectores de pantalla, necesitábamos tener un rol de botón para explicar eso a los usuarios. Al principio, estaba un poco confundida con esta retroalimentación porque antes era un botón, pero ahora es un rol de elemento de lista, ¿cuál debería ser? Pero ¿sabes qué? A veces la accesibilidad

2. Elementos Interactivos Anidados y Errores de Accesibilidad

Short description:

Me encontré con un error de accesibilidad en nuestro sitio que involucraba un componente de lista. El error de accesibilidad indicaba que cuando los usuarios de lectores de pantalla navegaban a este botón interno, comenzaba a garabatearse y no se leía correctamente. Decidí que no iba a solucionar este problema de inmediato. Necesitaba investigar qué estaba sucediendo en esta experiencia para poder determinar realmente cuál es la mejor solución para nuestro sitio. Me di cuenta y descubrí que los problemas del lector de pantalla que estoy experimentando están todos relacionados con problemas en torno a los elementos interactivos anidados. Los elementos interactivos anidados son esencialmente elementos interactivos que están anidados dentro de otros elementos interactivos.

La orientación cambia. Así que, estaba como, está bien, no hay problema. Lo cambiaré a un botón. Eso está bien. No hay problema. Continúo con mi trabajo, lo arreglo, y luego pierdo totalmente la cabeza hasta algún tiempo después. Y de nuevo, trabajando en mi escritorio, recibo un error de accessibility, y este error de accessibility es ligeramente diferente. Así que, es la misma lista, la fila tiene un rol de botón, y dentro de toda esa fila, hay un botón que tenemos para los usuarios, y el error de accessibility indicaba que cuando los usuarios de lectores de pantalla navegaban a este botón interno justo aquí en el área verde, comenzaba a garabatearse, y no se leía correctamente. Y luego, encima de eso, el probador de accessibility dijo que toda la fila debería ser una lista de propiedades. Así que, en este punto, estoy simplemente alucinado. Estoy muy frustrado. No sé qué está causando el problema del lector de pantalla que hace que este botón interno se lea de manera extraña, pero hay muchos problemas de comunicación en torno a cuáles deberían ser estos roles y estas propiedades para que funcionen con los lectores de pantalla y las herramientas de asistencia. Así que, en este punto, decidí que no iba a solucionar esto de inmediato. Necesito investigar qué está pasando en esta experiencia para poder determinar realmente cuál es la mejor solución para nuestro sitio. Así que, comienzo a hacer algunas investigaciones. Empiezo a profundizar en ello, y he bloqueado el problema en dos puntos. Primero, necesito solucionar el problema del lector de pantalla porque en este momento tal como existe mi experiencia, está causando problemas y los usuarios que están utilizando lectores de pantalla u otras herramientas no pueden navegar a este botón interno y no pueden activar la experiencia que quieren usar. Luego el segundo problema que necesito solucionar es que necesito averiguar qué está pasando con este elemento de lista o botón o cualquier rol, como la falta de comunicación. ¿Por qué no está claro qué rol debería ser? Y necesito averiguar qué debería ser realmente. Así que empiezo a hacer algunas investigaciones. Empiezo a buscar en línea, buscando qué es el problema del lector de pantalla? ¿Qué está pasando ahí? Y es durante este proceso que me doy cuenta y descubro que los problemas del lector de pantalla que estoy experimentando están todos relacionados con problemas en torno a los elementos interactivos anidados. Así que vamos a profundizar en qué son los elementos interactivos anidados y por qué podrían estar causando problemas para nuestro sitio. Así que como una breve nota al margen, los elementos interactivos anidados son muy claros, como los elementos interactivos anidados son esencialmente elementos interactivos que están anidados dentro de otros elementos interactivos. Así que aquí hay un ejemplo muy simple y breve de código que es un gran ejemplo de muchos casos de elementos interactivos anidados. Tenemos un elemento que tiene un rol de botón y dentro de él tenemos un enlace que tiene un objetivo de clic específico. Ahora este ejemplo, cuando pensamos en HTML básico, mucho HTML básico no recomienda que pongamos botones dentro de enlaces. Así que si miras hacia atrás a la web de los años 90, nunca realmente tuvo sentido poner enlaces dentro de botones. Causaba problemas de objetivo de clic. Pero lo más notable es que realmente no había muchos buenos ejemplos de usuarios que quisieran una experiencia así. Y no se traducía bien al HTML. Así que muchos de los primeros sitios no tenían realmente enlaces dentro de botones y usabas un enlace o usabas un botón.

3. Mitigando Estructuras Interactivas Anidadas

Short description:

Los elementos interactivos anidados están causando problemas de accesibilidad en los sitios web. Se utilizan comúnmente para crear hermosas experiencias de UX, pero no se traducen bien al HTML y pueden romper la funcionalidad del lector de pantalla. Este problema es generalizado en nuestro sitio web, con tarjetas y listas clicables que contienen elementos interactivos anidados. Desanidar estos elementos no es fácil, por lo que se necesita un nuevo enfoque. Mitigar las estructuras interactivas anidadas implica limitar estos patrones durante el desarrollo y desmontar los elementos anidados existentes. También se recomienda restringir las configuraciones de los desarrolladores para evitar conflictos entre las características interactivas.

Pero a medida que ha evolucionado el tiempo con muchas experiencias de UX, y estoy seguro de que muchos de ustedes probablemente han notado esto en la web, es que tenemos muchas UX en estos días que tienen muchos superposiciones de objetivos de clic. Un gran ejemplo que encontré, que estaba en Google, es que tienen algunos problemas de Nest Interactive aquí también. Abajo, si alguna vez estás en la página de Google, siempre hay un montón de enlaces en la parte inferior de las páginas a las que vas con mucha frecuencia y uno de mis enlaces, todo, es un enlace para dirigirte a esa página pero anidado dentro de ella, dentro del HTML DOM, tienes un botón allí, que causará problemas con el lector de pantalla. Este es otro sitio que visito con mucha frecuencia. Puedes ver otro problema de elemento interactivo anidado donde tenemos este menú desplegable con un montón de enlaces y dentro de ese enlace tenemos otro botón que se expandiría y mostraría más paneles de navegación. Así que en este punto de mi investigación, estoy empezando a ver que los elementos interactivos anidados no son compatibles con HTML pero los estamos viendo en todas partes de la web. Y están allí principalmente para crear estas hermosas experiencias de UX pero no se traducen bien al HTML y tienen el potencial de causar problemas con el lector de pantalla porque los lectores de pantalla, se basan en HTML básico y cuando hay elementos anidados dentro de elementos interactivos, los lectores de pantalla realmente no saben cómo leer ese contenido por lo que se rompe. Así que viendo esto en toda la web, estoy empezando a darme cuenta de que esto está en todo nuestro sitio web. Está en todo nuestro sitio web. Tenemos nuestras propias experiencias de tarjetas clicables en Microsoft, cuenta en Microsoft.com. Aquí hay un ejemplo de una tarjeta clickable con el exterior es un objetivo de clic y también hay un objetivo de clic interno, ambos con las mismas propiedades de clic. Verás esto en toda nuestra experiencia de lista, lo que explica por qué estaba viendo tantos errores de accessibility en nuestra lista diciendo, mostrando que toda la fila es un elemento clickable pero también tenemos elementos clicables dentro de esa lista. O incluso tenemos elementos de lista enteros que todo el contenedor está destinado a ser como un botón pero está en un paquete en un contenedor de una lista. Así que en este punto, estoy empezando a confundirme mucho. Lo veo en todo nuestro sitio web. No sé qué hacer. Tampoco sé qué roles deberían tener estos elementos. ¿Hay alguna forma de que podamos usar un rol diferente o una propiedad de rol para cambiarlo para que no sea un elemento interactivo anidado? ¿Cómo lo desenredo? Me siento perdido porque cuando estoy investigando esta información en ese momento, no hay realmente buenas mitigaciones para el problema de los elementos interactivos anidados más allá de arreglarlo y no anidar ellos. Pero mirando nuestro antiguo sitio, viendo lo generalizado que era este problema, desanidar no era tan fácil como está documentado. Así que necesitaba probar un nuevo enfoque para solucionar esto para nuestro sitio web. Así que ahora hablemos de formas en que podemos mitigar las estructuras interactivas anidadas en un proceso de varios pasos para que podamos resolver esto para nuestros sitios web y no lidiar con mucho dolor. Así que lo primero que necesitas hacer si estás experimentando problemas interactivos anidados es que necesitas intentar limitar estos patterns desde el principio antes de que incluso desarrolles. Si puedes, antes de desarrollar, simplemente no hagas elementos interactivos anidados. Pero si tú ya tienes mucho código que tiene elementos interactivos anidados, por favor intenta desmontar esa experiencia interactiva anidada. Así que aquí puedes hacer eso simplemente tomando ese elemento interno y simplemente moviéndolo hacia afuera. Sé que probablemente en la práctica eso no va a ser tan sencillo, pero en general, si puedes, intenta desanidarlos y trabajar con el código para ver cómo podría funcionar. Otra cosa que podemos intentar que recomendaría es que limitamos las configuraciones de los desarrolladores en estas experiencias. Si posees una biblioteca de componentes React o creas otros componentes React, si estás permitiendo a los usuarios y otros consumidores de tus componentes pasar objetivos de clic o características interactivas, por favor restríngelos para que no pasen ninguna propiedad que pueda entrar en conflicto con otra. Todo el contenedor es clickable. Quizás restrinja si pueden pasar botones o enlaces dependiendo de la situación para limitar

4. Reestructurando Elementos Interactivos Anidados

Short description:

Para mejorar la accesibilidad, limita configuraciones de roles específicas y reestructura la experiencia para traducirla bien a los lectores de pantalla y herramientas de asistencia. Usa CSS para superponer elementos y apilarlos para efectos interactivos anidados. Ajusta las propiedades de los roles para mejorar la accesibilidad. Interactúa con los usuarios y recopila comentarios para crear una experiencia cohesiva. Comparte tus aprendizajes y documenta las soluciones. Reestructurar elementos interactivos anidados resultó desafiante debido a la complejidad y al uso generalizado de los componentes. En su lugar, concéntrate en transmitir el significado y mejorar la accesibilidad dentro de la estructura actual del DOM. Asegúrate de que los elementos de la lista tengan el rol de elementos de la lista. Restringe las propiedades para los botones dentro de las listas. Usa un rol genérico de grupo para contenedores con objetivos de clic internos.

Los elementos interactivos de NIST aparecen. Además, por favor limita configuraciones de roles específicas que podrían ser problemáticas para la experiencia. Si tienes un cierto componente, digamos que permites a los usuarios modificar la propiedad de rol en HTML, tal vez en lugar de hacerlo abierto, intenta y restríngelo a propiedades que aún preservarán la experiencia accesible de tu componente. Así que ahora, una vez que hayas intentado todas esas cosas, intentando limitar la exposición de estas experiencias interactivas de NIST, el siguiente paso es intentar preservar y reestructurar tu experiencia para que se traduzca bien a los lectores de pantalla y otras herramientas de asistencia. Así que volvamos al ejemplo de Google y lo que podemos intentar aquí. Digamos que intentas desanidar la experiencia y fuiste capaz de mover estos elementos aparte, pero aún quieres crear esa experiencia de UX de los botones superponiéndose uno al otro, similar a otros patterns en la web. Una cosa que podemos hacer para crear esa experiencia es usar CSS para superponer los elementos y hacer que se apilen uno encima del otro. Eso te está dando el efecto de elementos interactivos anidados sin todos los efectos negativos en la accessibility y los usuarios de lectores de pantalla.

Otra estrategia que puedes intentar aquí para preservar la experiencia de UX, pero aún hacerla accesible, es que puedes jugar con las propiedades de rol de diferentes elementos para hacerlos trabajar de manera mucho más efectiva. En este ejemplo, digamos que el objetivo de clic dentro de esta área es el mismo que el objetivo exterior. En ese caso, una recomendación sería cambiar el rol del contenedor a algo genérico que realmente no se muestre a los usuarios de lectores de pantalla, pero preservando los botones internos para que los usuarios de lectores de pantalla puedan pasar el ratón sobre esa experiencia y escuchar ese objetivo de clic para que sepan activarlo si quieren seguir ese enlace. Y finalmente, esta es una sugerencia que abarca todo es, te animo, si estás intentando reestructurar estas experiencias, has desanidado y estás intentando recrear esta sensación en la UX para los usuarios de lectores de pantalla, a crear grupos de enfoque, hablar con los clientes, hablar con las personas que usan herramientas de asistencia y obtener sus comentarios sobre la interacción existente, recomendaciones sobre cómo mejorar la experiencia, o incluso trabajar con tus PMs y diseñadores sobre cómo puedes usar otras herramientas de ingeniería para crear una experiencia cohesiva para los usuarios de lectores de pantalla y los usuarios que utilizan otras herramientas de asistencia.

Y luego, una vez que hayas hecho todo esto, ahora que has solucionado tu problema de elementos interactivos anidados y está bien detrás de ti, te animo a compartir tus aprendizajes. Yo te animo a escribir documentation, compartirla en línea en Stack Overflow, en conferencias si eso es lo tuyo, y compartirla en línea porque estos problemas con elementos interactivos anidados, cuando estaba investigando, no había ninguna documentation y unas pocas pepitas de información fue lo que me ayudó realmente a resolver y crear una solución que funcionó para nuestro sitio web.

Así que dado eso, hablemos de lo que decidimos hacer con nuestro sitio web. Lo primero que intentamos hacer fue limitar estos patterns. Y lo intenté realmente duro. Intenté desanidar estos elementos interactivos para nuestro sitio, pero fue una pesadilla. El problema con nuestro sitio web es que muchos de estos componentes fueron construidos como parte de nuestra component library interna y estaban muy bien, uno, estaban muy bien anidados, y dos, se usaban muy ampliamente en todo nuestro sitio web. Así que para desanidar estos elementos y reestructurarlo de una manera que funcionaría con los lectores de pantalla en una estructura de DOM de HTML, habría cambiado nuestras props muy salvajemente y requeriría mucho refactoring no sólo en nuestra component library, sino en todos nuestros sitios asociados. Así que decidimos que, bueno, tal vez podríamos explorar eso en el futuro, por el momento queríamos abstenernos de hacer ese cambio sustancial porque requiere tanto refactoring. Así que en lugar de eso, lo que decidimos hacer fue realmente enfocarnos en dada la estructura del DOM de nuestros componentes, ¿qué podemos hacer para reestructurarlo de una manera que transmita el significado a nuestros clientes y facilite a los usuarios de lectores de pantalla? Así que volviendo a ese bug inicial, de vuelta en mi historia, tengo esta experiencia de lista, toda la fila es un botón de rol, y hay un botón dentro de él y estamos experimentando usuarios de lectores de pantalla. El primer paso que nos dimos cuenta fue 1, ese rol necesitaba ser un elemento de lista. Sí, hay un elemento clickable y por eso estábamos obteniendo bugs de accessibility. Pero para hacerlo accesible y transmitirlo a los usuarios de lectores de pantalla, necesitas asegurarte de que todos los elementos de una lista son de rol de elementos de lista para que funcione bien con los lectores de pantalla.

Y luego, eso realmente ayudó y solucionó el bug de accessibility que estábamos experimentando en esta área de botón justo aquí porque ahora no está anidado dentro de un botón y causando todo este lío para los usuarios de lectores de pantalla. También restringimos las propiedades para esta experiencia de lista empezamos a ir a nuestros socios y a recomendar y añadir en nuestra documentation indicando que si tienes un botón dentro de tu experiencia que ya es un objetivo de clic, no se recomienda hacer que toda la región sea clickable, de esa manera no causas todos estos problemas. Pero también teníamos elementos de lista, tenemos una component library muy compleja, también teníamos listas donde toda la fila estaba destinada a ser un botón. Para esas situaciones lo que decidimos hacer fue asegurarnos de que el contenedor exterior para toda esa fila fuera de rol de elemento de lista, pero añadimos un rol adicional de un botón dentro de él. Así que cuando los usuarios de lectores de pantalla están navegando esta experiencia pueden escuchar y escuchar que este contenedor entero es una lista con elementos de lista y luego dentro del elemento de la lista hay un objetivo de clic al que pueden navegar.

Y luego para nuestras experiencias de carrito completas, para esta situación nos dimos cuenta de que a lo largo de nuestro sitio el contenedor entero de ese carrito es el mismo que el objetivo de clic interno, así que decidimos cambiar el rol del contenedor exterior a un rol genérico de grupo que básicamente es solo un término genérico que dice que toda esta área es una colección de cosas.

5. Conclusión y Llamado a la Acción

Short description:

Los usuarios de lectores de pantalla pueden navegar por el contenido de manera normal, pero escucharán un botón en la parte inferior. El contenedor permite clics del ratón para usuarios visuales. Se creó y compartió documentación para abordar los elementos interactivos anidados. Existe documentación limitada sobre los elementos interactivos anidados y sus desafíos con las herramientas de asistencia. El objetivo es reestructurar las experiencias para una mejor accesibilidad. Las soluciones accesibles están en constante evolución. Comparte recursos accesibles y ayuda a construir soluciones más inclusivas. Contáctame en catinthemachines.com para más. Gracias por acompañarme hoy.

Entonces, los usuarios de lectores de pantalla pueden navegar por este contenido tratándolo como una imagen normal, párrafo, contenido, texto, pero cuando navegan hasta el fondo escucharán que hay un botón en el que pueden hacer clic y se activará de la misma manera. También nos aseguramos de que para todo el contenedor se mantuvieran las propiedades de clic, de modo que los usuarios visuales que usan su ratón puedan hacer clic en toda la región al igual que en cualquier otro sitio web.

Entonces, una vez que terminé de rediseñar todo, fuimos con la estrategia para un sitio web, escribí mucha documentation, la compartí en mi organización, notificando a varios ingenieros sobre este problema de los elementos interactivos anidados, y documentándolo en nuestra component library para asegurarnos de que no recrearíamos los mismos problemas que habíamos encontrado tan incrustados en nuestra base de código.

Y luego, no estoy hablando de aquí. Uno de los grandes problemas cuando estaba investigando esto es que había muy poca documentation sobre los elementos interactivos anidados y lo desafiantes que son para las herramientas de asistencia.

Y mi esperanza aquí al compartir en esta conferencia hoy, es ayudarles a todos a saber cómo podemos reestructurar nuestras experiencias y nuestra UX para ser experiencias mucho más accesibles para todos los que las navegan.

Y al concluir esta presentación, quiero animar nuevamente a todos a que las soluciones accesibles están en constante evolución.

Las soluciones que aplicamos para las experiencias en nuestro sitio web funcionan para hoy, pero estamos constantemente evolucionándolas y reconstruyéndolas para ser mucho más accesibles.

Te animo a leer recursos y a compartir en línea las soluciones accesibles que aplicas en tus sitios web, y a ayudarnos a todos a construir y desarrollar soluciones más accesibles de las que todos podemos aprender.

Y si realmente disfrutaste esta presentación y quieres ver más de mí, puedes contactarme en catinthemachines.com.

Me encanta hablar sobre accessibility y la architecture web y los React components.

Contáctame allí si tienes alguna pregunta, o simplemente quieres saludar.

Muchas gracias por acompañarme hoy en esta presentación.

Espero que disfrutes el resto de tu tiempo en React Advance. Y espero que tengas un muy feliz Halloween.

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

TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
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.
JSNation 2022JSNation 2022
24 min
a11y and TDD: A Perfect Match
Accessibility has been web development's ugly duckling for quite some time now. I often get asked, "when should you test for a11y in your apps?" My answer is simple, "right from the start!". Regardless of the framework considered - React, Svelte, Vue, YourOwn™️ - as developers we are in a privileged position to help the ugly duckling grow into a beautiful swan. How? By diving deep into the pond and harnessing the power of Javascript APIs to build the right components for your web apps. And how can do you know you are building them right? By pairing Test Driven Development with the Testing Library family. Ready to grow your web apps into swans?
JSNation 2023JSNation 2023
10 min
Dialog Dilemmas and Modal Mischief: A Deep Dive Into Pop-Ups
Our design systems commonly feature components that show on top of other content: tooltips, date pickers, menus and teaching UI, to name just a few. Proposed updates to the web platform are about to make building these a whole lot easier. You might not even need JavaScript. In this talk, you’ll learn all about the upcoming ‘popover’ attribute, modality and the top layer.
React Advanced Conference 2021React Advanced Conference 2021
32 min
How to do Good Without Doing Anything
There’s no arguing that building accessible websites is a force for good. But ensuring that our React websites and apps work for everyone can be time-consuming and isn’t always easy to get right. Luckily, investing a little bit of time on your accessibility workflow and setting up a series of automated tools will end up saving you tons of time and energy in the long run.In this talk I will demonstrate how you can leverage automated tools, clearly documented code standards and a well-defined development process in order to make building and testing accessible React apps a breeze. I will discuss the ways that I automate certain aspects of my development workflows to catch accessibility errors, define and set up tests and go through the entire lifecycle of accessibility feature development using a real-world example.
JSNation 2023JSNation 2023
30 min
Accessible Component System Through Customization
Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization, and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance.
How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much accessible we can provide out of the box to our users? How much customization freedom is enough?
That's what my talk's about.

Workshops on related topic

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!