Browser, API y Tecnología Asistiva: Un Triángulo Amoroso

Hola a todos. Vaya. Otra charla de conferencia. Es tan divertido acompañar como asistente de presentación. Pero me pregunto dónde estamos hoy. Oh, déjame verificar mi contexto aquí. No te preocupes por eso. Estamos en JS Nation en Ámsterdam.

He estado esperando estar en este escenario. ¿No es genial ver a todos aquí? Sí, lo es. Todos parecen listos para saber más sobre todas las diferentes capas involucradas en el viaje de accesibilidad. Lo siento, está retrasado. El video está retrasado.

¿Alguien quiere ser mi asistente? ¿Por favor? Solo tienes que leer el guion. Sí. ¡Muchas gracias! Lo siento. Lo siento por esto. Está bien. Tú leerás aquí. Eres el asistente. Sí. Pero ya hemos hecho esa parte. Bien. Entonces, sí. Todos parecen listos. Sí, lo es. Todos parecen listos para saber más sobre todas las diferentes capas que están involucradas en el viaje de accesibilidad. Ese es el espíritu. Tan positivo. Gracias.

Ahí. Para eso estoy aquí. Esta charla necesitó mucha investigación y enfoque. Recuerden, cuando no entendíamos todos los sistemas entre el desarrollador de software y la tecnología asistiva. Sí. Tienes razón. Mucha investigación, de hecho. Pero una vez que descubrimos que los sistemas podían compararse con un buen triángulo amoroso a la antigua, las cosas empezaron a tener sentido.

Sí. Y seguimos aprendiendo, ¿verdad? Porque los sistemas también están cambiando constantemente. Hace unos años, algunas APIs que discutiremos hoy ni siquiera eran compatibles. Whoa, whoa, whoa. Alerta de spoiler. Por favor, solo menciona lo que necesitamos saber ahora. Por supuesto. Lo siento. Querida audiencia, les guiaremos a través de cómo cada empresa contribuye a su relación de accesibilidad. Dónde está la fortaleza y dónde el drama.

Perfecto. Y aunque sabemos que el mundo es primero móvil, en interés del tiempo y porque la historia de la tecnología asistiva ha estado en los escritorios, nos centraremos solo en el viaje de accesibilidad en escritorios hoy. ¿Olvidé algo? No. Pero te estás quedando sin tokens. Si necesitas más tokens, puedo presentarte. ¿Te gustaría que lo hiciera? No, creo que puedo hacerlo yo mismo. Gracias. Gracias. Eso es hola mundo en el nombre en el idioma que me ha dado el nombre. Mi nombre es y soy sudafricano. Ahora vivo en Suecia y trabajo como ingeniero de software y defensor de la accesibilidad en la querida empresa de muebles para el hogar IKEA. También soy miembro del comité de conferencias en una de las conferencias de desarrolladores más grandes de Suecia ya.

Y soy voluntario y defensor de la accesibilidad digital, así como de cerrar la brecha digital. Les doy la bienvenida a esta charla. Es genial estar finalmente aquí. Mi objetivo es que al final de esta charla, hagamos que las pruebas de accesibilidad sean un poco menos frustrantes. Sé que he tenido mi buena dosis de frustraciones. A veces, solo a veces, en realidad no es tu código.

Vamos a entrar en ello. Voy a empezar con un caso. Hace unas semanas, dirigí una sesión de prueba de accesibilidad con mi equipo. Uno de mis colegas tuvo que probar la navegación por teclado. Y por lo tanto, no necesitaba un lector de pantalla. En el camino, encontró un problema de gestión de enfoque. Podía navegar en los elementos detrás del modal. Esto es obviamente un fallo porque un usuario que solo usa el teclado tendría que tabular a través de todo el contenido irrelevante detrás del modal para volver al modal.

Así que pedimos a otro colega que verificara. Mismo navegador, mismo sistema operativo, pero resultados diferentes. ¿Cómo era eso posible? Afortunadamente, me tenían a mí. Pero recogeremos pistas a lo largo de esta charla y veremos si podemos resolver esto. Nuestra primera parada es el navegador. Como desarrolladores, el navegador es la relación más cercana que tenemos con el viaje de accesibilidad. Cuando miramos nuestras DevTools, tenemos la posibilidad de ver que nuestro HTML se ha traducido en un árbol de accesibilidad. El árbol de accesibilidad es una extracción de nuestros roles, nombres y propiedades de nuestros elementos.

Estas son semánticas significativas que deben ser comunicadas por el lector de pantalla a los usuarios y a veces a otras tecnologías de asistencia como los lectores Braille. Así que cuando mapeamos el árbol de accesibilidad, en realidad tenemos orientación del W3C. Encontramos el cálculo del nombre accesible y la descripción así como las especificaciones de mapeo de accesibilidad. Estas especificaciones solo tienen un trabajo. Dado este elemento HTML, ¿qué debería poner el navegador en el árbol de accesibilidad? Así que si consideramos un botón, la especificación de mapeo de accesibilidad HTML pondrá en el rol, estado y propiedades del botón. El cálculo del nombre accesible y la descripción luego llenará el nombre y el espacio de descripción. Las especificaciones definen qué debería estar en el árbol de accesibilidad, pero no hablan sobre la estructura de este. Cada navegador tiene la flexibilidad de cómo pueden aplicarlas.

¿Y qué significa esto? Significa que cada navegador crea su propio árbol de accesibilidad. Un árbol de accesibilidad interno. Por ejemplo, algunos navegadores aplanan algunos puntos de datos más que otros. Así que a diferencia del árbol DOM, el árbol de accesibilidad no está estandarizado. Esto presenta la primera capa de discrepancia en nuestros datos. El siguiente punto va a ser nuestras APIs de plataforma. Comenzaré con algunas encuestas del número 10 de la encuesta de lectores de pantalla por WebAIM y luego el informe del estado del frontend por Software House. Por un lado, tenemos la mayoría de los usuarios de lectores de pantalla usando Mac, usando Windows como su sistema operativo principal. Y luego, por otro lado, tenemos a los desarrolladores frontend usando Mac como su sistema principal cuando están trabajando. Esto ya presenta una descoordinación en el viaje de accesibilidad.

Y digo esto porque los sistemas operativos tienen sus propias APIs de accesibilidad. Las APIs proporcionan protocolos para transmitir la información necesaria desde el árbol de accesibilidad a la tecnología de asistencia. Las APIs no se coordinan entre sistemas operativos. Nuestra primera API es la de Mac y se conoce como AX API. VoiceOver tiene una integración profunda con esta API. Y luego, siguiendo eso, tenemos la API moderna para Windows que es la UI automation y Microsoft Active Accessibility es una antigua y ha sido superada por UI automation. Narrator, JAWS y NVDA son capaces de soportar ambas APIs de Windows. Estas APIs se encuentran en el sistema operativo y el navegador y cualquier aplicación así como tu aplicación personalizada puede comunicarse con ellas. Pero también tenemos algo especial. Tenemos iAccessible2 y esta es otra API de accesibilidad pero en realidad está incrustada en el navegador, a saber navegadores basados en Chromium así como Firefox. Así que, no se encuentra en el sistema operativo. Antes de la adopción de UI automation, era la API principal para estos navegadores.

Antes de la adopción de UI automation, era la API principal para estos navegadores. Así que, hasta ahora, hemos hablado sobre el navegador y hemos hablado sobre las APIs de accesibilidad. Cada API tiene diferentes instrucciones sobre cómo manejar el árbol de accesibilidad. Así que entonces el árbol de accesibilidad no es una estructura fija única.

Es un modelo semántico que se remodela para adaptarse a cada API de plataforma. Esto es lo que mi sistema llama más drama, ¿verdad? Pasemos entonces a los lectores de pantalla. Nuestros lectores de pantalla convierten texto digital en voz sintetizada.

verdadero lector de pantalla se llamó IBM screen reader y fue lanzado en 1986. Desde entonces, hemos tenido algunos más inventados y utilizados. El lector de pantalla más popular según la encuesta es JAWS. Y JAWS es un lector de pantalla de pago para Windows. Tenemos NVDA seguido de cerca en popularidad y es la opción gratuita y de código abierto. VoiceOver es la opción nativa para dispositivos Apple. Ha habido muchos desarrollos e innovaciones interesantes en IA para la tecnología de lectores de pantalla. Por ejemplo, Apple anunció recientemente algunas nuevas características en VoiceOver.

Prometen descripciones de imágenes más detalladas y contextualizadas por IA. Bien. Entonces, esos eran nuestros componentes y sus cualidades. Pero no actúan solos, ¿verdad? Podemos tener varias combinaciones dentro del sistema. Creo que deberíamos recorrer algunas de las combinaciones de navegadores y lectores de pantalla y ver qué está en juego. Podría ser más fácil comenzar con las combinaciones que estaban destinadas para Windows y Mac. Para Windows, el navegador sería Edge y luego narrator sería el lector de pantalla y Windows habría expuesto la API de plataforma de automatización de UI. Para Mac, tendríamos Safari y eso hablaría con el Mac OS y el Mac OS luego expondría la API AX al lector de pantalla VoiceOver. Cuando toda la pila es propiedad de una empresa, el flujo parece limpio.

Pero la vida no es tan simple. Solo el 7% de los usuarios de la encuesta de lectores de pantalla usan la combinación de VoiceOver y Safari. En realidad, hay numerosas y a menudo combinaciones mucho más complicadas a considerar. Chrome y Firefox son los navegadores que probablemente representan las mayores complejidades. Exploremos sus caminos. En este viaje, tenemos tanto APIs a nivel de sistema operativo como APIs integradas en el navegador. La automatización de UI es la API de accesibilidad para Windows y los navegadores y los lectores de pantalla están trabajando para soportarla como la predeterminada en lugar de IAccessible2. Chrome ha estado aumentando activamente su soporte para UIA. Así que, UIA es la API que se expone principalmente en Chrome en lugar de IA2, pero IA2 ahora tiene soporte para compatibilidad histórica. Para Firefox, tiene una adopción lenta para la automatización de UI y por lo tanto expone principalmente IAccessible2.

Entonces, JAWS tiene un soporte integral para tanto la automatización de UI como IAccessible2 y luego NVDA está aumentando constantemente su soporte para IAccessible2, quiero decir, para la automatización de UI, pero ahora mismo funciona principalmente con IAccessible2 y narrator solo soporta la automatización de UI. Tomémonos un momento para asimilar esa complejidad. Aquí hay otro dato curioso, ¿verdad? Entonces, JAWS y NVDA son realmente capaces de inyectar su propio código directamente en el navegador.

Ejecutan el código en el navegador, recopilan toda la información requerida y luego crean un búfer virtual. Este búfer virtual se entrega al proceso del lector de pantalla. Esto permite que el lector de pantalla procese las páginas web rápidamente sin consultar constantemente el sistema operativo de ida y vuelta.

Así que ahora voy a volver a nuestro acertijo porque esas son todas las pistas. ¿Cómo fue esto posible?

NVDA y JAWS tienen la capacidad de hacer conjeturas informadas cuando el HTML está mal. Esto significa que los errores pueden ser enmascarados. Tu código está realmente roto y si alguien lo está usando sin una tecnología asistiva, no funcionará para ellos. Si no hubiera estado allí para presenciar esto yo mismo, podría no haberlo creído. Si encuentras errores, lo responsable es reportarlos. Encontramos varios repositorios donde puedes encontrar errores que han sido listados.

Esto también nos ayuda cuando no estamos seguros de ir a estos repositorios y ver si hay algo que se relacione con algo con lo que estamos luchando. Pero, ¿no sería genial si hubiera un lugar donde pudiéramos encontrar qué funciona y qué no funciona para diferentes combinaciones? Aunque tenemos algunas opciones, puedes ir a A11y support y encontrar los resultados de diferentes pruebas que se han realizado relacionadas con lectores de pantalla. Aquí hay una prueba realizada en 2021. No quiero criticar a VoiceOver, pero es bastante fácil. Podemos ver que para VoiceOver, cuando tienes un área descrita por atributo y también tienes una referencia para role alert, no funciona. Así que han dado el resultado de la prueba aquí.

A veces, estas pruebas pueden estar desactualizadas, pero creo que es un buen comienzo. Otro proyecto que me gustaría destacar es el proyecto de datos compactos de accesibilidad de Lola Odelola. Quieren facilitar a los desarrolladores saber si una característica que funciona en el navegador también funcionará en tecnología asistiva. Quieren llevarlo un paso más allá e integrar realmente esa información en las herramientas y navegadores que ya usamos como desarrolladores, para que no tengamos que ir a otra plataforma para encontrar esta información. Luego te mostraré una diapositiva que reúne todo.

todo. Así que estas son las combinaciones de toda la accesibilidad, el viaje. Tenemos un árbol de accesibilidad interno por el navegador, tenemos APIs de plataforma que tratan los árboles de accesibilidad de manera diferente, y luego tenemos lectores de pantalla que tienen su propia compatibilidad con las APIs de plataforma. Creo que la frustración a veces cuando estamos tratando de depurar nuestra accesibilidad es que no tenemos la configuración correcta. Espero que este modelo mental y algunas de las complejidades que he discutido con ustedes hoy les proporcionen un proceso mucho más fluido.

Mi nombre es Tepisa Luhutjo, y les agradezco el privilegio de su tiempo. Ha sido un absoluto placer hablar con ustedes. Tenemos algunas preguntas, pero tengo una. Primero que nada, gracias por iluminarme. No sabía que había tantas incompatibilidades y tantos lugares donde las cosas podrían salir mal en ese flujo.

Para los desarrolladores que quieren o probablemente necesitan soportar múltiples sistemas operativos, ¿tienes una configuración preferida? ¿Estás usando máquinas virtuales para tratar de asegurarte de que puedes probar en todos? Creo que para mí, soy uno de los desarrolladores que usa Mac, así que ya estoy fuera de todo este proceso, y eso fue lo que me frustró. Sentía que cada vez que necesitaba probar, necesitaba ir a pedir prestada una computadora con Windows.

Quizás incluso tener un dispositivo dedicado o múltiples dispositivos. Definitivamente. Sí.

Muy bien. Esta primera pregunta es, ¿cuál es tu opinión sobre bibliotecas como React, ARIA? Oh, vaya. No conozco React, ARIA. ¿Estás familiarizado con solo los atributos ARIA en HTML? Sí, por supuesto. OK, OK. Así que ARIA en general, en realidad consulté a un usuario nativo de lector de pantalla sobre esta charla. Y ellos dicen que ARIA es en realidad el mayor—uno de los mayores problemas en la salida del lector de pantalla. Y si realmente miras el sitio web de soporte de A11y el 80% de las pruebas están relacionadas con problemas de ARIA. Así que hay algo problemático con eso. Y creo que también es porque cuando miras el cálculo del nombre y la descripción accesible tiene una forma de—tiene su propio algoritmo para averiguar cómo vamos a nombrar las cosas. Y con el tema de ARIA, hay diferentes prioridades que toma sobre diferentes cosas dependiendo de cómo pongas las etiquetas. Así que ARIA complica las cosas. Y entiendo por qué dicen que la mejor práctica es no usarlo. Pero entiendo que a veces es necesario. Sí. Pero ARIA definitivamente complica las cosas para los lectores de pantalla. No—tenemos que mirar eso. Y pensaría que esto se traslada a React, ARIA. Porque React, ARIA probablemente hace que esos estén disponibles para los componentes de React.

Así que vas a ver los mismos problemas que tendrías con el ARIA regular. Muy bien. Esta siguiente pregunta, ¿es posible o peor sobreetiquetar HTML con atributos ARIA usando tanto ARIA description como ARIA described by? Sí, creo que sí. Y como he—como he mencionado, ¿verdad?, el cálculo de nombres y compu—cálculo de nombres y descripciones, tiene su propio tipo de proceso sobre cómo—cómo elegirá cuál será el nombre y cómo elegirá cuál será la descripción. Pero de nuevo, cada navegador toma esa decisión también.

Así que sí complica las cosas, sí. Wow. Creo que el W3C, cuando miro las directrices, está tratando de avanzar hacia la estandarización de esto, porque ayudaría mucho si todos los navegadores hablaran el mismo idioma cuando se trata del árbol de accesibilidad. Correcto. Quiero decir, eso parece súper importante. Sí. Pero con suerte sucede pronto.

La siguiente pregunta, ¿hay una explicación para que algunos lectores de pantalla sean más populares que las opciones nativas del sistema operativo? Sí, quiero decir, y eso es realmente sorprendente, ¿verdad? Como si estás en Mac, pensarías que usarías principalmente VoiceOver. Y si estás en Windows, especialmente en Windows, pensaría que usarías Narrator porque es el que está integrado. Sin embargo, JAWS tiene una historia de ser el proveedor preferido para agencias gubernamentales para temas de salud pública. Así que cuando alguien se queda ciego y necesita apoyo del gobierno, JAWS es a donde te derivan y donde te enseñan sobre los lectores de pantalla y todo eso, por lo que luego se convierte en un estándar. Entiendo. Sí.

Y supongo que esos son generalmente productos de pago o propietarios. Sí. Exactamente. Así que tienen buen marketing. Entiendo. Sí. Y luego el siguiente, la accesibilidad siempre se sintió como una prioridad secundaria para las empresas. ¿Cómo impulsamos la narrativa de su importancia? ¿Qué te ha funcionado? Lo que me ha funcionado es que trabajo en una empresa que tiene muchos usuarios y consumidores. Y por supuesto, va a ser una empresa que van a observar, ¿verdad? Pero además de eso, si eres una empresa más pequeña, no lo sé. Creo que la empatía está aumentando en la sociedad. Y se trata de recursos, y creo que se necesita ser, quiero decir, incluso cuando las empresas lo priorizan, algunas personas tienen que abanderarlo.

Algunas personas tienen que hacerlo fuera del horario habitual. Y cuando miro a algunas personas muy influyentes y, ya sabes, progresistas en la comunidad de accesibilidad, la mayoría de ellas dicen que comenzaron primero haciéndolo ellas mismas y luego tuvieron que llevarlo a la empresa y decir, esto es. Creo que uno de los mayores problemas es que no hay estructura para los programas de accesibilidad. Así que es muy difícil saber qué quiere la empresa que les pidas. Pero si comienzas con algo, lo pruebas y funciona. Es mucho más fácil para una empresa decir, oh, OK, bueno, tienes el plan, vamos a por ello. Pero tomaría a alguien que tenga su propia iniciativa. Y eso no es fácil.

Sí. Lo encontré por experiencia personal porque he sufrido de síndrome del túnel carpiano antes. Y de vez en cuando no puedo usar mi teclado. Pero es tan curioso que no pienso en cuán accesibles son mis aplicaciones hasta que ni siquiera puedo usarlas. Sí, exactamente. También en el trabajo, también he realizado lo que llamo masterclasses de empatía de accesibilidad. Y robé esa idea de Skyscanner. Vi un video de ellos. Y básicamente solo sientas a tu equipo durante 30 minutos y los desafías.

Y como, usa solo el teclado, ya sabes, durante 10 minutos o pones algunas aplicaciones que puedes usar que desenfocan la pantalla o cubren la pantalla y dices, bueno, intenta navegar por nuestro sitio web y ve cómo se siente. Creo que si las personas realmente lo sienten por sí mismas, podría ser algo que luego recuerden. Como, en lugar de solo ir a mirar la guía, como esa cosa es muy difícil de leer. No me gusta leerla yo mismo. Pero cuando comienzas a decirle a la gente, OK, bueno, el hecho de que no puedas pasar por esto es como todos viven todos los días. Tal vez entonces comencemos a darnos cuenta de que, sí, esto ya no es divertido. Genial. ¿Alguna vez has usado vendas en los ojos en esas sesiones? No vendas en los ojos, pero puedo hacer que la pantalla se ponga negra. Sí. Y encontré un juego realmente genial que en realidad hace como una simulación de algunas de estas cosas. Es realmente divertido. Sí.

Así que hazlo divertido. Sé que apesta. Como, ¿por qué tenemos que hacer que las luchas de algunas personas sean divertidas? Pero es una buena manera de comenzar la conversación y no hacer que se sienta como una carga. Definitivamente. Sí.

Y este siguiente punto en la misma línea. ¿Cuál es la acción más importante que podemos tomar como desarrolladores para mejorar la accesibilidad? Creo que conocer a los usuarios nativos de lectores de pantalla o personas que usan tecnología de asistencia. Y quiero decir, no tienes que tener uno a tu lado. Pero, realmente, hay toneladas de videos.

Hay personas hablando de ello en línea. Me he encontrado con varias cosas en LinkedIn donde alguien está explicando incluso una habitación de hotel. No sabía que había cosas como habitaciones de hotel accesibles, ya sabes, como una alarma de incendio. Yo dependo del sonido, pero algunas personas realmente necesitan que la alarma de incendio tenga luz porque no pueden oírla.

Habrá un incendio y no podrán escucharlo. Así que creo que empieza a seguir a personas que están creando el contenido para que puedas comenzar a desarrollar esta empatía. Eso es para mí, lo más importante. Sé que no es una respuesta técnica, pero no creo que nuestra solución dependa de la tecnicidad cuando se trata de accesibilidad. Realmente comienza con un enfoque centrado en el ser humano. Definitivamente.

Probablemente tengamos tiempo para una pregunta más. Creo que elegiré esta sobre, sí, ¿cuáles son las formas más económicas y/o automatizadas de probar la accesibilidad que no tienen recursos para pruebas más detalladas o manuales? Bueno, en la era de la IA. Pero creo que, mira, si no tiene recursos, pruebas más detalladas y manuales, creo que es suficiente tener dos sistemas operativos diferentes y simplemente ejecutarlo con los lectores de pantalla respectivos, llegarás muy lejos. Si simplemente usas dos sistemas operativos separados. Mac con Safari, Windows con Chrome o Firefox. De acuerdo. Y creo que funcionará.

¿Tienes alguna experiencia con, creo que he visto que Playwright tiene como un plugin de accesibilidad. Correcto. Sí. ¿Recomendarías usar algo así también? Playwright es, creo, uno de los más populares y efectivos. Yo mismo no he entrado en lo automatizado todavía. Y es porque realmente me gusta tener una idea de las cosas. Pero creo que Playwright es una buena opción. Genial. Gracias por eso. Sí, por supuesto. Eso es todo el tiempo que tenemos para preguntas. Gracias por tu charla. Gracias. Sí.