ARIA DevTools – Visualisierung des Accessibility Tree von Websites

 (chromewebstore.google.com)
4 Punkte von GN⁺ 2024-10-09 | 1 Kommentare | Auf WhatsApp teilen
  • ARIA DevTools ist eine Chrome-Erweiterung, mit der sich Webanwendungen in der Struktur anzeigen lassen, wie sie von Screenreadern interpretiert wird, sodass Barrierefreiheitsprobleme bereits während der Entwicklung leichter zu finden sind
  • Seitenelemente werden nach expliziten und impliziten ARIA-Rollen dargestellt; dabei lassen sich auch Überschriften, Bilder, Tabellen, Formularelemente und weitere Elemente prüfen
  • Der Fokus liegt auf Problemen, die die tatsächliche Nutzung mit assistiven Technologien beeinträchtigen können, etwa fehlende ARIA-Labels, falsch zugewiesene Rollen oder unvollständige Tastaturunterstützung
  • Laut Chrome Web Store hat die Erweiterung 10.000 Nutzer, eine Bewertung von 4,9/5 Punkten bei 33 Bewertungen und ist in der Kategorie Developer Tools gelistet
  • Der Entwickler gibt an, keine Nutzerdaten zu erheben oder zu verwenden; der Projektstatus lässt sich über das GitHub-Repository und die Issue-Seite einsehen

Accessibility Tree aus Sicht eines Screenreaders prüfen

  • ARIA DevTools ist eine Developer-Tools-Erweiterung, die bei Entwicklung und Test barrierefreier Webanwendungen hilft
  • Sie zeigt Websites so an, wie ein Screenreader sie blinden Nutzerinnen und Nutzern vermittelt
  • Seitenelemente werden nach expliziten oder impliziten ARIA-Rollen geordnet
    • Überschriften
    • Bilder
    • Tabellen
    • Formularelemente
    • Weitere Seitenelemente

Prüfbarkeit von Barrierefreiheitsproblemen

  • Fehlende ARIA-Labels lassen sich leichter erkennen
  • Die Erweiterung hilft dabei, falsch verwendete ARIA-Rollen zu finden
  • Auch unvollständige Tastaturunterstützung kann mit geprüft werden
  • Ziel ist es, den Aufwand für Entwicklung und Test barrierefreier Websites zu reduzieren

Angaben im Chrome Web Store

  • Die Erweiterung ist im Chrome Web Store gelistet und gehört zur Kategorie Developer Tools
  • Laut Eintrag beträgt die Nutzerzahl 10.000
  • Die Bewertung liegt bei 4,9/5 Punkten, mit 33 Bewertungen
  • Die Version ist 1.4.3, die Größe beträgt 156 KiB
  • Das Projekt ist als Open Source auf GitHub veröffentlicht

Datenschutz

  • Der Entwickler gibt an, dass diese Erweiterung Nutzerdaten nicht erhebt oder verwendet
  • Daten werden nicht an Dritte verkauft
  • Daten werden nicht für Zwecke verwendet oder übertragen, die nichts mit den Kernfunktionen der Erweiterung zu tun haben
  • Daten werden nicht zur Beurteilung der Kreditwürdigkeit oder für Kreditzwecke verwendet oder übertragen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-09
Hacker-News-Kommentare

  • Sieht großartig aus. Könnten Sie dafür sorgen, dass es auch innerhalb von iframes läuft? Es wäre wirklich toll, wenn man es in Storybook/Playroom verwenden könnte.
    Firefox-Link: https://addons.mozilla.org/en-US/firefox/addon/aria-devtools...

    • Freut mich, dass es Ihnen gefällt. Der wichtigste Grund, warum ich iframe-Support noch nicht eingebaut habe, ist, dass der Berechtigungsumfang dadurch viel größer würde.
      Statt wie jetzt nach einem Klick auf das „ARIA DevTools“-Icon nur den Zugriff auf den aktuellen Tab zu erlauben, müsste man der Erweiterung Zugriff auf alle Daten auf allen besuchten Websites geben. Ich werde aber noch einmal prüfen, ob sich seit meiner letzten Recherche etwas geändert hat.
    • Ich frage mich, ob man das iframe in einem neuen Tab öffnen und die Erweiterung dann darauf verwenden könnte.

  • Ein sehr nützliches Tool, sowohl für schnelle Checks als auch für Schulungen. Diese Visualisierung dürfte dabei helfen, nichttechnischen Stakeholdern Barrierefreiheit näherzubringen, insbesondere wie man über Screenreader nachdenken sollte.
    Die Hälfte der Schwierigkeit bei WCAG besteht darin, Stakeholder dazu zu bringen, über das bloße Abhaken einer Compliance-Checkbox hinauszugehen.

    • „Es ist doch schon Text – kann ein Screenreader das nicht einfach vorlesen?“
    • Bis zu einem gewissen Grad ergibt das Sinn. Wenn 98 % der Nutzer eine nicht barrierefreie Website problemlos verwenden können, warum sollte man dann mehr tun als die Checkbox abzuhaken – besonders wenn man bedenkt, dass Menschen, die viel am Computer arbeiten, im Allgemeinen eher jung sind? Das wirkt wie eine Entscheidung mit negativem Erwartungswert.

  • Sehr cool. Ich habe kürzlich meine eigene Visualisierung des Accessibility Tree implementiert [1], und interessant an diesem Tool ist, dass die Visualisierung weniger den Baum selbst in den Mittelpunkt stellt, sondern stärker die Gruppierung einzelner Einheiten.
    Ich hatte eher daran gedacht, die Gesamtstruktur zu zeigen und darüber den Fokus auf den logischen Fluss der Seite zu lenken. Der umgekehrte Ansatz, den Baum als Sammlung einzelner Blöcke zu betrachten und die Kohäsion innerhalb jedes Blocks als wichtiger anzusehen, ist ziemlich interessant. Wenn Sie das gern vergleichen möchten, tausche ich mich gerne darüber aus.
    [1] https://polypane.app/blog/polypane-20-1-the-accessibility-tr...

  • Sieht aufgeräumt aus und ist viel übersichtlicher als https://wave.webaim.org/.

    • Danke. Ich glaube, ARIA DevTools hat viel Potenzial. Nach meinen Maßstäben ist es recht beliebt, aber ich hatte bisher keine Verbindung zu Leuten, die sich intensiv mit Web Accessibility beschäftigen.
      Bei solchen Tools sind die Details wichtig; fairerweise ist WAVE also wahrscheinlich genauer.

  • Ziemlich sauber, gefällt mir. Ich habe es auf einer Metadatenseite für TV-Programme getestet, an der ich gerade arbeite.
    Ein Element ist eine Gruppe von divs, die jeweils ein span enthalten, dessen Inhalt per aria-label beschrieben wird. VoiceOver unter macOS liest das korrekt vor, und auch Chromes Accessibility Tree erkennt es, aber dieses Tool zeigt das aria-label nicht an und gibt die Werte stattdessen als fortlaufende Zeichenkette aus. Außerdem hat es ::before { content: ", " / ""; } als , value erkannt, was insgesamt nicht besonders gut unterstützt wird.

    • Könnte ich einen Link zu der Seite bekommen? Ich würde das gern selbst testen und beheben.

  • Schön. Ich interessiere mich sehr für Accessibility Support.
    Websites sind inzwischen nicht mehr meine Hauptarbeit, aber früher habe ich immer darauf geachtet, dass die von mir betreuten Sites sehr barrierefrei gebaut wurden.

  • Bei solchen Tools würde ich mir wünschen, dass die ARIA-Logik von der UI getrennt wird. Die komplexe ARIA-Verarbeitung sollte in eine Bibliothek, und darauf aufbauend könnten mehrere UIs auf einer gut getesteten gemeinsamen Codebasis entstehen.
    In eigener Sache: https://github.com/xi/aria-api

  • Wie schneidet es im Vergleich zu Chromes eingebautem Tool ab (https://developer.chrome.com/docs/devtools/accessibility/ref...)?

    • Beim Design dieses Tools wollte ich nicht nur ARIA-Rollen und -Attribute anzeigen, sondern die User Experience von Screenreader-Nutzern widerspiegeln.
      Zum Beispiel muss man die Seite ausschließlich per Tastatur navigieren. Wenn ein Dropdown nicht barrierefrei ist, fällt das dem Nutzer sofort auf. Auch bei Tabellen wird jeweils nur eine Zelle zusammen mit ihrem Header angezeigt. Ich denke, das kommt der tatsächlichen Erfahrung von Screenreader-Nutzern sehr nahe.

  • Gute Idee und gute Umsetzung. Ich werde es auf jeden Fall in einem Side Project ausprobieren. Ich hatte gerade Mandy Michaels Vortrag zu HTML-Performance und Accessibility [1] gesehen und mich gefragt, ob es ein besseres Tool als den eingebauten Accessibility-Tree-Viewer des Browsers gibt.

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

  • Tolles Tool. Ich beschäftige mich in letzter Zeit intensiver mit Accessibility und möchte besonders die User Experience von Screenreader-Nutzern verbessern.
    Haben erfahrenere Leute dieses Tool schon in komplexen Situationen wie großen Formularen oder dynamischen Tabellen getestet? Mich würde interessieren, wie es in solchen Fällen im Vergleich zu anderen Accessibility-Tools abschneidet. Für Tipps oder Einblicke wäre ich dankbar.