WCAG 2.1 AA erklärt: was der Standard verlangt und wie ich dafür baue und teste

Der Punkt: WCAG ist der Standard, und AA ist die Linie, die die Gesetze ziehen

WCAG steht für die Web Content Accessibility Guidelines, die Richtlinien für barrierefreie Webinhalte. Das ist der technische Standard, der festlegt, was eine Website, eine Web App oder ein Dokument für Menschen mit Behinderungen nutzbar macht, und es ist der Standard, auf den fast jedes Barrierefreiheitsgesetz in Europa zeigt.¹ Wenn du gelesen hast, dass dein Shop oder dein SaaS barrierefrei sein muss, sagt dir das Gesetz, dass du das tun musst und bis wann. WCAG sagt dir, was barrierefrei überhaupt heißt, Zeile für Zeile, und gibt dir etwas, gegen das du testen kannst.

Ich halte diesen Artikel auf dem Standard und der Praxis: was WCAG verlangt, wie du es erfüllst und wie du es nachweist. Die Frage, wer betroffen ist und ab wann, gehört zum Gesetz, und die behandle ich getrennt in meinem Artikel über das Barrierefreiheitsrecht für Onlineunternehmen. Beides gehört zusammen. Das Gesetz setzt die Pflicht, WCAG 2.1 auf Stufe AA setzt die Messlatte, und hier geht es darum, sie zu überspringen.

Ein Ehrlichkeitspunkt gleich vorweg, weil er alles Folgende durchzieht. WCAG ist ein Standard, den ein Normungsgremium veröffentlicht, kein Zertifikat, das irgendwer ausstellt. Es gibt kein Abzeichen zu kaufen und keinen Stempel, der dich konform macht. Du baust nach dem Standard, du testest dagegen, und wenn du eine unabhängige Bestätigung willst, bewertet ein Barrierefreiheitsaudit das Ergebnis. Die ehrliche Aussage lautet also gebaut und getestet nach WCAG 2.1 AA, nie garantiert konform. Warum diese Formulierung zählt, kommt noch.

Wer WCAG veröffentlicht und warum es Versionen gibt

WCAG wird vom World Wide Web Consortium herausgegeben, dem W3C, über seine Web Accessibility Initiative und die Accessibility Guidelines Working Group.¹ Dasselbe Gremium, das HTML und CSS normt, normt auch, wie sich barrierefreie Inhalte verhalten sollen, was ein Grund ist, warum WCAG für Aufsichtsbehörden zur gemeinsamen Referenz geworden ist.

Es gibt drei Versionen im Einsatz, und die Nummern sind wichtig.

WCAG 2.0 wurde am 11. Dezember 2008 veröffentlicht.¹ Es legte die Struktur fest, die alles seither behalten hat: vier Prinzipien, prüfbare Erfolgskriterien und drei Konformitätsstufen.

WCAG 2.1 erschien am 5. Juni 2018, die aktuelle Fassung trägt das Datum 6. Mai 2025.¹ Es behielt alles aus WCAG 2.0 und ergänzte 17 Erfolgskriterien, vor allem für mobile Geräte, Sehschwäche und kognitive Bedürfnisse, die die Fassung von 2008 schlecht abgedeckt hatte.² Auf diese Version zeigen die meisten europäischen Gesetze heute.

WCAG 2.2 wurde am 5. Oktober 2023 veröffentlicht.¹ Es ergänzt neun weitere Erfolgskriterien, darunter die Zielgröße für die Bedienung mit dem Finger, konsistente Hilfe und ein Kriterium zur Anmeldung, das Menschen kognitive Tests erspart, etwa das Merken und Abtippen eines Codes.³ Außerdem wurde ein älteres Kriterium entfernt, 4.1.1 Parsing, das moderne Browser überflüssig gemacht haben.³ WCAG 2.2 ist abwärtskompatibel: Inhalte, die 2.2 erfüllen, erfüllen auch 2.1, also ist das Bauen nach 2.2 ein sicherer Weg, voraus zu sein.

Mein praktischer Rat ist einfach. Bau nach WCAG 2.1 AA, weil darauf das Gesetz zeigt, und nimm die neun Ergänzungen aus WCAG 2.2 mit, wo du kannst, weil sie echte Verbesserungen sind und weil die gesetzlichen Verweise mit der Zeit auf 2.2 wandern werden. Nichts in 2.2 macht 2.1 rückgängig.

Die vier Prinzipien, oder POUR

WCAG ordnet alles unter vier Prinzipien. Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein, weshalb man die vier im Englischen zu POUR kürzt (perceivable, operable, understandable, robust).⁴ Jedes Erfolgskriterium sitzt unter einem davon, die Prinzipien sind also die Landkarte.

Wahrnehmbar heißt, dass eine Person die Information über den Sinn aufnehmen kann, der bei ihr funktioniert. Ist ein Inhalt nur auf eine Art verfügbar, bleibt ausgesperrt, wer diese Art nicht nutzen kann. In der Praxis sind das Textalternativen für Bilder, damit ein Screenreader eine alt Beschreibung vorliest statt einer leeren Grafik (Erfolgskriterium 1.1.1).⁴ Es sind Untertitel für Videos und eine Audiodeskription für den visuellen Inhalt (1.2.2 und 1.2.5).⁴ Es ist genügend Kontrast, auf den ich unter den Stufen zurückkomme. Und es heißt, Bedeutung nicht allein über Farbe zu transportieren, damit ein Formularfeld, das nur rot wird, einem farbenblinden Menschen trotzdem sagt, was falsch ist (1.4.1).⁴

Bedienbar heißt, dass eine Person die Oberfläche tatsächlich steuern kann. Der wichtigste Test ist die Tastatur: alles, was mit der Maus geht, muss auch allein mit der Tastatur gehen, weil sich viele Hilfsmittel der Seite gegenüber wie eine Tastatur verhalten (2.1.1).⁴ Eng damit verbunden ist, dass es keine Tastaturfalle geben darf, der Fokus darf also nie irgendwo hängen bleiben, von wo eine Tastaturnutzerin nicht mehr wegkommt (2.1.2).⁴ Bedienbar bedeutet auch eine sichtbare Fokusanzeige, damit man sieht, wo man gerade ist (2.4.7), und eine sinnvolle Fokusreihenfolge, die der Bedeutung der Seite folgt (2.4.3).⁴

Verständlich heißt, dass Menschen den Inhalt und die Oberfläche begreifen. Setz die Sprache der Seite, damit ein Screenreader die richtige Aussprache nutzt (3.1.1).⁴ Beschrifte Formularfelder klar und gib Hinweise, wo sie nötig sind (3.3.2).⁴ Wenn etwas schiefgeht, benenne den Fehler im Text und schlag, wo möglich, eine Lösung vor (3.3.1 und 3.3.3).⁴ Eine Kartennummer, die mit einem bloßen roten Rand abgewiesen wird, fällt hier durch; der Satz Kartennummer muss 16 Ziffern haben besteht.

Robust heißt, dass der Inhalt über Browser und Hilfsmittel hinweg funktioniert, jetzt und während sie sich ändern. Das Kernkriterium ist Name, Rolle und Wert: jede Komponente der Oberfläche muss Hilfsmitteln mitteilen, was sie ist, was sie tut und in welchem Zustand sie ist (4.1.2).⁴ Ein <button> Element bekommt das gratis. Ein <div>, das du wie einen Knopf aussehen lässt, bekommt es nicht, außer du ergänzt die richtige Rolle und die Tastaturbedienung, weshalb native HTML Elemente so viel Mühe sparen.

Konformitätsstufen: A, AA und warum AA das Ziel ist

WCAG teilt seine Erfolgskriterien in drei Stufen ein: A, AA und AAA.⁴ Das sind keine drei getrennten Listen. AA enthält alles aus A, und AAA enthält alles aus A und AA. Konform auf Stufe AA heißt also, jedes Kriterium der Stufe A und jedes der Stufe AA zu erfüllen.⁴

Stufe A ist der Boden. Sie fängt die Fehler ab, die Menschen völlig aussperren: keine Tastaturbedienung, Bilder ohne Textalternative, Video ganz ohne Untertitel. Eine Seite, die nur Stufe A erfüllt, ist nicht nutzbar genug, und kein ernsthaftes Gesetz bleibt bei A stehen.

Stufe AA ist das Arbeitsziel. Sie ergänzt die Kriterien, die eine Seite wirklich nutzbar machen statt nur bedienbar: ausreichender Farbkontrast, Text, der sich vergrößern lässt, Inhalt, der auf kleinem Bildschirm umbricht, Beschriftungen und Fehlerbehandlung, die halten. Das ist die Stufe, auf die der European Accessibility Act und die Regeln für den öffentlichen Sektor in Europa zeigen, und die Stufe, nach der ich standardmäßig baue.¹

Stufe AAA ist die anspruchsvollste, mit Kriterien wie einem Kontrastverhältnis von 7:1 und Gebärdensprache für Videos. Das W3C selbst empfiehlt AAA nicht als Anforderung für ganze Seiten, weil manche AAA Kriterien nicht für alle Inhalte erfüllbar sind.⁴ Einzelne AAA Kriterien kannst du erfüllen, wo sie leicht und wertvoll sind, aber du versprichst kein AAA über ein ganzes Produkt.

Der Grund, warum AA das Ziel ist, liegt darin, dass dort eine Seite für die große Mehrheit der Menschen mit Hilfsmitteln funktioniert und dass AA über eine ganze Seite erreichbar ist, was AAA nicht ist. Wenn das Gesetz barrierefrei sagt, meint es AA.

Eine Bemerkung zur Menge, weil sie beruhigt. WCAG 2.1 hat insgesamt 78 Erfolgskriterien, die 61 aus WCAG 2.0 plus die 17 aus 2.1.² AA zu erfüllen heißt nicht, alle 78 zu erfüllen. Es heißt, die der Stufen A und AA zu erfüllen, und viele davon sind eine einzige, gut getroffene Entscheidung, die dann die ganze Seite abdeckt, etwa saubere Überschriften, beschriftete Formulare und eine einmal gewählte barrierefreie Farbpalette.

Wie du wirklich testest: Werkzeuge finden nur einen Teil

Hier kommt die wichtigste praktische Wahrheit dieses Artikels, und die am häufigsten falsch verstandene. Ein automatischer Barrierefreiheitsscanner kann dir nicht sagen, ob du WCAG erfüllst. Er findet nur einen Ausschnitt der Probleme.

Das W3C ist dazu deutlich. Seine Anleitung zur Auswahl von Prüfwerkzeugen hält fest, dass Werkzeuge nicht alle Aspekte der Barrierefreiheit automatisch prüfen können und dass sie Barrierefreiheit nicht feststellen, sondern nur beim Feststellen helfen können.⁵ Seine Übersicht zur Bewertung sagt klar, dass kein Werkzeug allein bestimmen kann, ob eine Seite die Standards erfüllt, und dass eine sachkundige menschliche Bewertung nötig ist, um zu entscheiden, ob eine Seite barrierefrei ist.⁶

Dahinter steht eine Zahl. Als der britische Government Digital Service eine absichtlich kaputte Testseite mit 143 bekannten Barrieren baute und zehn automatische Werkzeuge dagegen laufen ließ, fand das beste Werkzeug rund 41 % der Barrieren, und 42 der 143, also etwa 29 %, wurden von jedem einzelnen getesteten Werkzeug übersehen.⁷ Automatisches Testen findet im besten Fall also etwa ein Drittel bis vielleicht die Hälfte der Probleme, und ein solides Drittel ist für die Werkzeuge unsichtbar.

Das ist kein Grund, Werkzeuge wegzulassen. Sie sind schnell, sie laufen bei jedem Build, und sie fangen die mechanischen Fehler zuverlässig: fehlende alt Attribute, leere Beschriftungen, zu niedrige Kontrastwerte, fehlende Seitensprache. Angesehene Werkzeuge sind etwa axe, das in Browsererweiterungen und Testsuiten läuft, Google Lighthouse, das in Chrome steckt, und WAVE von WebAIM. Lass eines davon früh und oft laufen und behebe, was es meldet. Nur melde nie der Scanner ist durch, als hieße das die Seite ist barrierefrei. Das tut es nicht.

Der manuelle Durchgang und der Test mit echten Menschen

Die zwei Drittel, die der Scanner übersieht, sind die Teile, die ein menschliches Urteil brauchen, und oft die wichtigsten. Ein manueller Durchgang gegen WCAG 2.1 AA deckt mindestens Folgendes ab:

Nur Tastatur. Steck die Maus aus. Tabbe durch jede Seite und jeden Ablauf: Navigation, Menüs, Formulare, die Kassa, jedes Fenster oder Pop up. Erreichst du alles, bedienst du alles, siehst du die ganze Zeit, wo du bist? Kommst du immer wieder heraus? Dieser eine Test holt die meisten Bedienfehler ans Licht, und kein Scanner macht ihn gut.⁷
Screenreader. Geh die wichtigsten Wege mit einem Screenreader durch, etwa NVDA oder JAWS unter Windows oder VoiceOver auf macOS und iOS. Hör hin, ob Links, Knöpfe, Bilder und Fehler sinnvoll angesagt werden und ob die Vorlesereihenfolge stimmt.
Zoom und Umbruch. Zoome den Browser auf 200 % und prüfe, dass nichts verloren geht (1.4.4), verschmälere dann das Fenster auf etwa 320 CSS Pixel und prüfe, dass der Inhalt in eine Spalte umbricht, ohne dass seitlich eine zweite Bildlaufleiste auftaucht (1.4.10).⁴
Kontrast. Miss die echten Farben von Text und von Oberflächenelementen mit einem Kontrastprüfer, statt dem Auge zu trauen.

Noch besser, und hier wird aus Konformität Vertrauen, teste mit Menschen, die Hilfsmittel täglich nutzen. Das W3C empfiehlt, Menschen mit Behinderungen über das ganze Projekt einzubeziehen, nicht erst am Ende, weil sie Probleme finden, die jede technische Prüfung bestehen und eine Aufgabe trotzdem schwer machen.⁶ Du brauchst kein Labor. Zwei Sitzungen mit erfahrenen Screenreader Nutzerinnen bringen dir mehr bei als jeder Bericht.

Die ehrliche Zusammenfassung des Testens lautet: automatisch fürs Mechanische, manuell fürs Menschliche, echte Menschen für die Wahrheit. Jedes der drei allein lässt Lücken.

Die Fehler, die ich am häufigsten sehe, und wie man sie behebt

Das meiste, was ein Audit durchfallen lässt, ist eine kurze Liste, immer wieder. Hier ist die Liste mit der Lösung zu jedem Punkt und dem Erfolgskriterium, unter dem er sitzt.

Zu niedriger Farbkontrast ist der häufigste einzelne Fehler, meist blasser grauer Text auf Weiß oder heller Text auf einer Markenfarbe. WCAG 2.1 AA verlangt ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text und mindestens 3:1 für großen Text, wobei groß ab 18 Punkt oder 14 Punkt fett bedeutet (1.4.3).⁴ Oberflächenelemente und bedeutungstragende Grafiken brauchen mindestens 3:1 gegen das, was daneben liegt (1.4.11).⁴ Die Lösung ist, zu messen und abzudunkeln und die barrierefreie Palette einmal festzulegen, damit das Problem beim nächsten Markenrefresh nicht zurückkommt.

Bilder ohne Textalternative kommen als Nächstes. Ein dekoratives Bild soll ein leeres alt haben, damit ein Screenreader es überspringt; ein informatives braucht ein alt, das seine Bedeutung trägt; ein Bild, das zugleich ein Link ist, muss sagen, wohin der Link führt (1.1.1).⁴ Die Lösung ist eine Regel im Redaktionsprozess: kein Bild geht ohne eine Entscheidung über seinen alt Text.

Formularfelder ohne echte Beschriftung sind überall, meist weil ein Platzhalter die Aufgabe der Beschriftung übernimmt und dann verschwindet, sobald getippt wird. Jedes Feld braucht eine programmatisch verknüpfte Beschriftung, damit Hilfsmittel sie ansagen (3.3.2), und Fehler müssen im Text benannt und mit einem Lösungsvorschlag versehen werden (3.3.1 und 3.3.3).⁴ Die Lösung ist ein ordentliches <label> je Feld und Fehlermeldungen, die sagen, was zu tun ist.

Tastaturfallen und eigene Bedienelemente, die die Tastatur nicht erreicht, sind das klassische Ergebnis, wenn man native Elemente von Hand nachbaut. Ein Menü, ein Datumswähler oder ein Fenster aus bloßen <div> Elementen lässt sich oft ohne Maus nicht öffnen, bedienen oder schließen (2.1.1 und 2.1.2).⁴ Die Lösung ist fast immer das native HTML Element, und wo ein eigenes Element unvermeidlich ist, gib ihm die Tastaturbedienung und den Namen, die Rolle und den Wert, die das native gehabt hätte (4.1.2).⁴

Eine fehlende oder unsichtbare Fokusanzeige lässt Tastaturnutzer auf der Seite verloren zurück. Browser zeigen von Haus aus einen Fokusrahmen, und die übliche Ursache des Fehlers ist CSS, das ihn aus optischen Gründen entfernt. Die Lösung ist, einen klaren, sichtbaren Fokusstil zu behalten, statt ihn zu verstecken (2.4.7).⁴

Nichts davon ist exotisch. Es sind gewöhnliche Entwicklungsentscheidungen, und der Grund, warum sie wiederkehren, ist, dass sie beim ersten Mal nie bewusst getroffen wurden.

Durchgerechnetes Beispiel: ein Linzer Shop, gebracht auf WCAG 2.1 AA

Donau Kochwaren ist ein erfundenes Unternehmen, eine Linzer Firma, die Kochgeschirr online verkauft, auf donaukochwaren.example, mit einem Katalog, einer Kassa und einem kleinen Kundenbereich. Die Inhaberin hat gelesen, dass das Gesetz nun Onlineshops nennt, und will die Seite gebaut und getestet nach WCAG 2.1 AA. So lief die Arbeit. Die Zahlen unten veranschaulichen dieses Beispiel, sie sind keine Behauptung über einen echten Auftrag.

Ich begann mit einem automatischen Scan auf jeder Vorlage, mit axe in der Testsuite und einem WAVE Durchgang von Hand. Er meldete 34 Kontrastfehler, 12 Bilder ohne alt und drei Formularfelder, deren einzige Beschriftung ein Platzhalter war. Die kamen zuerst auf die Liste, weil es echte Fehler sind und die am schnellsten behobenen.

Dann der Tastaturdurchgang, Maus ausgesteckt. Die Hauptnavigation ging, aber das Schnellansicht Pop up zum Produkt hielt den Fokus fest: einmal mit der Tastatur geöffnet, ließ es sich ohne Maus nicht schließen, ein Durchfall bei 2.1.2.⁴ Der Mengenzähler im Warenkorb, aus gestylten <div> Elementen gebaut, ließ sich mit der Tastatur gar nicht bedienen, ein Durchfall bei 2.1.1 und 4.1.2.⁴ Keines tauchte im Scan auf.

Der Screenreader Durchgang fand, dass die Fehlerübersicht der Kassa die ungültigen Felder rot färbte, aber nichts ansagte, sodass ein blinder Mensch beim Ausfüllen die Seite neu laden hörte und keine Ahnung hatte, was durchgefallen war, ein Durchfall bei 3.3.1.⁴ Beim Zoom auf 200 % und beim Verschmälern auf 320 Pixel hielt das Produktraster drei Spalten und erzwang eine seitliche Bildlaufleiste, statt umzubrechen, ein Durchfall bei 1.4.10.⁴

Die Lösungen waren gewöhnlich. Ich dunkelte die Palette ab, bis Text 4,5:1 und Knöpfe 3:1 klar erreichten, und legte diese als Tokens fest, womit alle 34 Kontrastfehler auf einen Schlag weg waren.⁴ Ich ersetzte Schnellansicht und Mengenzähler durch native Elemente, die ihre Tastaturbedienung und Rollen selbst mitbringen. Ich ergänzte echte <label> Elemente und eine Fehlerübersicht, die jedes Problem im Text benennt und den Fokus dorthin setzt. Ich ließ das Raster unter dem Umbruchpunkt auf eine Spalte umbrechen. Zuletzt führte ich zwei Sitzungen mit regelmäßigen Screenreader Nutzerinnen durch, die fanden, dass die Bestätigung in den Warenkorb gelegt keine gesprochene Rückmeldung gab, also ergänzte ich einen höflichen Live Bereich, der sie ansagt.

Das Ergebnis ist eine Seite, gebaut und getestet nach WCAG 2.1 AA, mit dem Prüfprotokoll als Beleg: die Scanergebnisse, die manuelle Checkliste, die Notizen aus den Nutzersitzungen und die Liste der behobenen Probleme mit dem jeweils erfüllten Kriterium. Will die Inhaberin später eine unabhängige Bestätigung, kann ein Barrierefreiheitsaudit die Konformität gegen dieses Protokoll prüfen. Das ist die ehrliche Form einer Konformitätsaussage, und darum sage ich nie garantiert konform.

Was es jenseits des Gesetzes wert ist

Barrierefreiheit wird leicht als Abgabe behandelt, etwas, das man macht, weil eine Behörde es sagt. Diese Lesart übersieht den meisten Wert.

Der offensichtliche Gewinn ist Reichweite. Eine nach AA gebaute Seite funktioniert für Menschen mit dauerhaften Behinderungen und ebenso für die viel größere Gruppe mit einer vorübergehenden oder situativen Einschränkung: ein gebrochener Arm, grelle Sonne auf dem Handy, ein lauter Zug, in dem Untertitel zählen, ein alterndes Auge, das größeren Text braucht. Jede davon ist Kundschaft, die du behältst, statt sie an der ersten Hürde zu verlieren.

Der zweite Gewinn ist, dass dieselbe Arbeit die Seite für alle verbessert. Eine saubere Überschriftenstruktur, beschreibende Links, schnelle Tastaturwege und klare Fehlermeldungen sind schlicht gute Bedienbarkeit, und sie helfen der Conversion, nicht nur der Konformität. Auch die Überschneidung mit der Suche ist echt, denn die Struktur, auf die ein Screenreader angewiesen ist, Überschriften, Beschriftungen, Textalternativen und sauberes Markup, ist weitgehend dieselbe, die eine Suchmaschine liest.

Der dritte Gewinn ist Risiko. Die Pflicht ist rechtlich, und das Wer und das Ab wann behandle ich im Artikel zum Barrierefreiheitsrecht. Von Anfang an nach dem Standard zu bauen ist weit weniger teuer als eine Nachrüstung unter einer Beschwerde, und es ist genau die Art Entwicklungsdisziplin, die neben den anderen Qualitätslatten in meiner Übersicht über die Qualitätsstufen für geschäftskritische Software steht.

Wie ich dafür baue und teste

Ich baue SaaS Plattformen auf Ruby on Rails und Shops auf Solidus, und ich baue sie vom ersten Commit an nach WCAG 2.1 AA, statt es am Ende anzuschrauben. In der Praxis heißt das native HTML Elemente, wo immer es geht, eine semantische Struktur mit echten Überschriften und Landmarken, eine Beschriftung an jedem Formularfeld, eine einmal gewählte Farbpalette, die die AA Kontrastwerte erreicht, ein sichtbarer Fokusstil, der behalten statt entfernt wird, und Fehler, die im Text benannt und erreichbar sind.

Das Testen folgt der Mischung von oben, nicht einem einzelnen Werkzeug. Automatische Prüfungen laufen in der Testsuite bei jedem Build, sodass ein Kontrast oder Beschriftungsrückfall den Build genauso scheitern lässt wie ein kaputter Test. Die Durchgänge nur mit Tastatur und mit Screenreader mache ich von Hand auf den wichtigsten Wegen, und die Zoom und Umbruchprüfungen bei 200 % und 320 Pixel. Wo es sich rechtfertigt, organisiere ich Sitzungen mit Menschen, die Hilfsmittel nutzen, weil das der einzige Test ist, der dir sagt, ob die Sache wirklich nutzbar ist. Und ich halte das Protokoll, die Scanausgabe, die manuelle Checkliste und die behobenen Probleme, weil darauf ein unabhängiges Audit aufbaut.

Was ich nicht tue, ist ein Abzeichen verkaufen oder eine Garantie versprechen. WCAG ist ein Standard, den du erfüllst und weiter erfüllst, während sich die Seite ändert, und der einzige ehrliche Beweis sind das Testen und die Behebungen, prüfbar durch ein Audit, wenn du die Bestätigung schriftlich willst.

Was jetzt zu tun ist

Wenn du einen Build beginnst, setz WCAG 2.1 AA von Anfang an als Ziel und nimm die WCAG 2.2 Ergänzungen mit, wo sie wenig kosten, denn Nachrüsten ist der teure Weg. Hast du eine bestehende Seite, lass heute einen automatischen Scan laufen, um die mechanischen Fehler zu finden, und buch dann einen manuellen Durchgang, denn der Scan ist im besten Fall ein Drittel des Bildes.⁷ So oder so, halte das Prüfprotokoll, denn eine Aussage ohne Beleg ist bloß eine Hoffnung.

Und wenn du nicht sicher bist, ob das Gesetz dich überhaupt erreicht oder welche Teile deines Produkts es berührt, lies zuerst den Artikel zum Barrierefreiheitsrecht und komm dann, wir gehen es durch.

W3C Web Accessibility Initiative, WCAG 2 Overview (Herausgeber und die Veröffentlichungsdaten von WCAG 2.0 am 11. Dezember 2008, WCAG 2.1 am 5. Juni 2018 mit späteren Fassungen und WCAG 2.2 am 5. Oktober 2023), https://www.w3.org/WAI/standards-guidelines/wcag/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
W3C Web Accessibility Initiative, What's New in WCAG 2.1 (WCAG 2.1 ergänzt 17 Erfolgskriterien gegenüber WCAG 2.0), https://www.w3.org/WAI/standards-guidelines/wcag/new-in-21/ ↩ ↩²
W3C Web Accessibility Initiative, What's New in WCAG 2.2 (neun zusätzliche Erfolgskriterien und die Streichung von 4.1.1 Parsing), https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/ ↩ ↩²
W3C, Web Content Accessibility Guidelines (WCAG) 2.1, W3C Recommendation, aktuelle Fassung 6. Mai 2025 (die vier Prinzipien, die Konformitätsstufen A, AA und AAA und die Erfolgskriterien 1.1.1, 1.2.2, 1.2.5, 1.3.1, 1.4.1, 1.4.3, 1.4.4, 1.4.10, 1.4.11, 2.1.1, 2.1.2, 2.4.3, 2.4.7, 3.1.1, 3.3.1, 3.3.2, 3.3.3 und 4.1.2), https://www.w3.org/TR/WCAG21/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷
W3C Web Accessibility Initiative, Selecting Web Accessibility Evaluation Tools (Werkzeuge können nicht alle Aspekte automatisch prüfen und Barrierefreiheit nicht feststellen), https://www.w3.org/WAI/test-evaluate/tools/selecting/ ↩
W3C Web Accessibility Initiative, Evaluating Web Accessibility Overview (kein Werkzeug allein kann Konformität feststellen, eine sachkundige menschliche Bewertung ist nötig, und Menschen mit Behinderungen einbeziehen), https://www.w3.org/WAI/test-evaluate/ ↩ ↩²
Government Digital Service, What we found when we tested tools on the world's least accessible webpage, Accessibility in government blog, 24. Februar 2017 (zehn Werkzeuge gegen 143 bekannte Barrieren, bestes Werkzeug rund 41 %, 42 Barrieren von jedem Werkzeug übersehen), https://accessibility.blog.gov.uk/2017/02/24/what-we-found- ↩ ↩² ↩³