Im Jahr 2025 reichten Kläger 3.117 Klagen wegen Website-Barrierefreiheit gemäß ADA Title III vor Bundesgerichten ein – ein Anstieg von 27 Prozent gegenüber 2024 und der höchste Jahreswert seit 2022. Rechnet man die Einreichungen bei staatlichen Gerichten hinzu, übersteigt die Gesamtzahl 5.000. Selbst diese Schlagzeile unterschätzt den Druck: Verteidiger schätzen, dass im vergangenen Jahr 35.000 bis 50.000 Abmahnschreiben wegen mangelnder Barrierefreiheit an US-Unternehmen verschickt wurden, von denen die meisten privat für Beträge zwischen 1.000 und 25.000 US-Dollar beigelegt werden, ohne jemals in einem Gerichtsregister zu erscheinen.
Wenn Ihr Unternehmen eine Website, eine mobile App, einen Online-Shop, ein Buchungs-Widget oder ein Kundenportal betreibt, sind Sie nun ein realistisches Ziel. Und Serienkläger beschränken sich nicht mehr auf eine kleine Gruppe von Wiederholungstätern – etwa 40 Prozent der ADA Title III-Einreichungen auf Bundesebene im Jahr 2025 stammten von selbstvertretenden Einzelpersonen, von denen viele KI-gestützte Scanner nutzen, um potenzielle Beklagte zu identifizieren und Beschwerdeschriften in Minutenschnelle zu entwerfen.
Dieser Leitfaden erläutert, was ADA Title III tatsächlich für digitale Erlebnisse erfordert, warum WCAG 2.1 Level AA zum De-facto-Benchmark geworden ist, wie eine Roadmap zur Behebung aussieht und wie man eine verteidigungsfähige Dokumentation aufbaut, bevor ein Abmahnschreiben eintrifft.
Warum Ihre Website jetzt in den Geltungsbereich von ADA Title III fällt
Titel III des Americans with Disabilities Act verbietet Diskriminierung aufgrund von Behinderungen an Orten öffentlicher Zugänglichkeit. Das Gesetz wurde 1990 verfasst und erwähnte Websites oder mobile Apps nie explizit – aber die Gerichte haben das letzte Jahrzehnt damit verbracht, diese Unklarheit aufzulösen, fast immer zugunsten der Kläger.
Das Erbe von Robles gegen Domino's Pizza
Der wichtigste Einzelfall ist Robles gegen Domino's Pizza. Guillermo Robles, ein blinder Kläger in Kalifornien, verklagte Domino's im Jahr 2016, nachdem er festgestellt hatte, dass er die Website und die mobile App der Pizzakette nicht mit einem Screenreader nutzen konnte. Das Bezirksgericht wies den Fall zunächst aus rechtsstaatlichen Gründen ab, mit der Begründung, dass Domino's ohne veröffentlichte Vorschriften zur Web-Barrierefreiheit keinen angemessenen Hinweis darauf hatte, was die Compliance erforderte.
Der Neunte Berufungshof hob diese Entscheidung im Jahr 2019 auf. Das Gericht entschied, dass Titel III die Website und App von Domino's abdeckte, da sie einen Nexus zu einem physischen Ort öffentlicher Zugänglichkeit (den Pizzerien) hatten, und dass die Auferlegung einer Haftung auch ohne veröffentlichte technische Standards nicht gegen rechtsstaatliche Grundsätze verstieß. Der Oberste Gerichtshof lehnte eine Überprüfung der Entscheidung des Neunten Berufungshofs später in jenem Jahr ab, womit die Regelung bestehen blieb. Domino's einigte sich schließlich im Juni 2022 nach sechs Jahren Rechtsstreit auf einen Vergleich.
Die praktische Folge ist, dass jedes Unternehmen mit einem physischen Standort – und in vielen Gerichtsbezirken sogar rein online tätige Unternehmen – nun einem realen Risiko durch eine nicht barrierefreie Website ausgesetzt ist.
Die Title II-Regel des DOJ von 2024 und ihre Auswirkungen auf Title III
Im April 2024 veröffentlichte das Justizministerium (DOJ) eine endgültige Regelung gemäß Titel II des ADA, die verlangt, dass Websites und mobile Apps von Bundesstaaten und Kommunalverwaltungen dem Standard WCAG 2.1 Level AA entsprechen. Obwohl diese Regel formal nur öffentliche Stellen bindet, begannen Kläger und Gerichte sofort damit, sie als die maßgeblichste bundesweite Artikulation dessen zu zitieren, was „barrierefrei“ bedeutet.
Für ein privates Unternehmen änderte sich das rechtliche Kalkül über Nacht. Selbst wenn Titel III immer noch keinen veröffentlichten technischen Standard hat, kann ein Kläger nun auf eine verbindliche Bundesverordnung verweisen, die WCAG 2.1 Level AA als Standard für wesentlich ähnliche Titel II-Einheiten nennt. Die meisten Verteidiger raten ihren Titel III-Mandanten nun, WCAG 2.1 Level AA als Mindestanforderung zu betrachten.
Was WCAG 2.1 Level AA tatsächlich erfordert
Die WCAG – Web Content Accessibility Guidelines, gepflegt vom World Wide Web Consortium – sind um vier Prinzipien herum organisiert, die praktischerweise durch das Akronym POUR zusammengefasst werden: Perceivable (Wahrnehmbar), Operable (Bedienbar), Understandable (Verständlich) und Robust. Level AA umfasst jedes Erfolgskriterium von Level A plus zusätzliche AA-spezifische Kriterien. Es gibt insgesamt 50 Erfolgskriterien auf Level AA, aber eine Handvoll verursacht den überwältigenden Teil der Abmahnschreiben.
Farbkontrast (1.4.3 und 1.4.11)
Fließtext muss ein Kontrastverhältnis von mindestens 4,5:1 gegenüber seinem Hintergrund aufweisen. Großer Text (18 Punkt oder 14 Punkt fett) benötigt mindestens 3:1. Schaltflächen, Rahmen von Formularfeldern, Fokus-Indikatoren und andere interaktive grafische Elemente müssen 3:1 gegenüber angrenzenden Farben einhalten. Viele Abmahnschreiben haben hier ihren Ursprung, da automatisierte Scanner Kontrastfehler in Sekunden erkennen.
Textalternativen für Nicht-Text-Inhalte (1.1.1)
Jedes Bild, Icon, Diagramm, Foto und jede Grafik, die eine Bedeutung trägt, benötigt ein Alt-Attribut, das dieselbe Information vermittelt. Dekorative Bilder erhalten ein leeres Alt-Attribut (alt=""), damit Screenreader sie überspringen. Logos sollten die Marke beschreiben. Diagramme und Infografiken benötigen eine längere Textentsprechung in der Nähe oder verlinkt. Icons für Formulareingaben benötigen Beschriftungen. CAPTCHAs benötigen eine Audio-Alternative.
Tastaturbedienbarkeit (2.1.1, 2.1.2, 2.4.3, 2.4.7)
Jedes interaktive Element — Menüs, modale Dialoge, Karussells, Akkordeons, Tabs, benutzerdefinierte Dropdowns — muss ausschließlich über die Tastatur erreichbar und bedienbar sein. Benutzer dürfen niemals innerhalb eines Widgets gefangen sein, ohne einen Ausweg zu finden (der klassische Fehler: ein modales Fenster, das sich ohne Maus nicht schließen lässt). Die Fokus-Reihenfolge muss logisch sein, und ein sichtbarer Fokus-Indikator muss jederzeit anzeigen, wo auf der Seite sich der Benutzer befindet.
Formularbeschriftungen, Fehler und Anweisungen (1.3.1, 3.3.1, 3.3.2, 3.3.3, 3.3.4)
Jedes Formulareingabefeld benötigt eine programmatisch zugeordnete Beschriftung (ein <label for="">-Element oder aria-label). Fehlermeldungen müssen identifizieren, welches Feld fehlerhaft ist und wie der Fehler behoben werden kann. Bei Formularen mit hohen Auswirkungen (Checkout, Kontoerstellung, rechtliche Anerkennungen) müssen Benutzer die Möglichkeit haben, ihre Eingaben vor dem Absenden zu überprüfen und zu korrigieren.
Untertitel und Audiobeschreibungen (1.2.2, 1.2.5)
Voraufgezeichnete Videos benötigen synchronisierte Untertitel. Wenn wesentliche Informationen visuell und nicht über die Tonspur vermittelt werden, sind zusätzlich Audiobeschreibungen erforderlich. Live-Videos auf Level AA erfordern Live-Untertitel.
Überschriftenstruktur und Landmarks (1.3.1, 2.4.6)
Überschriften müssen einer logischen Hierarchie folgen (h1 → h2 → h3, ohne willkürliches Überspringen von Ebenen). Verwenden Sie semantische HTML-Elemente — <nav>, <main>, <header>, <footer> — oder ARIA-Landmarks, damit Screenreader-Benutzer direkt zu dem gewünschten Abschnitt springen können. Vermeiden Sie es, ein <div> so zu stylen, dass es wie eine Überschrift aussieht, ohne ihm die entsprechende semantische Rolle zuzuweisen.
Größenanpassung und Reflow (1.4.4, 1.4.10)
Text muss bei einem Zoom von 200 Prozent lesbar bleiben, ohne dass horizontales Scrollen erforderlich ist. Layouts müssen in einem Viewport von 320 CSS-Pixeln umbrechen (Reflow), ohne dass zweidimensionales Scrollen entsteht.
Schwerpunkte der Rechtsstreitigkeiten
Drei Bundesdistrikte in den USA machen den Großteil der Klagen zur Barrierefreiheit von Websites aus: der Southern District of New York, der Central District of California und der Southern District of Florida. New York führt mit großem Abstand, unter anderem weil das New York State Human Rights Law und das New York City Human Rights Law zusätzliche staatliche rechtliche Anknüpfungspunkte bieten und niedrigere Hürden für die Klagebegründung haben als bundesstaatliche ADA-Ansprüche (Americans with Disabilities Act).
Kalifornien ergänzt dies durch den Unruh Civil Rights Act, der einen gesetzlich festgelegten Schadensersatz von 4.000 US-Dollar pro Verstoß und Kläger vorsieht. Dies verändert die Vergleichskalkulation drastisch — eine kleine Forderung kann schnell zu einem sechsstelligen Risiko werden, wenn eine Sammelklage zertifiziert wird.
Florida hat sich seit 2020 als drittes Zentrum herauskristallisiert, wobei eine Handvoll Anwaltskanzleien auf Klägerseite spezialisierte Praktiken mit hohen Fallzahlen entwickelt haben, die auf Restaurantketten, Hotelmarken und Direct-to-Consumer-E-Commerce-Shops abzielen.
Erstellung eines Fahrplans zur Fehlerbehebung
Wenn Sie ein Aufforderungsschreiben erhalten — oder, besser noch, wenn Sie handeln, bevor eines eintrifft — gliedert sich die Arbeit in etwa fünf Phasen. Betrachten Sie dies als Projekt mit Budget und Deadline, nicht als einmaliges Audit.
Phase 1: Automatisierte und manuelle Prüfung
Beginnen Sie mit einem automatisierten Scan mit Tools wie axe DevTools, WAVE oder Google Lighthouse. Automatisierte Tools finden etwa 30 bis 50 Prozent der WCAG-Fehler — der Rest erfordert manuelle Tests mit einem Screenreader (NVDA unter Windows, VoiceOver unter macOS und iOS, TalkBack unter Android), reine Tastaturnavigation sowie Tests zur Größenanpassung und zum Reflow.
Dokumentieren Sie jeden Fehler mit dem verletzten WCAG-Kriterium, der betroffenen Seite oder Vorlage, dem Schweregrad und dem geschätzten Aufwand zur Behebung. Dieses Audit-Protokoll wird zum Rückgrat jeder weiteren Phase.
Phase 2: Designsystem- und Komponenten-Fixes
Die meisten der am häufigsten auftretenden Fehler befinden sich in Ihrem Designsystem: Schaltflächenkontrast, Fokus-Indikatoren, Formulareingaben, Modal-Muster, Karussell-Steuerungen, Navigationsmenüs. Wenn Sie eine Komponente einmal reparieren, beheben Sie jeden Anwendungsfall davon. Priorisieren Sie die Komponenten, die auf den meisten Seiten erscheinen.
Phase 3: Inhaltsüberprüfung
Alt-Texte, Video-Untertitel, Überschriftenstrukturen und Formularbeschriftungen sind in der Regel Korrekturen auf Inhaltsebene, die die meisten Vorlagen und Seiten betreffen. Erstellen Sie eine Inhalts-Checkliste, der Autoren für jede neue Seite folgen müssen, und einen Backlog-Punkt für die rückwirkende Korrektur bestehender Seiten.
Phase 4: Koordination von Drittanbietern
Die meisten modernen Websites betten Widgets von Drittanbietern ein: Zahlungsformulare, Live-Chats, Buchungskalender, Videoplayer, Analyse-Overlays, Review-Widgets und Pop-ups zur E-Mail-Erfassung. Jedes dieser Elemente kann eigene Barrierefreiheitsfehler verursachen, und die Gerichte haben im Allgemeinen entschieden, dass ein Unternehmen für die Barrierefreiheit des von ihm eingebetteten Codes von Drittanbietern verantwortlich ist.
Fordern Sie von jedem Anbieter ein aktuelles VPAT (Voluntary Product Accessibility Template) oder einen Accessibility Conformance Report an. Überprüfen Sie, ob die bereitgestellte Version WCAG 2.1 Level AA entspricht. Drängen Sie Anbieter, die dies nicht erfüllen, zur Nachbesserung oder tauschen Sie sie aus.
Phase 5: Erklärung zur Barrierefreiheit und Feedback-Kanal
Veröffentlichen Sie eine klar verlinkte Erklärung zur Barrierefreiheit, die den Standard nennt, den Sie anstreben (in der Regel WCAG 2.1 Level AA), die bekannten Einschränkungen aufführt und einen Kontaktkanal (E-Mail und Telefon) für Benutzer bereitstellt, um Barrieren zu melden. Die Erklärung bietet keine rechtliche Immunität, dokumentiert jedoch guten Glauben (Good Faith) und gibt denjenigen, die auf Abmahnschreiben reagieren müssen, eine konkrete Grundlage.
Ein Wort zu Barrierefreiheits-Overlays
Eine boomende Branche von „Barrierefreiheits-Overlay“-Tools – JavaScript-Widgets, die eine sofortige WCAG-Konformität durch eine einzige Codezeile versprechen – behauptet, Barrierefreiheit schnell und günstig zu lösen. Die Realität ist komplizierter. Overlays wurden in Dutzenden von Gerichtsverfahren als Ursache für Barrierefreiheitsprobleme genannt, da sie die assistierenden Technologien der Nutzer beeinträchtigen. Mehrere Gerichte haben das Argument zurückgewiesen, dass ein Overlay allein ausreicht, um einen Title-III-Anspruch abzuwehren.
Overlays können eine Rolle als Ergänzung zur zugrunde liegenden Fehlerbehebung spielen – für Nutzer, die ihre eigenen Präferenzen über eine bereits barrierefreie Seite legen möchten –, aber sie sind kein Ersatz für die Korrektur des zugrunde liegenden Codes. Klägerkanzleien nehmen mittlerweile gezielt Websites ins Visier, auf denen bestimmte Overlay-Produkte laufen.
Alles für die Verteidigung dokumentieren
Wenn ein Forderungsschreiben eintrifft, hängt Ihre Verteidigungsstrategie fast ausschließlich davon ab, was Sie über Ihr Barrierefreiheitsprogramm zum Zeitpunkt des mutmaßlichen Verstoßes beweisen können. Erstellen Sie eine lückenlose Dokumentation, die Folgendes umfasst:
- Datierte Audit-Berichte mit Umfang und Ergebnissen
- Behebungstickets mit Abschlussdatum
- VPATs von Anbietern und Berichte zur Barrierefreiheitskonformität
- Schulungsnachweise für Designer und Entwickler
- Interne Checklisten zur Überprüfung der Barrierefreiheit bei Produkteinführungen
- Ein Änderungsprotokoll für die Barrierefreiheitserklärung
- Nutzerfeedback, das über Ihren Kontaktkanal für Barrierefreiheit eingegangen ist, sowie Ihre Reaktion darauf
Diese Aufzeichnungen verhindern keine Klagen, aber sie verändern die Vergleichsverhandlungen dramatisch. Ein Kläger, der auf einen schnellen Vergleich in Höhe von 10.000 $ wegen einer Bagatelle hofft, ist weit weniger interessiert, wenn der Beklagte ein aktuelles Audit, einen dokumentierten Backlog bei der Fehlerbehebung und ein Anbieter-VPAT für jedes eingebettete Widget vorlegen kann.
Die buchhalterische Seite der Barrierefreiheits-Konformität
Die Behebung von Barrierefreiheitsmängeln ist selten eine einmalige Ausgabe. In Ihren Büchern erscheint sie in der Regel als wiederkehrender Aufwand – Rechnungen von Agenturen oder Auftragnehmern für Audits, Softwarelizenzen für Test-Tools und Überwachungsdienste, Kosten für den Neuaufbau von Design-Systemen, Kosten für den Anbieterwechsel und die unvermeidlichen Vergleiche bei Forderungsschreiben, die trotz Ihrer besten Bemühungen durchrutschen.
Die getrennte Erfassung dieser Ausgaben von allgemeinen Marketing- oder Entwicklungskosten macht einiges einfacher. Sie erhalten einen klaren Überblick über die tatsächlichen Compliance-Kosten im Zeitverlauf, was bei der Budgetierung des Programms für das nächste Jahr hilft. Sie dokumentieren die Ausgaben, falls Sie später einen Abzug geltend machen oder eine aktivierte Website-Verbesserung abschreiben müssen. Und falls Sie jemals mit einer Sammelklage eines Serienklägers konfrontiert werden, können Sie schnell einen Finanzbericht über Ihre Investitionen in die Barrierefreiheit vorlegen – nützlich sowohl bei Vergleichsverhandlungen als auch bei einer Verteidigung durch den Nachweis angemessener Anpassungen.
Ein einfaches Kontenrahmen-Segment für „Barrierefreiheits-Compliance“ mit Unterkategorien für Audits, Arbeitsaufwand für die Behebung, Test-Tools, Due-Diligence-Prüfung von Anbietern und Rückstellungen für Vergleiche ist sehr hilfreich. Kombinieren Sie dies mit vierteljährlichen Überprüfungen, damit das Programm nicht stillschweigend aus dem Budget verschwindet.
Häufige Fehler, die vermieden werden sollten
Einige Muster tauchen in fast jedem Forderungsschreiben auf, das ich von Geschäftsinhabern sehe.
Barrierefreiheit als einmaliges Projekt behandeln. Websites ändern sich ständig. Eine neue Produktseite, ein neu gestalteter Checkout, ein eingebetteter Chatbot – all dies kann neue Fehler verursachen. Verankern Sie Barrierefreiheit in Ihrem Entwicklungszyklus, sodass jede Änderung vor der Veröffentlichung überprüft wird.
Sich ausschließlich auf automatisierte Scans verlassen. Automatisierte Tools finden nur eine Minderheit der WCAG-Fehler. Manuelle Tests mit assistierenden Technologien sind der einzige Weg, um Probleme wie eine unlogische Fokus-Reihenfolge, irreführende Alternativtexte oder unbrauchbare benutzerdefinierte Widgets zu finden.
Mobile Apps ignorieren. Title-III-Kläger reichen zunehmend Doppelklagen ein, die sowohl die Website als auch die native mobile App abdecken. iOS und Android haben jeweils ihre eigenen Barrierefreiheits-APIs (UIAccessibility und TalkBack/AccessibilityService), und es gelten die gleichen WCAG-Prinzipien, erfordern jedoch plattformspezifische Tests.
PDFs vergessen. Steuerformulare, Whitepaper, Menüs und herunterladbare Ressourcen, die auf Ihrer Website gehostet werden, fallen alle in den Geltungsbereich. PDFs benötigen eine korrekte Lesereihenfolge, Tags, Alternativtexte und Beschriftungen für Formularfelder, genau wie HTML-Seiten.
Annehmen, dass eine Drittanbieter-Plattform dies für Sie erledigt. Shopify, WordPress, Wix, Squarespace und ähnliche Plattformen bieten ein gewisses Grundgerüst für Barrierefreiheit, aber die Wahl des Themes, benutzerdefinierter Code, eingebettete Widgets und die von Ihnen veröffentlichten Inhalte liegen weiterhin in Ihrer Verantwortung. Einem Forderungsschreiben ist es egal, ob ein Theme vorgefertigt war.
Die Barrierefreiheitserklärung auslassen. Die Veröffentlichung kostet nichts und ist ein nachweisbarer Beleg für guten Willen. Das Fehlen einer solchen Erklärung wird in Beschwerden manchmal ausdrücklich angeführt.
Halten Sie Ihre Compliance-Finanzen vom ersten Tag an organisiert
Während Sie Ihr Barrierefreiheitsprogramm aufbauen, müssen die unterstützenden Finanzunterlagen – Audit-Rechnungen, Anbieterverträge, Behebungsarbeiten, Schulungskosten und Rückstellungen für Vergleiche – an einem Ort liegen, an dem Sie sie auch in Jahren noch finden können, falls ein Serienkläger Ihr Unternehmen benennt. Beancount.io bietet Plain-Text-Accounting, das Ihnen vollständige Transparenz und eine versionskontrollierte Historie über jeden Posten bietet, ohne Blackboxen und ohne Vendor-Lock-in. Starten Sie kostenlos und erfahren Sie, warum Entwickler, Finanzteams und Compliance-bewusste Betreiber auf Plain-Text-Accounting setzen, um eine prüfungssichere Aufzeichnung zu führen.