ARIA DevTools - Visualización del árbol de accesibilidad de sitios web

• ARIA DevTools es una extensión de Chrome que permite revisar una aplicación web según la estructura que interpreta un lector de pantalla, para que sea más fácil detectar problemas de accesibilidad durante el desarrollo
• Muestra los elementos de la página según roles ARIA explícitos e implícitos, y permite revisar títulos, imágenes, tablas, campos de formulario y otros elementos
• Se enfoca en detectar problemas que pueden afectar la experiencia real con tecnologías de asistencia, como etiquetas ARIA faltantes, asignación incorrecta de roles o soporte incompleto para teclado
• Según Chrome Web Store, tiene 10,000 usuarios, una calificación de 4.9/5 y 33 reseñas, y está registrada en la categoría Developer Tools
• El desarrollador declara que no recopila ni usa datos de los usuarios, y el estado del proyecto puede revisarse en su repositorio de GitHub y su página de issues

---

Verificación del árbol de accesibilidad desde la perspectiva de un lector de pantalla

• ARIA DevTools es una extensión para herramientas de desarrollo que ayuda a crear y probar aplicaciones web accesibles
• Muestra los sitios web de la forma en que un lector de pantalla los transmite a usuarios con discapacidad visual
• Los elementos de la página se organizan según roles ARIA explícitos o implícitos
  • Títulos
  • Imágenes
  • Tablas
  • Campos de formulario
  • Otros elementos de la página

Problemas de accesibilidad que puede revisar

• Permite identificar con mayor facilidad etiquetas ARIA faltantes
• Ayuda a encontrar roles ARIA usados incorrectamente
• También permite revisar soporte incompleto para teclado
• Su objetivo es reducir el esfuerzo necesario para desarrollar y probar sitios web accesibles

Información de registro en Chrome Web Store

• Es una extensión registrada en Chrome Web Store y pertenece a la categoría Developer Tools
• Según su ficha, cuenta con 10,000 usuarios
• Su calificación es de 4.9/5 y tiene 33 reseñas
• La versión es 1.4.3 y su tamaño es 156KiB
• El proyecto es de código abierto y está publicado en GitHub
  • aria-devtools GitHub repository
  • Página de soporte e issues

Tratamiento de datos personales

• El desarrollador declara que esta extensión no recopila ni usa datos de los usuarios
• Los datos no se venden a terceros
• Los datos no se usan ni transfieren para fines no relacionados con la funcionalidad principal de la extensión
• Los datos no se usan ni transfieren para evaluación crediticia ni para fines de préstamos

[GN⁺]

Opiniones en Hacker News

• Se ve excelente. ¿Podrían hacer que también se ejecute dentro de iframes? Sería buenísimo poder usarlo en Storybook/Playroom.
  Enlace para Firefox: https://addons.mozilla.org/en-US/firefox/addon/aria-devtools...

  • Me alegra que te guste. La principal razón por la que todavía no incluí soporte para iframes es que el alcance de los permisos se vuelve mucho más amplio.
    En vez de permitir solo el acceso a la pestaña actual después de hacer clic en el ícono de "ARIA DevTools", como ahora, habría que otorgar permiso para acceder a todos los datos de todos los sitios web que visites. De todos modos, voy a volver a investigar si la situación cambió desde la última vez que lo revisé.
  • Me pregunto si se podría abrir el iframe en una pestaña nueva y usar la extensión ahí.

• Es una herramienta muy útil tanto para revisiones rápidas como para educación. Esta visualización parece ayudar a mostrarles a stakeholders no técnicos cómo pensar en la accesibilidad, especialmente en los lectores de pantalla.
  La mitad de la dificultad de WCAG está en hacer que los stakeholders vayan más allá de simplemente marcar una casilla de cumplimiento.

  • "Pero si ya es texto, ¿no debería simplemente leerlo el lector de pantalla?"
  • Hasta cierto punto tiene sentido. Si el 98% de los usuarios puede usar sin problemas un sitio no accesible, sobre todo considerando que quienes usan mucho la computadora suelen ser más jóvenes, ¿por qué hacer algo más que marcar la casilla? Parece una decisión con valor esperado negativo.

• Muy bueno. Hace poco implementé mi propia visualización del árbol de accesibilidad [1], y me resulta interesante que esta herramienta se aleje del árbol en sí y se enfoque más en la agrupación de unidades individuales.
  Yo lo pensé más por el lado de mostrar la estructura completa y, con eso, ayudar a enfocarse en el flujo lógico de la página. En cambio, ver el árbol como un conjunto de bloques individuales y considerar más importante la cohesión dentro de cada bloque es un enfoque bastante interesante. Si quieren comparar ambos, con gusto conversaría.
  [1] https://polypane.app/blog/polypane-20-1-the-accessibility-tr...

• Se ve limpio y está mucho más ordenado que https://wave.webaim.org/

  • Gracias. Creo que ARIA DevTools tiene mucho potencial. Según mis criterios, es bastante popular, pero no tenía conexión con gente que trabaje a fondo la accesibilidad web.
    En estas herramientas los detalles importan, así que, siendo justos, es probable que WAVE sea más preciso.

• Está bastante limpio y me gusta. Lo probé en una página de metadatos de programas de TV que estoy desarrollando.
  Un elemento es un grupo de div que contiene span que describen su contenido con aria-label; VoiceOver de MacOS lo lee correctamente y el árbol de accesibilidad de Chrome también lo detecta, pero esta herramienta no muestra el aria-label y presenta los valores como una cadena corrida. También detectó ::before { content: ", " / ""; } como , value, pero en general eso no tiene muy buen soporte.

  • ¿Podrías pasarme el enlace a esa página? Me gustaría probarlo directamente y corregirlo.

• Muy bien. Me interesa mucho el soporte de accesibilidad.
  Hoy los sitios web ya no son mi trabajo principal, pero antes siempre me preocupaba de que los sitios a mi cargo estuvieran hechos con muy buena accesibilidad.

• En este tipo de herramientas me gustaría que se separara la lógica de ARIA de la UI. Sería bueno poner el procesamiento complejo relacionado con ARIA en una biblioteca y montar varias UI sobre una base de código común y bien probada.
  Ya que estamos, aprovecho para promocionar: https://github.com/xi/aria-api

• ¿Cómo se compara con la herramienta integrada de Chrome (https://developer.chrome.com/docs/devtools/accessibility/ref...)?

  • Al diseñar esta herramienta, en vez de mostrar solo roles y atributos ARIA, intenté reflejar la experiencia de usuario de un lector de pantalla.
    Por ejemplo, hay que navegar la página solo con el teclado. Si un desplegable no es accesible, se vuelve evidente de inmediato para el usuario. Las tablas también muestran solo una celda y sus encabezados a la vez. Creo que se acerca mucho a la experiencia real de un usuario de lector de pantalla.

• Buena idea y buena implementación. Sin duda la voy a probar en un proyecto paralelo. Justo venía de ver la charla de Mandy Michael sobre rendimiento y accesibilidad de HTML [1], y me preguntaba si habría una herramienta mejor que el visor de árbol de accesibilidad integrado en el navegador.

  1. https://youtu.be/cghb0VpCJqM?si=5pWNrkPOyUsohyGJ

• Excelente herramienta. Últimamente estoy profundizando más en accesibilidad y, en especial, intentando mejorar la experiencia de usuario con lectores de pantalla.
  ¿Alguien con más experiencia la probó en situaciones complejas, como formularios grandes o tablas dinámicas? Me interesa saber cómo se compara con otras herramientas de accesibilidad en esos casos. Agradecería cualquier consejo o insight.