Existe la sensación de que la accesibilidad no es una lista de verificación, lo que significa que si realmente está tratando de hacer que un sitio sea accesible, no solo puede marcar algunas cosas de una lista y llamarlo perfecto. La lista puede ser imperfecta y, lo que es peor, saca al usuario de la ecuación, así se dice.
Karl Groves una vez argumentó en contra de esto:
Yo diría que un proceso bien documentado que incluye evaluaciones basadas en listas de verificación es mejor para garantizar que se satisfagan todas las necesidades de los usuarios, no solo algunos usuarios.
Menciono esto porque podría considerar una herramienta de prueba de accesibilidad automatizada como otra forma de lista de verificación. Tienen reglas integradas y prueban su sitio con esa lista de reglas.
Soy bastante nuevo en la idea de estas cosas, así que no soy un experto aquí, ¡pero parece que hay bastantes opciones! Echemos un vistazo a algunos de ellos.
hacha
El motor de accesibilidad para pruebas automatizadas de interfaces de usuario basadas en HTML. ¡Deje caer el hacha sobre sus defectos de accesibilidad!
ax puede echar un vistazo a un documento HTML y encontrar posibles problemas de accesibilidad e informárselo. Por ejemplo, existen extensiones de navegador (Firefox / Chrome) que le brindan la capacidad de generar un informe de errores de accesibilidad en la página que está viendo.
En esencia, es un guión, por lo que se puede utilizar de muchas formas. Por ejemplo, puede cargar esa secuencia de comandos en un lápiz y probar la accesibilidad de ese lápiz.
Hay una CLI para que pueda integrarla en procesos de compilación o entornos de prueba o flujos de implementación o lo que sea.
Parece que tal vez intern-a11y pueda ayudar a script axe para una funcionalidad adicional.
Pa11y
Pa11y es su compañero de pruebas de accesibilidad automatizadas. Ejecuta HTML CodeSniffer desde la línea de comandos para informes de accesibilidad programáticos.
Pa11y es otra herramienta en este sentido. Es un script que puede probar una URL en busca de problemas de accesibilidad. Puede presionarlo con una ruta de archivo o URL desde la línea de comando (pa11y http://example.com) y obtenga un informe.
Además de utilizarlo desde un entorno de nodo y configurarlo como sea necesario. En realidad, está intencionalmente destinado a usarse solo mediante programación, ya que es la versión programática de HTML_CodeSniffer, la versión de bookmarklet / visual.
También hay una versión de la aplicación nativa llamada Koa11y si eso facilita el uso.
Seren Davies escribió recientemente sobre un escenario específico en el que eligieron a Pa11y en lugar de ax:
Comenzamos investigando la CLI de ax, pero pronto nos dimos cuenta de que no se ajustaba a nuestros requisitos. No podía verificar las páginas que requerían que un visitante iniciara sesión, por lo que, aunque pudimos probar nuestras páginas de productos, no pudimos probar ninguna página de cuenta de cliente. En cambio, nos mudamos a Pa11y. Su beforeScript paso significaba que podíamos iniciar sesión en el sitio y probar páginas como el historial de pedidos.
Herramientas para desarrolladores de accesibilidad de Google
Google participa en el juego con las herramientas para desarrolladores de accesibilidad.
Su componente principal es la auditoría de accesibilidad: una colección de reglas de auditoría que verifican problemas de accesibilidad comunes y una API para ejecutar estas reglas en una página HTML.
Es similar a los demás en el sentido de que está diseñado para usarse de diferentes maneras, como la tarea Grunt, desde la línea de comandos o el navegador.
Addy Osmani tiene todo, impulsado por Chrome Accessibility Tools, que parece proporcionar una mejor API y mejores informes.
Sin embargo, parece que la mayor parte del peso de la auditoría de sitios web de Google está detrás de Lighthouse en estos días, que incluyen pruebas de accesibilidad. Por ejemplo, la prueba “Los botones tienen un nombre accesible”, pero esa prueba es en realidad un hacha bajo el capó.
No me queda claro si Lighthouse ejecuta una auditoría completa y actualizada o no, y si las herramientas de desarrollo de accesibilidad están en desuso a favor de eso, o qué.
Herramienta de prueba de accesibilidad automatizada (AATT)
PayPal está en el juego con AATT, una combinación y extensión de las herramientas ya mencionadas:
Las herramientas y complementos de prueba de accesibilidad basados en navegador requieren probar manualmente cada página, una a la vez. Las herramientas que pueden rastrear un sitio web solo pueden escanear páginas que no requieren credenciales de inicio de sesión y que no están detrás de un firewall. En lugar de desarrollar, probar y utilizar un conjunto de pruebas de accesibilidad separado, ahora puede integrar las pruebas de accesibilidad en su conjunto de pruebas de automatización existente utilizando AATT.
AATT incluye HTML CodeSniffer, ax y la herramienta de desarrollo Chrome con Express y PhantomJS, que se ejecuta en Node.
Activa un servidor con una API que puede usar para probar páginas en otros servidores.
accessibilityjs
Los propios GitHub lanzaron recientemente accessibilityjs, la herramienta que ellos mismos utilizan para las pruebas de accesibilidad. Lo usan en el lado del cliente, donde cuando encuentra un error, aplica un borde rojo enorme y aplica un controlador de clic para que pueda hacer clic en él y decirle cuál es el problema.
Lo limitan a estos errores comunes:
ImageWithoutAltAttributeErrorElementWithoutLabelErrorLinkWithoutLabelOrRoleErrorLabelMissingControlErrorInputMissingLabelErrorButtonWithoutLabelErrorARIAAttributeMissingError
Tenon.io
Tenen.io es quizás el más fácil de todos para comenzar, ya que la página de inicio tiene un validador en la parte superior donde puede copiar y pegar HTML o colocar una URL para validar.
Tenon.io puede identificar problemas 508 y WCAG 2.0 en cualquier entorno, incluso en la computadora portátil de su desarrollador. Porque la producción es un mal lugar para descubrir errores.
Tiene una prueba gratuita de 30 días / 500 llamadas API, y es un producto de pago más allá de eso.
Tenon.io se integra en muchos lugares. El mismo Karl me dijo:
Tenemos una CLI. Tenemos complementos de Grunt & Gulp, módulos de nodo y complementos para Chrome, Firefox, IE y Opera. Clases PHP, Ruby Gems, integraciones CMS para WordPress, Drupal, etc.
Menciones honoríficas
No estoy tratando de mostrar u ocultar intencionalmente ninguna herramienta de prueba de accesibilidad en particular. Todo esto es nuevo para mí. Parecía que estos eran muchos de los grandes jugadores. ¡Pero la búsqueda en la web revela mucho más!
- Tanaguru: “Herramienta de prueba de accesibilidad automatizada (a11y), con énfasis en la confiabilidad y la automatización”
- La máquina A11y “es una herramienta de prueba de accesibilidad automatizada que rastrea y prueba las páginas de cualquier aplicación web para producir informes detallados”.
- tota11y: “un conjunto de herramientas de visualización de accesibilidad (a11y)”