Configurando las Pruebas de Accesibilidad de Axe

Rate this content
Bookmark

Axe-core es un motor de pruebas de accesibilidad popular que es utilizado por Google, Microsoft y cientos de otras empresas para asegurar que sus sitios web sean accesibles. Axe-core incluso puede integrarse en muchos marcos de pruebas populares, herramientas e IDEs. En esta sesión avanzada, aprenderemos cómo configurar axe y sus integraciones para afinar cómo se ejecutan y revisan tus páginas y código en busca de violaciones de accesibilidad.

Steven Lambert
Steven Lambert
30 min
19 Nov, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

AXe es un motor de accesibilidad para pruebas automatizadas de UI web que ejecuta un conjunto de reglas para probar problemas de accesibilidad. Se puede configurar para deshabilitar o habilitar reglas específicas y ejecutar en base a etiquetas. Axe ofrece varias opciones, pero el linter de axe no admite todas las opciones. Se enfatiza la importancia de invertir tiempo y recursos en la accesibilidad, ya que beneficia no solo a las personas con discapacidades sino que mejora la web para todos. También se destaca la prueba manual como un complemento necesario para las pruebas automatizadas para abordar problemas de accesibilidad.

Available in English

1. Introducción a AXe y su uso

Short description:

Hola, mi nombre es Steven Lambert. 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 accesibilidad. AXe es un motor de accesibilidad para pruebas automatizadas de la interfaz de usuario web. Ejecuta un conjunto de reglas en una página o en tu código para probar problemas de accesibilidad. Puedes usar AXe en una página web cargando la biblioteca central de AXe y esperando los resultados de AXe.run. La propiedad de violaciones te mostrará cada regla que informa una violación. Axe tiene muchas integraciones en varios idiomas y marcos, como la integración de CLI, Playwright, Puppeteer, React, WebDriver.IO y WebDriver.js. También tenemos integraciones en VS Code, extensiones de Chrome y Firefox, y otros idiomas como Java y Ruby. Para configurar qué reglas ejecuta Axe, puedes especificar el conjunto de reglas a utilizar.

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.

2. Configuración de la ejecución de reglas en AXe

Short description:

Por defecto, Axe ejecutará todas las reglas soportadas. Puedes configurar qué reglas deshabilitar, especificar un conjunto determinado de reglas para ejecutar, o ejecutar reglas que coincidan con una etiqueta particular. Mostraré ejemplos de cómo hacer esto en Axe core, Puppeteer y Axe linter. Para deshabilitar reglas en Axe core, pasa un objeto de opciones a ax.run con la propiedad de reglas establecida en un objeto donde cada clave es el nombre de la regla a deshabilitar. En Puppeteer, usa la función disabledRules del objeto ax builder para pasar un array de nombres de reglas a deshabilitar. Para Ax linter, la configuración se realiza a través de un archivo de configuración.

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.

3. Configurando las reglas de ax-linter en el archivo YAML del proyecto

Short description:

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.

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.

4. Ejecución selectiva de reglas con ax-core y linter

Short description:

Para ejecutar solo un conjunto determinado de reglas, pasa un objeto a ax.run con la propiedad run only establecida en los nombres de reglas deseados. Para CLI y marcos de prueba, inicializa el constructor de ax y encadena la función con reglas, especificando los nombres de las reglas. Desafortunadamente, ax linter no admite la habilitación de reglas específicas. Para habilitar reglas específicas, debes deshabilitar todas las demás reglas y solo habilitar las deseadas. Consulta la página de la extensión ax linter de VS Code para la lista de reglas admitidas.

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.

5. Ejecución de reglas basadas en etiquetas

Short description:

Las etiquetas se utilizan para categorizar las reglas en grupos basados en la versión de WCAG y el nivel de conformidad. Por ejemplo, la etiqueta WCAG AA agrupa las reglas relacionadas con la conformidad WCAG 2.0 AA. Puedes encontrar la lista de etiquetas admitidas en el repositorio de GitHub de AxeCore, específicamente en el archivo API.md.

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.

6. Configurando Axe y sus opciones

Short description:

Ahora, para axe-linter, solo admite un subconjunto de etiquetas, específicamente WCAG 2.0 AA y AA, y WCAG 2.1 AA y AA. AxeCore puede ejecutar un cierto conjunto de reglas pasando nombres de etiquetas. Sin embargo, axe solo ejecutará reglas que coincidan con una etiqueta específica, por lo que se requiere una correspondencia uno a uno. Los marcos de prueba también se pueden configurar para ejecutar etiquetas específicas. Axe ofrece varias opciones, como tipos de resultados para limitar qué resultados se muestran, y la capacidad de ejecutar o no dentro de iframes. Estas opciones son compatibles en axe y sus integraciones, pero no en axe linter.

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.

7. Contactando a Deque y Discusión sobre los Resultados

Short description:

Si quieres contactar a Deque, puedes hacerlo en cualquiera de estos lugares. Gracias. Increíble charla, Steven. Demos la bienvenida a Steven y debatamos un poco sobre ello. ¿Qué esperas en este número, Steven? ¿Qué piensas sobre los resultados? El 65% respondió con no. No inesperado. 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 accesibilidad. 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. 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 accesibilidad. Por eso estoy un poco sorprendido. Bueno, entonces veamos cómo nos va con las preguntas.

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.

8. Viaje Personal y Configuración de Axe

Short description:

Hace muchos años, me topé con artículos sobre accesibilidad y con el tiempo me interesé más en ello. Una vez elegí no usar un método de pago debido a problemas de contraste de color, lo que me llevó a abogar por la accesibilidad. Los desarrolladores a menudo ven la accesibilidad como otra herramienta más, pero es importante invertir tiempo y recursos en ella. La accesibilidad beneficia no solo a las personas con discapacidades sino que también mejora la web para todos. En términos de configuración de Axe, si estás usando Gests, que probablemente esté construido sobre Axe, aún debería ser bueno usarlo. Si se deben escribir pruebas de extremo a extremo con Axe depende de tu enfoque de prueba. Mientras que las pruebas unitarias cubren muchas reglas de accesibilidad, algunas reglas requieren probar toda la página, como el orden de los encabezados. X y TypeScript.

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.

9. X y TypeScript en Pruebas de Accesibilidad

Short description:

X y TypeScript. Sí, todas las integraciones de marcos de prueba están escritas en TypeScript. Axe tiene un archivo de definición de TypeScript. Actualmente no es posible suprimir advertencias, pero los falsos positivos pueden ser reportados en la página de problemas de GitHub de Axe core. La introducción de las pruebas de accesibilidad en una empresa puede hacerse introduciéndola en tu propio código y demostrando los beneficios para los usuarios. Mostrar ejemplos de la vida real de cómo la accesibilidad beneficia a todos puede ayudar a convencer a otros de que la tomen en serio.

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.

10. La Experiencia de Annie y los Problemas Clave de Accesibilidad

Short description:

Annie comparte su experiencia con los desarrolladores y la importancia de las pruebas manuales además de las pruebas automatizadas de accesibilidad. Discute las limitaciones de las pruebas automatizadas y proporciona ejemplos de problemas de accesibilidad que requieren verificación manual. Annie enfatiza el uso de HTML semántico y asegurar la accesibilidad del teclado como puntos de partida clave para abordar la accesibilidad. También menciona la regla WCAG 2.1 sobre el espaciado de objetivos para discapacidades motoras, pero destaca la necesidad de pruebas manuales para asegurar suficiente espacio para los usuarios con temblores. Annie concluye invitando a la audiencia a unirse a su sala de chat y compartir sus soluciones de accesibilidad.

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.

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

Network Requests with Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Top Content
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
Testing Pyramid Makes Little Sense, What We Can Use Instead
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
Gleb Bahmutov
Roman Sandler
2 authors
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
Full-Circle Testing With Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Top Content
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
Test Effective Development
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
Accessibility at Discord
React Advanced Conference 2021React Advanced Conference 2021
22 min
Accessibility at Discord

Workshops on related topic

Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
How to Start With Cypress
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
Filip Hric
Filip Hric
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
Detox 101: How to write stable end-to-end tests for your React Native application
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Top Content
WorkshopFree
Yevheniia Hlovatska
Yevheniia Hlovatska
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
API Testing with Postman Workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
Gleb Bahmutov
Gleb Bahmutov
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
Best Practices for Writing and Debugging Cypress Tests
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
Filip Hric
Filip Hric
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.