NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Isometrische Illustration Browser mit grünem ANDI Schriftzug und Rakete als Header

Inhaltsverzeichnis

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 im Audit Einsatz: Schnelle Hilfe von NCA

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.

Lass uns sprechen

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Wozu wird ANDI eingesetzt?

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)?

Wie unterstützt ANDI die Barrierefreiheit?

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.

Vier Levels von Accessibility Testing: Wo ANDI hingehört

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.

Level Test-Methode Tool-Beispiele
Level 1: Statisch HTML und Markup Validierung W3C Validator, ESLint a11y Plugins
Level 2: Automatisiert Browser basierte Scanner und Bookmarklets ANDI, axe DevTools, WAVE
Level 3: Manuell Screenreader und Tastatur Test NVDA, JAWS, VoiceOver, Tab Navigation
Level 4: User Tests Tests mit Menschen mit Behinderung Echte Nutzer im strukturierten Test Setup
Bar Chart Infografik vier ansteigende grüne Balken zeigt Testing Levels von Static bis User Tests

Die Module von ANDI im Überblick

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.

ANDI installieren und im Browser nutzen

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 im Vergleich zu axe DevTools, WAVE und Silktide

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.

Man muss zuerst an die Nutzerinnen und Nutzer denken. Nur dann kann ein gutes barrierefreies Angebot entstehen.

Lisa Schiedermaier – Beratungsstelle Barrierefreiheit, Beitrag Digitale barrierefreie Kommunikation

ANDI in NCA Projekten: Stärken und Grenzen aus der Praxis

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.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Erreichen Sie unsere Spezialisten zu barrierefreien Webdesign

Wir sind hier, um Ihnen zu helfen. Gemeinsam meistern wir Ihre digitalen Herausforderungen und fördern die Inklusion im Internet. Lassen Sie uns Ihre Projekte mit barrierefreiem Webdesign erfolgreich machen.

Kostenlose Demo Jetzt anrufen

Häufige Fragen zu ANDI

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.

Ist ANDI 2026 noch aktuell und nutzbar?

Ja, ANDI wird weiter von der US Social Security Administration gepflegt und ist 2026 frei verfügbar. Die letzte größere Aktualisierung erweiterte die Modulpalette und die ARIA Erkennung. Für reine WCAG 2.0 Section 508 Prüfungen ist ANDI aktuell. Für WCAG 2.2 Audits braucht es zusätzliche Werkzeuge wie axe DevTools.

Welche Browser unterstützen ANDI 2026?

ANDI funktioniert mit allen aktuellen Desktop Browsern: Google Chrome, Microsoft Edge, Mozilla Firefox, Apple Safari, Brave und Vivaldi. Mobile Browser werden nicht offiziell unterstützt, da Bookmarklets dort umständlich zu nutzen sind. Für mobile Tests sind die Web Inspectoren in Safari iOS und Chrome Android Developer Tools zusammen mit Screenreader Tests die bessere Wahl.

Erfüllt ANDI 2026 die WCAG 2.2 Anforderungen?

Nein, ANDI prüft auf WCAG 2.0 Basis und die überarbeiteten Section 508 Standards. Neue WCAG 2.2 Erfolgskriterien wie Focus Not Obscured oder Dragging Movements werden nicht abgedeckt. Wer 2026 nach BFSG auditiert, ergänzt ANDI mit axe DevTools oder WAVE für vollständige WCAG 2.2 Coverage.

Welche Alternativen zu ANDI gibt es 2026?

Die wichtigsten Alternativen sind axe DevTools (Browser Erweiterung von Deque, WCAG 2.2 fähig), WAVE (von WebAIM, sehr visuell), Silktide Accessibility Checker (gut für Lerneffekte) und Lighthouse (in Chrome DevTools integriert). Jedes Tool hat eigene Stärken — Profis kombinieren mehrere.

Wie viel Zeit spart ANDI 2026 im Audit?

Bei der Detailprüfung von ARIA Implementierungen und Accessible Names spart ANDI im Vergleich zu manueller DOM Inspektion typischerweise zwei Drittel der Zeit. Für vollständige Site Audits ist ANDI dagegen weniger effizient als axe core basierte Scanner. Wir kombinieren beide Ansätze in unseren Audit Workflows.

Kann ANDI alle Barrierefreiheitsprobleme erkennen?

Nein, ANDI ist ein Hilfswerkzeug. Es zeigt, was Screenreader an einem Element wahrnehmen, prüft aber nicht alle WCAG Erfolgskriterien. Probleme wie unzureichende Farbkontraste auf Hintergrundbildern, kognitive Verständlichkeit oder semantische Unklarheiten brauchen manuelle Bewertung und Tests mit echten Nutzern.

Ist ANDI ein Ersatz für manuelle Tests mit Screenreadern?

Definitiv nein. ANDI zeigt was Screenreader theoretisch lesen würden, aber das tatsächliche Verhalten von NVDA, JAWS oder VoiceOver hängt von zusätzlichen Faktoren ab. Browser Engine, Screenreader Version und Nutzer Einstellungen können das Ergebnis verändern. Manuelle Screenreader Tests bleiben Pflicht.

Wie installiere ich ANDI?

ANDI wird als Bookmarklet installiert. Die offizielle Seite www.ssa.gov/accessibility/andi/help/install.html zeigt den Install Button, den man per Drag and Drop in die Lesezeichenleiste zieht. Keine Browser Erweiterung, keine Zugriffsrechte, kein Account nötig. Die Installation dauert weniger als eine Minute.

Funktioniert ANDI mit Single Page Applications?

Bedingt. ANDI analysiert die Seite einmalig beim Aktivieren. Wenn die SPA das DOM nach State Changes umbaut, muss ANDI erneut aufgerufen werden, um die neuen Elemente zu erfassen. Für SPAs mit häufigem Re Rendering sind axe core basierte Tools mit Mutation Observer oft praktischer.

Welche Module hat ANDI?

ANDI besteht aus dem Hauptmodul und sieben spezialisierten Modulen: iANDI (Bilder), tANDI (Tabellen), fANDI (Formulare), gANDI (Grafiken), sANDI (Strukturelemente), lANDI (Links), cANDI (Color Contrast) und hANDI (Hidden Content). Jedes Modul ist auf einen Element Typ optimiert und liefert detailliertere Analysen als das Hauptmodul.

Was zeigt ANDI über Accessible Names an?

ANDI zeigt für jedes interaktive Element den berechneten Accessible Name an, also den Text, den ein Screenreader vorlesen würde. Dabei wird die Quelle angegeben: aria-label, aria-labelledby, label-Element, sichtbarer Text oder alt Attribut. Falls mehrere Quellen vorhanden sind, zeigt ANDI die Reihenfolge nach der ARIA Spezifikation.

Eignet sich ANDI für Continuous Integration?

Nein, ANDI ist ein Bookmarklet für manuelle Detailprüfung im Browser. Für CI/CD Pipelines sind axe core, pa11y oder Lighthouse CI die richtigen Werkzeuge. Diese laufen headless, integrieren sich in Jenkins, GitHub Actions oder GitLab CI und blocken Pull Requests bei Accessibility Regressions.

Welche Probleme kann ANDI nicht erkennen?

ANDI erkennt keine kognitiven Barrieren (zu komplexe Sprache, unklare Strukturen), keine Farbkontraste auf dynamischen Hintergründen wie Bildern, keine Probleme mit Animationen oder Bewegungsempfindlichkeit und nichts was nur im konkreten Nutzungsszenario sichtbar wird. Diese Aspekte bleiben menschlichem Audit und Nutzer Tests vorbehalten.

Kann ich ANDI auch für Schulungen nutzen?

Ja, ANDI eignet sich gut für Frontend Schulungen. Entwickler sehen direkt, was Screenreader an ihren Komponenten wahrnehmen und welche ARIA Implementierungen wirklich funktionieren. In NCA Workshops zur Barrierefreiheit ist ANDI fester Bestandteil der praktischen Übungen — neben axe DevTools und manuellen NVDA Tests.