Configurando Pruebas de Accesibilidad con Axe

Rate this content
Bookmark

Axe-core es un popular motor de pruebas de accesibilidad que es utilizado por Google, Microsoft y cientos de otras compañías para asegurarse de que sus sitios web sean accesibles. Axe-core incluso se puede integrar en muchos marcos de pruebas, herramientas y entornos de desarrollo populares. En esta sesión avanzada, aprenderemos cómo configurar axe y sus integraciones para ajustar cómo se ejecuta y verifica tus páginas y código en busca de violaciones de accesibilidad.

30 min
19 Nov, 2021

Video Summary and Transcription

AXe es un motor de accesibilidad para pruebas automatizadas de la interfaz de usuario web que ejecuta un conjunto de reglas para detectar problemas de accesibilidad. Se puede configurar para desactivar o habilitar reglas específicas y ejecutarlas en función de 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 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 un 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 UI web. Ejecuta un conjunto de reglas en una página o en tu código para detectar problemas de accesibilidad. Puedes usar AXe en una página web cargando la biblioteca principal 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 lenguajes y frameworks, como la integración CLI, Playwright, Puppeteer, React, WebDriver.IO y WebDriver.js. También tenemos integraciones en extensiones de VS Code, Chrome y Firefox, y otros lenguajes como Java y Ruby. Para configurar qué reglas ejecuta Axe, puedes especificar el conjunto de reglas a utilizar.

Me identifico con los pronombres él y él. Soy un 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.

En caso de que todos quieran contactarme 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 visitar mi sitio web, stevenklambert.com y contactarme allí.

Antes de adentrarnos 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. Entonces, AXe es un motor de accesibilidad para pruebas automatizadas de UI web. Lo que significa es que AXe ejecuta un conjunto de reglas en una página o en tu código para detectar problemas de accesibilidad.

Aquí tienes un ejemplo de cómo usarías AXe en una página web. Primero cargarías un script cuya fuente apunta a la biblioteca principal de AXe. En este caso, es de unpkg.com slash AXe dash core at latest slash AXe dot JS. Eso cargará la biblioteca principal de AXe en tu página. Una vez cargada, puedes usar un script de tipo módulo para esperar los resultados de AXe dot run. Usando esos resultados, puedes luego imprimir la propiedad de violaciones, que te mostrará cada regla que informa una violación. Aquí tienes un ejemplo de cómo se vería eso.

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 en la regla en particular. Entonces, en este ejemplo, estoy mostrando que hay una violación de landmark one main, todas las reglas de heading one y region están fallando.

Entonces, ¿dónde puedes usar Axe? Bueno, Axe tiene muchas integraciones en varios lenguajes y frameworks. La biblioteca principal es axe-core y se puede usar directamente en el navegador o en Node. También proporcionamos algunas integraciones en la línea de comandos y en populares frameworks de pruebas. Entonces, en npm, puedes buscar en el espacio de nombres axe-core y allí encontrarás la integración de CLI, Playwright, Puppeteer, React, WebDriver.IO y la integración WebDriver.js. Este año, también lanzamos una nueva integración para VS Code, que se llama Axelinter y proporciona verificación de accesibilidad para tu código que es consistente con el motor de reglas de Axe-Core.

Entonces, lo que eso significa es que a medida que escribes, recibirás sugerencias de verificación 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 en esta presentación. Solo hablaremos sobre integraciones compatibles con JavaScript y Node.

Ahora que sabemos qué es Axe y cómo usarlo, quiero hablar sobre cómo configurar qué reglas ejecuta Axe. Como mencioné, Axe ejecuta un conjunto de reglas que determinan los problemas de accesibilidad en una página.

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

Short description:

De forma predeterminada, AXe ejecutará todas las reglas admitidas. Puedes configurar qué reglas desactivar, especificar un conjunto determinado de reglas para ejecutar o ejecutar reglas que coincidan con una etiqueta específica. Mostraré ejemplos de cómo hacer esto en AXe core, Puppeteer y AXe linter. Para desactivar reglas en AXe core, pasa un objeto de opciones a ax.run con la propiedad de reglas establecida como un objeto donde cada clave es el nombre de la regla a desactivar. En Puppeteer, usa la función disabledRules del objeto ax builder para pasar una matriz de nombres de reglas a desactivar. Para AXe linter, la configuración se realiza a través de un archivo de configuración.

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

Entonces, hay varias formas en las que puedes configurar qué reglas ejecutará AXe. Para empezar, puedes desactivar un conjunto determinado de reglas para que no se ejecuten durante una ejecución normal. También puedes especificar un conjunto determinado de reglas para ejecutar solo esas reglas, y también puedes ejecutar reglas que coincidan con una etiqueta específica. Ahora, para esta presentación, voy a 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 integración de nodo como Puppeteer, y también te mostraré cómo hacerlo en AXe linter.

Primero, quiero hablar sobre cómo desactivar reglas. Digamos, por ejemplo, que quieres desactivar dos reglas específicas, las reglas de nombre de botón y etiqueta. La regla de nombre de botón asegura que cada elemento de botón HTML tenga un nombre accesible, que se puede lograr ya sea mediante contenido de texto en el botón o mediante el uso de una etiqueta ARIA, ARIA labeled by o atributo de título. La regla de etiqueta hace algo similar, asegurando que cada elemento de entrada tenga un nombre accesible, ya sea mediante un elemento de etiqueta asociado o mediante el uso de una etiqueta ARIA, ARIA labeled by o atributo de título. Para usar esto en AXe 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 deseas desactivar. Y luego el valor de eso es un objeto que toma una propiedad de habilitado y puede pasar true o false. True es el comportamiento predeterminado y significa que la regla se ejecutará, pasar false desactivará la regla para que no se ejecute. En este ejemplo, pasamos las reglas de nombre de botón y etiqueta y las habilitamos en false a ambas. Para una CLI y un marco de pruebas, lo que harías es inicializar un nuevo objeto ax builder que te permite encadenar un par de funciones. Una de esas funciones que puedes encadenar se llama disabledRules. Y la función disabledRules te permite pasar un nombre de regla o una matriz de nombres de reglas que deseas desactivar. En este caso, podemos pasar una matriz de nombre de botón y etiqueta para desactivar ambas reglas. Y luego, por último, encadenaríamos la función analyze y eso ejecutaría AXe en esa página. Para AXe linter, no tenemos una API que puedas usar. Entonces, en su lugar, lo configuras a través de un archivo de configuración.

3. Configuración de reglas 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, debes establecer la clave de reglas, que es un diccionario. Y cada clave de ese diccionario es el nombre de la regla que deseas desactivar.

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, debes establecer la clave de reglas, que es un diccionario. Y cada clave de ese diccionario es el nombre de la regla que deseas desactivar. Y el valor es verdadero o falso nuevamente, donde verdadero significa ejecutar la regla, que es el comportamiento predeterminado y falso significa desactivar 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 desactivarías ciertas reglas.

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

Short description:

Para ejecutar solo un conjunto específico de reglas, pasa un objeto a ax.run con la propiedad 'run only' establecida en los nombres de las reglas deseadas. Para CLI y frameworks de pruebas, inicializa el constructor de ax y encadena la función con las 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 desactivar todas las demás reglas y solo habilitar las deseadas. Consulta la página de la extensión ax linter de VS Code para obtener la lista de reglas admitidas.

Y ahora, para hacer lo contrario, queremos ejecutar solo un conjunto específico de reglas. Entonces, digamos que en lugar de desactivar las reglas de nombre de botón y etiqueta, quieres habilitarlas y hacer que sean las únicas reglas que se ejecuten. Para ax core, nuevamente pasaremos un objeto a ax.run. Ese objeto de opciones ahora toma la propiedad 'run only' cuyo valor es un nombre de regla o una matriz de nombres de reglas para ejecutar. Entonces, en este caso, pasaríamos una matriz con los nombres de las reglas de nombre de botón y etiqueta y eso hará que ax solo ejecute esas dos reglas cuando devuelva los resultados.

Para la CLI y los frameworks de pruebas, lo que harías es inicializar el constructor de ax nuevamente y esta vez encadenar la función con las reglas. La función 'with rules' tomará un solo nombre de regla o una matriz de nombres de reglas y solo ejecutará esas reglas cuando llames a 'analyze'. Bien. Para ax linter, desafortunadamente, no tenemos una forma para que habilites solo un conjunto específico de reglas. Entonces, la única forma de hacer esto es desactivar todas las demás reglas y solo habilitar las que deseas. Ax linter tiene alrededor de 33 reglas. Entonces tendrías que listar las 33 reglas, poner 'false' para 31 de ellas y 'true' solo para las reglas de nombre de botón y etiqueta. Nuevamente, 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 basada en etiquetas

Short description:

Las etiquetas se utilizan para categorizar las reglas en grupos basados en la versión y nivel de conformidad de WCAG. 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 AxeCores, específicamente en el archivo API.md.

Entonces, ahora queremos ejecutar solo las reglas que coincidan con una etiqueta específica. ¿Qué es una etiqueta? Primero, 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 y nivel de conformidad de WCAG. 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 consultar el archivo docs/rule-descriptions.md una vez más. Para obtener una lista de las etiquetas admitidas, puedes ir al repositorio de AxeCores en GitHub, en el directorio docs y consultar el archivo API.md. Allí hemos enlazado una lista de todas las etiquetas admitidas. El resumen rápido de las etiquetas admitidas generalmente incluirá WCAG 2.0 AA y AAA así como WCAG 2.1 AA y AAA.

6. Configuración de Axe y sus opciones

Short description:

Ahora, en cuanto a 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 conjunto específico 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 coincidencia uno a uno. Los marcos de prueba también se pueden configurar para ejecutar etiquetas específicas. Axe proporciona varias opciones, como tipos de resultados para limitar qué resultados se muestran y la capacidad de ejecutar o no ejecutar dentro de iframes. Estas opciones son compatibles en axe y sus integraciones, pero no en axe linter.

Ahora, en cuanto a axe-linter nuevamente, 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 conjunto específico de reglas, una vez más usaremos axe.run, pasando un objeto de opciones y utilizando 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. Por ejemplo, supongamos que deseas 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á reglas WCAG 2 AA si solo pasas la etiqueta WCAG 2 AA. Debe haber una coincidencia uno a uno. Entonces, si deseas ejecutar todas las reglas para cumplir con WCAG 2 A, debes pasar las etiquetas WCAG 2 A y WCAG 2 AA.

Ahora, para los frameworks de prueba, nuevamente inicializarías el constructor de axe y luego usarías la función encadenable with tags y with tags toma una sola etiqueta o una matriz de etiquetas. Y luego lo que se llama analyze, solo se ejecutarían esas reglas. Para axe linter, usarías la propiedad tags, que es una lista de etiquetas para ejecutar, y luego enumerarías las etiquetas que deseas ejecutar.

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

Entonces, una breve lista de opciones de ejecución, ya hemos hablado sobre el run only y las propiedades rules. Tienen cosas similares en axe linter, el run only siendo las propiedades rules o tags. Pero también admitimos algunas otras cosas, por ejemplo, podemos admitir pasar la propiedad result types, y result types te permite limitar qué resultados se muestran. Entonces puedes pasar results, incomplete o violations. También puedes pasar la opción iframes y eso le dirá a axe si se ejecuta o no se ejecuta dentro de iframes. De forma predeterminada, una integración de axe se ejecutará en todos los iframes de la página. Entonces, por ejemplo, supongamos que solo queremos que se muestre el resultado de las violaciones, por lo que pasaríamos el objeto result types a axe.run. Y luego, como es una matriz, pasaríamos la cadena violation. Y lo que esto hará es que cuando axe se ejecute, obtendrás una lista de todas las reglas, pero para aquellas reglas que no coincidan con los tipos particulares, solo se mostrará un nodo. Entonces, para cualquier aprobación en este ejemplo, solo se mostrará un nodo aprobado para esa regla. Lo que esto te permite hacer es útil para mejorar el rendimiento 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 options para pasar la lista de opciones de esa manera. Y así es como se configura axe. Gracias por asistir a esta presentación.

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

Short description:

Si quieres ponerte en contacto con Deque, puedes hacerlo en cualquiera de estos lugares. Gracias. Increíble charla, Steven. Damos la bienvenida a Steven y debatimos un poco al respecto. ¿Qué esperas en este número, Steven? ¿Qué opinas sobre los resultados? El 65% respondió que no. No es inesperado. Y veo que hay un buen número de personas que ya usan X, o XAI, me preguntaba cómo lo pronunciamos mejor al principio. O accesibilidad insights. 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, aunque no esté bajo tu responsabilidad, me sorprende que Wave tenga cero. Es una de las herramientas más mediáticas o promocionadas, especialmente cuando investigas cómo probar la accesibilidad. Por eso estoy un poco sorprendido. Bueno, veamos cómo nos va con las preguntas.

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

Gracias. Increíble charla, Steven. Definitivamente me convencerás al predicar sobre la web y la accesibilidad y mostrarnos 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 tengo mucha curiosidad por ver los resultados de la encuesta. Damos la bienvenida a Steven y debatimos un poco al respecto.

¿Qué esperas en este número, Steven? Sí, gracias por tenerme aquí. No te escuché bien, lo siento. Dije eso, y gracias por invitarme. Bienvenido, por supuesto, es un placer. ¿Qué opinas sobre los resultados? El 65% respondió que no. No es inesperado. La prueba de accesibilidad es difícil de comenzar en muchos sistemas de tipo empresa que no la tienen desde el principio. En efecto, en efecto. Y veo que hay un buen número de personas que ya usan X, o XAI, me preguntaba cómo lo pronunciamos mejor al principio. O accesibilidad insights. 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. En efecto, en efecto. Estoy de acuerdo en que, aunque no esté bajo tu responsabilidad, me sorprende que Wave tenga cero. Es una de las herramientas más mediáticas o promocionadas, especialmente cuando investigas cómo probar la accesibilidad. Por eso estoy un poco sorprendido. Es cierto. Sí, en efecto. Bueno, veamos cómo nos va con las preguntas.

8. Personal Journey and Configuration of Axe

Short description:

Hace muchos años, me encontré con artículos sobre accesibilidad y con el tiempo me interesé más en ello. En una ocasión, decidí no utilizar 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 solo otra herramienta, 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 cuanto a la configuración de Axe, si estás utilizando Gests, que probablemente esté construido sobre Axe, debería ser bueno usarlo. Si debes escribir pruebas de extremo a extremo con Axe depende de tu enfoque de pruebas. Si bien 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 tengo una historia personal, tal vez para contarte cómo fue, cuál fue el momento que desencadenó esta pasión o exploración de la accesibilidad desde tu lado. Es una buena pregunta. Hace muchos años, cuando estaba investigando cómo mejorar la experiencia del usuario, me encontré con artículos sobre accesibilidad y me pareció interesante, algo que nunca había escuchado antes. A lo largo de los años, me he ido interesando cada vez más en ello y he querido seguir adelante con ello.

Sí, eso es realmente bueno. Te lo preguntaba porque en mi caso, al igual que tú, estaba tratando de aprenderlo, pero no estaba impulsado necesariamente por algo específico. Una vez no elegí un método de pago debido al contraste de color. Y luego pensé, ya está, tenemos que acortar más estas brechas. Tenemos que enseñar a la gente al respecto. Incluso entrevisté a desarrolladores sobre cuánto tiempo invierten en crear todas estas cosas de forma más accesible. Y para mi sorpresa, la respuesta común que obtuve fue: `Iona, es solo otra biblioteca o otra herramienta que usas. Una vez que lo aprendes, lo aplicas la próxima vez y no supone un costo adicional en todos los proyectos`. Y ese es mi momento de predicación para los desarrolladores o gerentes que no creen que tengan tiempo o dinero para invertir. Y después de eso, para los usuarios, menciono todos los beneficios que incluso las personas que no los necesitan obtendrán de la accesibilidad. Porque al final del día, todos nos beneficiamos de una mejor web. De acuerdo. Gracias por unirte a esta intrigante y curiosa conversación que tenía. Milad preguntó, en tu presentación configuras Axe para los marcos de texto, ¿debemos usar Axe-gest o Axe para la escritura de derecha a izquierda? Los que Axe y Deque Systems mantienen están todos bajo el espacio de nombres axe-core en NPM. Así que creo que axe-gest no es mantenido por Deque. Pero si estás utilizando Gests, y creo que aún utiliza Axe internamente, probablemente sea bueno seguir usándolo. Aunque no puedo decir cuál será su API para configurar Axe internamente. Está bien, genial. Cuando usas aislint-plugin-js-accessibility en React, ¿crees que también es necesario escribir las pruebas de extremo a extremo con Axe? Supongo que depende de cómo estés haciendo tus pruebas. Muchas veces, cuando haces pruebas con Axe, las he visto como pruebas unitarias. Así que estás probando 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 se centran más en cómo funciona toda la página en conjunto. Por ejemplo, tenemos una regla para el orden de los encabezados, que se asegura de que tengas tus etiquetas h1 a h6 en el orden correcto, y esas solo se pueden ejecutar realmente en una página completa. Por lo tanto, probablemente sea bueno usarlas como pruebas de extremo a extremo para detectar problemas de accesibilidad a nivel de página. Interesante.

9. X and TypeScript in Accessibility Testing

Short description:

X y TypeScript. Sí, todas las integraciones del marco de pruebas están escritas en TypeScript. Axe tiene un archivo de definición de TypeScript. Actualmente no es posible suprimir las advertencias, pero se pueden informar falsos positivos en la página de problemas de GitHub de Axe core. Introducir pruebas de accesibilidad en una empresa se puede hacer introduciéndolas en tu propio código y demostrando los beneficios a los usuarios. Mostrar ejemplos de la vida real de cómo la accesibilidad beneficia a todos puede ayudar a convencer a otros de que lo tomen en serio.

X y TypeScript. ¿Existe una API de TypeScript para Axe o las definiciones son definitivamente tipadas? Sí. Todas nuestras integraciones del marco de pruebas 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 sobre X y la supresión de advertencias. ¿Existe alguna forma de suprimir las advertencias porque no quiero corregirlas o porque simplemente no es posible hay informes de falsos positivos? Si encuentras falsos positivos, nos encantaría que los informaras en la página de problemas de GitHub de Axe core. Intentamos darle una alta prioridad a solucionar los falsos positivos. En cuanto a ignorar las advertencias, actualmente no hay forma de hacerlo a menos que estés utilizando la extensión de Axe y estés pagando una licencia, en cuyo caso hay una forma de ignorar los resultados que no te importa ver más.

Oh, ciertamente. Y también una de las curiosidades de cómo introdujiste estas pruebas de accesibilidad en tu empresa. Mucha gente está curiosa. En empresas anteriores, como desarrollador, no fue demasiado difícil introducirlo en mi propio código. Así que puedes simplemente introducirlo en tu código y luego ejecutar Axe como una prueba unitaria. En cuanto a tratar de integrarlo, veamos, ¿qué fue lo que mencionaron en la última sesión de preguntas y respuestas alguien estaba hablando de eso? Oh no, simplemente lo mencionaste tú, sí. Tratando de convencerlos de que, hey, podemos hacer esto. Ya lo he hecho, no es difícil, ahora es simplemente gratis incorporarlo en una prueba unitaria. Así que cada vez que quieras probar tu código, está ahí, y luego explicar todos los beneficios a los usuarios y encontrar realmente a un usuario que tenga dificultades con la aplicación o la página web y mostrarles cómo intentan usarla es una excelente manera de hacer que las personas reconozcan, hey, tal vez debamos tomar esto en serio. Ciertamente, ciertamente. Y una de las cosas que uso para mostrar a las personas que son usuarios y probablemente muchas otras personas es el ejemplo del avión de la Segunda Guerra Mundial cuando definitivamente estás buscando en la base de datos equivocada, la base de datos de personas. Olvidé cómo se llama ahora. Creo que algo con sesgo... Sí, sesgo de supervivencia. Sí, exactamente, sesgo de supervivencia. Sí, de hecho. Bueno, por supuesto, nunca lo intentamos, o lo que los ayudó o los impulsó muy rápido fue encontrar una solución para sus tareas diarias que les aplica a ellos, pero también a la accesibilidad. Un ejemplo con aceras de la vida real que necesitan tener una rampa para personas discapacitadas, pero también se utilizan para correr. Bicicletas, scooters, madres con niños o padres con niños en carritos. Nuevamente, una solución que ayuda a todos no necesariamente está dedicada a solucionar un problema de accesibilidad. Sí, eso es genial.

10. Experiencia de Annie y 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 garantizar la accesibilidad mediante el teclado como puntos clave para abordar la accesibilidad. También menciona la regla WCAG 2.1 sobre el espaciado objetivo para discapacidades motoras, pero destaca la necesidad de pruebas manuales para garantizar un espacio suficiente 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 ha sido tu experiencia con los desarrolladores? ¿Cómo percibes las comprobaciones que hacen si has probado con ellos, cómo sientes que se realizan las comprobaciones, el escaneo se realiza automáticamente con herramientas de desarrollo? ¿Cómo crees que esto crea conciencia? ¿Se hace de manera insuficiente o es suficiente para comenzar? ¿Si los has probado?

Sí, las pruebas de accesibilidad y al menos las pruebas de accesibilidad automatizadas solo pueden detectar alrededor del 50 al 60% de los errores de accesibilidad. Lo cual, introducir eso de a poco es mejor que no detectar ningún error. Entonces, cualquier prueba de accesibilidad es mejor que ninguna, pero siempre debes realizar una prueba manual, alguien que entienda el 40% restante de los errores para que venga y verifique. Si realmente quieres que tu página sea verdaderamente accesible y cumpla con ADA y todo eso.

Sí, bueno, al principio comencé 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 que tienen para diferentes cosas. Pero solo cubren tanto como se puede automatizar fácilmente, como el contraste de color en los enlaces, por supuesto, como las pestañas de navegación, o algo más. Sí, pero cosas como los narradores de voz eran muy difíciles de probar en un teléfono móvil, cómo probar eso de la accesibilidad. Y oh, otro buen ejemplo para mostrar por qué la accesibilidad es importante es lo que encontré para mí misma, que es tener subtítulos en los videos del teléfono. Porque vas a escuchar algo y tal vez no siempre tienes los auriculares puestos y es más fácil ver el texto cuando estás viendo algo para no molestar a nadie, o estás con un niño y quieres... Así que eso me ayudó desde el teléfono y los encontré por accidente y después los usé. Nuevamente, una gran cosa.

¿Qué más o cuáles de estos problemas de accesibilidad te gustaría que se implementaran más o que se conocieran más y se pensara en soluciones? Supongo que los más comunes, hay algunos problemas comunes de accesibilidad que si hubiera más conciencia sobre ellos, se podrían resolver. Lo más importante que un desarrollador podría hacer para ayudar con la accesibilidad es usar HTML semántico. Entonces, está el término llamado divitis o div soup donde simplemente convertimos todo en divs y luego agregamos la funcionalidad que necesitamos. Sin embargo, al hacer eso, es muy fácil olvidar todos los beneficios nativos de la accesibilidad que cosas como un botón o un enlace ya tienen. Entonces, simplemente usando HTML semántico, puedes solucionar una amplia variedad de problemas de accesibilidad. Junto con eso, probablemente el siguiente problema más importante sería asegurarse de que tu página web sea utilizable solo con el teclado. Prueba tu página, ve a tu teclado, presiona la tecla Tab, asegúrate de que todo lo que se pueda hacer clic también se pueda seleccionar con la tecla Tab y activarlo con la tecla Enter o la barra espaciadora. Porque la mayoría del software de accesibilidad o tecnologías de asistencia se basan en un sistema de enfoque basado en el teclado. Entonces, también puedes solucionar muchos problemas asegurándote de que tu página sea accesible mediante el teclado. Por lo tanto, esos dos puntos son probablemente los puntos de partida más importantes.

Mmm. En efecto. Estoy de acuerdo. Y una pregunta más sobre X. X, el enfoque parece estar en los ciegos. Pero ¿hay alguna comprobación para discapacidades motoras? Por ejemplo, el botón debe ser lo suficientemente grande para ser presionado con manos temblorosas. Mm, hay... Entonces, en términos de cómo automatizar la prueba de algo así, las WCAG, que es la lista definitiva de lo que hace que las cosas sean accesibles para el cumplimiento, han implementado una nueva versión, WCAG 2.1, que introdujo una nueva regla sobre lo que llaman espaciado objetivo. Eso dice que cualquier botón o cualquier cosa que se pueda hacer clic debe tener un cierto tamaño y que debe tener un cierto margen alrededor. Y eso es probablemente lo más cercano que se puede llegar a algo como manos temblorosas o temblores en términos de asegurarse de que tu página sea accesible para eso pero no hay mucho más que puedas hacer. En términos de automatización, eso probablemente queda más en manos de un probador manual para ver si hay suficiente espacio alrededor del área para asegurarse de que si tienes temblores no puedas hacer clic accidentalmente en otra cosa. En efecto, oh, muchas gracias por la respuesta. Fue realmente interesante también especialmente porque en las pruebas siempre consideramos desde un punto de vista de experiencia de usuario que tal vez alguien tenga un dedo más fuerte o simplemente 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 la accesibilidad. Tengo curiosidad por leer más al respecto. No olvides calificar también 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

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.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
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.
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
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!

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
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
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
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.
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
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
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
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.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
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.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
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.