AA-Web-Barrierefreiheit: Werkzeugvergleich 2026

AA-Webzugänglichkeit bezieht sich auf die AA-Konformitätsstufe der vom W3C veröffentlichten Web Content Accessibility Guidelines (WCAG) 2.2, die die Erfüllung der 30 Level-A-Kriterien plus 20 Level-AA-Kriterien (insgesamt 50) erfordert. Dazu kombinieren Teams neben einer manuellen Überprüfung drei Arten von Tools: automatisierte Auditoren, Kontrastassistenten und Screenreader.

Wichtige Erkenntnisse

• Die WCAG 2.2 Stufe AA umfasst 50 Erfolgskriterien (30 Stufe A + 20 Stufe AA); sie ist die Schwelle für die AA-Webzugänglichkeit, die von den meisten Gesetzgebungen gefordert wird, einschließlich der europäischen Norm EN 301 549.
• Kein Tool erkennt allein alle Fehler: Automatisierte Auditoren decken etwa ein Drittel der Kriterien ab, daher sind die manuelle Überprüfung und Tests mit Screenreadern obligatorisch.
• Die Wahl hängt vom Workflow ab: Browser-Erweiterungen für die tägliche Entwicklung, CI-Suites für Teams und externe Audits für formelle Zertifizierungen.
• Die vier Arten von Tools, die Sie benötigen, sind: automatisierte Auditoren, Kontrastprüfer, Screenreader und Struktur-/HTML-Validatoren.
• Die Dokumentation jeder Entscheidung zur Barrierefreiheit (was wurde mit welcher Version und in welchem Browser getestet) ist ebenso wichtig wie die Behebung des Fehlers, um die Konformität nachzuweisen.

Was „AA“ bei der Webzugänglichkeit wirklich bedeutet

WCAG Level AA ist die zweite von drei vom W3C definierten Konformitätsstufen (A, AA und AAA). Jede Stufe kombiniert die Kriterien der vorherigen Stufe: Um die AA-Konformität zu erklären, müssen Sie die 30 Level-A-Kriterien und die 20 Level-AA-Kriterien erfüllen, was insgesamt 50 Erfolgskriterien entspricht. Die AAA-Stufe fügt 28 weitere hinzu; es ist selten, dass sie vollständig gefordert wird, da bestimmte Kriterien in allen Inhalten unmöglich zu erfüllen sind.

Der praktische Unterschied zwischen A und AA ist erheblich. Level A deckt das Wesentliche ab (Alternativtext, semantische Struktur, Tastaturnavigation). Level AA fügt Anforderungen hinzu, die Design und Farbe betreffen: ein Mindestkontrast von 4,5:1 für normalen Text und 3:1 für großen Text, Textskalierung bis zu 200 % ohne Inhaltsverlust, Untertitel für voraufgezeichnete Videos sowie Überschriften und Labels, die den Zweck jedes Feldes beschreiben.

Diese Kriterien werden häufig bei Websites verletzt, die mit veraltetem XHTML und CSS erstellt wurden, bei denen Farben und Größen in absoluten Pixeln festgelegt wurden.

Die normative Referenz, die zitiert werden sollte, ist die offizielle WCAG 2.2-Spezifikation des W3C, die die vollständige Liste der Kriterien sowie die ausreichenden und beratenden Techniken enthält. Im europäischen Kontext harmonisiert die Norm EN 301 549 diese Anforderungen für das öffentliche Beschaffungswesen und die Richtlinie zur Webzugänglichkeit, während in den Vereinigten Staaten Section 508 und der ADA die entsprechenden Referenzen sind. Die Kenntnis des rechtlichen Rahmens Ihres Marktes ist wichtig: In Spanien und Lateinamerika fordern viele institutionelle Kunden in den Ausschreibungen eine explizite AA-Konformität, um die AA-Webzugänglichkeit zu gewährleisten.

Die vier Arten von Tools, die Sie benötigen

Keine Tool-Kategorie deckt das gesamte WCAG-Spektrum für die AA-Webzugänglichkeit ab. Ein seriöser Workflow kombiniert vier Typen, von denen jeder unterschiedliche Fragen beantwortet.

Verwandte: accessiBe — Superposición de IA, das die WCAG seit 48 Stunden unterstützt.

Automatisierte Auditoren. Sie scannen das DOM und das CSS nach bekannten Fehlermustern: Bilder ohne alt, Felder ohne Label, unzureichender Kontrast, übersprungene Überschriften, falsch verwendete ARIA-Attribute. Sie sind schnell und erkennen repetitive Fehler, aber ihre Abdeckung ist nur teilweise: Die Hersteller selbst geben zu, dass sie keine Kriterien bewerten können, die von der Bedeutung abhängen, wie die Qualität eines Alternativtextes oder die Klarheit einer Fehlermeldung.

Kontrastprüfer. Sie berechnen das Kontrastverhältnis zwischen Textfarbe und Hintergrund gemäß der Formel für relative Luminanz der WCAG. Dies sind kleine, aber kritische Tools, da der Kontrast einer der häufigsten Fehler ist und einer der am einfachsten objektiv zu messenden.

Screenreader. NVDA (Windows, kostenlos), JAWS (Windows, kommerziell) und VoiceOver (macOS/iOS, integriert) sind die Generalprobe. Ein Auditor mag sagen, dass ein Formular „bestanden“ hat, aber nur ein Screenreader offenbart, ob die Tabulator-Reihenfolge sinnvoll ist oder ob ein aria-label mehr verwirrt als hilft.

Einen Blick wert: UserWay — Widget für den kostenlosen Zugang mit Plan, damit Sie noch heute dort arbeiten können.

Struktur- und HTML-Validatoren. Sie stellen sicher, dass das Markup gültig und semantisch ist. Bei XHTML-Websites erkennt ein Validator falsche Verschachtelungen, veraltete Attribute und Codierungsprobleme, die sich dann auf die Interpretation des Screenreaders auswirken.

Vergleich: Welches Tool für welchen Fall

Die folgende Tabelle fasst die Entscheidungskriterien zur Sicherstellung der AA-Webzugänglichkeit zusammen. Es ist keine Preisliste (da diese häufig variieren und von der Lizenz abhängen), sondern eine Zuordnung nach Szenarien.

Tool-Typ	Wann wählen	Hauptstärke	Zentrale Einschränkung
Browser-Erweiterung (Live-Audit)	Tägliche Entwicklung, Prüfung einer konkreten Seite	Sofortiges Feedback zum gerenderten DOM	Analysiert nur, was der Browser geladen hat; deckt keine vollständigen Flows ab
Suite mit CI-Integration	Teams mit Continuous Deployment	Erkennt Regressionen vor der Veröffentlichung	Erfordert Konfiguration und Wartung von Regeln
Kontrastprüfer	Design und Überprüfung von Farbsystemen	Objektive und exakte Messung	Bewertet nichts außer der Farbe
Screenreader	Finale Validierung und Nutzertests	Reproduziert die reale Erfahrung	Hohe Lernkurve; zeitaufwendig in der Ausführung
Externes Audit	Formelle Zertifizierung, öffentliche Ausschreibungen	Gegenüber Dritten vertretbarer Bericht	Kosten und Abhängigkeit von einem Anbieter

Die Faustregel: Nutzen Sie die Browser-Erweiterung während der Entwicklung, die CI-Suite, um bestehende Funktionen nicht zu beeinträchtigen, den Kontrastprüfer bei der Definition der Palette, den Screenreader vor jeder Auslieferung und das externe Audit nur, wenn Sie ein formelles Dokument benötigen.

Wie man ein Tool für Barrierefreiheit vor der Einführung bewertet

Ein Tool allein aufgrund seiner Popularität zu wählen, ist ein häufiger Fehler. Diese Kriterien unterscheiden ein nützliches Werkzeug von einem, das nur Rauschen erzeugt.

Abdeckung der Kriterien und Transparenz. Ein gutes Tool gibt an, welches WCAG-Kriterium jedem Alarm entspricht. Wenn nur ein „Barrierefreiheitsfehler“ angezeigt wird, ohne ihn einem Erfolgskriterium zuzuordnen, können Sie die Konformität nicht dokumentieren oder Prioritäten setzen.

Falsch-Positiv-Rate. Alarme, die keine echten Fehler sind, kosten Zeit und untergraben das Vertrauen des Teams. Testen Sie das Tool auf einer Website, von der Sie bereits wissen, dass sie die AA-Webstandards für Barrierefreiheit erfüllt, und beobachten Sie, wie viele Warnmeldungen es generiert.

Verwandte: IAAP CPACC / WAS Certification — Die professionelle Zertifizierung erfordert Erfahrung und Zugang.

ARIA-Unterstützung und dynamische Komponenten. Moderne Widgets (Dropdown-Menüs, Modals, Tabs, Akkordeons) hängen von ARIA-Zuständen ab. Ein Tool, das aria-expanded, aria-controls oder das Fokusmanagement in Modalen nicht auswertet, lässt die schwerwiegendsten Fehler durch.

Integration in Ihren Stack. Wenn Sie mit reinem XHTML und CSS arbeiten, prüfen Sie, ob das Tool kein spezifisches Framework voraussetzt. Wenn Sie eine Build-Pipeline verwenden, prüfen Sie, ob eine Befehlszeilenintegration vorhanden ist.

Barrierefreiheit des Tools selbst. Eine häufige Ironie: Einige Auditing-Tools sind selbst nicht per Tastatur bedienbar. Wenn Sie es täglich nutzen, stellen Sie sicher, dass es ohne Maus navigierbar ist.

Einen Blick wert: Deque axe DevTools Pro — Der Stand der Technik dient dazu, die Zugänglichkeit während der Fahrt zu testen.

Aktualisierung und Wartung. WCAG entwickelt sich weiter (2.0, 2.1, 2.2) und Browser ändern sich. Ein Tool ohne aktuelle Updates wendet möglicherweise veraltete Regeln an.

Schritt-für-Schritt AA-Workflow für Webzugänglichkeit

Ein wiederholbarer Prozess ist wertvoller als jedes einfache Tool. Dies ist die Reihenfolge, die in realen Projekten funktioniert.

Schritt 1 — Umfang und Ebene definieren. Legen Sie fest, welche Seiten und Flows in das Audit einbezogen werden, und bestätigen Sie, dass das Ziel AA ist (nicht A oder AAA). Dokumentieren Sie die WCAG-Version: 2.2 ist die aktuelle W3C-Empfehlung.

Schritt 2 — Erstes automatisiertes Audit. Lassen Sie die wichtigsten Seiten durch einen Auditor laufen, um eine Baseline zu erhalten. Notieren Sie sich wiederkehrende Fehler: Diese konzentrieren sich meist auf Templates, nicht auf einzelne Seiten.

Schritt 3 — Manuelle Überprüfung dessen, was die Maschine nicht sieht. Prüfen Sie die Tabulator-Reihenfolge, die Fokussichtbarkeit, die Qualität der Alternativtexte, die Klarheit der Fehlermeldungen und die Konsistenz der Überschriften. Hier entscheidet sich die Konformität.

Schritt 4 — Test mit einem Screenreader. Durchlaufen Sie mindestens einen vollständigen Flow (z. B. ein Kontaktformular oder einen Kauf) mit NVDA oder VoiceOver. Notieren Sie, wo Sie den Faden verlieren.

Schritt 5 — Nach Möglichkeit mit echten Nutzern testen. Menschen mit Behinderungen erkennen Barrieren, die kein Tool und kein Experte ohne diese Erfahrung wahrnimmt. Dies ist das wertvollste und am schwierigsten zu ersetzende Kriterium.

Schritt 6 — Dokumentieren und Korrigieren. Halten Sie jeden Befund mit dem entsprechenden WCAG-Kriterium, der angewandten Technik und dem Nachweis (Screenshot, Browserversion, Datum) fest. Diese Aufzeichnung macht aus „wir glauben, dass es konform ist“ ein „wir können beweisen, dass es konform ist“.

Häufige Fehler beim Streben nach Level AA der Webzugänglichkeit

Verwechslung von „null Auditor-Fehlern“ mit Konformität. Ein sauberer Bericht eines automatischen Tools bedeutet nicht automatisch AA-Konformität. Auditoren decken nur einen Bruchteil der Kriterien ab; der Rest erfordert menschliches Urteilsvermögen.

Ignorieren des Kontrasts in interaktiven Zuständen. Der Kontrast wird oft nur im Standardzustand geprüft, aber auch die Zustände :hover, :focus und :disabled müssen konform sein. Ein Button, der im Ruhezustand besteht, kann beim Fokussieren scheitern.

Verwendung von ARIA zur Behebung von schlecht strukturiertem HTML. Die erste Regel von ARIA lautet: Verwenden Sie kein ARIA, wenn natives HTML das Problem bereits löst. Ein <div> mit role="button" wird niemals so robust sein wie ein echter <button>, der Fokus und Tastatur bereits nativ verwaltet.

Vergessen der Textskalierung. Kriterium 1.4.4 verlangt, dass Text bis zu 200 % vergrößert werden kann, ohne dass Inhalte oder Funktionen verloren gehen. Designs mit festen Höhen in Pixeln brechen hier oft zusammen.

Kein Testen auf Mobilgeräten. Das Reflow-Kriterium (1.4.10) verlangt, dass Inhalte auf schmalen Bildschirmen ohne horizontales Scrollen funktionieren. Viele konforme Desktop-Seiten scheitern an diesem Punkt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Barrierefreiheit A, AA und AAA?

Die WCAG-Konformitätsstufen sind kumulativ. Stufe A deckt 30 grundlegende Kriterien ab; AA fügt 20 weitere hinzu (insgesamt 50) und ist der Standard, der von der Mehrheit der Gesetze gefordert wird; AAA fügt weitere 28 hinzu und ist in allgemeiner Form nicht gefordert, da einige Kriterien für alle Inhalte nicht umsetzbar sind. Für die meisten Webprojekte ist AA ein realistisches und ausreichendes Ziel für die AA-Webzugänglichkeit.

Wie viele Kriterien von WCAG 2.2 müssen für Level AA erfüllt werden?

WCAG 2.2 Level AA erfordert die Erfüllung von 50 Erfolgskriterien: die 30 aus Level A plus die 20 aus Level AA. Die Zahl bleibt gleich wie bei WCAG 2.1, aber 2.2 hat neue Kriterien wie die Zielgröße (2.5.8) und konsistente Hilfe (3.2.6) hinzugefügt, einige auf Stufe A und einige auf Stufe AA.

Reicht ein automatisches Tool aus, um AA zu erfüllen?

Nein. Automatisierte Tools erkennen objektive und repetitive Fehler, können aber keine Kriterien bewerten, die von der Bedeutung oder dem Kontext abhängen, wie die Qualität von Alternativtexten oder die Nützlichkeit einer Fehlermeldung. Die AA-Konformität erfordert die Kombination aus automatisiertem Audit, manueller Überprüfung und Tests mit Screenreadern und, wenn möglich, mit echten Nutzern.

Welchen Screenreader sollte man zum Testen einer Website verwenden?

NVDA ist kostenlos und unter Windows weit verbreitet, was es zur zugänglichsten Startoption macht. JAWS ist kommerziell und in Unternehmensumgebungen üblich. VoiceOver ist in macOS und iOS integriert und daher der natürliche Weg, wenn Sie im Apple-Ökosystem arbeiten. Das Testen mit mindestens zwei Kombinationen aus Browser und Screenreader liefert ein zuverlässigeres Bild.

Ist AA-Barrierefreiheit gesetzlich vorgeschrieben?

Das hängt vom Land und der Art der Organisation ab. In der Europäischen Union stellen die Richtlinie zur Webzugänglichkeit und die Norm EN 301 549 Anforderungen an den öffentlichen Sektor und viele private Dienste. In den Vereinigten Staaten führen Section 508 und der ADA zu ähnlichen Verpflichtungen. In Lateinamerika haben mehrere Länder eigene, von der WCAG inspirierte Vorschriften. Es ist ratsam, die für Ihren Markt geltende Gesetzgebung zu prüfen.

Wie oft muss eine Website neu auditiert werden, um das Level AA zu halten?

Es gibt keinen universellen Zeitrahmen, aber jede Änderung am Design, an der Vorlage oder an einer Komponente kann zu Regressionen führen. Ein praktischer Ansatz besteht darin, bei jeder Bereitstellung automatisch über Continuous Integration zu prüfen und mindestens einmal im Jahr oder nach erheblichen Neugestaltungen eine vollständige manuelle Überprüfung durchzuführen. Die Dokumentation jedes Audits erleichtert den Nachweis der dauerhaften Konformität im Laufe der Zeit.

Schlussfolgerung

Die AA-Konformität der Web-Barrierefreiheit wird nicht gekauft oder installiert: Sie wird durch die Kombination von Werkzeugen und Urteilsvermögen geschaffen. Automatisierte Prüftools beschleunigen die Arbeit, Kontrastprüfer lösen objektive Fehler, Screenreader offenbaren die tatsächliche Erfahrung und die manuelle Überprüfung deckt ab, was keine Maschine beurteilen kann.

Wählen Sie Ihre Tools entsprechend Ihrem Workflow, nicht nach ihrer Beliebtheit, und dokumentieren Sie jede Entscheidung. Um tiefer in die Kriterien und Techniken einzutauchen, bleiben die maßgeblichen Referenzen die WCAG-Dokumentation des W3C und die Richtlinien der WAI-Initiative.

Quellen & Weiterführende Literatur

• Web Content Accessibility Guidelines — Wikipedia: Die Web Content Accessibility Guidelines (WCAG) sind Teil einer Reihe, die von der Web Accessibility Initiative (WAI) des World Wide Web Consortium (W3C) veröffentlicht wurde,…
• Web accessibility — Wikipedia: Web-Barrierefreiheit, oder eAccessibility, ist die inklusive Praxis, sicherzustellen, dass es keine Barrieren gibt, die die Interaktion mit oder den Zugriff auf Websites im World Wide Web verhindern…