Configurando las Pruebas de Accesibilidad de Axe

Hola, mi nombre es Steven Lambert. Me identifico con los pronombres él, él. Soy líder técnico y gerente de personas en Deque Systems. También soy el desarrollador principal de AXe core, la biblioteca de pruebas de accessibility.

En caso de que todos quieran ponerse en contacto conmigo más tarde o conectarse, pueden encontrarme en Twitter usando el nombre de usuario @StevenKLambert. Pueden enviarme un correo electrónico a Steven en sklambert.com o pueden visitar mi sitio web, stevenklambert.com y contactarme allí.

Así que antes de sumergirnos en cómo configurar AXe, primero quería dar una breve descripción de qué es AXe y cómo usarlo en caso de que alguien no esté familiarizado. Así que AXe es un motor de accessibility para pruebas automatizadas de la interfaz de usuario web. Lo que significa es que AXe ejecuta un conjunto de reglas en una página o en tu code para probar problemas de accessibility.

Aquí hay un ejemplo de cómo usarías AXe en una página web. Primero cargarías un script cuyo origen apunta a la biblioteca central de AXe. En este caso, es de unpkg.com barra AXe guión core en la última barra AXe punto JS. Eso cargará la biblioteca principal de AXe en tu página. Una vez que se ha cargado, puedes usar un script de tipo módulo para esperar los resultados de AXe.run. Usando esos resultados, puedes registrar la propiedad de violaciones, que te mostrará cada regla que informa una violación. Aquí hay un ejemplo de cómo se vería eso.

Así que la propiedad de violaciones es un array donde cada índice del array es un objeto. Esos objetos listarán el nombre de la regla que falló así como cosas como el impacto en el usuario y todos los nodos que fallaron la regla particular. Así que en este ejemplo, estoy mostrando que hay una violación de landmark one main, las reglas de la página tiene encabezado uno y región están fallando.

¿Dónde puedes usar Axe? Bueno, Axe tiene muchas integraciones en varios idiomas y frameworks. La biblioteca principal es axe-core y se puede usar en el navegador o nodo directamente. También proporcionamos un puñado de integraciones en la línea de comandos y populares testing frameworks. Así que en npm, puedes mirar el espacio de nombres de axe-core y allí puedes encontrar la integración de CLI, un Playwright, un Puppeteer, un React, un WebDriver.IO y la integración de WebDriver.js. Este año, también lanzamos una nueva integración para VS Code, que se llama Axelinter y proporciona linting de accessibility para tu code que es consistente con el motor de reglas de Axe-Core.

Así que lo que eso significa es que a medida que escribes, obtendrás sugerencias de linting para cualquier cosa que podamos detectar. Por último, tenemos otras integraciones como las extensiones de Chrome y Firefox. También tenemos integraciones en Java y varias bibliotecas de Ruby, pero no cubriremos ninguna de esas para esta presentación. Solo hablaremos de integraciones compatibles con JavaScript y Node.

Así que ahora que sabemos qué es Axe y cómo usarlo, quiero hablar sobre cómo configurar qué reglas ejecuta Axe. Así que como mencioné, Axe ejecuta un conjunto de reglas que determinan los problemas de accessibility en una página.

Por defecto, Axe ejecutará todas las reglas soportadas. Ahora, qué reglas son soportadas depende de qué integración estés utilizando. Así que para Axe core y sus diversas integraciones de nodo, puedes encontrar las reglas soportadas yendo a la página de GitHub de Axe core. Allí, tenemos un directorio docs y el archivo rule-descriptions.md, que enumerará todas las reglas soportadas. Para Axe Linter, puedes encontrar la lista de reglas soportadas yendo a la página de VS Code Axe Linter. Para Axe core, hay alrededor de 91 reglas soportadas que puedes consultar. Y para Axe Linter, como mencioné, como solo un subconjunto de reglas tiene alrededor de 33 reglas soportadas.

Así que hay varias formas en las que puedes configurar qué reglas ejecutará Axe. Para empezar, puedes deshabilitar un conjunto determinado de reglas para que no se ejecuten durante una ejecución normal. También podrías especificar un conjunto determinado de reglas para ejecutar solamente, y también puedes ejecutar reglas que coincidan con una etiqueta particular. Ahora, para esta presentación, lo que voy a hacer es mostrar un ejemplo de cómo hacer esto en solo tres integraciones. Te mostraré cómo hacerlo en Axe core, te mostraré cómo hacerlo en un ejemplo de una integración de nodo como Puppeteer, y también te mostraré cómo hacerlo en Axe linter.

Así que primero, quiero hablar sobre deshabilitar reglas. Así que digamos como ejemplo que querías deshabilitar dos reglas particulares, las reglas de nombre de botón y etiqueta. Ahora, la regla de nombre de botón asegura que cada elemento de botón HTML tiene un nombre accesible, y eso se puede usar ya sea teniendo contenido de texto en el botón o que el botón tenga una etiqueta ARIA, ARIA etiquetado por, o atributo de título. La regla de etiqueta hace algo similar en que asegura que cada elemento de entrada tiene un nombre accesible, ya sea a través de un elemento de etiqueta asociado o usando la etiqueta ARIA, ARIA etiquetado por, o atributo de título. Así que para usar esto en ax-core, lo que harías es pasar un objeto de opciones a ax.run. El objeto toma una propiedad de reglas, cuyo valor también es un objeto. Cada clave de ese objeto es el nombre de la regla que quieres deshabilitar. Y luego el valor de eso es un objeto que toma una propiedad habilitada y puede pasar verdadero o falso. Ahora, verdadero es el comportamiento por defecto y eso significa que la regla se ejecutará, pasar falso deshabilitará la regla por lo que la regla no se ejecutará. Así que en este ejemplo, pasamos las reglas de nombre de botón y etiqueta y habilitamos falso en ambas. Para un CLI y un framework de prueba. Así que lo que harías es inicializar un nuevo objeto de constructor de ax que te permite encadenar un par de funciones a partir de él. Una de esas funciones que puedes encadenar se llama reglas deshabilitadas. Y la función de reglas deshabilitadas te permite pasar un nombre de regla o un array de nombres de reglas que deseas deshabilitar. Así que en este caso, podemos pasar un array de nombre de botón y etiqueta para deshabilitar ambas reglas. Y por último, encadenarías la función de análisis y eso entonces ejecutaría ax en esa página. Para ax linter, no tenemos una API que puedas usar. Así que en su lugar lo que haces es configurarlo a través de un archivo de configuración.

El archivo de configuración que puedes usar se llama ax-linter.yaml. Y ese archivo debe estar en la raíz de tu proyecto para que ax linter lo encuentre. Dentro de ese archivo YAML, establecerías la clave de reglas, que es un diccionario. Y cada clave de ese diccionario es entonces el nombre de la regla que deseas deshabilitar. Y el valor es verdadero o falso de nuevo, donde verdadero significa ejecutar la regla, que es el comportamiento predeterminado y falso significa deshabilitar la regla. Entonces, para este ejemplo en particular, pasamos el nombre del botón y la etiqueta y los establecemos en falso en el archivo YAML. Así es como deshabilitarías ciertas reglas.

Y ahora para hacer lo inverso, queremos ejecutar solo un conjunto determinado de reglas. Así que ahora digamos que en lugar de deshabilitar el nombre del botón y las reglas de etiquetas, querías habilitarlas y hacerlas las únicas reglas que se ejecutan. Entonces, para ax core, una vez más pasaremos un objeto a ax dot run ese objeto de opciones toma ahora la propiedad run only cuyo valor es ya sea un nombre de regla o un array de nombres de reglas a ejecutar. Entonces, en este caso, pasaríamos un array de nombre de botón y etiqueta y luego eso hará que ax solo ejecute esas dos reglas cuando devuelva resultados.

Para la CLI y los frameworks de prueba, lo que harías es inicializarías el constructor de ax una vez más y esta vez encadenarías la función con reglas y la función con reglas tomará un solo nombre de regla o un array de nombres de reglas y luego solo ejecutará esas cuando llames a analyze. Vale. Para ax linter, desafortunadamente, no tenemos una forma para ti de habilitar solo un conjunto determinado de reglas. Así que la única forma en que puedes hacer esto es que tendrás que deshabilitar todas las demás reglas y luego solo habilitar las que quieres. Entonces, ax linter tiene unas 33 reglas. Así que tendrías que listar todas las 33 reglas, poner falso para 31 de ellas y verdadero solo para las reglas de nombre de botón y etiqueta. De nuevo, para encontrar la lista de reglas admitidas, puedes ir a la página de la extensión ax linter de VS Code.

Así que ahora queremos ejecutar solo las reglas que coinciden con una etiqueta en particular. ¿Qué es una etiqueta? En primer lugar, las etiquetas son formas de categorizar las reglas en grupos. En la mayoría de los casos, se utilizan para agrupar las reglas por la versión de WCAG y el nivel de conformidad. Así que, por ejemplo, la etiqueta WCAG AA se utiliza para agrupar las reglas que se refieren a la conformidad WCAG 2.0 AA. Para ver qué reglas están asociadas con qué etiquetas puedes ir al repositorio de AxeCores y mirar el archivo docs slash rule dash descriptions MD una vez más. Para obtener una lista de las etiquetas admitidas, puedes ir al repositorio de GitHub de AxeCores a la carpeta docs y mirar el archivo API.md. Allí hemos vinculado una lista de todas las etiquetas admitidas. El resumen rápido para esas etiquetas admitidas suele ser WCAG 2.0 AA y AAA así como WCAG 2.1 AA y AAA.

Ahora, para axe-linter de nuevo, solo admiten un subconjunto de etiquetas, que creo que son WCAG 2.0 AA y AA y WCAG 2.1 AA y AA. Por lo tanto, axe-linter actualmente no admite ninguna regla AAA.

Para que AxeCore ejecute solo un cierto conjunto de reglas, una vez más usaremos axe.run, pasando un objeto de opciones y usando la propiedad run only una vez más. Pero esta vez, en lugar de pasar un conjunto de reglas, le pasaremos un conjunto de nombres de etiquetas. En este caso, las etiquetas WCAG 2 AA y WCAG 2 AA.

Ahora, algo a tener en cuenta sobre estos nombres de etiquetas es que axe solo ejecutará reglas que coincidan con una etiqueta específica. Entonces, por ejemplo, digamos que querías ejecutar toda la conformidad WCAG 2 AA, lo que normalmente significaría que también cumples con la conformidad WCAG 2 AA. Pero axe no ejecutará las reglas WCAG 2 AA si solo pasas la etiqueta WCAG 2 AA. Tiene que ser una correspondencia uno a uno. Entonces, si quisieras ejecutar todas las reglas para cumplir con WCAG 2 A, debes pasar WCAG 2 A y WCAG 2 AA.

Ahora, para los frameworks de prueba, volverías a inicializar el constructor de axe y luego usarías la función encadenable con etiquetas y con etiquetas toma una sola etiqueta o un array de etiquetas. Y luego lo que se llama analizar, solo se ejecutarían esas reglas. Para axe linter, usarías la propiedad de etiquetas, que es una lista de etiquetas para ejecutar, y luego listarías las etiquetas que quisieras ejecutar.

Por último, quería hablar sobre algunas de las diversas opciones que axe te permite pasar cuando lo ejecutas. Una lista de todas las opciones disponibles se puede encontrar en el archivo de documentación de la API de axe course. Una nota sobre las opciones de ejecución, las opciones de ejecución solo son compatibles en axe y sus integraciones, y realmente no son compatibles en axe linter, con dos excepciones.

Entonces, una breve lista de opciones de ejecución, ya hemos hablado sobre la propiedad run only y las propiedades de las reglas. Tienen cosas similares en axe linter, siendo run only las propiedades de reglas o etiquetas. Pero también admitimos algunas otras cosas, por ejemplo, podemos admitir pasar la propiedad de tipos de resultados, y los tipos de resultados te permiten limitar qué resultados se muestran. Entonces, puedes pasar resultados, incompletos o violaciones. También puedes pasar la opción de iframes y eso le dirá a axe que se ejecute o no dentro de los iframes. Por defecto, una integración de axe se ejecutará en todos los iframes de la página. Entonces, por ejemplo, digamos que solo queríamos que se mostrara el resultado de las violaciones, entonces pasaríamos el objeto de tipos de resultados a axe.run. Y luego, como es un array, pasaríamos la cadena de violación. Y lo que esto hará es que cuando axe se ejecute, obtendrás una lista de todas las reglas aún, pero para aquellas reglas que no coincidieron con los tipos particulares, solo mostrarán un nodo. Entonces, para cualquier paso en este ejemplo, solo un nodo mostrará un paso para esa regla. Lo que te permite hacer es útil para mejorar el performance en páginas muy grandes o páginas muy complicadas donde solo estás interesado en un cierto tipo de resultado.

Para los frameworks de prueba, usarías la función encadenable de opciones para pasar la lista de opciones de esa manera. Y así es como configuras axe. Gracias por venir a esta presentación.

Si quieres contactar a Deque, puedes hacerlo en cualquiera de estos lugares. Puedes usar su Twitter en DequeSystems. Puedes encontrarlos en GitHub en DequeLabs. También puedes conectar en LinkedIn en deque-systems-inc y también en YouTube en deque-systems, sin guiones.

Gracias. Increíble charla, Steven. Definitivamente me ganarás predicando sobre la web y la accessibility y mostrándonos lo fácil que a veces puede ser, o más fácil, no necesariamente fácil para todos, pero más fácil. Muchas gracias por eso. Y estoy realmente curioso por ver los resultados de la encuesta. Demos la bienvenida a Steven y debatamos un poco sobre ello.

¿Qué esperas en este número, Steven? Sí, gracias por tenerme. No te escuché bien, lo siento. Dije eso, y gracias por tenerme. Bienvenido, por supuesto, es un placer. ¿Qué piensas sobre los resultados? El 65% respondió con no. No inesperado. La accessibility testing es difícil de empezar en muchos sistemas de tipo empresarial que no los tienen ya allí. De hecho, de hecho. Y veo un buen grupo de personas ya usando X, o XAI nos estaba preguntando literalmente cómo lo pronunciamos mejor al principio. O insights de accessibility. Y cero para el resto. ¿Cómo te sientes acerca del cero en las otras dos herramientas? No las mantengo, así que todas son excelentes herramientas. Siempre y cuando estén usando algo. De hecho, de hecho. Estoy de acuerdo en que, quiero decir, no está bajo tu responsabilidad, pero me sorprende que Wave tenga cero. Es una de las herramientas más mediatizadas o promocionadas, especialmente cuando investigas cómo probar la accessibility. Por eso estoy un poco sorprendido. Eso es cierto. Sí, de hecho. Bueno, entonces veamos cómo nos va con las preguntas.

Y realmente tengo una personal, quizás para contarte cómo fue, ¿cuál fue el momento que desencadenó esta pasión o exploración por la accessibility de tu lado? Es una buena pregunta. Hace mucho, muchos años, cuando estaba investigando cómo mejorar la user experience, me topé con artículos sobre accessibility y simplemente me pareció interesante y nunca antes había oído hablar de ello. Y así, profundizando en ello a lo largo de los años, me he interesado cada vez más en ello y he querido seguir adelante.

Sí, eso es realmente agradable. Te preguntaba esto porque en mi caso, como tú, estaba tratando de, estaba tratando de aprenderlo, pero no estaba necesariamente impulsado por algo específico. Así que una vez no elegiría un pago debido al contraste de color. Y entonces para mí, ya está. Necesitamos construir más puentes. Necesitamos enseñar a la gente sobre ello. E incluso entrevisté a desarrolladores sobre cuánto tiempo invierten creando todo esto en una forma más accesible. Y para mi sorpresa, la respuesta común que obtuve, fue como, Iona, es solo otra biblioteca o simplemente otra herramienta que usas. Una vez que lo aprendes, simplemente lo aplicas la próxima vez no es el costo en absoluto de los proyectos. Y ese es mi momento de predicación para los desarrolladores o gerentes que no creen que tienen tiempo o dinero para invertir. Y después de eso para los usuarios, menciono todos los beneficios que incluso las personas que no necesitan se beneficiarán de la accessibility. Porque al final del día, nos beneficiamos de una mejor web, igual. Vale. Gracias por unirte a esta intrigante y curiosidad que tenía. Milad estaba preguntando, en tu presentación configuras Axe para text frameworks, ¿deberíamos usar Axe-gest o Axe para de derecha a izquierda? Así que los que Axe y los sistemas Deque mantienen están todos bajo el espacio de nombres axe-core NPM. Así que creo que axe-gest no es mantenido por Deque. Pero si estás usando Gests, y creo que todavía está usando Axe bajo el capó, probablemente todavía sea bueno usarlo. No puedo decir cuál será su API, sin embargo, para configurar Axe bajo el capó. Vale, genial. Al usar aislint-plugin-js-accessibility en React, ¿crees que es necesario también escribir las pruebas de extremo a extremo con Axe? Supongo que depende de cómo estés haciendo tu testing. Muchas veces cuando estás haciendo pruebas de Axe, las he visto hacer como unit testing. Así que estás testing las piezas individuales, asegurándote de que todas sean accesibles. Eso funciona para un buen conjunto de las reglas que Axe ejecuta, pero hay reglas que están más enfocadas en cómo funciona toda la página en conjunto. Así, por ejemplo, tenemos una regla para el orden de los encabezados, que asegura que tienes tus etiquetas h1 a h6 en un orden correcto, y esas solo pueden ser ejecutadas realmente en una página completa. Así que probablemente todavía sean buenas para usar como una testing de extremo a extremo para simplemente atrapar tus problemas de accessibility a nivel de página. Interesante.

X y TypeScript. ¿Existe una API de TypeScript para Axe o las definiciones son definitivamente tipadas? Sí. Todas nuestras integraciones de marcos de prueba están escritas en TypeScript. Axe tiene un archivo de definición de TypeScript que puedes usar, pero Axe en sí no está escrito en TypeScript. Y la X y la supresión de advertencias. ¿Existe una forma de suprimir las advertencias porque no quiero solucionarlo o porque simplemente no es posible que haya falsos positivos? Si te encuentras con falsos positivos, nos encantaría que lo reportaras en la página de problemas de GitHub de Axe core. Intentamos darle una alta prioridad a la solución de falsos positivos. En términos de ignorar advertencias, actualmente no hay una forma de hacerlo a menos que estés usando la extensión de Axe y estés pagando por una licencia, en cuyo caso hay una forma de ignorar los resultados que ya no te interesa ver.

Oh, ciertamente. Y también una de las curiosidades de cómo introdujiste esta masterclass de accesibilidad en tu empresa. Mucha gente curiosa. Así que en empresas anteriores, siendo desarrollador, no fue muy difícil introducirlo en mi propio código. Así que puedes simplemente introducirlo allí y luego tu código como una prueba unitaria está ejecutando Axe. En términos de intentar integrarlo, tú, veamos, ¿qué fue lo que se mencionó en la última sesión de preguntas y respuestas de la que alguien estaba hablando? Oh no, tú lo mencionaste, sí. Intentando convencerlos de que, Hey, podemos hacer esto. Ya lo he hecho, no es difícil, ahora es simplemente gratis para llevarlo a una prueba unitaria. Así que cada vez que quieras probar tu código, está ahí, y luego explicar todos los beneficios para los usuarios y realmente encontrar un usuario que lucha con la aplicación o la página web y mostrarles intentando usarla es una gran forma de hacer que la gente reconozca, Hey, tal vez necesitamos tomar esto en serio. Ciertamente, ciertamente. Y una de las cosas que uso para mostrar a la gente que son usuarios y probablemente muchas otras personas es el ejemplo con el avión de la Segunda Guerra Mundial cuando definitivamente estás mirando la base de datos equivocada, la base de datos de las personas. Extraño cómo se llama ahora. Creo que algo con sesgo es... Sí, sesgo de supervivencia. Sí, exactamente, sesgo de supervivencia. Y la gente dice, no, no tenemos usuarios. Bueno, por supuesto, nunca lo intentamos, o lo que les ayudó o los activó muy rápido fue encontrar una solución para sus cosas diarias que se aplica a ellos, pero también para la accesibilidad. Un ejemplo con aceras de la vida real que necesitan tener la rampa para personas discapacitadas, pero también se usan para correr. Bicicletas, scooters, madres con niños o padres con niños en carritos. De nuevo, una solución que ayuda a todos no necesariamente está dedicada a solucionar un problema de accesibilidad. Sí. Eso es genial.

Annie, me gustaría preguntarte, ¿cómo es tu experiencia con los desarrolladores? ¿Cómo te sientes con las comprobaciones que hacen si has probado con ellos, cómo sientes que se realizan las comprobaciones, los escaneos se hacen automáticamente con las herramientas de escaneo del desarrollador? ¿Cómo crees que esto genera conciencia? ¿Cómo se hace o sientes que es muy poco o suficiente para empezar? ¿Si los pruebas?

Sí, las pruebas de accessibility y al menos las pruebas automatizadas de accessibility sólo pueden detectar alrededor del 50 al 60% de los errores de accessibility. Introducir eso en un poco es mejor que no detectar ningún error. Cualquier prueba de accessibility es mejor que ninguna, pero siempre tienes que hacer una prueba manual, alguien que entienda el 40% restante de los errores para venir y verificar. Si realmente quieres que tu página sea verdaderamente accesible y cumpla con la ADA y todo eso.

Sí, bueno, empecé con estos escaneos y al menos en Firefox, porque trabajo con Mozilla, te darán incluso un enlace a MDN y te explicarán todos los niveles con los que tienen para diferentes cosas. Pero sólo cubren tanto como se puede automatizar fácilmente, como los enlaces de contraste de color, por supuesto, como las pestañas de navegación, o qué más, algo. Sí, pero como las locuciones superpuestas eran muy difíciles de probar en un teléfono móvil, ¿cómo pruebas eso de accessibility? Y oh, otro buen ejemplo para mostrar por qué la accessibility es importante es lo que encontré para mí misma, es tener subtítulos en los videos en el teléfono. Porque vas a escuchar algo y tal vez no siempre tienes auriculares y es más fácil ver textos cuando estás viendo algo para no molestar a nadie, o estás con un niño y quieres... Así que esos me ayudaron desde el teléfono y los encontré por error y después de eso, los uso. De nuevo, gran cosa.

¿Qué más o cuál de estos problemas de accesibilidad te gustaría que se implementaran más o que se conocieran más y se pensara con solución? Supongo que el más común, hay algunos problemas comunes de accessibility que si hubiera más conciencia sobre ellos, podrías resolver. Lo más importante que un desarrollador podría hacer para ayudar con la accessibility es usar HTML semántico. Así que hay el término llamado divitis o sopa de div donde simplemente hacemos todo divs y luego añadimos la funcionalidad que necesitamos. Hacer eso, sin embargo, hace que sea muy fácil olvidar todos los beneficios nativos de accessibility que cosas como un botón o un enlace ya tienen en ellos. Así que sólo con el uso de HTML semántico, puedes cubrir una amplia gama de problemas de accessibility y asegurarte de que se solucionen. Junto a eso, probablemente el siguiente problema importante sería asegurarse de que tu página web es sólo utilizable con un teclado solo. Prueba tu página, ve a tu teclado, presiona tab, asegúrate de que todo lo que es clickable puede ser tabulado también que puedes activarlo con el enter o el espacio. Porque la mayoría del software de accessibility o las tecnologías de asistencia se basan en un sistema de enfoque de tipo teclado. Así que puedes cubrir muchos problemas también asegurándote de que tu página es accesible al teclado. Así que esas dos cosas son probablemente los puntos de partida más importantes.

Hmm. De hecho. Estoy de acuerdo. Y una pregunta más sobre X. X, el enfoque parece estar en los ciegos. Pero hay alguna comprobación para las discapacidades motoras. El botón debe ser lo suficientemente grande para ser golpeado con manos temblorosas, por ejemplo. Mm, hay... Así que en términos de cómo probar algo así de forma automatizada, el WCAG, que es la lista definitiva de lo que hace las cosas accesibles para el cumplimiento, han implementado una nueva versión, WCAG 2.1, que introdujo una nueva regla sobre lo que llaman espaciado de objetivos. Así que eso dice que cualquier botón o cualquier cosa que sea clickable necesita ser de un cierto tamaño y que necesita tener una cierta cantidad de padding alrededor de él. Y eso es probablemente lo más cercano que podrías conseguir a algo como manos temblorosas o temblores en términos de asegurarte de que tu página es accesible hacia eso pero no hay mucho que puedas hacer. Es automatizado sabio, eso probablemente queda más a un probador manual para ver si hay suficiente espacio alrededor del área para asegurarse de que si estás teniendo temblores que puedes hacer clic en cualquier otra cosa accidentalmente. De hecho, oh, muchas gracias por la respuesta. Fue realmente interesante también especialmente porque en testing siempre consideramos desde un punto de vista de UX que tal vez alguien tendrá un dedo más fuerte o simplemente uno tembloroso. Muchas gracias por tu increíble charla. Invito a todos a unirse a tu sala de chat en spatial.chat y ver alrededor. También tuitea tu solución para accessibility. Estoy curioso por leerlo más. No olvides también calificar la charla y muchas gracias de nuevo, Steven.