Was ist WCAG? Die Richtlinien für barrierefreie Webinhalte erklärt

Fast 94,8% der eine Million meistbesuchten Websites verfehlen grundlegende Barrierefreiheitsstandards und weisen im Durchschnitt rund 51 erkennbare Fehler pro Startseite auf. Gleichzeitig wurden allein im Jahr 2025 in den Vereinigten Staaten mehr als 5.100 ADA-Klagen zur digitalen Barrierefreiheit eingereicht – und die rechtlichen wie reputativen Kosten, Barrierefreiheit zu ignorieren, steigen rasant. Egal, ob du einen E-Commerce-Shop, eine SaaS-Plattform oder ein Regierungsportal betreibst: Ein Dokument steht im Zentrum fast jeder Diskussion über Barrierefreiheit – WCAG, die Web Content Accessibility Guidelines. Wenn du dich jemals gefragt hast, was WCAG genau ist, warum es existiert und was es konkret von dir verlangt, ist dieser Leitfaden die verständliche Erklärung in Alltagssprache, nach der du gesucht hast.

Die Ursprünge von WCAG: Woher der Standard kommt

WCAG wird von der Web Accessibility Initiative (WAI) veröffentlicht, einem Programm des World Wide Web Consortium (W3C) – derselben internationalen Organisation, die HTML, CSS und die meisten grundlegenden Webtechnologien standardisiert. Die Richtlinien existieren, weil das Web seiner Natur nach das Versprechen universellen Zugangs in sich trägt. In der Praxis bricht dieses Versprechen für Millionen von Nutzerinnen und Nutzern zusammen, wenn nicht bewusst barrierefreie Designentscheidungen getroffen werden.

Die Wurzeln der Richtlinien zur Web-Barrierefreiheit reichen bis ins Jahr 1995 zurück, als Gregg Vanderheiden die erste Richtlinie zur Web-Barrierefreiheit erstellte, kurz nachdem Tim Berners-Lee in einer Keynote auf der Second International Conference on the World-Wide Web den Zugang für Menschen mit Behinderungen erwähnte. In den folgenden Jahren entstanden mehr als 38 verschiedene Richtlinien zum Webzugang von unterschiedlichen Autorinnen, Autoren und Organisationen, die schließlich in den Unified Web Site Accessibility Guidelines an der University of Wisconsin–Madison zusammengeführt wurden. Version 8 dieses Dokuments, veröffentlicht 1998, wurde zum Ausgangspunkt für WCAG 1.0, das am 5. Mai 1999 zu einer offiziellen W3C-Empfehlung wurde.

WCAG 2.0 erschien im Dezember 2008 und war so bedeutend, dass es im Oktober 2012 als ISO-Standard – ISO/IEC 40500:2012 – übernommen wurde. WCAG 2.1, veröffentlicht im Juni 2018, erweiterte die 2.0-Kriterien um 17 neue Erfolgskriterien mit Fokus auf mobile Nutzbarkeit, Sehbehinderungen und kognitive Barrierefreiheit. Und die aktuelle Version, WCAG 2.2, wurde am 5. Oktober 2023 als W3C-Empfehlung veröffentlicht und seither als ISO/IEC 40500:2025 anerkannt. Das W3C empfiehlt allen, die jeweils neueste Version zu verwenden – aus gutem Grund: Inhalte, die WCAG 2.2 erfüllen, erfüllen automatisch auch WCAG 2.1 und WCAG 2.0.

Es lohnt sich, klar zu benennen, was WCAG ist und was nicht. Es ist ein technischer Standard – eine präzise, testbare Spezifikation, die in einem strengen Multi-Stakeholder-Prozess des W3C in Zusammenarbeit mit Personen und Organisationen weltweit entwickelt wurde. Es ist kein Rechtsdokument an sich, wurde aber in zahlreichen Rechtsordnungen in Gesetze und Verordnungen durch Verweis aufgenommen und ist damit faktisch das Regelwerk für digitale Barrierefreiheit weltweit.

Für wen WCAG entwickelt wurde

WCAG adressiert Barrieren für Menschen mit einem breiten Spektrum an Behinderungen, darunter Seh-, Hör-, körperliche, Sprach-, kognitive, sprachliche, Lern- und neurologische Beeinträchtigungen. Das ist eine bemerkenswert große Bevölkerungsgruppe. Die Weltgesundheitsorganisation schätzt, dass etwa 1,3 Milliarden Menschen – rund 16% der Weltbevölkerung – mit einer Form von Behinderung leben, die ihren Alltag und ihren Online-Zugang beeinflusst. Jede dieser Personen könnte gerade jetzt eine potenzielle Kundin, ein potenzieller Bürger, eine Studentin oder ein Mitarbeiter sein, der versucht, deine Website zu nutzen.

Doch die Vorteile der WCAG-Konformität gehen weit über Nutzerinnen und Nutzer mit dauerhaften Behinderungen hinaus. Die Richtlinien helfen auch älteren Menschen mit altersbedingten Einschränkungen – eingeschränktem Sehvermögen, Hörverlust, verlangsamter Motorik – und verbessern häufig die Nutzbarkeit für alle. Man denke an Untertitel in Videos: Sie wurden für gehörlose Nutzerinnen und Nutzer entwickelt, kommen aber auch Personen zugute, die in lauten Umgebungen schauen, Nicht-Muttersprachlerinnen und -Muttersprachlern, die mitlesen, und allen, die lieber lesen als zuhören. Ebenso hilft Tastaturnavigation Power-Usern, die die Maus als langsam empfinden, und ausreichender Farbkontrast hilft allen, die im grellen Sonnenlicht auf den Bildschirm blinzeln.

WCAG deckt außerdem Inhalte auf nahezu allen Arten digitaler Geräte ab – Desktops, Laptops, Kioske und mobile Geräte – und ist bewusst technologie-neutral. Die Erfolgskriterien sind als testbare Aussagen formuliert, die keine bestimmte Technologie vorschreiben. Dadurch bleiben sie relevant, während sich HTML, JavaScript-Frameworks und unterstützende Technologien weiterentwickeln.

Die POUR-Prinzipien: Das konzeptionelle Fundament von WCAG

Jedes Erfolgskriterium in WCAG – alle 86 in Version 2.2 – ist unter vier übergeordneten Prinzipien organisiert, die gemeinsam das Akronym POUR bilden. Diese Prinzipien bilden das konzeptionelle Fundament des gesamten Standards. Wer sie versteht, erhält ein intuitives mentales Modell für Barrierefreiheit, noch bevor auch nur ein einziges konkretes Kriterium gelesen wird.

• Perceivable (Wahrnehmbar): Informationen und Bedienelemente der Benutzeroberfläche müssen so präsentiert werden, dass Nutzerinnen und Nutzer sie wahrnehmen können. In der Praxis bedeutet das, dass Inhalte nicht für alle Sinne einer Person unsichtbar sein dürfen. Wenn ein Nutzer ein Bild nicht sehen kann, muss es eine Textalternative geben, die er sich über einen Screenreader vorlesen lassen kann. Wenn ein Video eine gesprochene Tonspur hat, müssen Untertitel für Personen vorhanden sein, die nicht hören können. Praktische Anforderungen unter diesem Prinzip umfassen Alt-Text für Bilder, Untertitel für Videos, ausreichenden Farbkontrast zwischen Text und Hintergrund sowie die Möglichkeit, Text zu vergrößern, ohne dass Inhalte verloren gehen.
• Operable (Bedienbar): Bedienelemente und Navigation müssen bedienbar sein. Keine Interaktion darf eine Eingabe erfordern, die eine Nutzerin oder ein Nutzer nicht leisten kann. Die häufigste Konsequenz: Alle Funktionen müssen allein mit der Tastatur nutzbar sein, nicht nur mit der Maus. Dieses Prinzip umfasst auch, Nutzerinnen und Nutzern genügend Zeit zu geben, Inhalte zu lesen und mit ihnen zu interagieren, Inhalte zu vermeiden, die Anfälle auslösen könnten, und mehrere Navigationswege durch eine Website bereitzustellen.
• Understandable (Verständlich): Informationen und die Bedienung der Benutzeroberfläche müssen verständlich sein. Inhalte dürfen nicht so komplex oder verwirrend sein, dass Nutzerinnen und Nutzer sie nicht wie vorgesehen verwenden können. Dies umfasst verständliche Sprache (einschließlich der Angabe der Seitensprache im Code, damit Screenreader die richtige Aussprache verwenden), vorhersehbares Seitenverhalten, klare Anweisungen und hilfreiche Fehlermeldungen, die erklären, was schiefgelaufen ist und wie es behoben werden kann.
• Robust (Robust): Inhalte müssen robust genug sein, um von einer Vielzahl von User Agents, einschließlich unterstützender Technologien, zuverlässig interpretiert zu werden. Eine robuste Website verwendet sauberes, gültiges semantisches Markup, damit Screenreader, Braillezeilen und andere Hilfsmittel die Inhalte korrekt erfassen und wiedergeben können – sowohl heute als auch in Zukunft, wenn sich Technologien weiterentwickeln.

Man kann POUR sich als vier Filter vorstellen, die jedes Element deiner Website passieren muss. Wenn eine Komponente auch nur einen dieser vier Filter nicht besteht, ist sie wahrscheinlich für einige deiner Nutzerinnen und Nutzer eine Barriere.

Diese vier Prinzipien sind in allen Versionen von WCAG – 2.0, 2.1 und 2.2 – stabil geblieben, auch wenn die konkreten Erfolgskriterien darunter gewachsen und weiterentwickelt wurden. Diese Stabilität macht POUR zu einer dauerhaften Linse zur Bewertung von Barrierefreiheit, unabhängig davon, auf welche Version sich ein bestimmtes Gesetz bezieht.

Konformitätsstufen: A, AA und AAA erklärt

Unter den vier POUR-Prinzipien stehen 13 Richtlinien, und darunter wiederum die 86 testbaren Erfolgskriterien – die konkreten Anforderungen, die erfüllt sein müssen, um WCAG-Konformität zu beanspruchen. Jedes Erfolgskriterium ist einer von drei Konformitätsstufen zugeordnet.

• Stufe A ist das Minimum. Dies sind die kritischsten Anforderungen, die so schwerwiegende Barrieren darstellen, dass bestimmte Nutzerinnen und Nutzer Inhalte überhaupt nicht erreichen können. Beispiele sind Textalternativen für Nicht-Text-Inhalte und die Sicherstellung, dass alle Funktionen per Tastatur zugänglich sind. Stufe A allein reicht für die meisten regulatorischen Zwecke nicht aus, aber ein Verfehlen bedeutet ein grundlegendes Scheitern.
• Stufe AA ist der mittlere Standard und derjenige, der von der überwiegenden Mehrheit der Gesetze und Verordnungen weltweit gefordert wird. Er umfasst alle Kriterien der Stufe A plus zusätzliche Anforderungen wie Text-Hintergrund-Kontrastverhältnisse von mindestens 4,5:1, konsistente Navigation über Seiten hinweg und Untertitel für vorab aufgezeichnete Videos. Die meisten globalen Barrierefreiheitsgesetze – einschließlich Section 508 in den USA, EN 301 549 in Europa und AODA in Ontario, Kanada – verlangen Konformität mit Stufe AA. Dies ist das Ziel, das nahezu jede Organisation priorisieren sollte.
• Stufe AAA ist der höchste Standard und umfasst Kriterien, die eher aspirativ als universell erreichbar sind. Das W3C selbst erkennt an, dass es nicht möglich ist, alle AAA-Kriterien für alle Arten von Inhalten zu erfüllen, weshalb diese Kriterien in der Regel nicht als allgemeine politische Vorgabe festgelegt werden. Beispiele sind Gebärdensprachdolmetschung für alle Audioinhalte und ein Lesbarkeitsniveau, das nicht über der unteren Sekundarstufe liegt.

Ein wichtiger Punkt: Konformitätsstufen sind kumulativ. Wer Stufe AA erreicht, erfüllt damit auch alle Kriterien der Stufe A. Wer Stufe AAA erreicht, erfüllt A und AA ebenfalls. Und entscheidend: Konformität ist auf jeder Stufe ein Alles-oder-nichts-Prinzip – du kannst keine AA-Konformität beanspruchen, wenn auch nur ein einziges AA-Kriterium auf einer Seite nicht erfüllt ist.

Für die meisten Organisationen ist WCAG 2.2 Stufe AA das richtige Ziel. Es ist die Stufe, die in Gesetzen verankert ist, die Gerichte als Maßstab verwenden und die deine digitale Erfahrung für das größtmögliche Publikum tatsächlich öffnet.

Was sich in WCAG 2.2 geändert hat: Die neun neuen Erfolgskriterien

WCAG 2.2, veröffentlicht im Oktober 2023, hat neun neue Erfolgskriterien zusätzlich zu allen bestehenden Kriterien aus WCAG 2.1 eingeführt. Diese Ergänzungen wurden durch laufende Forschung dazu motiviert, wo Nutzerinnen und Nutzer mit Behinderungen – insbesondere mit kognitiven Beeinträchtigungen, motorischen Einschränkungen und Sehbehinderungen – weiterhin häufig auf Barrieren stoßen, die durch die früheren Richtlinien nicht ausreichend adressiert wurden. WCAG 2.2 entfernt oder ändert keine bestehenden Anforderungen aus WCAG 2.1; es erweitert sie lediglich.

Von den neun neuen Kriterien liegen vier auf Stufe AA (und sind damit für die meisten Organisationen rechtlich relevant), zwei auf Stufe A und drei auf Stufe AAA. Das bedeuten die Kriterien auf AA-Niveau und darunter in der Praxis:

• 2.4.11 Fokus nicht verdeckt – Minimum (AA): Wenn eine Tastaturnutzerin oder ein Tastaturnutzer zu einem interaktiven Element navigiert, darf dieses Element nicht vollständig durch andere, vom Autor erstellte Inhalte verdeckt sein. Dies ist eine direkte Reaktion auf ein häufiges modernes Designmuster: Sticky Header, Cookie-Banner und fixierte Footer, die über Seiteninhalte gleiten und den Tastaturfokus unbemerkt verschlucken, sodass Nutzerinnen und Nutzer ohne sichtbare Fokusanzeige auf der Seite „stranden“.
• 2.5.7 Ziehbewegungen (AA): Jede Funktion, die eine Ziehbewegung erfordert – etwa Drag-and-drop-Datei-Uploads, sortierbare Listenelemente oder benutzerdefinierte Slider – muss eine Alternative für einen einzelnen Zeiger bieten, die kein Ziehen erfordert. Für eine Person mit Handzittern oder eingeschränkter Feinmotorik kann es nahezu unmöglich sein, kontinuierlichen Druck auszuüben, während der Zeiger über den Bildschirm bewegt wird. Alternativen wie „Klicken zum Auswählen, dann Klicken zum Platzieren“ oder Auf-/Ab-Pfeiltasten bei sortierbaren Listen lösen dieses Problem.
• 2.5.8 Zielgröße – Minimum (AA): Interaktive Ziele wie Buttons und Links müssen mindestens 24×24 CSS-Pixel groß sein. Kleine Tippziele sind ein gut dokumentiertes Usability-Problem für mobile Nutzerinnen und Nutzer mit motorischen Einschränkungen, ältere Menschen und im Grunde alle, die auf dem Handy tippen, während sie mehrere Dinge gleichzeitig tun.
• 3.3.8 Barrierefreie Authentifizierung – Minimum (AA): Authentifizierungsprozesse dürfen nicht verlangen, dass Nutzerinnen und Nutzer einen Test kognitiver Funktionen lösen – etwa ein klassisches CAPTCHA mit Zeichenerkennung oder Rätsellösen –, es sei denn, es wird eine Alternative bereitgestellt. Dies ist ein wichtiges Kriterium für jede Website, die Standard-CAPTCHA-Herausforderungen in Login- oder Registrierungsabläufen verwendet. Lösungen umfassen die Unterstützung von Passwortmanagern, E-Mail- oder SMS-Magic-Links, biometrische Authentifizierung oder Alternativen auf Basis von Objekterkennung.
• 3.2.6 Konsistente Hilfe (A): Wenn eine Website auf mehreren Seiten eine Hilfefunktion bereitstellt (z. B. einen Live-Chat-Button, einen FAQ-Link oder eine Support-Telefonnummer), muss diese Funktion an derselben relativen Position auf den Seiten erscheinen. Nutzerinnen und Nutzer mit kognitiven Beeinträchtigungen, die Hilfe benötigen, profitieren stark davon, genau zu wissen, wo sie diese finden, ohne jedes Mal suchen zu müssen.
• 3.3.7 Redundante Eingabe (A): Informationen, die eine Nutzerin oder ein Nutzer in einem mehrstufigen Prozess bereits eingegeben hat, müssen automatisch ausgefüllt oder auswählbar sein, statt erneut eingegeben werden zu müssen. Dies reduziert Reibung für Menschen mit kognitiven oder motorischen Beeinträchtigungen, für die das Ausfüllen von Formularen besonders anstrengend ist.

WCAG 2.2 hat außerdem ein Kriterium aus 2.1 offiziell entfernt: 4.1.1 Parsing. Dieses Kriterium verlangte ursprünglich strikt gültiges HTML, um sicherzustellen, dass unterstützende Technologien Markup korrekt parsen können. Es wurde zurückgezogen, weil moderne Browser und unterstützende Technologien fehlerhaftes Markup inzwischen robust durch eigene Fehlerkorrekturmechanismen verarbeiten, sodass das Kriterium für die Barrierefreiheit praktisch nicht mehr aussagekräftig ist.

WCAG und das Recht: Was Nicht-Konformität tatsächlich kostet

WCAG ist ein technischer Standard, kein Gesetz. Aber er ist in den meisten großen Rechtsordnungen in das rechtliche Gefüge der digitalen Barrierefreiheit eingewoben, was bedeutet, dass Nicht-Konformität reale rechtliche Risiken mit sich bringt.

In den Vereinigten Staaten nennen weder der ADA noch Section 508 WCAG 2.2 ausdrücklich im Gesetzestext, doch WCAG wird in Klagen und bei der Durchsetzung konsequent als technischer Maßstab verwendet. Das Justizministerium veröffentlichte 2024 eine Final Rule, die WCAG 2.1 Stufe AA als offiziellen Standard für die Einhaltung von Section 508 und ADA Title II für staatliche und kommunale Behörden festlegt. ADA Title III – das für öffentliche Einrichtungen gilt, einschließlich der meisten privatwirtschaftlichen Online-Unternehmen – wird aktiv durch Privatklagen durchgesetzt. Im Jahr 2024 wurden über 4.000 ADA-Klagen im Zusammenhang mit digitalen Angeboten vor Bundes- und Staatsgerichten eingereicht, und der Trend setzte sich 2025 nach oben fort. Die zivilrechtlichen ADA-Strafen für Erstverstöße wurden 2024 inflationsbereinigt und können nun bis zu 115.231 $ erreichen, bei wiederholten Verstößen bis zu 230.464 $.

In Europa ist die Lage ebenso bedeutsam. Der European Accessibility Act (EAA) wurde am 28. Juni 2025 in den EU-Mitgliedstaaten rechtlich anwendbar und verlangt, dass Websites, Apps, E-Books, E-Commerce-Plattformen und PDFs die Kriterien von WCAG 2.1 AA erfüllen. Die europäische Norm EN 301 549 verweist derzeit auf WCAG 2.1, wobei in der nächsten Version ein Update auf WCAG 2.2 erwartet wird. Für Organisationen mit Präsenz in Europa ist die EAA-Konformität nicht mehr optional.

Die Klagedaten zeigen zudem ein besonders schmerzhaftes Muster für kleinere Unternehmen: Die Vorstellung, klein zu bleiben schütze vor Klagen, ist ein Mythos. Im Jahr 2023 richteten sich 77% der ADA-Klagen zur digitalen Barrierefreiheit gegen Unternehmen mit weniger als 25 Millionen $ Jahresumsatz. E-Commerce bleibt mit großem Abstand der am häufigsten verklagte Sektor. Und entscheidend: Eine einmalige Klage schützt nicht vor weiteren – nahezu die Hälfte aller Klagen zur digitalen Barrierefreiheit in den letzten Jahren richtete sich gegen Unternehmen, die bereits mindestens eine frühere Klage erlebt hatten.

Die häufigsten WCAG-Verstöße (und wie man sie erkennt)

Angesichts der Tatsache, dass fast 95% der Websites grundlegende Barrierefreiheitsstandards verfehlen, lohnt es sich zu wissen, welche konkreten Verstöße am häufigsten vorkommen. Der jährliche WebAIM Million Report, der die Startseiten der eine Million meistbesuchten Websites prüft, identifiziert konsequent dieselbe Handvoll Probleme, die auf der überwiegenden Mehrheit der Seiten auftreten:

• Niedriger Farbkontrast: Text mit zu geringem Kontrast betraf 79,1% der Startseiten in der Analyse 2025, mit durchschnittlich fast 30 Fällen pro Seite. Dies ist gleichzeitig der häufigste Verstoß und einer der am einfachsten mit automatisierten Tools erkennbaren. Text muss ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund aufweisen (3:1 für große Schrift), um Stufe AA zu erfüllen.
• Fehlender Alternativtext: Fehlender Alt-Text betrifft 55,5% der Seiten. Für Screenreader-Nutzerinnen und -Nutzer, die blind oder sehbehindert sind, ist ein Bild ohne Alt-Text schlicht unsichtbar – die unterstützende Technologie überspringt es entweder lautlos oder liest einen nichtssagenden Dateinamen vor. Verlinkte Bilder ohne Alt-Text zerstören die Navigation vollständig.
• Fehlende Formularbeschriftungen: Formulareingabefelder ohne zugeordnete Labels bedeuten, dass Screenreader-Nutzerinnen und -Nutzer nicht erkennen können, welche Information ein Feld verlangt. Dies schafft eine unüberwindbare Barriere bei jedem Checkout, jeder Registrierung oder jedem Kontaktformular.
• Leere Links: Links ohne beschreibenden Text – oft reine Icon-Links oder Bildlinks ohne Alt-Text – lassen Tastatur- und Screenreader-Nutzerinnen und -Nutzer ohne Kontext darüber, wohin der Link führt.
• Fehlende Dokumentensprache: Wird die Sprache einer Seite im HTML nicht deklariert, können Screenreader Inhalte mit den Aussprache-Regeln der falschen Sprache vorlesen, was den Text unverständlich macht.

Auffällig an dieser Liste ist, dass keines dieser Probleme exotische Randfälle sind, die fortgeschrittene Technik erfordern. Es handelt sich um einfache Markup- und Designentscheidungen. Dass sie auf der überwiegenden Mehrheit der Websites weiterhin auftreten, spiegelt eine strukturelle Lücke darin wider, wie Barrierefreiheit in typische Webentwicklungs-Workflows integriert wird – oder eben nicht –, und nicht eine grundlegende technische Hürde.

Wie Organisationen WCAG-Konformität angehen sollten

Von dem Punkt, an dem sich die meisten Websites heute befinden, zu einer echten Konformität mit WCAG 2.2 Stufe AA zu gelangen, erfordert ein systematisches Vorgehen. Es handelt sich nicht um ein einmaliges Projekt – es ist ein fortlaufender Prozess, weil sich Inhalte ändern, Frameworks aktualisiert werden und Drittkomponenten ausgetauscht werden. So strukturierst du den Aufwand effektiv.

Beginne mit einem Basisaudit. Bevor du etwas beheben kannst, musst du wissen, was kaputt ist. Automatisierte Scantools können einen bedeutenden Teil der Probleme – Farbkontrast, fehlender Alt-Text, fehlende Formularlabels – schnell und in großem Umfang identifizieren. Automatisierte Tools haben jedoch bekannte Grenzen; sie erkennen etwa 30–40% der WCAG-Probleme. Der Rest erfordert manuelle Tests: deine Website ausschließlich mit der Tastatur bedienen, Tests mit echten Screenreadern wie NVDA oder JAWS unter Windows und VoiceOver auf macOS und iOS durchführen und idealerweise Menschen mit Behinderungen in den Testprozess einbeziehen.

Priorisiere nach Auswirkung und Häufigkeit. Nicht alle Probleme sind gleich schwerwiegend. Fehlender Alt-Text bei einem dekorativen Icon ist weit weniger kritisch als eine Tastaturfalle, die Nutzerinnen und Nutzer in einem Modal-Dialog festhält, oder ein Login-Formular, das mit einem Screenreader überhaupt nicht nutzbar ist. Konzentriere deinen ersten Behebungs-Sprint auf Barrieren, die zentrale Nutzerwege blockieren – Checkout, Kontoerstellung, Suche, Kontakt – bevor du kosmetische oder weniger gravierende Punkte angehst.

Baue Barrierefreiheit in den Entwicklungs-Workflow ein, nicht am Ende an. Die teuerste Barrierefreiheitsarbeit ist die nachträgliche Behebung nach dem Launch. Wenn du Barrierefreiheitsprüfungen in dein Designsystem, deine Komponentenbibliothek, deinen Code-Review-Prozess und deine CI/CD-Pipeline integrierst, werden Probleme an dem Punkt abgefangen, an dem sie am günstigsten zu beheben sind. Bestimme eine klare verantwortliche Person für Barrierefreiheit in deinem Team und biete rollenspezifische Schulungen für Designerinnen, Entwickler und Content-Editorinnen an.

Pflege eine Barrierefreiheitserklärung. Eine klare, ehrliche Barrierefreiheitserklärung auf deiner Website zu veröffentlichen – in der du beschreibst, welchen Standard du anstrebst, wie Nutzerinnen und Nutzer Barrieren melden können und wie du auf Meldungen reagierst – zeigt guten Willen und ist in einigen Rechtsordnungen, etwa nach der EU-Webzugangsrichtlinie, sogar gesetzlich vorgeschrieben. Sie schafft außerdem eine Feedbackschleife, die dir hilft, Probleme zu erkennen, die du in Tests übersehen hast.

Nutze Overlay-Widgets als Ergänzung, nicht als Ersatz für Barrierefreiheit im Code. Overlay-Widgets und SDKs für Barrierefreiheit – einschließlich Accsible – können wertvolle Werkzeuge sein, um nutzergesteuerte Einstellungen wie Textvergrößerung, Kontrastmodi und Verbesserungen der Tastaturnavigation bereitzustellen. Aber die Daten sind eindeutig: Widgets, die anstelle grundlegender Barrierefreiheitsarbeit eingesetzt werden, verhindern keine Klagen. Der rechtliche Schutz entsteht dadurch, dass dein zugrunde liegender Code die WCAG-Kriterien erfüllt, nicht durch ein Widget, das auf ein nicht barrierefreies Fundament gesetzt wird. Nutze Overlays als Ergänzung zu echter Behebung, nicht als Ersatz.

Der Weg nach vorn: WCAG 3.0 am Horizont

Während Organisationen noch daran arbeiten, WCAG 2.2 zu erfüllen, entwickelt die W3C Accessibility Guidelines Working Group WCAG 3.0, eine deutlich umfassendere Umstrukturierung der Leitlinien zur Web-Barrierefreiheit. Der erste öffentliche Arbeitsentwurf wurde Anfang 2021 veröffentlicht, und Ende 2025 befindet sich der Arbeitsentwurf weiterhin in intensiver Entwicklung. Kein Teil von WCAG 3.0 ist bislang eine offizielle Empfehlung, und es gibt kein festes Veröffentlichungsdatum.

Es wird erwartet, dass WCAG 3.0 sich deutlich vom A/AA/AAA-Konformitätsmodell entfernt, einen punktbasierten Ansatz einführt und ein breiteres Spektrum digitaler Inhaltstypen abdeckt, einschließlich nativer mobiler Anwendungen und neuer Technologien. Vorerst sollten sich Organisationen auf WCAG 2.2 Stufe AA konzentrieren – es ist der derzeit durchsetzbare Standard und wird es auf absehbare Zeit bleiben. Organisationen, die jetzt eine solide WCAG-2.2-Basis schaffen, werden deutlich besser aufgestellt sein, sich anzupassen, wenn WCAG 3.0 schließlich zur Empfehlung wird.

Wesentliche Erkenntnisse

• WCAG 2.2 ist der aktuelle globale Standard für Web-Barrierefreiheit, veröffentlicht vom W3C und als ISO/IEC 40500:2025 anerkannt. Inhalte, die WCAG 2.2 erfüllen, erfüllen automatisch 2.1 und 2.0 – strebe die neueste Version an.
• Stufe AA ist das entscheidende Ziel. Nahezu alle globalen Barrierefreiheitsgesetze – ADA, Section 508, EAA, EN 301 549, AODA – verweisen auf WCAG Stufe AA als erforderliches Konformitätsniveau. Konzentriere deine Anstrengungen zuerst darauf.
• Die häufigsten Verstöße sind behebbar. Niedriger Farbkontrast, fehlender Alt-Text, fehlende Formularlabels und leere Links machen den Großteil der Barrierefreiheitsfehler im Web aus. Diese Probleme lassen sich mit relativ geringem Aufwand und großer Wirkung lösen.
• Automatisiertes Testen ist notwendig, aber nicht ausreichend. Tools können etwa 30–40% der WCAG-Probleme erkennen. Kombiniere automatisierte Scans mit Tastaturtests, Screenreader-Tests und idealerweise Nutzertests mit Menschen mit Behinderungen, um ein vollständiges Bild zu erhalten.
• Barrierefreiheit ist ein fortlaufender Prozess, kein einmaliges Projekt. Inhalte ändern sich, Drittkomponenten ändern sich und Standards entwickeln sich weiter. Integriere Barrierefreiheit in deine Design-, Entwicklungs- und Content-Workflows, damit sie kontinuierlich gepflegt wird und nicht nur reaktiv nach einer Beschwerde oder Klage behoben wird.