Was ist ANDI? Accessible Name and Description Inspector erklärt

ANDI (Accessible Name & Description Inspector) ist ein kostenloses Bookmarklet zur Prüfung der Barrierefreiheit von Webseiten. Es zeigt Entwicklern und Testern direkt im Browser, wie Screenreader Webinhalte interpretieren und welche Accessible Names, Roles und Descriptions an Bedienelementen anliegen — ohne Installation einer Browser Erweiterung.

ANDI wurde von der US Social Security Administration (SSA) entwickelt und ist seit über einem Jahrzehnt frei verfügbar. Das Tool prüft Webseiten auf Konformität mit den überarbeiteten Section 508 Standards, die auf WCAG 2.0 basieren. Neuere WCAG 2.2 Erfolgskriterien werden nicht vollständig abgedeckt.

Trotz dieser Einschränkung gehört ANDI zum Standard Werkzeugkasten in Accessibility Audits: kaum ein anderes frei verfügbares Tool zeigt so detailliert, was Screenreader an einem Element wahrnehmen — inklusive Reihenfolge und Quelle der Information.

ANDI ist eines der Tools, die wir bei NCA in Accessibility Audits regelmäßig einsetzen. Gerade wenn ARIA Implementierungen verifiziert oder Accessible Names im Detail geprüft werden müssen, liefert das Bookmarklet Antworten schneller als jedes andere frei verfügbare Tool. Wir kennen die Stärken und Grenzen der ANDI Module und wissen, wann ein Wechsel zu axe DevTools, WAVE oder einem manuellen Screenreader Test sinnvoller ist.

Konkret unterstützen wir Teams beim barrierefreien Webdesign nach BFSG und WCAG 2.2. Dazu gehören Audits, Accessibility Testing Setups, die Optimierung von ARIA Strukturen und die Schulung von Frontend Teams im Umgang mit Tools wie ANDI.

ANDI dient als schnelles Diagnose Tool für die Barrierefreiheit von Webseiten. Statt sich durch die DevTools zu klicken, sieht man auf einen Blick, was Screenreader an einem Element wahrnehmen würden. Typische Anwendungsfälle:

• Accessible Names prüfen: Hat dieser Button einen sinnvollen Namen, den Screenreader vorlesen würden?
• ARIA Implementierung verifizieren: Funktionieren aria-label, aria-labelledby, aria-describedby wie erwartet?
• Screenreader Verhalten simulieren: Was würde ein blinder Nutzer bei diesem Element hören?
• Section 508 Konformität testen: Erfüllt die Seite die US Bundesvorgaben für Barrierefreiheit?
• Quick Audit ohne Setup: Bei Kunden, in Restricted Browsern oder als Demo ohne Installation einer Erweiterung.

Im Unterschied zu reinen Accessibility Testing Scannern wie axe oder WAVE liefert ANDI die Detailansicht eines Elements: Was wird gelesen, in welcher Reihenfolge und aus welcher Quelle (alt, aria-label, label Tag, sichtbarer Text)?

ANDI hilft Entwicklern, Designern und Redakteuren, Probleme der Barrierefreiheit auf ihren Webseiten zu identifizieren. Das Tool macht sichtbar, was sonst nur indirekt über die Accessibility Tree der Browser DevTools zu erkennen ist.

Konkret prüft ANDI Folgendes:

• Accessible Name: Welchen Namen würde ein Screenreader für dieses Element ausgeben?
• Role: Wird das Element korrekt als Button, Link, Heading oder Region erkannt?
• Description: Gibt es zusätzliche Beschreibungen via aria-describedby?
• State: Ist das Element aktiviert, deaktiviert, ausgewählt oder versteckt?
• Tabbable Status: Kann das Element per Tastatur erreicht werden?
• Hidden Content: Welche Inhalte sind für Screenreader sichtbar, obwohl visuell versteckt?

Diese Informationen werden in einem Overlay direkt am oberen Rand der getesteten Seite eingeblendet. Beim Hovern oder per Tastatur Navigation aktualisiert sich die Anzeige für jedes Element. So lassen sich Probleme wie fehlende Alt-Texte, kaputte ARIA Labels oder unklare Bedien Bezeichnungen schnell finden.

ANDI ist ein wertvolles, aber begrenztes Werkzeug. Um seine Rolle einordnen zu können, hilft eine Klassifikation der Accessibility Testing Methoden. In der Praxis lassen sich vier Levels unterscheiden, die in ihrer Aussagekraft aufsteigend geordnet sind. Die folgende Tabelle und die Infografik darunter zeigen die Levels mit Beispiel Tools — ANDI sitzt klar in Level 2.

ANDI besteht nicht nur aus dem Haupt Tool. Die SSA hat eine ganze Familie von Modulen entwickelt, die jeweils auf bestimmte Elementtypen spezialisiert sind. Jedes Modul lässt sich aus dem ANDI Hauptmenü heraus aktivieren:

• ANDI (default): Allgemeiner Inspector für alle interaktiven Elemente
• iANDI: Bilder, Grafiken und SVG Elemente, prüft Alt-Texte und visuelle Alternativen
• tANDI: Tabellen, analysiert Header Zuordnungen, Caption und Scope Attribute
• fANDI: Formulare, prüft Labels, Fieldsets, Required Attribute und ARIA Verbindungen
• gANDI: Grafiken und Icons, Detailprüfung für SVG und visuelle Inhalte
• sANDI: Strukturelemente, Headings, Landmarks, ARIA Regions
• lANDI: Links, prüft auf sinnvolle Linktexte und Title Attribute
• cANDI: Color Contrast, analysiert Farbkontraste nach WCAG
• hANDI: Hidden Content, zeigt versteckte Inhalte die Screenreader trotzdem lesen würden

Diese Modulauswahl macht ANDI flexibler als andere Bookmarklets. Wer nur Tabellen prüfen will, nutzt tANDI, wer Formulare auditiert, fANDI. Eine vollständige Übersicht und Demos finden sich auf der offiziellen ANDI Help Seite der SSA.

Die Installation von ANDI dauert weniger als eine Minute und benötigt keine Browser Erweiterung. Stattdessen wird das Bookmarklet einfach in die Lesezeichenleiste gezogen.

• Schritt 1: Die offizielle ANDI Seite öffnen unter www.ssa.gov/accessibility/andi/help/install.html
• Schritt 2: Den Install Button per Drag and Drop in die Lesezeichenleiste ziehen
• Schritt 3: Die zu prüfende Webseite öffnen
• Schritt 4: Das ANDI Bookmarklet anklicken — ein Overlay erscheint am oberen Browser Rand
• Schritt 5: Mit Maus oder Tastatur durch die Elemente navigieren — ANDI zeigt für jedes Element den Accessible Name, die Rolle und mögliche Probleme an

Bei Single Page Applications muss ANDI nach DOM Änderungen erneut aktiviert werden, da das Bookmarklet die Seite einmalig analysiert. Für lange Test Sessions oder Continuous Integration sind automatisierte Tools wie axe-core besser geeignet.

ANDI ist eines von vielen Werkzeugen für die Accessibility Prüfung. Die Wahl des richtigen Tools hängt vom Anwendungsfall ab.

• ANDI: Bookmarklet ohne Installation. Stärke: Detailansicht der Accessible Names, ARIA Verbindungen und Hidden Content. Schwäche: nur Section 508 und WCAG 2.0, kein automatisches Reporting.
• axe DevTools: Browser Erweiterung von Deque. Stärke: WCAG 2.2 Coverage, Integration in CI/CD via axe-core, präzise Issue Reports. Schwäche: erfordert Installation, kostenpflichtige Pro Variante.
• WAVE: Browser Erweiterung und Online Tool von WebAIM. Stärke: visuelle Markierung von Issues direkt auf der Seite, einfacher Einstieg. Schwäche: weniger Detailtiefe als ANDI bei einzelnen Elementen.
• Silktide Accessibility Checker: Browser Erweiterung mit Fokus auf Lernen. Stärke: Erklärungen, warum etwas ein Problem ist, Trainingseffekt für Teams. Schwäche: weniger detailliert für Power User. Mehr im Artikel Silktide Accessibility Checker.

In NCA Audits kombinieren wir typischerweise mehrere dieser Tools: axe DevTools für den Initial Scan, ANDI für die Detailprüfung kritischer Komponenten, manuelle Tests mit NVDA und VoiceOver für die User Experience. Mehr zur Methodik in unserem Artikel Accessibility Testing.

In Beratungsprojekten setzen wir ANDI als ein Tool unter mehreren ein. Die Erfahrungen aus den letzten Audits lassen sich in drei klaren Erkenntnissen zusammenfassen:

Erstens: ANDI ist unschlagbar bei der Detailprüfung von ARIA Implementierungen. Wenn ein Custom Component nicht so liest wie erwartet, zeigt ANDI in Sekunden, was Screenreader tatsächlich wahrnehmen — ohne durch DevTools Tabs zu klicken. Für Frontend Entwickler ist das oft der Aha Moment im Audit.

Zweitens: Die WCAG 2.0 Basis macht ANDI für moderne Audits limitiert. Wer auf WCAG 2.2 prüft (was seit BFSG Pflicht ist), braucht zusätzlich axe DevTools oder ähnliche Werkzeuge. ANDI ergänzt, ersetzt aber kein vollständiges Audit Setup.

Drittens: Single Page Applications fordern ANDI heraus. Bei dynamischem DOM braucht es nach jedem State Change einen erneuten ANDI Run. Für Continuous Testing sind automatisierte Tools mit axe-core Integration die bessere Wahl.

Wer ANDI in einem strukturierten Setup einsetzen will, findet bei NCA sowohl Accessibility Audits als auch konkrete Hilfe bei der Umsetzung der BFSG Anforderungen.

Die folgenden Antworten beruhen auf der offiziellen ANDI Dokumentation der SSA, aktuellen WCAG 2.2 Vorgaben und unserer eigenen Praxis aus Beratungsprojekten. Für vertiefende Erklärungen verlinken wir auf die passenden Artikel im NCA Glossar für Barrierefreiheit.