My Heart Is In the Right Place, but the DOM Isn't

Hola a todos. Me llamo Kyle West. Soy ingeniero web y líder de accesibilidad para Family Search. El título de mi charla es Mi Corazón Está en el Lugar Correcto, pero el DOM No. Uno de mis roles principales es que soy coautor de nuestra biblioteca de sistemas de diseño React, que se utiliza mucho en todos nuestros productos. Como autor de un sistema central que es utilizado por la mayoría de nuestros, casi todos nuestros usuarios, siempre he sentido una responsabilidad adicional por construir un producto accesible que esté disponible para todos. Esto a menudo me ha llevado a la guía de prácticas de autoría ARIA, que es proporcionada por W3C. Es un recurso maravilloso para cualquiera que esté tratando de construir un producto que se ajuste a las mejores prácticas de la industria.

Si has estado allí antes, sin duda habrás visto este banner en la parte superior, que dice, No ARIA es mejor que un mal ARIA. Tienen un enlace maravilloso al que podríamos hacer clic y leer juntos si quisiéramos, pero es muy lógico y explica totalmente por qué eso es importante. Pero he aprendido más que de la documentación. He tenido mis propias experiencias de vida. A lo largo de mi tiempo, he visto muchas veces en las que yo y otros hemos intentado hacer lo correcto, pero no lo hicimos lo suficientemente bien como para ser efectivos. Tengo unas tres de esas historias que me gustaría compartir contigo.

La primera para empezar, probablemente hayas oído hablar de spaghetti code y probablemente con él ravioli code, pero probablemente no hayas oído hablar de potato code, que es el título de mi primera historia. Para dar un poco de contexto, una cosa que hago es reunirme periódicamente con algunos de mis clientes ciegos para entender cómo es su experiencia e identificar cualquier problema que puedan estar enfrentando, obtener comentarios. Me reúno periódicamente con ellos. Una vez, estaba reuniéndome con una mujer que es ciega. Ella trabaja en nuestro departamento de soporte y a menudo atiende las llamadas de otros clientes ciegos. Esa semana, había notado algo que estaba un poco fuera de lo que esperaba, y quería mostrarnos cuál era el problema.

Si no estás familiarizado, la forma en que un usuario ciego interactúa con una computadora es a través de una herramienta llamada lector de pantalla, que toma la información gráfica mostrada en la pantalla y luego la lee en voz alta al usuario. Luego, el usuario tiene un conjunto elevado de atajos de teclado que le permiten navegar por la página. En otras palabras, en lugar de que tú le grites a la computadora, ahora la computadora te grita a ti. Bueno, para este caso particular, el problema que nuestro usuario había encontrado estaba en una página que se veía algo así. Tiene un encabezado en la parte superior con algunos detalles importantes sobre la información en la página, y luego una serie de tarjetas principales que contienen todo tipo de información importante, y luego una serie de barras laterales más pequeñas con algunos widgets de tarjetas más pequeñas que realizan ciertas acciones relacionadas con la página. El problema que ella quería señalarnos estaba en la parte inferior de la sección de la barra lateral, y mientras navegaba a esa parte de la página, en el camino, aproximadamente a la mitad de la barra lateral, el lector de pantalla dijo algo que encontramos muy intrigante. Dijo, Enlace potato. Ella simplemente lo pasó por alto como si no fuera gran cosa. Dijimos, espera, espera, espera, vuelve atrás. ¿Dijiste potato, o el lector de pantalla dijo potato? Ella dijo, sí, lo hizo.

Cuando la gente me pregunta al respecto, les he estado diciendo que no es realmente una patata. Es solo un carácter o algo que nuestro lector de pantalla no entiende, y por eso se confunde y dice patata. Pero no es realmente una patata, así que pueden simplemente ignorarlo. Bendita sea. Ella tenía tanta confianza en nosotros, los ingenieros, que asumió que era el lector de pantalla el que tenía el problema y no nuestro código.

Bueno, yo no confío tanto en nuestro código, así que fui y traté de encontrar esto de inmediato. No me llevó mucho tiempo llegar a esta pequeña joya donde, como puedes ver, alguien había codificado manualmente la etiqueta ARIA de patata en un icono. Si no estás familiarizado, ARIA label es un atributo especial que el lector de pantalla utiliza para que nosotros podamos decir, oye, para esta parte del DOM, usa el valor dado para describirlo.

Así que cuando llegamos allí con el lector de pantalla, dijo patata, lo cual no es realmente ideal para la situación, ya que obviamente no era una patata. La mayoría de las veces, una etiqueta ARIA es algo bueno tener, pero en nuestro caso, simplemente se puso allí de manera superflua, lo que me da la definición de lo que ahora llamo código patata, que es código que nunca debería haber pasado una revisión de código. Este es un ejemplo claro de que no ARIA es mejor que un mal ARIA.

Resulta que uno de mis amigos cercanos, él es quien escribió esto, y si no hubiera hecho nada, el lector de pantalla simplemente habría leído esto como un gráfico sin etiqueta y luego habría seguido, pero no, mis amigos me escucharon hablar una y otra vez sobre accesibilidad y que es importante que pongamos etiquetas apropiadas en iconos e imágenes, y entonces él se dijo a sí mismo, esencialmente, no sé qué poner aquí ahora mismo, pero volveré a ello más tarde, y luego continuó y terminó lo que estaba trabajando en, pero se olvidó de volver. Un desarrollador junior hizo la revisión, se fusionó, y luego siguió su camino alegre hacia los clientes.

Afortunadamente, esto es una solución bastante fácil. La primera opción que tenemos es simplemente proporcionar un valor legítimo para la etiqueta. De esta manera, el usuario puede, cuando navega hacia ella, conocer su relevancia y que el lector de pantalla pueda comunicar eso al usuario. Sin embargo, debes saber que no todos los usuarios de lectores de pantalla hablan tu idioma, así que un consejo que tengo es asegurarte de que estás traduciendo tus etiquetas si tu sitio soporta más de un idioma. Solo para asegurarte de que sea comprensible para todas las personas que usan tu sitio web.

Otra opción, y esta es la que creo que terminamos usando, fue utilizar un atributo llamado aria-hidden, y en caso de que no lo sepas, aria-hidden es un atributo que le dice al lector de pantalla, oye, esta parte del DOM, puedes simplemente ignorarla por cualquier razón, y así el lector de pantalla simplemente la omitirá. Esto es apropiado para usar en casos donde el elemento proporcionado no da ningún valor adicional a la página, típicamente para un propósito decorativo, y eso es lo que era en este caso. La etiqueta apropiada que podríamos haber puesto en el icono ya estaba dicha en el DOM justo al lado del icono. Habría sido un hermano, y eso ya estaba en texto visual, así que decidimos ocultar el icono ya que estaba todo dentro de un enlace.

El enlace ya estaba siendo etiquetado con el texto visual, lo cual es totalmente apropiado. Tengo algunas lecciones aprendidas de esta experiencia. La primera, ya que este es mi aprendizaje intuitivo de que no aria es mejor que aria mala, si mi amigo no hubiera hecho nada, entonces habría sido menos confuso que tener una papa aleatoria en el DOM. Otra lección que es algo bueno que cubrimos hoy fue que si tu producto está diseñado para soportar más de una localidad, asegúrate de que lo estás traduciendo. Cualquier etiqueta que pongas, nuevamente, porque no todas las personas hablan tu idioma, e incluso aquellas que tienen la necesidad de usar un lector de pantalla.

Entonces está bien ocultar elementos decorativos si solo proporcionan un valor visual simple, pero nada que sea semántico o necesario para entender tu página. Por último, mi consejo es que puedes evitar el código papa teniendo revisiones de código de calidad. Se ve bien para mí. Ese sello de goma no es realmente apropiado para todas las situaciones, especialmente aquellas que no son entendidas por todos. Esto es algo bueno para asegurarte de que estás revisando y probando tu código adecuadamente.

Mi próxima historia, la llamo Tabindex Everywhere. Tiene lugar al principio de mi carrera, cuando recién salía de la universidad, y no sabía cuáles eran las mejores prácticas. No sabía sobre lectores de pantalla, que eran una cosa, o nada sobre el APG o WCAG o todo eso. Todo lo que sabía era cómo escribir mucho y mucho código rápido, y eso no siempre es algo bueno. Un día, recibí un ticket de error. Decía algo defectuoso. Hemos estado recibiendo informes de que algunos usuarios no han podido usar el teclado para navegar en esta página, y luego un enlace a la experiencia. Genial.

Bueno, realmente no sabía lo que eso significaba. Todo lo que realmente vi fueron las palabras teclado y navegar, así que decidí hacer mi propia investigación. Fui a mi navegador favorito. Escribí algo de basura para ver qué aparecía, y luego encontré esto. Lo primero que apareció fue Tabindex, y sonaba exactamente como lo que necesitaba. ¿Quieres decirme que hay un atributo mágico que si lo pongo en cualquier elemento del DOM, lo hará enfocarse con el teclado? Genial.

Así que lo hice. Eso sonaba como lo que necesitaba. Hice lo que cualquier programador junior altamente prolífico haría. Pasé el siguiente sprint poniéndolo en todo. Lo puse en todos los encabezados. Lo añadí a cada párrafo. Lo puse en elementos de lista. Lo añadí a tarjetas. Hice que cada parte de una tabla fuera enfocada, y lo puse en botones y enlaces, que ya vienen con Tabindex, por cierto. Solo estaba siendo precavido, supongo.

Para asegurarme de que mi solución continuara funcionando, hice una serie de pruebas para simplemente solidificarla. Luego lo puse para revisión de código. Ahora, si no está claro ya, esta fue una mala idea hecha por alguien bien intencionado pero que no sabía nada de lo que estaba haciendo. Es un esfuerzo terriblemente equivocado. Tabindex no es accesibilidad. De hecho, mi amigo sentado a mi lado fue quien hizo la revisión de código, y recuerdo distintivamente que se inclinó sobre el escritorio y simplemente me miró y dijo, Kyle, ¿estás seguro de esto? ¿Estás seguro de que esta es la forma en que podemos hacer las cosas navegables con el teclado?

Simplemente lo miré y le dije, sí, creo que sí. Él no me discutió porque también era un junior, y se fusionó. Otra papa en el éter, si se quiere. Pero no hay necesidad de preocuparse. No era una gran papa. Simplemente resultó que esto estaba en una parte de nuestro sitio que estaba durante un período beta, por lo que nuestros primeros adoptantes lo encontraron. Eventualmente terminó siendo revertido, y lo único que realmente se perdió fue el tiempo de mi equipo. Aún así, no es algo bueno de tener.

Lo que debería haber hecho en su lugar era haber hecho más que simplemente cinco minutos de investigación. Me gustaría imaginar que si lo hubiera hecho, eventualmente habría encontrado la guía de prácticas de autoría. Como pueden ver en la captura de pantalla, tiene tantos detalles sobre las formas adecuadas de implementar características accesibles en sus productos, incluyendo descripciones sobre el soporte de teclado con ejemplos de código. Esto es lo que debería haber estado mirando, no la primera publicación de ayuda de codificación en un subreddit que apareció.

Así que las lecciones que aprendí de esta experiencia, nuevamente, esto se solidificó en mi historia personal, no ARIA es mejor que un mal ARIA. Lo que construí fue muy confuso y más difícil de navegar que si no hubiera hecho nada. En retrospectiva, habría sido mejor para el usuario si simplemente hubiera sido perezoso y mentido sobre arreglar el error que haber hecho lo que hice. No estoy animando a nadie a mentir sobre su trabajo, deben ser honestos. Pero así de mala fue la experiencia, no solo para el mantenimiento, sino al pasar por ella.

La verdadera mejor práctica de esto, sin embargo, para mí, es que necesitaba familiarizarme con las mejores prácticas. Y eso incluye al revisor también. Tanto como codificador como revisor, tenemos la responsabilidad de asegurarnos de que nuestros usuarios entiendan o que entendamos qué es una experiencia accesible para nuestros usuarios. Necesitamos asegurarnos de que estamos haciendo las cosas de la manera correcta. Como adivinar no es una opción viable o factible. Necesitamos, hay muchos recursos reales para ayudarnos y deberíamos estar confiando en ellos.

Esta última historia es un poco más seria, si no puedes decirlo por mi título, no me hagas vomitar. En este punto de mi carrera, habíamos estado trabajando en accesibilidad durante mucho tiempo. Se hicieron muchos grandes esfuerzos. Por supuesto, había mucho trabajo por hacer y muchos errores. Pero en general, los grandes problemas se habían resuelto y me sentía cómodo con eso.

Sentía que estábamos en una muy buena posición. Luego, un día recibí un mensaje que hizo que mi corazón se hundiera. Esto fue de un usuario. Y lo que escribieron fue, el problema es que no puedo pasar casi nada de tiempo usando el sitio web porque me provoca náuseas. Las animaciones me marean. Por favor, elimínelas. Te lo ruego.

Sabía inmediatamente qué estaba mal. Este usuario tiene, probablemente tiene, lo que llamarías un trastorno vestibular, que es una situación bastante compleja. Pero esencialmente, lo que sucede es que son muy sensibles al movimiento y a los efectos de paralaje e incluso a los colores de alto contraste. Esencialmente, lo que está sucediendo es que la información visual que tu cuerpo está recibiendo entra en conflicto con la otra sensorial, en particular, la información que viene de tu oído interno. Tu cerebro piensa que algo está mal, y te hace sentir náuseas, podría hacerte vomitar.

Si alguna vez experimentaste mareos, como al viajar en un vehículo, entonces has experimentado una disfunción vestibular. Un trastorno vestibular, experimentan sensaciones similares pero todo el tiempo. No es muy divertido. Afortunadamente, la mayoría de los navegadores soportan una media query llamada prefersReduceMotion. Esto expone las preferencias de accesibilidad del sistema operativo para que podamos adaptarnos a ellas y ajustar nuestras animaciones según sea necesario.

La cuestión fue que me sorprendió recibir esta carta, porque pensé que ya había solucionado este problema. Hace un tiempo, habíamos escrito un código que se veía algo así que le decía a nuestra biblioteca de animación, usamos React Spring, es una biblioteca bastante buena si no estás familiarizado con ella. Le estábamos diciendo a la biblioteca de animación que simplemente omitiera las animaciones si el usuario prefería reducir el movimiento. Esto funcionó cuando lo fusionamos. Pero la mayoría del código eventualmente retrocede, y con el tiempo, lo perdimos. No teníamos pruebas de aceptación suficientes para esta característica en particular. Terminó pasando desapercibido y eventualmente llegó a los usuarios en un estado defectuoso.

Afortunadamente para nosotros, entre el momento en que se rompió y cuando nos enteramos, React Spring había reducido un nuevo hook llamado useReduceMotion que hacía exactamente lo que necesitábamos, y funciona perfectamente. Lo implementamos, y ha sido genial desde entonces. Para tu información, hay varios tipos de estas consultas que podrías usar. Probablemente hayas usado el prefers color scheme si alguna vez implementaste un tema para tu aplicación. No muchas personas piensan en eso como un problema de accesibilidad, pero está haciendo que el sitio web sea más cómodo.

La accesibilidad es solo usabilidad para más personas. Cuanto más cómodo podamos hacer nuestro sitio web, más tiempo pasarán los usuarios en él, y mejor estarán por ello. Estos ni siquiera son todos, por cierto. Es solo lo que quería incluir en la diapositiva. Sabemos sobre prefersReduceMotion juntos aquí. También hay contraste y transparencia para los que puedes hacer consultas y poder hacer la experiencia más cómoda. No tienes que usarlos todos para todas las experiencias, pero mejorar la experiencia para tu usuario nunca es algo malo. Ahora estamos preparados, en cuanto a las lecciones aprendidas, para enmendar nuestro mantra del día, que es que ningún ARIA es mejor que un mal ARIA, excepto si no haces nada y hace que tus usuarios vomiten.

Generalmente se considera una mala práctica que tus usuarios asocien sentimientos de náuseas con tu producto. No es realmente bueno para el negocio. Podemos honrar nuestras preferencias de DOS para evitar eso. Si lo hacemos, los usuarios, nuevamente, pueden pasar más tiempo en el sitio web, y luego todos los beneficios que vienen de eso.

La mayor lección que aprendí de esto es que necesitaba tener pruebas de aceptación más inclusivas. Si lo hubiéramos detectado antes, habría sido mejor. El usuario nunca se habría sentido mareado al usar nuestro producto, con suerte. Entonces podríamos haber evitado toda la situación si hubiéramos tenido mejores pruebas.

Lo siento, por cierto, si fuiste tú. Me siento mal de que alguna vez llegáramos a ese punto. Bueno, eso es todo el tiempo que tengo para historias hoy, pero quería dejarte con esta cita. Es de uno de mis héroes personales, Fred Rogers. Él dijo que los seres humanos son mucho más maravillosos que las máquinas. Para mí, esto es un recordatorio de que la vida humana es increíblemente única, y eso es lo que la hace hermosa.

Hay muchas personas para quienes el mundo no está construido, y tienen que vivir en él de todos modos. Por favor, considera el potencial que tienes para mostrar amor a los demás y reducir las cargas de las personas, al menos en las interacciones que tienen con tus productos. Tienes una tremenda capacidad para hacer el bien aquí, así que por favor hazlo. Muchas gracias. Nuevamente, mi nombre es Kyle West. Puedes encontrarme en Blue Sky o LinkedIn bajo KyleWestCS. También puedes encontrar estas diapositivas en mi sitio web, kylewest.dev, barra slides. Gracias de nuevo. Ha sido un placer. Te aprecio.