Elementos Interactivos Anidados: Una Pesadilla en Accesibilidad

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

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

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.

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.