Configurando las Pruebas de Accesibilidad de Axe

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

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.

This talk has been presented at TestJS Summit 2021, check out the latest edition of this JavaScript Conference.

FAQ

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 identificar problemas de accesibilidad.

Para usar AXe, primero debes cargar un script desde unpkg.com que apunta a la biblioteca central de AXe. Una vez cargada, puedes usar un script de tipo módulo para ejecutar AXe.run y registrar los resultados, específicamente las violaciones encontradas.

AXe tiene integraciones con varios lenguajes y frameworks, incluyendo CLI, Playwright, Puppeteer, React, WebDriver.IO y WebDriver.js. También cuenta con una integración para VS Code llamada Axelinter.

Puedes personalizar las reglas en AXe deshabilitando ciertas reglas que no deseas ejecutar, o configurando solo un conjunto determinado de reglas para ejecutar, utilizando objetos de opciones en AXe.run.

Para AXe core, puedes encontrar la lista de reglas soportadas en el archivo 'rule-descriptions.md' en la página de GitHub de AXe core. Para AXe Linter, la lista está disponible en la página de la extensión de VS Code.

Puedes contactar a Steven Lambert a través de Twitter utilizando el nombre de usuario @StevenKLambert, enviarle un correo electrónico a Steven en sklambert.com o visitar su sitio web stevenklambert.com.

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.

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

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
Playwright Test Runner
TestJS Summit 2021TestJS Summit 2021
25 min
Playwright Test Runner
Top Content
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.
Accesibilidad en Discord
React Advanced 2021React Advanced 2021
22 min
Accesibilidad en Discord
This Talk discusses the accessibility efforts at Discord, focusing on keyboard navigation and the challenges faced with implementing focus rings and outlines. The speaker showcases a unified focus ring system and a saturation slider to address accessibility concerns. They also highlight the implementation of role colors and the use of CSS filters for accessibility improvements. The Talk concludes with insights on runtime accessibility checking and the development of a performant core runtime system for checking accessibility issues.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()?
En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor.
Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos
Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles.
Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador.
Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E.
Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes.
Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman.
Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend.
Nivel de la masterclass: Intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
TestJS Summit 2023TestJS Summit 2023
148 min
Mejores Prácticas para Escribir y Depurar Pruebas de Cypress
Top Content
Workshop
Filip Hric
Filip Hric
Probablemente conozcas la historia. Has creado un par de pruebas y, como estás utilizando Cypress, lo has hecho bastante rápido. Parece que nada te detiene, pero luego - prueba fallida. No fue la aplicación, no fue un error, la prueba fue... ¿inestable? Bueno sí. El diseño de la prueba es importante sin importar la herramienta que utilices, incluyendo Cypress. La buena noticia es que Cypress tiene un par de herramientas bajo su cinturón que pueden ayudarte. Únete a mí en mi masterclass, donde te guiaré lejos del valle de los anti-patrones hacia los campos de pruebas estables y siempre verdes. Hablaremos sobre los errores comunes al escribir tu prueba, así como depurar y revelar problemas subyacentes. Todo con el objetivo de evitar la inestabilidad y diseñar pruebas estables.