ADA Title III Checkliste für Website-Konformität

Die rechtliche Grundlage: ADA Title III und Websites

Title III des Americans with Disabilities Act verbietet Diskriminierung aufgrund einer Behinderung in öffentlich zugänglichen Einrichtungen. Der ADA wurde 1990 erlassen, bevor das kommerzielle Web existierte — was jahrzehntelange Rechtsstreitigkeiten darüber ausgelöst hat, ob Websites als „öffentlich zugängliche Einrichtungen” gelten.

Die aktuelle Rechtslage hat diese Frage weitgehend im Sinne der Inklusion geklärt. Die Mehrheit der Bundesgerichte, die sich mit der Frage befasst haben, hat entschieden, dass Websites von Unternehmen, die öffentlich zugänglich sind, unter Title III fallen. Das Department of Justice (DOJ) veröffentlichte im März 2022 eine formelle Leitlinie, die bestätigt, dass der ADA auf Websites anwendbar ist. Im April 2024 veröffentlichte das DOJ eine endgültige Regel unter Title II (für staatliche und lokale Behörden), die ausdrücklich WCAG 2.1 Level AA übernimmt — ein starkes Signal dafür, was Title III letztlich kodifizieren wird.

Das praktische Ergebnis: Wenn Sie eine Website betreiben, über die Kunden Waren, Dienstleistungen oder Informationen erhalten, gilt ADA Title III für diese Website.

Was „barrierefrei” nach dem ADA bedeutet

Der ADA definiert keinen spezifischen technischen Standard für Website-Barrierefreiheit. Gerichte und das DOJ haben die Konformität mit den Web Content Accessibility Guidelines (WCAG) 2.1 Level AA durchgängig als Maßstab dafür behandelt, ob eine Website die Nichtdiskriminierungspflicht des ADA erfüllt. WCAG 2.1 AA ist der Standard, der in fast allen Vergleichsvereinbarungen des DOJ und den meisten gerichtlich überwachten Konformitätsplänen verwendet wird.

Die folgende Checkliste ordnet die wichtigsten WCAG-2.1-AA-Erfolgskriterien praktischen Konformitätspflichten zu.

---

ADA Title III Checkliste für Website-Konformität

1. Textalternativen für Nicht-Text-Inhalte

• Jedes bedeutungstragende Bild hat ein alt-Attribut, das seinen Zweck vermittelt
• Dekorative Bilder haben ein leeres alt="", damit Screenreader sie überspringen
• Icons, die als Schaltflächen oder Links verwendet werden, haben zugängliche Namen (über aria-label oder sichtbaren Text)
• Diagramme und Infografiken haben Textbeschreibungen oder Datentabellen als Alternative
• CAPTCHA bietet neben der visuellen Aufgabe eine Audio-Alternative

Warum das wichtig ist: Screenreader-Nutzende erhalten ohne Alternativtext keine Information über ein Bild. Eine Bezahlen-Schaltfläche, die nur mit einem Icon und ohne zugänglichen Namen versehen ist, ist für Screenreader-Nutzende faktisch unsichtbar.

2. Untertitel und Transkripte für Medien

• Vorab aufgezeichnete Videos haben synchronisierte Untertitel
• Live-Videostreams haben Echtzeit-Untertitel
• Vorab aufgezeichnete reine Audioinhalte (Podcasts) haben ein Text-Transkript
• Vorab aufgezeichnete Videos mit wichtigem Audioinhalt haben ein verfügbares Transkript
• Automatisch erstellte Untertitel werden vor der Veröffentlichung überprüft und korrigiert

Warum das wichtig ist: Untertitel sind das wichtigste Mittel, mit dem gehörlose und schwerhörige Nutzende auf Videoinhalte zugreifen. Ungenaue automatisch erstellte Untertitel erfüllen die Anforderung nicht.

3. Farbe und visuelles Design

• Informationen werden niemals ausschließlich durch Farbe vermittelt (z. B. werden Pflichtfelder mit Text oder einem Icon markiert, nicht nur mit einem roten Rand)
• Normaler Text (unter 18pt / 14pt fett) erreicht ein Kontrastverhältnis von mindestens 4,5:1 gegenüber dem Hintergrund
• Großer Text (18pt+ oder 14pt+ fett) erreicht ein Kontrastverhältnis von mindestens 3:1
• UI-Komponenten (Schaltflächen, Eingabefelder, Fokusindikatoren) haben mindestens 3:1 Kontrast gegenüber angrenzenden Farben
• Fehlerzustände werden in Text kommuniziert, nicht nur durch eine Farbänderung

Warum das wichtig ist: Etwa 8 % der Männer und 0,5 % der Frauen haben eine Form von Farbfehlsichtigkeit. Sich allein auf Farbe zu verlassen schließt einen erheblichen Teil Ihrer Nutzenden aus.

4. Tastaturbedienbarkeit

• Alle interaktiven Elemente (Links, Schaltflächen, Formulare, Menüs, Modals, Datumsauswahl) sind ausschließlich per Tastatur erreichbar und bedienbar
• Die Tab-Reihenfolge folgt einer logischen, vorhersehbaren Abfolge
• Keine Tastaturfallen — Nutzende können jede Komponente mit Standardtasten betreten und verlassen
• Benutzerdefinierte Widgets (Dropdowns, Schieberegler, Dialoge) implementieren die erwarteten Tastaturinteraktionsmuster
• Ein „Zum Hauptinhalt springen”-Link ist das erste fokussierbare Element auf jeder Seite

Warum das wichtig ist: Nutzende mit motorischen Einschränkungen, von denen viele auf Tastaturnavigation oder Switch-Access-Geräte angewiesen sind, können keine Maus verwenden. Eine Website, die für zentrale Funktionen eine Maus voraussetzt, ist für sie unzugänglich.

5. Sichtbarkeit des Fokus

• Der Tastaturfokus ist stets sichtbar — ein klarer Fokusindikator (Umrandung, Hervorhebung, Unterstreichung) erscheint auf dem aktiven Element
• Der Fokusindikator wird nicht ohne Ersatz durch outline: none oder outline: 0 unterdrückt
• Der Fokusindikator hat ausreichenden Kontrast gegenüber dem umgebenden Inhalt

Warum das wichtig ist: Ohne sichtbaren Fokusindikator können Tastaturnutzende nicht erkennen, wo sie sich auf der Seite befinden — vergleichbar mit dem Surfen ohne Cursor.

6. Keine Inhalte, die Anfälle auslösen können

• Kein Inhalt blitzt mehr als dreimal pro Sekunde
• Nicht deaktivierbare Animationen erstrecken sich nicht mit hoher Frequenz über große Teile des Bildschirms
• Parallax-Effekte und automatisch abspielende Animationen lassen sich über die Media-Query prefers-reduced-motion pausieren oder reduzieren

Warum das wichtig ist: Photosensitive Epilepsie betrifft einen erheblichen Teil der Bevölkerung. Eine einzelne blinkende Werbeanzeige kann einen Anfall auslösen.

7. Genug Zeit, um Aufgaben abzuschließen

• Sitzungs-Timeouts warnen Nutzende vor dem Ablauf und bieten eine Möglichkeit, die Sitzung zu verlängern
• Automatisch aktualisierte Inhalte (Newsticker, Live-Ergebnisse, rotierende Banner) lassen sich pausieren, stoppen oder ausblenden
• Für kritische Aufgaben (Bezahlvorgang, Formularübermittlung) gelten keine Zeitlimits ohne einen angemessenen Verlängerungsmechanismus

Warum das wichtig ist: Nutzende mit kognitiven Einschränkungen, motorischen Beeinträchtigungen oder Nutzende assistiver Technologie brauchen oft mehr Zeit, um Aufgaben abzuschließen. Abrupte Timeouts können zu verlorenem Fortschritt führen.

8. Navigation und Orientierung

• Jede Seite hat ein eindeutiges, beschreibendes <title>-Element
• Navigationsmenüs sind über Seiten hinweg in Struktur und Position konsistent
• Die aktuelle Seitenposition wird in der Navigation angezeigt (aktiver Zustand)
• Breadcrumb-Pfade sind auf tiefen Seiten vorhanden
• Es gibt mehrere Wege, Inhalte zu finden (Suche, Sitemap oder Navigation)
• Überschriften sind logisch strukturiert (h1 → h2 → h3) und beschreiben den Abschnittsinhalt genau

Warum das wichtig ist: Screenreader-Nutzende navigieren über Überschriften, Landmarks und Seitentitel. Schlecht strukturierte Überschriften machen eine Seite für jemanden, der mit einem Screenreader navigiert, unverständlich.

9. Barrierefreiheit von Formularen

• Jedes Formularfeld hat ein sichtbares, programmatisch zugeordnetes <label>-Element
• Pflichtfelder werden in Text kenntlich gemacht (nicht nur durch ein Sternchen ohne Erklärung)
• Fehlermeldungen identifizieren, welches Feld den Fehler enthält, und beschreiben, wie er zu beheben ist
• Fehlermeldungen werden Screenreader-Nutzenden angesagt (über aria-live oder Fokusmanagement)
• Autocomplete-Attribute sind bei gängigen Eingabefeldern vorhanden (Name, E-Mail, Adresse, Kreditkarte)
• Die Formularübermittlung läuft nicht stillschweigend ab

Warum das wichtig ist: Formulare sind der Weg, über den Nutzende mit Ihrem Dienst interagieren — Buchen, Kaufen, Registrieren, Kontaktieren. Ein unzugänglicher Bezahlvorgang ist das digitale Äquivalent eines Ladens ohne Rampe.

10. Links und Schaltflächen

• Jeder Link hat einen beschreibenden zugänglichen Namen — „Mehr lesen” allein reicht nicht aus; „Mehr über [Thema] lesen” schon
• Links und Schaltflächen sind vom umgebenden Text unterscheidbar, ohne sich allein auf Farbe zu verlassen
• Schaltflächen, die Aktionen auslösen, sind als <button>-Elemente markiert, nicht als gestylte <div>- oder <span>-Elemente
• Links, die einen neuen Tab öffnen oder einen Download auslösen, kommunizieren dies den Nutzenden

Warum das wichtig ist: Screenreader-Nutzende überfliegen Seiten oft, indem sie sich alle Links einer Seite auflisten lassen. Eine Liste aus „hier klicken”- und „mehr lesen”-Links bietet keinen Navigationswert.

11. Sprache und Lesbarkeit

• Die Hauptsprache der Seite ist im lang-Attribut des <html>-Elements festgelegt (z. B. lang="de")
• Abschnitte in einer anderen Sprache sind mit einem lang-Attribut am umschließenden Element markiert
• Abkürzungen werden bei erster Verwendung ausgeschrieben oder, wo hilfreich, über <abbr title="..."> erklärt

Warum das wichtig ist: Screenreader nutzen das Sprachattribut, um die richtige Aussprache-Engine auszuwählen. Ohne es ist deutscher Text, der von einer englischsprachigen Engine vorgelesen wird, kaum verständlich.

12. Konsistentes, vorhersehbares Verhalten

• Fokuserhalt löst keine automatische Kontextänderung aus (z. B. wird ein Formular nicht abgesendet, wenn ein Feld den Fokus erhält)
• Das Ändern einer Formulareingabe löst keine unerwartete Navigation oder modale Dialoge aus
• Komponenten mit derselben Funktion sind über Seiten hinweg konsistent beschriftet

Warum das wichtig ist: Unvorhersehbares Verhalten ist für alle Nutzenden verwirrend, insbesondere für Menschen mit kognitiven Einschränkungen oder Screenreader-Nutzende.

13. PDFs und Dokumente

• Zum Download verfügbare PDFs sind für die Struktur getaggt (Überschriften, Listen, Lesereihenfolge)
• PDF-Formularfelder sind beschriftet
• Gescannte PDFs (nur Bild) sind per OCR verarbeitet und getaggt
• Word-, Excel- und PowerPoint-Dateien nutzen integrierte Barrierefreiheitsfunktionen (Überschriftenformate, Alternativtext, Tabellennamen)

Warum das wichtig ist: Gerichte und das DOJ haben herunterladbare Dokumente durchgängig als Teil der barrierefreien Inhalte einer Website behandelt. Ein unzugängliches PDF in einem sonst barrierefreien Bezahlvorgang bleibt eine Barriere.

14. Barrierefreiheit auf Mobilgeräten

• Alle Funktionen sind sowohl im Hoch- als auch im Querformat verfügbar
• Berührungsziele (Schaltflächen, Links) sind mindestens 44×44 CSS-Pixel groß
• Inhalte erfordern bei Standard-Viewports kein horizontales Scrollen
• Die Website deaktiviert die Nutzerskalierung nicht über maximum-scale oder user-scalable=no im Viewport-Meta-Tag

Warum das wichtig ist: Viele Nutzende mit Behinderungen greifen hauptsächlich oder ausschließlich über Mobilgeräte auf das Web zu. Barrieren auf Mobilgeräten schließen sie ebenso wirksam aus wie Barrieren auf dem Desktop.

15. Erklärung zur Barrierefreiheit

• Eine Erklärung zur Barrierefreiheit ist veröffentlicht und von der Website-Fußzeile aus verlinkt
• Die Erklärung nennt den Standard, an dem sich die Website orientiert (WCAG 2.1 AA)
• Die Erklärung enthält einen Kontaktmechanismus, über den Nutzende Barrieren melden können
• Der Kontaktmechanismus ist selbst barrierefrei

Warum das wichtig ist: Eine Erklärung zur Barrierefreiheit zeigt guten Willen und gibt Nutzenden einen Weg zur Lösung, bevor sie rechtliche Schritte einleiten. Sie ist zudem nach mehreren Landesgesetzen vorgeschrieben und wird gemäß DOJ-Leitlinien als gängige Praxis erwartet.

---

Durchsetzung und Klagerisiko

ADA Title III verlangt von Klägern nicht, vorsätzliche Diskriminierung nachzuweisen. Wenn eine Barriere existiert und sie eine Person mit Behinderung daran gehindert hat, auf Waren oder Dienstleistungen zuzugreifen, kann eine Klage fortgeführt werden. Rechtsmittel nach Title III umfassen keinen Schadensersatz (anders als bei Section 504), wohl aber Unterlassungsverfügungen und Anwaltskosten — die häufig der Hauptantrieb für serielle Klagewellen sind.

Die Zahl der ADA-Website-Barrierefreiheitsklagen in den Vereinigten Staaten ist in den letzten Jahren stark gestiegen, mit Tausenden von Klagen jährlich. Klein- und mittelständische Unternehmen sind häufige Ziele, weil man ihnen unterstellt, weniger wahrscheinlich in Konformität investiert zu haben.

Wenn Sie ein ADA-Abmahnschreiben erhalten haben, ignorieren Sie es nicht. Ziehen Sie umgehend rechtlichen Rat hinzu und beauftragen Sie ein Barrierefreiheits-Audit, damit Sie ein genaues Bild von der Konformität Ihrer Website haben.

Konformität dauerhaft aufrechterhalten

Ein einmaliges Audit und eine einmalige Behebung reichen nicht aus. Jede neue Seite, Funktion oder Drittanbieter-Integration kann neue Barrieren einführen. Organisationen mit dem geringsten Klagerisiko halten Konformität kontinuierlich aufrecht:

• Automatisiertes Scannen, eingebettet in den Entwicklungsworkflow, erkennt erfassbare Probleme, bevor sie in die Produktion gelangen. Unser Service zur CI/CD-Barrierefreiheitsintegration macht dies zu einem Bestandteil jedes Builds.
• Geplante manuelle Audits decken die Probleme auf, die automatisierte Tools nicht erkennen können — Screenreader-Interaktion, kognitive Komplexität, Tastaturfallen.
• Barrierefreiheitsschulungen für Entwickler und Content-Autoren verhindern, dass Barrieren überhaupt erst entstehen.
• Nutzer-Feedback-Mechanismen geben Menschen mit Behinderungen einen direkten Kanal, um Barrieren zu melden, bevor sie zu Rechtsfragen werden.

Ein kostenloser automatisierter Scan ist der schnellste Weg, die sichtbarsten WCAG-Verstöße Ihrer Website zu identifizieren. Für ein vollständiges Bild, das Ihr ADA-Risiko abbildet, kontaktieren Sie unser Team, um ein vollständiges Audit zu besprechen.