Was vor Gericht landet: Ein Leitfaden zu den UI-Mustern hinter 6.666 Beschwerden wegen mangelnder Barrierefreiheit

Die Kopfzeile ist die erste interaktive Fläche auf jeder Seite, und der Hamburger-Button ist oft das Erste, was ein Tastaturnutzer erreicht. Wenn dieser Button als <div> Wenn ein Element ein CSS-Hintergrundbild enthält, keinen barrierefreien Namen hat oder ein Menü aufklappt, das den Fokus einschließt oder seinen geöffneten bzw. geschlossenen Zustand nicht anzeigt, wird die gesamte Website strukturell über die Tastatur unbedienbar, noch bevor der Nutzer überhaupt einen tatsächlichen Inhalt aufgerufen hat.

Der Sprunglink ist der begleitende Fehler. Ein funktionierender "Skip to main content" Der Link lässt sich mit fünf Zeilen Code beheben, ist aber auch der effizienteste Indikator dafür, ob ein Entwicklungsteam Barrierefreiheit überhaupt auf seiner Checkliste hat. In Beschwerden werden beide Punkte häufig im selben Absatz genannt, denn ein fehlender oder defekter Sprunglink ist der erste Warnsignal – wenn das Team keinen Sprunglink implementiert hat, hat es mit ziemlicher Sicherheit auch keine „aria-expanded“-Zustände implementiert.

Den Menü-Trigger als echten <button> mit einer sichtbaren oder nur für Screenreader bestimmten Textbeschriftung und einem verwalteten aria-expanded Attribut. Geben Sie ein "Skip to main content" Link, der beim Fokus sichtbar wird und innerhalb des <main> Orientierungspunkt. Stellen Sie sicher, dass der Fokus beim Öffnen des Menüs in dieses wechselt, beim Schließen zum Auslöser zurückkehrt und dass Esc schließt das Menü.

Auf den meisten großen Websites wird die Suchfunktion als benutzerdefinierte Komponente neu implementiert – ein entprelltes Textfeld, das bei jedem Tastendruck eine Anfrage auslöst und eine schwebende Liste mit Vorschlägen innerhalb eines absolut positionierten <div>. Die Texteingabe selbst funktioniert in der Regel einwandfrei. Die Vorschlagsliste hingegen fast nie. Sie wird außerhalb des DOM-Kontexts des Eingabefelds dargestellt und verfügt über keine role="listbox", nein aria-activedescendantund es gibt keine Ansage der Live-Region, wenn die Ergebnisse angezeigt werden. Ein Screenreader-Nutzer tippt, hört nichts, drückt die Eingabetaste und erhält eine Ergebnisseite, von der er nicht wusste, dass sie bereits bereitstand.

Das gleiche Architekturmuster findet sich sowohl in den Filterfeldern der facettierten Suche als auch in der Ergebnisliste selbst wieder: Elemente, auf die der Tastaturfokus gesetzt werden kann, die zwar visuell vorhanden sind, aber nie angesagt werden. Beschwerden über die Suche beziehen sich selten auf das Suchfeld selbst, sondern auf alles, was erscheint, nachdem der Nutzer etwas eingegeben hat.

Verwenden Sie das etablierte WAI-ARIA-Kombinationsfeld-Muster: role="combobox" am Eingang mit aria-expanded, aria-controlsund aria-activedescendant angeschlossen an einen role="listbox" Vorschläge. Fügen Sie einen höflichen Live-Bereich hinzu, der die Anzahl der Ergebnisse anzeigt. Stellen Sie sicher, dass die Vorschlagsliste nicht nur mit der Maus, sondern auch mit der Pfeiltaste nach unten aufgerufen werden kann.

Das PLP-Raster vereint mehrere Anti-Patterns auf einem einzigen Bildschirm. Jede Kachel ist in der Regel eine anklickbare Karte mit drei oder vier interaktiven Unterelementen – Bildlink, Titel-Link, Farbfelder, Schnell-Hinzufügen-Schaltfläche –, die wiederum in einen weiteren Link zur Produktseite eingebettet sind. Das Ergebnis sind verschachtelte interaktive Elemente (ein HTML-Fehler), redundanter Linktext („Hero Dash Three Graphic Image Link“, der sich viermal wiederholt) und Farbfelder, die aus <div> Elemente mit Klick-Handlern, aber ohne Rolle und ohne Namen.

Die Filter-Seitenleiste führt eine zweite Fehlerkategorie ein. Filterfacetten sind in der Regel Listen mit Kontrollkästchen, bestehen jedoch aus benutzerdefinierten div- und span-Elementen, die so gestaltet sind, dass sie wie Kontrollkästchen aussehen, wobei die eigentliche <input> außerhalb des Bildschirms ausgeblendet. Wenn diese ausgeblendete Eingabe ihre Zuordnung verliert – sei es durch eine CSS-Regel, einen JavaScript-Ereignisbehandler, der das Drücken der Leertaste unterdrückt, oder durch ein fehlendes for Attribut auf dem sichtbaren Label – der Filter lässt sich dann nur noch mit der Maus bedienen.

Verwenden Sie pro Kachel einen Anker mit beschreibendem Text, nicht drei Links pro Produkt. Stellen Sie die Farbmuster realistisch dar <button> Elemente innerhalb eines role="radiogroup". Erstellen Sie Filterfacetten auf der Grundlage der tatsächlichen <input type="checkbox"> Elemente mit zugehörigen <label> Tags; Gestalte die Eingabefelder optisch ansprechend, anstatt sie auszublenden. Weise mit einem dezenten Live-Bereich auf Filteränderungen hin.

Auf der Produktdetailseite muss ein Screenreader-Nutzer mehrere spezifische Entscheidungen in der richtigen Reihenfolge treffen: eine Farbe auswählen, eine Größe auswählen, die Menge festlegen und dann in den Warenkorb legen. Jede dieser Entscheidungen wird im modernen E-Commerce als benutzerdefiniertes Widget umgesetzt – in der Regel als horizontale Reihe von <button>-förmig <div>Was die Größen angeht, so handelt es sich um farbige Kacheln, die aus mit CSS gestalteten Div-Elementen bestehen, sowie um einen numerischen Schieberegler, der aus zwei Symbolschaltflächen besteht, die ein Eingabefeld flankieren. Die Schaltflächen zum Erhöhen und Verringern werden standardmäßig ohne barrierefreien Namen ausgeliefert; in Beschwerden werden sie als angekündigt als „Button, Button“ ohne Hinweis darauf, was sie tun.

Größenratgeber und Größentabellen stellen ein eigenes Problem dar: Sie sind fast immer hinter einem Link „Größentabelle“ versteckt, der ein Modalfenster öffnet, und der Link selbst ist häufig nicht beschriftet, das Modalfenster hat oft keinen angekündigten Titel und die Tabelle darin verfügt häufig über keine Zeilen- oder Spaltenüberschriften.

Verwenden Sie echte Formularsteuerelemente. Farbfelder und Größenauswahlfelder sollten role="radiogroup" von role="radio" Schaltflächen (oder unsichtbar gestaltete Radio-Eingabefelder), jeweils mit einem barrierefreien Namen wie „Größe: Mittel“. Der Schieberegler für die Menge sollte ein beschriftetes Zahleneingabefeld mit zugehörigen Schaltflächen zum Erhöhen und Verringern sein, deren barrierefreie Namen die Aktion und die aktuelle Menge enthalten. Umgeben Sie den gesamten Auswahlblock mit einem „fieldset“-Element mit einer Beschriftung.

„In den Warenkorb“ ist der am häufigsten getestete Schritt in jedem E-Commerce-Trichter und einer der Punkte, an denen es für Nutzer von assistiver Technologie am häufigsten zu Problemen kommt. Der Ablauf ist mechanisch: Ein Besucher klickt auf die Schaltfläche, ein kleines Bestätigungs-Toast oder ein Mini-Warenkorb-Fenster erscheint für zwei oder drei Sekunden, und das Warenkorb-Symbol aktualisiert die Anzahl im Header. Sehende Nutzer sehen alle drei Signale. Nutzer von Screenreadern erhalten in der Regel keines davon. Das Popup wird außerhalb des aktiven Bereichs angezeigt, das Warenkorb-Fenster erscheint ohne Fokusverwaltung, und die Änderung der Warenkorbanzahl wird als einfache DOM-Änderung übermittelt, die kein Screenreader ansagt.

Das Ergebnis ist eine Schaltfläche, die aus Sicht des Nutzers nichts bewirkt. Er drückt sie, hört nichts, nimmt an, dass sie nicht funktioniert hat, und drückt sie erneut. In einigen Beschwerden wird beschrieben, dass die Schaltfläche fünf- oder sechsmal gedrückt wurde, bevor der Nutzer bemerkte, dass sich im Warenkorb still und leise fünf oder sechs Artikel angesammelt hatten.

Schließe den Bereich „cart-status“ in aria-live="polite" und den Text bei jedem erfolgreichen Hinzufügen aktualisieren. Wenn das Design eine Bestätigungsleiste verwendet, den Fokus beim Öffnen auf die Leiste verlagern und beim Schließen wieder auf die ursprüngliche Schaltfläche zurückführen. Die Anzahl im Warenkorb mit einer nur für Screenreader bestimmten Ansage aktualisieren, z. B. „1 Artikel hinzugefügt. Gesamtzahl im Warenkorb: 3 Artikel.“

Steuerelemente, die ausschließlich aus Symbolen bestehen, versagen auf vorhersehbare Weise: Der sichtbare Inhalt ist ein SVG- oder Icon-Font-Zeichen, der barrierefreie Inhalt ist leer, und die Ausgabe des Screenreaders reduziert sich auf die strukturelle Rolle des Elements ohne Namen. Das Warenkorb-Symbol wird schließlich als „Link“ oder „zusammengeklappt“ angekündigt; die Sprechblase als „Schaltfläche“; die Reihe von Social-Media-Symbolen in der Fußzeile als „Link, Link, Link, Link, Link“. Der Nutzer hat keine Möglichkeit zu erfahren, welche Funktion diese Elemente haben.

Warenkorb-Symbole versagen aus einem architektonischen Grund häufiger als andere Symbole: Bei vielen Implementierungen wird die Anzahl der Artikel im barrierefreien Namen des Symbols dargestellt (z. B. zeigt das Symbol im SVG eine „0“ an), und der Screenreader erfasst nur die Ziffer. In Beschwerden wird beschrieben, dass das Warenkorb-Symbol als „3, Link“ oder „0, Link“ angesagt wird, ohne dass darauf hingewiesen wird, dass sich die „3“ auf die Anzahl der Artikel im Warenkorb bezieht.

Jedes reines Symbol-Steuerelement benötigt einen barrierefreien Namen. Fügen Sie einen aria-label auf der Schaltfläche oder fügen Sie eine optisch unsichtbare Textbeschriftung darin ein: "Shopping cart, 3 items". Vermeiden Sie es, Ziffern ohne Kontext in den barrierefreien Namen des Symbols aufzunehmen. Verwenden Sie bei dekorativen Symbolen, die neben sichtbarem Text stehen, aria-hidden="true" auf das Symbol und lassen Sie den Text die Beschriftung übernehmen.

Der Checkout-Bereich birgt pro Pixel ein höheres Compliance-Risiko als jede andere Seite einer E-Commerce-Website, und die Fehlerquellen sind zahlreich. Adressauswahlmenüs, die als benutzerdefinierte Elemente dargestellt werden <div> Komponenten, die die Leertaste ignorieren. Markierungen für Pflichtfelder werden nur als rotes Sternchen angezeigt, ohne aria-required und keine programmatische Verknüpfung. Inline-Fehlermeldungen werden in roter Schrift unterhalb des Feldes angezeigt, ohne aria-describedby Das Feld wird nicht mit dem Fehler verknüpft, und es erfolgt keine Meldung im aktiven Bereich, wenn die Validierung fehlschlägt. Der Benutzer füllt das Formular aus, klickt auf „Weiter“, wird stillschweigend zurückgeleitet und hat keine Möglichkeit zu erfahren, welche Felder fehlerhaft sind oder warum.

In Hunderten von Fällen tauchen immer wieder dieselben Beschwerden auf: Fehlermeldungen werden nicht angesagt, Fehlermeldungen sind vage, Zahlungsdaten lassen sich nicht eingeben. Dabei handelt es sich nicht um vereinzelte Fehler. Es ist das Standardverhalten der meisten E-Commerce-Checkout-Komponenten, die ohne explizite Maßnahmen zur Barrierefreiheit ausgeliefert werden.

Verwende echte <label> Elemente, die den Eingaben zugeordnet sind durch for/id. Kennzeichnen Sie Pflichtfelder mit aria-required="true" und kennzeichnen Sie die Pflichtangabe im sichtbaren Text, nicht nur durch die Farbe. Bei einer fehlgeschlagenen Validierung zeigen Sie die Fehlermeldung innerhalb des Eingabefelds an aria-describedby Ziel, gib das fehlerhafte Feld an aria-invalid="true"und den Tastaturfokus auf das erste fehlerhafte Feld zu setzen. Zeigen Sie oben im Formular einen Bereich mit einer Fehlerübersicht an, der Ankerlinks zu jedem fehlerhaften Feld enthält.

Der Zahlungsblock ist ungewöhnlich, da er häufig über einen eingebetteten Iframe eines Drittanbieters bereitgestellt wird – etwa Stripe Elements, Braintree Hosted Fields oder ein Adyen-Drop-in. Innerhalb des Iframes ist das Formular des Zahlungsanbieters in der Regel gut beschriftet. Sobald eine Website jedoch eine eigene Karteneingabe erstellt oder die eingebetteten Felder in ein benutzerdefiniertes Layout einbindet, das die Beschriftungen durch visuelle Platzhalter überschreibt, werden die vier Felder – Nummer, Ablaufdatum, CVV, Postleitzahl – für einen Screenreader zu einer Reihe leerer Eingabefelder.

Das CVV-Feld wird am häufigsten falsch beschriftet, da Entwickler dessen Beschriftung häufig durch ein Fragezeichen-Symbol ersetzen, das einen Tooltip öffnet, in dem erklärt wird, was ein CVV ist. Der Tooltip ist jedoch nicht die Beschriftung; das Feld benötigt weiterhin einen programmatischen Namen. Fehlt dieser, verkündet der Screenreader den gesamten Zahlungsblock als „Bearbeiten, Bearbeiten, Bearbeiten, Bearbeiten“, und die Transaktion wird abgebrochen.

Wenn Sie eine Integration mit von Drittanbietern gehosteten Feldern verwenden, befolgen Sie die Barrierefreiheitsrichtlinien des Anbieters – die meisten bieten eine dokumentierte Methode, um Felder von außerhalb des iframe zu beschriften. Wenn Sie eine benutzerdefinierte Kartenerfassung erstellen, benötigt jedes Eingabefeld ein echtes <label> Element mit einer sichtbaren Textbeschriftung sowie autocomplete="cc-number" / cc-exp" / cc-csc" Attribute, damit Passwortmanager und assistive Technologien die Felder anhand ihres Zwecks identifizieren können.

Auf der Warenkorbseite wiederholt sich der Fehler des Mengenreglers auf der Produktdetailseite, allerdings mit noch schwerwiegenderen Folgen: Ein Screenreader-Nutzer, der den Regler nicht bedienen kann, kann die Bestellung nicht abschließen. Die Schaltfläche „Entfernen“ ist ein Anti-Pattern für sich – es handelt sich in der Regel um ein kleines ×-Symbol neben jeder Artikelzeile, oft ohne sichtbaren Text, ohne aria-label, und es erfolgt keine Meldung, wenn die Zeile entfernt wird. Der Benutzer drückt auf die Schaltfläche, von der er hofft, dass es die Schaltfläche zum Entfernen ist, die Zeile verschwindet, und der Screenreader gibt keine Rückmeldung. Es gibt keine Möglichkeit, zu überprüfen, ob die Aktion erfolgreich war.

In mehreren Beschwerden wird ein ähnlicher Fehler beschrieben: Die laufende Gesamtsumme im Warenkorb wird dynamisch aktualisiert, wenn sich die Mengen ändern oder Artikel entfernt werden, doch die neue Gesamtsumme wird als gewöhnlicher DOM-Text außerhalb eines Live-Bereichs angezeigt, sodass der Nutzer keine Ahnung hat, welcher Betrag ihm in Rechnung gestellt wird.

Jede Zeile sollte eine beschriftete Schaltfläche zum Löschen enthalten (z. B. "Remove Blue T-Shirt, size M, from cart"). Schieberegler für die Menge sollten ihren aktuellen Wert als Teil des barrierefreien Namens oder über zugehörige Aktualisierungen der Live-Region anzeigen. Die Zwischensumme des Warenkorbs sollte sich innerhalb eines aria-live="polite" Region, sodass Änderungen angekündigt werden. Bestätigen Sie das Entfernen mit einer Rückgängig-Funktion.

Dies ist die größte Einzelkategorie im Datensatz, da es sich um das Problem handelt, dessen Erkennung die geringsten Kosten verursacht, dessen Ignorieren jedoch die höchsten Kosten mit sich bringt. Ein Screenreader durchläuft das DOM, stößt auf ein <input>und liest dessen beschreibbaren Namen – den es aus folgenden Elementen in dieser Reihenfolge berechnet: aria-labelledby, aria-label, ein verbundenes <label for>, der title Attribut oder den Platzhalter. Ist keines davon vorhanden, gibt der Screenreader lediglich die Rolle an: „Bearbeitungsfeld“ oder „Bearbeitung, leer“. Dieser Satz taucht fast wortwörtlich in Hunderten von Beschwerdeprotokollen auf.

Der Grund dafür ist struktureller Natur. Moderne Designsysteme zeigen häufig Platzhaltertext innerhalb des Eingabefelds als Ersatz für die sichtbare Beschriftung an, und Entwickler gehen davon aus, dass der Platzhalter die Beschriftung übernimmt. Das tut er jedoch nicht. Der Platzhalter verschwindet, sobald der Benutzer etwas eingibt, hinterlässt keinen programmgesteuerten Namen und macht das Feld für jeden unbrauchbar, der später im Ablauf darauf stößt oder nach einem Fehler dorthin zurückkehrt.

Jedes interaktive Steuerelement erhält eine sichtbare Beschriftung, die programmgesteuert zugewiesen wird. <label for="email">Email</label><input id="email" type="email"> ist das Standardmuster. Platzhalter dienen als ergänzende Hinweise, nicht als Ersatz. Bei Steuerelementen, bei denen eine sichtbare Beschriftung tatsächlich unerwünscht ist (Suchfelder, Symbolschaltflächen), verwenden Sie aria-label mit beschreibendem Text – niemals mit doppeltem Platzhalter.

Der Ausdruck „nicht angekündigt oder mit Fokus versehen“ taucht wörtlich in über 400 Beschwerdeeinträgen auf und ist einer der am häufigsten wiederkehrenden Sätze im gesamten Datensatz. Er beschreibt einen bestimmten Fehlerfall: Ein Modal oder Dialog erscheint auf der Seite (oft automatisch – Newsletter-Anmeldung, Altersprüfung, Standortbestätigung), der sichtbare Inhalt verschiebt sich, aber der Screenreader erhält kein Signal, dass sich etwas geändert hat. Der Fokus verbleibt auf der darunterliegenden Seite. Der Nutzer navigiert mit der Tabulatortaste weiter durch den Inhalt, der sich unter dem Modal befand, und bemerkt dabei überhaupt nicht, dass ein blockierendes Dialogfeld erschienen ist.

Das ist der klassische Fall eines Modals, das in jeder Hinsicht gleichzeitig versagt: nein role="dialog", nein aria-modal="true", keine programmatische Fokusverschiebung bei geöffnetem Fenster, keine Fokusfalle im geöffneten Zustand, kein Schließen per Esc-Taste, kein Titelbild. Da all diese Fehler zusammen auftreten, bringt die isolierte Behebung eines einzelnen Fehlers keine Verbesserung der Fallquote.

Verwenden Sie ein etabliertes Dialogmuster (die WAI-ARIA-Spezifikation für Autoren dient als Referenz). Beim Öffnen: Setzen Sie den Fokus auf das erste fokussierbare Element innerhalb des Dialogs und legen Sie aria-modal="true" und role="dialog", benenne das Dialogfeld mit aria-labelledby mit einem Verweis auf die Überschrift. Solange das Fenster geöffnet ist: Fokus im Dialogfenster belassen. Beim Schließen: Fokus auf das Element zurückgeben, das das Fenster ausgelöst hat. Die Esc-Taste berücksichtigen. Falls das modale Fenster einen Ablauf unterbricht (z. B. automatische Wiedergabe beim Laden der Seite), dem Benutzer eine einzige Möglichkeit bieten, es dauerhaft zu schließen.

Fokusindikatoren werden in der Regel bewusst deaktiviert, und zwar von einem Entwickler oder Designer, der die standardmäßige Umrandung des Browsers als visuelles Störelement empfand und *:focus { outline: none; } in ein globales Stylesheet. Für einen sehenden Mausbenutzer wirkt die Seite nun übersichtlicher. Für einen sehenden Tastaturbenutzer – darunter die meisten sehbehinderten Benutzer, Benutzer mit motorischen Einschränkungen und Benutzer, die ohne Maus navigieren – wird die Seite jedoch unbrauchbar. Der Benutzer kann zwar die Tabulatortaste drücken, sieht aber nicht, wo er sich gerade befindet.

Dies ist einer der wenigen Fehlerfälle, die ohne Hilfsmittel erkennbar sind. Ein QA-Prüfer, der einmal ohne weitere Hilfsmittel mit der Tabulatortaste durch die Startseite navigiert, wird den Fehler in weniger als einer Minute entdecken. Dass Barrierefreiheitsteams diesen Fehler bei Websites, gegen die Klage eingereicht wurde, regelmäßig finden, während er bei internen Überprüfungen übersehen wurde, ist eines der zuverlässigsten Anzeichen im Datensatz dafür, dass die Website den Tastaturtest überhaupt nicht bestanden hat.

Niemals pauschal deaktivieren :focus Konturlinien ohne Ersatz. Verwenden Sie einen gut sichtbaren Fokusstil – in der Regel eine 2–3-Pixel-Konturlinie mit ausreichendem Kontrast sowohl zum Element als auch zu dessen Hintergrund – mithilfe von :focus-visible Der Cursor wird also bei der Tastaturnavigation angezeigt, nicht jedoch bei Mausklicks. Überprüfen Sie dies bei allen interaktiven Komponenten, einschließlich benutzerdefinierter Widgets, Links innerhalb von Karten und Elementen mit tabindex.

Das Logo ist das am häufigsten aufgerufene Bild auf einer Website und eines der am häufigsten fehlerhaften. Es ist in der Regel in einem Link eingebettet, der zurück zur Startseite führt, doch das Bild wird ohne alt, nein aria-label auf den Link und keinen umgebenden Text. Der Screenreader liest nur „Link“, ohne dass man weiß, wohin das führt. Und das auf jeder einzelnen Seite der Website.

Die übergeordnete Kategorie – Bilder ohne Alt-Text – umfasst Bannerbilder, Produktfotos, Hero-Illustrationen, Symbole für soziale Netzwerke sowie den umfangreichen Katalog an Marketingbildern, den eine typische E-Commerce-Website bereitstellt. In Beschwerden dieser Kategorie werden häufig bestimmte Bilddateinamen genannt, was darauf hindeutet, dass der Sachverständige des Klägers eine automatisierte Überprüfung durchgeführt hat, bei der jedes Bild aufgelistet wurde, dessen alt Das Attribut fehlte oder war leer, obwohl es eigentlich aussagekräftig hätte sein sollen.

Logos sollten einen Alt-Text enthalten, der den Firmennamen beschreibt, und, falls das Logo mit einer Seite verlinkt ist, das Ziel — alt="Acme Co. — homepage". Dekorative Bilder erhalten ein leeres alt-Attribut (alt=""), wodurch sie bewusst vor assistiven Technologien verborgen bleiben. Informative Bilder erhalten einen beschreibenden Alt-Text. Vermeiden Sie die automatische Generierung von Alt-Text aus Dateinamen oder KI-Beschriftungen ohne menschliche Überprüfung; in Beschwerdeprotokollen werden immer wieder Fälle angeführt, in denen Overlay-Tools ein Firmenlogo als „ein blau-gelbes Schild“ bezeichneten.

Bildschirmleseprogramme bieten eine Ansicht mit einer „Liste von Links“ an, die von erfahrenen Nutzern häufig genutzt wird, um eine Seite in Sekundenschnelle zu überfliegen. Diese Ansicht zeigt nur den Linktext an, losgelöst vom umgebenden Absatz. Eine Seite, auf der jeder Blog-Teaser mit „Weiterlesen“ wird in dieser Ansicht als fünfzehn identische Einträge dargestellt. Eine Seite mit fünf leeren Links — <a href="..."></a>, was häufig vorkommt, wenn sich Symbole in Link-Tags befinden, ohne dass ein Text als Ausweichlösung vorhanden ist – führt dazu, dass fünf Leerzeichen angezeigt werden.

Die Lösung ist bekannt, ebenso wie der Fehler, weshalb dieses Muster immer wieder in Beschwerden auftaucht – seine Hartnäckigkeit deutet auf einen Entwicklungsprozess hin, bei dem es weder einen automatisierten Linter für Linktexte noch eine manuelle Überprüfung mit einem Screenreader gibt.

Jeder Link muss einen barrierefreien Namen haben, der sein Ziel oder die damit verbundene Aktion beschreibt. Ersetze allgemeine Formulierungen durch beschreibende – „Weiterlesen“ wird „Erfahren Sie mehr über die Ergebnisse des dritten Quartals“. Bei Links, die nur aus Symbolen bestehen, fügen Sie unsichtbaren Text oder einen aria-label. Führen Sie eine automatisierte Prüfung (axe, Lighthouse usw.) auf leere <a> Elemente während der CI.

Videos tauchen in Beschwerden in zwei Formen auf. Die erste ist offensichtlich: Ein Marketingvideo, eine Produktdemo oder ein Erklärvideo wird ohne Untertitel, Transkript oder jegliche Textalternative bereitgestellt – und ein gehörloser oder schwerhöriger Besucher kann auf den Inhalt nicht zugreifen. Das zweite Muster ist subtiler: Ein Hero-Video, das beim Laden der Seite automatisch abgespielt wird, was die Ausgabe des Screenreaders stört und gegen die in WCAG 2.2 AA-Level erwarteten Steuerelemente zum Anhalten/Stoppen verstößt (gemäß SC 2.2.2 „Pause, Stop, Hide“ für bewegte Inhalte und SC 1.4.2 für jegliche Audioinhalte).

In einigen Beschwerden dieses Datensatzes wird die Behauptung aufgestellt, dass „das Fehlen von Untertiteln bei Videos auf der Website einen Verstoß gegen das ADA darstellt“, was als rechtliche Schlussfolgerung dargestellt wird. Ob diese Darstellung zutrifft , hängt von der jeweiligen Rechtsordnung und den Umständen ab; unbestritten ist jedoch, dass diese Videos durchweg die Anforderungen von WCAG 2.2 AA nicht erfüllen – dem Standard, den die meisten Gerichte und Vergleichsvereinbarungen als maßgeblichen Konformitätsmaßstab betrachten.

Stellen Sie für alle vorab aufgezeichneten Videos mit Ton synchronisierte Untertitel bereit. Stellen Sie außerdem eine Text-Transkription zur Verfügung; Transkriptionen sind nützlich für Nutzer mit stummgeschalteten Geräten, in Umgebungen mit geringer Bandbreite sowie für die Indizierung. Vermeiden Sie die automatische Wiedergabe; falls eine automatische Wiedergabe aus gestalterischen Gründen erforderlich ist, stellen Sie eine Pause-/Stopp-Steuerung bereit, die direkt über die Tastatur erreichbar ist. Für reine Videoinhalte (ohne Ton) stellen Sie eine Audiodeskription oder eine Textalternative bereit.

Die Anmeldung ist das Tor zur gesamten authentifizierten Benutzererfahrung. Wenn das Formular fehlschlägt, sind alle nachfolgenden Seiten nicht mehr erreichbar, und in Beschwerden wird diese Kettenreaktion häufig als ein einziges Hindernis wahrgenommen. Das Muster ist derselbe Fehler bei der Formularbeschriftung wie bei E·01, oft kombiniert mit drei spezifischen Teilfehlern: einem Umschaltknopf „Passwort anzeigen“, der als reiner Symbolknopf ohne Namen und ohne Ansage der Statusänderung implementiert ist, einem CAPTCHA, das die Nutzung von Screenreadern vollständig zunichte macht, und Inline-Fehlern („ungültige Anmeldedaten“), die auf dem Bildschirm angezeigt, aber nicht angesagt werden.

Das Kontrollkästchen „Angemeldet bleiben“ ist ein weiterer häufig auftretender Teilfehler: Es wird als formatiertes <div>, wobei die tatsächliche <input> Da das Kontrollkästchen außerhalb des Bildschirms verborgen ist, lässt es sich zwar mit der Maus, jedoch nicht über die Tastatur oder einen Screenreader bedienen. Der Benutzer hat keine Möglichkeit, eine dauerhafte Sitzung zu aktivieren.

Verwende echte <input>, <label>und <button> Elemente. Gestalten Sie den Schalter zum Ein- und Ausblenden des Passworts als echte Schaltfläche mit einem barrierefreien Namen, der sich je nach Status aktualisiert ("Show password" / "Hide password") und die Änderung bekannt geben mit aria-pressed. Bieten Sie eine barrierefreie Alternative zu bildbasierten CAPTCHAs an (Audio-CAPTCHA oder – vorzugsweise – ersetzen Sie CAPTCHA durch risikobasierte Authentifizierung oder die barrierefreien Varianten von hCaptcha).

Bildschirmleseprogramme stellen die Seite in drei Navigationsmodi dar: nach Überschriften, nach Orientierungspunkten und nach Links. Eine Seite, die ohne eine <h1>, ohne <main>, <nav>und <footer> Sehenswürdigkeiten und ohne eine lang="en" Attribut auf dem <html> Element hat alle drei Navigationsmodi gleichzeitig entfernt. Die Nutzer haben keine Möglichkeit mehr, den Text zu überfliegen, zu Inhalten zu springen oder den Screenreader dazu zu bringen, die richtige Aussprache-Engine zu laden.

Dies ist ein ungewöhnlich weitreichender Fehler: Ein einziger fehlender Orientierungspunkt löst eine ganze Kette von Problemen aus, da nun jede darauf basierende Navigationsstrategie von Screenreadern versagt. Bei Beanstandungen dieser Art werden in der Regel vier oder fünf konkrete strukturelle Probleme aufgeführt, die als Beweis dafür dienen, dass die Website keine semantische Grundlage aufweist.

Jede Seite erhält genau eine <h1>, mit Unterüberschriften (<h2>, <h3>) logisch verschachtelt. Schließen Sie Bereiche in HTML5-Landmark-Elemente ein: <header>, <nav>, <main>, <aside>, <footer>. Einstellen lang im Stammverzeichnis <html> Element. Überprüfen Sie es mit einem Outline-Checker oder führen Sie document.querySelectorAll('h1').length === 1 als Smoketest in CI.

Die meisten Qualitätssicherungsprüfungen zur Barrierefreiheit werden auf Desktop-Browsern mit NVDA oder JAWS durchgeführt. Mobile assistive Technologien – VoiceOver auf iOS, TalkBack auf Android – zeigen eine andere Darstellung desselben DOM an, oft mit anderen Fehlern. In Beschwerden wird wiederholt die Abkürzung „mobile SRU“ (mobile Screenreader-Nutzer) verwendet, um Fehler zu kennzeichnen, die spezifisch für die mobile Ansicht sind: ein Hamburger-Menü, das mit NVDA auf dem Desktop funktioniert, unter VoiceOver jedoch keine Reaktion zeigt, eine Apple-Pay-Schaltfläche, die auf einem Laptop erreichbar ist, auf der iPhone-Version der Seite jedoch nicht, sowie Fehlermeldungen, die auf dem Desktop, nicht aber auf Mobilgeräten ausgegeben werden.

Die Daten lassen darauf schließen, dass Beklagte, deren Barrierefreiheit auf Desktop-Geräten ansonsten einwandfrei ist, dennoch wegen mobiler spezifischer Probleme verklagt werden. Die mobile Barrierefreiheit ist ein eigenständiger Prüfpunkt.

Testen Sie mindestens mit VoiceOver in iOS Safari und TalkBack in Android Chrome anhand derselben Abläufe, die auch bei der Desktop-Qualitätssicherung abgedeckt werden. Achten Sie besonders auf gestenbasierte Interaktionen, native Zahlungsschaltflächen und die Ansage von Formularfeldern beim Fokuswechsel. Falls eine native App vorhanden ist, unterziehen Sie diese derselben Prüfung – Beschwerden betreffen häufig sowohl die Webversion als auch die App im Rahmen desselben Falls.

Das Barrierefreiheits-Overlay ist das einzige Beispiel in diesem Katalog, bei dem der Fehler gar nicht in der zugrunde liegenden Website liegt – sondern in der vermeintlichen Korrekturschicht, die zur Behebung des Problems hinzugefügt wurde. Beschwerden dieser Art beschreiben zwei unterschiedliche Probleme. Das erste besteht darin, dass Overlays die zugrunde liegenden Barrieren nicht wirklich beseitigen, sodass der Nutzer unabhängig davon, ob das Widget vorhanden ist, weiterhin auf dieselben fehlerhaften Modal-Fenster, falsch beschrifteten Formulare und unangekündigten Fehler stößt. Der zweite ist noch gravierender: Overlays führen manchmal zu neuen Fehlern, indem sie falsche Beschriftungen einfügen, ARIA-Rollen falsch anwenden oder die Konfiguration der Hilfsmittel des Nutzers beeinträchtigen.

Ein bemerkenswertes Detail: In Beschwerden aus den Jahren 2024 und 2025 wird der Anbieter des Overlay-Tools zunehmend namentlich genannt. In zwei konkreten Passagen von Beschwerden werden UserWay und AccessiBe unmissverständlich genannt, und die jüngsten Maßnahmen der FTC haben zu einem konkreten Risiko geführt, dass das Hinzufügen eines Overlay-Tools an sich schon als Beweis für das Versäumnis echter Abhilfemaßnahmen gilt – und nicht als Verteidigungsargument in Rechtsstreitigkeiten.

Betrachten Sie Overlays als Hinweis, nicht als Lösung. Wenn derzeit ein Overlay eingesetzt wird, sollten Sie einen Plan für eine echte Barrierefreiheitsoptimierung erstellen, der den zugrunde liegenden Code angeht, anstatt ihn zu überdecken. Der bewährte Weg besteht aus einer Kombination aus folgenden Maßnahmen: einem in die CI integrierten automatisierten Scanner, einer manuellen Überprüfung gemäß WCAG 2.2 AA, manuellen Tests mit mindestens einem Screenreader und einer Navigation ausschließlich über die Tastatur sowie einer kontinuierlichen Qualitätssicherung im Bereich Barrierefreiheit während des Design- und Entwicklungsprozesses.