WCAG 2.1 AA verlangt, alle Erfolgskriterien der Stufen A und AA zu erfüllen, insgesamt 50 Prüfpunkte, gegliedert unter vier Prinzipien: wahrnehmbar, bedienbar, verständlich und robust. Diese Checkliste geht die praktischen Bereiche durch, die für eine typische Unternehmenswebsite am wichtigsten sind, gegliedert nach diesen vier Prinzipien, damit Sie Ihre eigene Website systematisch prüfen können, statt zu raten, was “AA-konform” tatsächlich abdeckt.

Zwei Dinge sollten Sie vor dieser Liste wissen. Erstens ist das ein praktischer Überblick über die wichtigsten Bereiche für eine typische Unternehmenswebsite, keine wortgetreue Wiedergabe aller 50 Erfolgskriterien; die offizielle W3C-Dokumentation ist die maßgebliche Quelle, wenn Sie den genauen rechtlichen Wortlaut brauchen. Zweitens ist “AA” eine Stufe, kein eigener Standard: Stufe AA umfasst alles, was auf Stufe A verlangt wird, plus die zusätzlichen AA-Kriterien, eine Website, die AA-Konformität behauptet, muss also beide Stufen zusammen erfüllen, nicht AA-Kriterien isoliert.

Wahrnehmbar: Können Nutzer den Inhalt überhaupt wahrnehmen

Farbkontrast. Text braucht ein Kontrastverhältnis von mindestens 4,5:1 gegenüber seinem Hintergrund (3:1 für großen Text). Das lohnt sich, zuerst zu prüfen: Der WebAIM-Million-Bericht 2026 fand heraus, dass 83,9 % der Startseiten kontrastarmen Text hatten, was ihn zum häufigsten Fehler im gesamten Datensatz macht. Hellgrauer Text auf weißem Hintergrund, eine in vielen modernen Website-Vorlagen weiterhin verbreitete Design-Entscheidung, ist ein häufiger Übeltäter, den es sich lohnt, gezielt zu prüfen.

Alt-Text für Bilder. Jedes bedeutsame Bild braucht eine Textalternative, die seinen Zweck oder Inhalt beschreibt; rein dekorative Bilder sollten leere Alt-Attribute haben, damit Screenreader sie überspringen, statt etwas Bedeutungsloses anzusagen. Produktfotos, informative Grafiken und Icons, die eine Bedeutung vermitteln (wie ein Häkchen, das Erfolg anzeigt), sind die Kategorien, die am häufigsten übersehen werden.

Untertitel und Transkripte. Vorab aufgezeichnetes Video braucht Untertitel, und reine Audioinhalte brauchen ein Transkript. Das gilt für jeden eingebetteten Videoinhalt, nicht nur für selbst produzierte Inhalte.

Skalierbarer Text. Text muss bis 200 % vergrößerbar sein, ohne dass Inhalt oder Funktionalität verloren gehen, und Inhalte sollten sich nicht auf ein festes Pixel-Layout verlassen, das beim Zoomen zerbricht.

Nicht allein auf Farbe verlassen. Jede über Farbe vermittelte Information (etwa ein roter Rahmen, der einen Formularfehler anzeigt) braucht auch einen zweiten Indikator, wie ein Icon oder ein Textlabel, für Nutzer, die den Farbunterschied nicht wahrnehmen können.

Bedienbar: Können Nutzer alles navigieren und bedienen

Volle Tastaturzugänglichkeit. Jedes interaktive Element, Links, Buttons, Formularfelder, individuelle Widgets wie Dropdowns oder Modals, muss allein mit der Tastatur bedienbar sein, ohne Tastaturfallen, die einen Nutzer daran hindern, wieder herauszutabben.

Sichtbarer Fokusindikator. Wenn ein Nutzer zu einem Element tabbt, muss ein sichtbarer Indikator zeigen, wo sich der Fokus gerade befindet. Das ist ein Bereich, den WCAG 2.2 später weiter ausgebaut hat, aber es ist bereits eine AA-Anforderung unter 2.1.

Keine unerwarteten Inhaltsverschiebungen. Elemente sollten nicht automatisch eine größere Kontextänderung auslösen (etwa das Laden einer neuen Seite), nur weil sie den Fokus erhalten, und Inhalte sollten sich während der Interaktion nicht unvorhersehbar bewegen.

Beschreibender Linktext und Überschriften. Linktext sollte auch aus dem Kontext gelöst Sinn ergeben (vermeiden Sie generische “hier klicken”-Links), und Seiten brauchen eine logische Überschriftenstruktur, damit Screenreader-Nutzer nach Überschriftenebene navigieren können.

Mehrere Wege, Inhalte zu finden. Eine Website braucht generell mehr als einen Weg, eine bestimmte Seite zu finden, etwa eine Suchfunktion plus ein Navigationsmenü plus eine Sitemap, statt zu verlangen, dass Nutzer einen genauen Pfad kennen.

Verständlich: Sind Inhalt und Verhalten vorhersehbar

Klare Sprache und Anweisungen. Formularfelder brauchen klare Labels, und Anweisungen sollten verständlich sein, besonders bei Pflichtfeldern und erwarteten Eingabeformaten.

Konsistente Navigation. Navigationsmenüs und wiederkehrende Komponenten sollten seitenübergreifend in derselben relativen Reihenfolge erscheinen, damit Nutzer ein zutreffendes mentales Modell der Website aufbauen.

Fehlerkennzeichnung und Vorschläge. Wenn ein Formularversand fehlschlägt, muss der konkrete Fehler in Text (nicht allein über Farbe) benannt werden, und wo möglich sollte ein Vorschlag zur Behebung gegeben werden.

Vorhersehbares Verhalten bei Eingaben. Das Ändern eines Formularfeldwerts oder einer Einstellung sollte nicht automatisch eine unerwartete Kontextänderung auslösen, etwa das Absenden des Formulars oder das Verlassen der Seite, ohne dass der Nutzer eine ausdrückliche Aktion vornimmt.

Robust: Funktioniert der Inhalt mit assistiven Technologien

Gültiges, gut strukturiertes Markup. Auch wenn das alte Kriterium 4.1.1 Parsing in WCAG 2.2 entfernt wurde, ist sauberes, standardkonformes HTML in der Praxis weiterhin wichtig für zuverlässige Unterstützung durch assistive Technologien.

Korrekter Name, Rolle und Wert für individuelle Komponenten. Jede individuelle interaktive Komponente (ein individuelles Dropdown, Tab-Panel oder Modal, von Grund auf statt mit nativen HTML-Elementen gebaut) braucht die korrekten ARIA-Rollen, -Zustände und -Eigenschaften, damit assistive Technologien sie korrekt identifizieren und bedienen können.

Statusmeldungen. Dynamische Statusaktualisierungen, wie eine Bestätigung “Artikel in den Warenkorb gelegt” oder ein Formularvalidierungsergebnis, müssen Screenreader-Nutzern angesagt werden, ohne dass sie den Fokus manuell verschieben müssen.

Eine einfache Reihenfolge zum Durcharbeiten

Der Versuch, alle 50 Kriterien auf einmal zu beheben, bringt ein Projekt tendenziell zum Stillstand, bevor es beginnt, deshalb hilft eine grobe Priorisierung. Beginnen Sie mit Problemen, die sowohl hohe Wirkung haben als auch leicht zu prüfen sind: Farbkontrast und fehlender Alt-Text, da beide verbreitet (Kontrastfehler allein tauchten auf 83,9 % der Startseiten in der WebAIM-Million-Studie 2026 auf) und mit einem Scanner unkompliziert zu prüfen sind. Widmen Sie sich als Nächstes der Tastaturzugänglichkeit Ihrer zentralen Conversion-Abläufe, da ein Nutzer, der Checkout oder Kontoerstellung nicht allein mit der Tastatur abschließen kann, vollständig blockiert ist, nicht nur behindert. Arbeiten Sie sich dann durch Formularbeschriftung und Fehlermeldungen, wo viele individuell gebaute Komponenten selbst auf ansonsten einigermaßen barrierefreien Websites still zurückbleiben. Heben Sie sich die Kriterien, die mehr Urteilsvermögen verlangen, wie ob eine Überschriftenstruktur wirklich logisch ist oder ob eine Statusmeldung einem Screenreader korrekt angesagt wird, für einen dedizierten manuellen Testdurchgang auf, sobald die eher mechanischen Probleme erledigt sind.

Wie Sie diese Checkliste tatsächlich durcharbeiten

Automatisierte Scan-Tools, einschließlich solcher, die auf Deques weit verbreiteter axe-core-Engine basieren, sind ein wirklich nützlicher erster Durchgang und erfassen einen echten Teil dieser Probleme schnell, besonders Kontrast- und fehlende-Alt-Text-Probleme. Aber automatisierte Tools können nicht alles auf dieser Liste bewerten: ob eine Überschriftenstruktur logisch ist, ob ein ARIA-Label tatsächlich zutreffend ist, oder ob ein Screenreader-Nutzer Ihren Checkout-Prozess in sinnvoller Reihenfolge abschließen kann, all das erfordert einen menschlichen Tester, idealerweise mit echter assistiver Technologie auf Ihren wichtigsten Nutzerabläufen. Manche Anbieter, wie Wawsome, kombinieren automatisierte, widget-basierte Prüfungen gezielt mit einem manuell geprüften Checker, um genau diese Lücke abzudecken, während andere wie UserWay einen automatisierten Scan mit optionalem professionellem manuellem Audit als Zusatz für einen tieferen Durchgang anbieten.

Wenn Sie unsicher sind, ob Sie diese Checkliste in einen internen Prozess einbauen oder externe Hilfe holen sollten, geht unser Leitfaden zur Wahl zwischen Widget und manuellem Audit genauer darauf ein, wie Sie diese Entscheidung anhand der Ressourcen Ihres Teams treffen.