Ressourcen für Barrierefreiheit

Eine kurze Geschichte der Web-Barrierefreiheit

Lange bevor es ein Web gab, hatte das US-Bundesrecht begonnen, das rechtliche Gerüst aufzubauen, an das die Barrierefreiheit später anknüpfen sollte. Abschnitt 504 des Rehabilitation Act von 1973 verbot die Diskriminierung aufgrund einer Behinderung durch jedes Programm, das finanzielle Unterstützung des Bundes erhält, wobei die Durchführungsverordnungen erst am 28. April 1977 unterzeichnet wurden, und das auch erst nach dem berühmten 504-Sit-in, bei dem Aktivisten für Behindertenrechte 25 Tage lang ein Bundesgebäude in San Francisco besetzten, die längste gewaltfreie Besetzung eines Bundesgebäudes in der US-Geschichte. Abschnitt 508 desselben Gesetzes wurde 1986 durch eine Änderung hinzugefügt, hatte aber keine Durchsetzungskraft; die wesentlich überarbeitete Fassung, auf die sich Fachleute heute beziehen, wurde 1998 als Teil des Workforce Investment Act erlassen und verpflichtet US-Bundesbehörden, ihre elektronische und Informationstechnologie barrierefrei zu gestalten. Der Americans with Disabilities Act von 1990 ist das umfassendere Bürgerrechtsgesetz, das die Diskriminierung von Behinderten verbietet, und es ist der ADA (nicht Abschnitt 508), der in Klagen gegen Websites der Privatwirtschaft angeführt wird.

Das W3C rief 1997 die Web Accessibility Initiative (WAI) ins Leben, um die Arbeit an der Web-Barrierefreiheit in der normsetzenden Gemeinschaft zu koordinieren. Tim Berners-Lees Sichtweise (dass der Wert des Webs auf seiner Universalität beruht und der Zugang für alle, unabhängig von einer Behinderung, wesentlich ist) wurde zur Gründungsprämisse der WAI.

Die Zeitleiste der WCAG-Versionen

• WCAG 1.0: W3C-Empfehlung, 5. Mai 1999. Ordnete die Empfehlungen zur Barrierefreiheit um 14 Richtlinien mit Prüfpunkten der Priorität 1, 2 oder 3 (die Konformitätsstufen A, AA und AAA leiten sich von diesem Schema ab). Fest auf HTML und den frühen Web-Stack der späten 1990er-Jahre ausgerichtet.
• WCAG 2.0: W3C-Empfehlung, 11. Dezember 2008. Ordnete das gesamte Rahmenwerk um die vier POUR-Prinzipien neu. Führte das bis heute gültige dreistufige Konformitätsmodell ein (A / AA / AAA). Im Oktober 2012 als ISO/IEC 40500:2012 übernommen.
• WCAG 2.1: W3C-Empfehlung, 5. Juni 2018. Fügte 17 neue Erfolgskriterien hinzu, die mobile Nutzer (Bildschirmausrichtung, Zeigergesten, Bewegungsaktivierung), Nutzer mit Sehschwäche (Umbruch bei 320 CSS-Pixeln, 3:1-Kontrast für Nicht-Text-UI-Komponenten, Toleranz beim Textabstand) und Menschen mit kognitiven und Lernbehinderungen (Autofill-Eingabezweck, Timeout-Hilfe) betreffen. „WCAG 2.1 AA“ bleibt der weltweit meistzitierte Standard im Recht der Barrierefreiheit.
• WCAG 2.2: W3C-Empfehlung, 5. Oktober 2023, mit redaktionellen Pflegeaktualisierungen, die im Dezember 2024 veröffentlicht wurden. Fügte neun neue Erfolgskriterien hinzu, darunter Focus Not Obscured (2.4.11/2.4.12), Dragging Movements (2.5.7), Target Size Minimum (2.5.8 (mindestens 24×24 CSS-Pixel), Consistent Help (3.2.6), Redundant Entry (3.3.7) und Accessible Authentication (3.3.8/3.3.9) Anmeldeabläufe dürfen keine Rätsel-CAPTCHAs ohne barrierefreie Alternative verlangen). Entfernte das überholte Kriterium 4.1.1 Parsing. Dies ist die aktuell veröffentlichte Version.
• WCAG 3.0: noch ein Arbeitsentwurf. Mit einem flexibleren Bewertungsmodell und breiterem Geltungsbereich (Apps, Autorenwerkzeuge, Veröffentlichungsplattformen, neue Technologien) konzipiert. Das W3C stellt klar, dass WCAG 3 die WCAG 2 nicht sofort ablösen wird, die WCAG 2 wird noch mehrere Jahre nach der Fertigstellung von 3 gepflegt. Fachleute, die 2026 Erklärungen zur Barrierefreiheit verfassen, sollten weiterhin WCAG 2.2 (oder 2.1) als den maßgeblichen Standard heranziehen.

Die vier POUR-Prinzipien in einfachen Worten

Wahrnehmbar (Perceivable) fragt: Kann der Nutzer das, was auf dem Bildschirm steht, tatsächlich aufnehmen? Ein Foto ohne Alternativtext ist für jemanden, der einen Screenreader verwendet, nicht wahrnehmbar. Ein Video ohne Untertitel ist für jemanden, der gehörlos ist, nicht wahrnehmbar. Text in 9-Punkt-Dunkelgrau auf etwas weniger dunklem Grau ist für viele Menschen mit Sehschwäche nicht wahrnehmbar. „Wahrnehmbar“ bedeutet nicht „sieht hübsch aus“, es bedeutet „liegt die Information in einer Form vor, die die Sinne und Werkzeuge dieses Nutzers erfassen können?“.

Bedienbar (Operable) fragt: Kann der Nutzer die Oberfläche tatsächlich bedienen? Eine Website, die das Überfahren mit der Maus erfordert, ist für Tastatur- oder Touch-Nutzer nicht bedienbar. Ein 60-Sekunden-Timeout ist für jemanden, der länger zum Lesen braucht, nicht bedienbar. Ein modales Fenster, das den Tastaturfokus ohne Ausweg festhält, ist nicht bedienbar.

Verständlich (Understandable) fragt: Kann der Nutzer nachvollziehen, was geschieht? Ein Formular, das „Fehler 47“ und sonst nichts sagt, ist nicht verständlich. Eine Seite, auf der sich die Navigation bei jedem Besuch anders umordnet, ist nicht verständlich.

Robust fragt: Wird der Inhalt weiterhin funktionieren, während sich Benutzeragenten und assistive Technologien weiterentwickeln? Benutzerdefinierte Komponenten, die dem Accessibility-Baum keine ordentlichen Rollen, Namen und Zustände offenlegen, erfüllen dieses Prinzip nicht. Der häufigste praktische Rat: Bevorzugen Sie nach Möglichkeit Standard-HTML-Elemente gegenüber benutzerdefinierten JavaScript-Widgets; wenn Sie doch benutzerdefinierte Widgets bauen, folgen Sie den vom W3C dokumentierten ARIA-Mustern.

WAI-ARIA, der Begleiter für reichhaltige Anwendungen

WAI-ARIA ist eine eigene W3C-Spezifikation, die Rollen, Zustände und Eigenschaften definiert, die HTML tragen kann, um assistiven Technologien den Zweck und den aktuellen Zustand dynamischer Oberflächenkomponenten mitzuteilen. ARIA wird benötigt, weil HTML allein moderne Muster wie Tabs, Dialoge, Autovervollständigungs-Comboboxen, Baumansichten und Live-Regionen, die sich ohne Neuladen der Seite aktualisieren, nicht beschreiben kann. Versionszeitleiste: WAI-ARIA 1.0 Empfehlung am 20. März 2014; 1.1 am 14. Dezember 2017; 1.2 am 6. Juni 2023, die aktuelle Version. Die fünf „Regeln der ARIA-Verwendung“ laufen darauf hinaus: natives HTML bevorzugen; die Semantik vorhandener Elemente nicht ändern; die Tastaturbedienbarkeit sicherstellen; fokussierbare Elemente niemals vor assistiver Technik verbergen; und jedem interaktiven Element stets einen barrierefreien Namen geben.

Die Rechtslandschaft, Rechtsraum für Rechtsraum

In den Vereinigten Staaten werden Klagen zur Web-Barrierefreiheit fast ausschließlich nach ADA Title III eingereicht. Zwei Fälle prägen die moderne Landschaft. National Federation of the Blind v. Target Corp. (eingereicht am 7. Februar 2006, im August 2008 für 6 Millionen US-Dollar zuzüglich 3,7 Millionen US-Dollar Anwaltskosten beigelegt) war die erste große US-Sammelklage zur Web-Barrierefreiheit. Robles v. Domino's Pizza: Urteil des Ninth Circuit am 15. Januar 2019; der Supreme Court lehnte es am 7. Oktober 2019 ab, die Berufung zu verhandeln, womit bestätigt wurde, dass der ADA jede Online-Plattform eines US-Unternehmens mit physischen Standorten erfasst. Das Ergebnis war ein anhaltender Boom an Klagen: 4.187 bundesweite Klagen zur digitalen Barrierefreiheit im Jahr 2024, mit jährlich mehr als 4.000 seit 2021. Etwa ein Viertel der Fälle von 2024 betraf Unternehmen, die bereits zuvor verklagt worden waren. Bemerkenswert: Mehr als 1.000 der Beklagten von 2024 hatten bereits ein „Barrierefreiheits-Widget“ installiert (die stark an kleine Unternehmen vermarkteten Overlay-Skripte), das die Klage nicht verhinderte.

Im April 2024 verabschiedete das US-Justizministerium eine lang erwartete Regelung, die ADA Title II auf Web-Inhalte und mobile Apps von Behörden auf bundesstaatlicher und kommunaler Ebene anwendet. Die Regelung wurde am 24. April 2024 im Federal Register veröffentlicht und übernahm WCAG 2.1 Level AA als technischen Standard. Im April 2026 verlängerte das DOJ die ursprünglichen Fristen per Interim Final Rule um ein Jahr: Große öffentliche Stellen haben nun bis zum 26. April 2027 Zeit, kleine Stellen bis zum 26. April 2028.

Der European Accessibility Act ist die Richtlinie (EU) 2019/882, verabschiedet im April 2019. Die Mitgliedstaaten mussten sie bis zum 28. Juni 2022 in nationales Recht umsetzen, und die inhaltlichen Barrierefreiheitsanforderungen gelten seit dem 28. Juni 2025. Der EAA deckt eine breite Palette von Verbraucherprodukten und -dienstleistungen ab, die auf dem EU-Markt angeboten werden: Computer und Betriebssysteme, Smartphones und Tablets, E-Reader, Geldautomaten und Ticket-/Check-in-Automaten, E-Commerce-Websites, Bankdienstleistungen, E-Books, audiovisuelle Mediendienste und Fahrgastinformationen. Kleinstunternehmen (weniger als 10 Beschäftigte, Umsatz unter 2 Millionen Euro), die Dienstleistungen erbringen, sind ausgenommen. Der harmonisierte technische Standard ist EN 301 549, gemeinsam von CEN, CENELEC und ETSI veröffentlicht; die aktuelle Version 3.2.1 (März 2021) übernimmt den vollständigen Text von WCAG 2.1.

Weitere bedeutende nationale Rahmenwerke: Ontarios AODA (Accessibility for Ontarians with Disabilities Act), 2005 mit dem erklärten Ziel vollständiger Barrierefreiheit bis 2025 erlassen; Frankreichs RGAA (Référentiel Général d'Amélioration de l'Accessibilité) v4.1.2 (2022), ein Satz von 106 technischen Kriterien, die auf WCAG 2.1 AA abgebildet sind, mit erheblichen Bußgeldern bei Nichteinhaltung durch den öffentlichen Sektor und große Privatunternehmen (Jahresumsatz von 250 Millionen Euro oder mehr).

Wer Ihre Website tatsächlich nutzt, die Landschaft der assistiven Technik

Die zuverlässigsten Daten zu Kombinationen aus Screenreader und Browser stammen aus der WebAIM Screen Reader User Survey. Die jüngste Ausgabe, Umfrage #10, wurde im Dezember 2023 und Januar 2024 durchgeführt und erbrachte 1.539 gültige Antworten. Die wichtigsten Zahlen: als primärer Screenreader JAWS 40,5 %, NVDA 37,7 %, VoiceOver 9,7 %. Als „insgesamt am häufigsten verwendet“ (Mehrfachauswahl) NVDA 65,6 %, JAWS 60,5 %, VoiceOver 43,9 %: etwa 71,6 % der Befragten verwenden mehr als einen Screenreader. Die häufigsten Kombinationen sind JAWS + Chrome (24,7 %), NVDA + Chrome (21,3 %), JAWS + Edge (11,4 %), NVDA + Firefox (10,0 %) und VoiceOver + Safari (7,0 %).

• JAWS (Job Access With Speech), kommerzieller Windows-Screenreader, ursprünglich 1989 von Ted Henter über Henter-Joyce veröffentlicht, heute Teil von Vispero. Dominierend in US-Unternehmen und -Behörden.
• NVDA (NonVisual Desktop Access), führender kostenloser quelloffener Windows-Screenreader, erstmals im April 2006 von Michael Curran und James Teh (beide selbst blind) veröffentlicht. Die gemeinnützige Organisation NV Access wurde Anfang 2007 gegründet. NVDAs Wachstum war im vergangenen Jahrzehnt der auffälligste Trend auf dem Screenreader-Markt.
• VoiceOver: in Apples Betriebssysteme eingebaut. Debütierte in Mac OS X 10.4 Tiger (2005); mit dem iPhone 3GS (2009) zu iOS hinzugefügt. Wird heute auf macOS, iOS, iPadOS, tvOS und watchOS ausgeliefert.
• TalkBack: der entsprechende eingebaute Screenreader auf Android, gepflegt von Google.

Weitere assistive Technologien im breiteren Ökosystem: Bildschirmlupen (ZoomText für Windows, die eingebaute macOS-Lupe), Spracherkennungssoftware (Dragon NaturallySpeaking), Schaltergeräte für Nutzer mit eingeschränkter Motorik, alternative Tastaturen und Kopfzeiger, Eye-Tracking-Systeme und aktualisierbare Braillezeilen. Die WCAG-Kriterien adressieren all diese, auch wenn die Seite nur an Screenreader denkt.

Farbkontrast, das WCAG-2-Modell und der APCA-Kandidat

WCAG 2.x misst den Kontrast als Leuchtdichteverhältnis zwischen zwei Farben, eine Zahl von 1:1 (kein Kontrast) bis 21:1 (reines Weiß auf reinem Schwarz). Die Schwellen: Stufe AA, normaler Text 4,5:1; großer Text (18 pt oder 14 pt fett) 3:1; Stufe AAA, normaler Text 7:1; großer Text 4,5:1. Der §1.4.11 Nicht-Text-Kontrast von WCAG 2.1 fügte auf Stufe AA eine Anforderung von 3:1 für UI-Komponenten und grafische Objekte hinzu, die Informationen vermitteln.

Das Leuchtdichteverhältnis-Modell hat bekannte Schwächen, insbesondere, dass es den wahrgenommenen Kontrast dunkler Farben überbewertet, ein 4,5:1-Paar zweier dunkler Farben kann funktional unlesbar sein, obwohl es technisch besteht. APCA (Accessible Perceptual Contrast Algorithm), entwickelt von Andrew Somers, ist ein wahrnehmungsbasierter Ersatz, der für selbstleuchtende Displays konzipiert ist. Es ist die Kandidaten-Kontrastmethode für WCAG 3.0, derzeit nicht Teil einer veröffentlichten WCAG-Version. APCA erzeugt eine vorzeichenbehaftete Zahl auf etwa einer Skala von -108 bis +108 (negativ, wenn heller Text auf dunklem Hintergrund sitzt). Fachleute, die 2026 etwas veröffentlichen, sollten weiterhin gegen die WCAG-2.x-Verhältnisse als gesetzliche Anforderung testen und APCA-Werte als ergänzende Wahrnehmungs-Plausibilitätsprüfungen behandeln.

Der Stand des Feldes, in Zahlen

Die meistzitierte jährliche Momentaufnahme ist WebAIMs Million-Bericht, der seit 2019 automatisierte Barrierefreiheitsprüfungen an den Startseiten der eine Million wichtigsten Websites weltweit durchführt. Die Ausgabe WebAIM Million 2026, veröffentlicht im März 2026, ist zum Zeitpunkt des Schreibens die jüngste. 95,9 % der Startseiten wiesen festgestellte WCAG-2-Mängel auf (gegenüber 94,8 % im Jahr 2025, die erste Umkehr eines sechsjährigen Verbesserungstrends). Die durchschnittliche Seite hatte 56,1 festgestellte Barrierefreiheitsfehler, ein Anstieg von 10,1 % gegenüber dem Vorjahr. Die sechs häufigsten Fehlerarten machen etwa 96 % aller festgestellten Probleme aus:

1. Text mit geringem Kontrast: 83,9 % der Seiten, durchschnittlich ~34 Vorkommen pro Seite
2. Fehlender Alternativtext bei Bildern, 53,1 %
3. Fehlende Formularbeschriftungen: 51,0 %
4. Leere Links: 46,3 %
5. Leere Schaltflächen: 30,6 %
6. Fehlende Dokumentsprachen-Deklaration: 13,5 %

Zum Hintergrund: 1,3 Milliarden Menschen weltweit) etwa 16 % der Weltbevölkerung, also rund 1 von 6, leben mit einer erheblichen Behinderung, laut dem zuletzt am 7. März 2023 aktualisierten Informationsblatt der Weltgesundheitsorganisation.

Woher die Ressourcen in diesem Verzeichnis stammen

Das obige Verzeichnis schöpft aus der kleinen Zahl von Organisationen und Projekten, die das Feld faktisch bestimmen:

• W3C Web Accessibility Initiative (WAI). Das Normungsgremium selbst. Die beiden aktivsten Arbeitsgruppen für Website-Teams sind die Accessibility Guidelines Working Group (die WCAG pflegt) und die ARIA Working Group (die WAI-ARIA pflegt). Die WAI veröffentlicht Überblicksseiten, vertiefende technische Spezifikationen, die Quick Reference und kostenlose Bildungskurse auf edX.
• WebAIM (Web Accessibility In Mind). 1999 am Center for Persons with Disabilities der Utah State University gegründet. Betreibt das Evaluationswerkzeug WAVE, führt die Screen Reader User Survey und die WebAIM Million durch und veröffentlicht eine der meistkonsultierten Bibliotheken praktischer Barrierefreiheitsartikel im Web.
• Deque Systems. 1999 gegründet, mit Sitz in Herndon, Virginia. Herausgeber der Regel-Engine axe-core, die das Unternehmen im Juni 2015 quelloffen machte. Deque betreibt zudem die Deque University und produziert die Browser-Erweiterung axe DevTools, die heute der Industriestandard für automatisiertes Testen ist.
• A11Y Project. Eine von der Gemeinschaft getragene, quelloffene Ressourcen- und Mustersammlung, gegründet 2013. Am bekanntesten für seine weit verbreitete Barrierefreiheits-Checkliste; die gesamte Website liegt auf GitHub für Beiträge der Gemeinschaft.
• International Association of Accessibility Professionals (IAAP). Berufsverband, gegründet am 19. März 2014, wurde im Juli 2016 eine Abteilung von G3ict. Vergibt die anerkannten Branchenzertifizierungen (CPACC, WAS, CPWA, ADS).
• MDN Web Docs. Mozillas Entwicklerreferenz, einschließlich des gepflegten Abschnitts zur Barrierefreiheit, der ARIA, Semantik und Barrierefreiheitsmuster aus dem Blickwinkel der Entwickler-Umsetzung dokumentiert.

All dies zusammengenommen: Die praktische Antwort auf die Frage „welchen Standard sollte ich einhalten“ lautet 2026 WCAG 2.1 AA als Untergrenze (weil die meisten Gesetze ihn noch zitieren) und WCAG 2.2 AA als zukunftsgerichtetes Ziel. Die praktische Antwort beim Testwerkzeug ist axe DevTools für die Automatisierung plus ein echter Screenreader (NVDA + Chrome unter Windows, VoiceOver + Safari unter macOS) für die Teile, die kein automatisiertes Werkzeug erfassen kann, Deque selbst beschreibt axe so, dass es „bis zu 80 % der Probleme“ erfasst, und die meisten unabhängigen Schätzungen beziffern die automatisierte Erkennung auf 30-50 % der gesamten WCAG-Konformität. Manuelles Testen mit einem echten Screenreader ist weiterhin erforderlich.