ARIA DevTools - visualisation de l’arbre d’accessibilité d’un site web

 (chromewebstore.google.com)
4 points par GN⁺ 2024-10-09 | 1 commentaires | Partager sur WhatsApp
  • ARIA DevTools est une extension Chrome qui permet d’examiner une application web selon la structure interprétée par les lecteurs d’écran, afin de repérer plus facilement les problèmes d’accessibilité dès la phase de développement
  • Elle affiche les éléments de la page selon leurs rôles ARIA explicites ou implicites, et permet aussi de vérifier les titres, images, tableaux, champs de formulaire, etc.
  • Elle se concentre sur la vérification de problèmes susceptibles de nuire à l’expérience réelle avec les technologies d’assistance, comme des labels ARIA manquants, des rôles mal attribués ou une prise en charge incomplète du clavier
  • D’après le Chrome Web Store, elle compte 10 000 utilisateurs, une note de 4,9/5 et 33 avis, et elle est répertoriée dans la catégorie Developer Tools
  • Le développeur indique publiquement ne pas collecter ni utiliser les données des utilisateurs, et l’état du projet peut être vérifié via le dépôt GitHub et la page des issues

Vérifier l’arbre d’accessibilité du point de vue d’un lecteur d’écran

  • ARIA DevTools est une extension d’outils pour développeurs destinée à aider au développement et aux tests d’applications web accessibles
  • Elle montre un site web de la manière dont un lecteur d’écran le restitue à un utilisateur malvoyant ou aveugle
  • Les éléments de la page sont organisés selon leurs rôles ARIA explicites ou implicites
    • Titres
    • Images
    • Tableaux
    • Champs de formulaire
    • Autres éléments de la page

Problèmes d’accessibilité pouvant être vérifiés

  • Elle permet de repérer plus facilement les labels ARIA manquants
  • Elle aide à trouver les rôles ARIA mal utilisés
  • Elle permet également de vérifier une prise en charge incomplète du clavier
  • Son objectif est de réduire les efforts nécessaires pour développer et tester des sites web accessibles

Informations de la fiche Chrome Web Store

  • Il s’agit d’une extension enregistrée sur le Chrome Web Store, dans la catégorie Developer Tools
  • Le nombre d’utilisateurs indiqué est de 10 000
  • La note est de 4,9/5, avec 33 avis
  • La version est 1.4.3 et la taille est de 156KiB
  • Le projet est un open source publié sur GitHub

Traitement des données personnelles

  • Le développeur déclare que cette extension ne collecte ni n’utilise les données des utilisateurs
  • Les données ne sont pas vendues à des tiers
  • Les données ne sont ni utilisées ni transférées à des fins sans rapport avec les fonctionnalités principales de l’extension
  • Les données ne sont ni utilisées ni transférées à des fins d’évaluation de solvabilité ou d’octroi de prêts

À lire aussi

1 commentaires

 
GN⁺ 2024-10-09
Avis sur Hacker News

  • Ça a l’air excellent. Serait-il possible de le faire fonctionner aussi dans les iframes ? Ce serait vraiment super de pouvoir l’utiliser dans Storybook/Playroom.
    Lien Firefox : https://addons.mozilla.org/en-US/firefox/addon/aria-devtools...

    • Ravi que ça vous plaise. La principale raison pour laquelle je n’ai pas encore ajouté la prise en charge des iframes est que la portée des permissions deviendrait beaucoup plus large.
      Au lieu de simplement autoriser l’accès à l’onglet courant après avoir cliqué sur l’icône « ARIA DevTools », comme aujourd’hui, il faudrait donner l’autorisation d’accéder à toutes les données de tous les sites web visités. Cela dit, je vais vérifier de nouveau si la situation a changé depuis la dernière fois que j’ai regardé.
    • Je me demande s’il serait possible d’ouvrir l’iframe dans un nouvel onglet et d’utiliser l’extension dessus.

  • C’est un outil très utile, aussi bien pour des vérifications rapides que pour la formation. Cette visualisation semble pouvoir aider des parties prenantes non techniques à comprendre comment penser l’accessibilité, en particulier les lecteurs d’écran.
    La moitié de la difficulté avec les WCAG consiste à amener les parties prenantes à dépasser le simple fait de cocher une case de conformité.

    • « C’est déjà du texte, le lecteur d’écran n’a qu’à le lire, non ? »
    • Dans une certaine mesure, ça se tient. Si 98 % des utilisateurs peuvent utiliser sans problème des sites non accessibles, surtout quand on pense que les personnes qui utilisent beaucoup l’ordinateur sont généralement jeunes, pourquoi faire plus que cocher la case ? On dirait un choix à espérance négative.

  • Très chouette. J’ai récemment implémenté ma propre visualisation de l’arbre d’accessibilité [1], et je trouve cet outil intéressant parce que sa visualisation s’éloigne de l’arbre lui-même pour se concentrer davantage sur le regroupement d’unités individuelles.
    De mon côté, je l’ai plutôt pensé pour montrer la structure globale et aider ainsi à se concentrer sur le flux logique de la page. À l’inverse, l’approche qui consiste à voir l’arbre comme un ensemble de blocs individuels, où la cohésion interne de chaque bloc est plus importante, est assez intéressante. Si vous voulez comparer les deux, je serais ravi d’en discuter.
    [1] https://polypane.app/blog/polypane-20-1-the-accessibility-tr...

  • Ça a l’air propre, et c’est beaucoup plus ordonné que https://wave.webaim.org/

    • Merci. Je pense qu’ARIA DevTools a beaucoup de potentiel. À mon échelle, il est assez populaire, mais je n’avais pas de lien avec les personnes qui travaillent en profondeur sur l’accessibilité web.
      Les détails comptent pour ce genre d’outil, donc pour être honnête, WAVE est probablement plus précis.

  • C’est plutôt propre et ça me plaît. Je l’ai testé sur une page de métadonnées de programmes TV que je développe.
    Un élément est un groupe de div contenant chacun un span dont le contenu est décrit par aria-label ; VoiceOver sur macOS le lit correctement et l’arbre d’accessibilité de Chrome le détecte aussi, mais cet outil n’affiche pas les aria-label et présente simplement les valeurs comme une longue chaîne de texte. Il a aussi détecté ::before { content: ", " / ""; } comme , value, ce qui, globalement, n’est pas très bien pris en charge.

    • Pourriez-vous m’envoyer un lien vers la page ? J’aimerais tester directement et corriger ça.

  • C’est bien. Je m’intéresse beaucoup à la prise en charge de l’accessibilité.
    Les sites web ne sont plus mon activité principale, mais auparavant je veillais toujours à ce que les sites dont je m’occupais soient très accessibles.

  • Avec ce genre d’outils, j’aimerais que la logique ARIA soit séparée de l’UI. Le traitement complexe lié à ARIA devrait être placé dans une bibliothèque, puis plusieurs UI pourraient être construites au-dessus d’une base de code commune et bien testée.
    Au passage, un peu d’auto-promo : https://github.com/xi/aria-api

  • Comment cela se compare-t-il aux outils intégrés de Chrome (https://developer.chrome.com/docs/devtools/accessibility/ref...) ?

    • En concevant cet outil, j’ai essayé de refléter l’expérience utilisateur des lecteurs d’écran, plutôt que de simplement afficher les rôles et attributs ARIA.
      Par exemple, il faut naviguer dans la page uniquement au clavier. Si un menu déroulant n’est pas accessible, cela apparaît immédiatement à l’utilisateur. Les tableaux aussi n’affichent qu’une cellule à la fois avec ses en-têtes. Je pense que c’est très proche de l’expérience réelle d’un utilisateur de lecteur d’écran.

  • Bonne idée et bonne implémentation. Je vais sûrement l’essayer sur un projet perso. Je venais justement de regarder la conférence de Mandy Michael sur les performances HTML et l’accessibilité [1], et je me demandais s’il existait un meilleur outil que le visualiseur d’arbre d’accessibilité intégré au navigateur.

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

  • Super outil. Je creuse davantage l’accessibilité ces derniers temps, et j’essaie surtout d’améliorer l’expérience utilisateur des lecteurs d’écran.
    Parmi les personnes plus expérimentées, quelqu’un a-t-il testé cet outil dans des cas complexes comme de grands formulaires ou des tableaux dynamiques ? Je serais curieux de savoir comment il se compare à d’autres outils d’accessibilité dans ce genre de situations. Tous conseils ou retours seraient appréciés.