Barrierefreiheit-Check: Befunde verstehen und beheben

Wie ein Befund aufgebaut ist

Der BFSG-Check im kostenlosen Scan nennt zu jedem Befund drei Angaben: das betroffene Element, die Fundstelle und das WCAG-Kriterium. Das Element zeigt, um welchen Baustein es geht, etwa einen Button, ein Bild oder ein Eingabefeld. Die Fundstelle sagt, wo er auftaucht. Das Kriterium ordnet den Mangel in die WCAG 2.1 ein, auf die sich auch Entwickler und Agenturen beziehen.

Bevor Sie etwas ändern, lohnt eine Frage: Stammt das Element aus dem Inhalt, den jemand im Redaktionssystem gepflegt hat, aus dem Theme beziehungsweise der Seitenvorlage oder aus einem eingebundenen Dienst wie einem Chat-Fenster oder Buchungs-Widget? Davon hängt ab, wer den Fehler beheben kann. Inhaltsfehler korrigiert die Redaktion, Vorlagenfehler die Entwicklung, und bei fremden Widgets liegt die Lösung oft nur in deren Einstellungen oder beim Anbieter.

Farbkontraste (WCAG 1.4.3)

Ein Kontrastbefund bedeutet, dass Text sich nicht deutlich genug vom Hintergrund abhebt. Für normalen Text liegt die Schwelle bei 4,5:1, für großen Text bei 3:1. Die Werte sind feste Grenzen: Ein Verhältnis knapp unter 4,5:1 erfüllt die Anforderung nicht. Häufige Ursachen sind hellgraue Hinweistexte, weiße Schrift auf hellen Markenfarben, Platzhalter in Formularfeldern und kleine Texte im Seitenfuß.

Kontrastfehler entstehen fast immer in der Farbpalette des Themes. Ändern Sie deshalb die Farbe dort, wo sie definiert ist, statt einzelne Elemente zu überschreiben; dann verschwinden oft Dutzende Befunde auf einmal. Zwei Grenzen des automatischen Tests sollten Sie kennen: Zustände, die erst bei Interaktion erscheinen, etwa beim Überfahren mit der Maus, sieht ein Test beim Laden der Seite in der Regel nicht. Und bei Text auf Fotos oder Farbverläufen lässt sich der Kontrast maschinell oft nicht sicher berechnen. Welche Ausnahmen gelten, etwa für Logos oder deaktivierte Bedienelemente, erläutert das W3C in seiner Erklärung zum Kriterium Kontrast (Minimum) (englisch).

Alternativtexte (WCAG 1.1.1)

Dieser Befund meldet Bilder, Icons oder Grafiken ohne Textalternative. Der Test erkennt, dass der Text fehlt, aber nicht, welcher Text passend wäre. Das hängt von der Aufgabe des Bildes ab:

• Rein schmückende Bilder erhalten ein leeres alt-Attribut (alt=""), damit Screenreader sie überspringen.
• Informative Bilder erhalten eine kurze Beschreibung dessen, was sie zeigen und was sie aussagen.
• Bilder und Icons in Links oder Buttons beschreiben das Ziel oder die Aktion, also „Warenkorb“ statt „Einkaufswagen-Symbol“.

Das W3C bietet dafür einen alt-Entscheidungsbaum auf Deutsch. Vorsicht bei der schnellen Lösung: Ein leeres alt-Attribut lässt den Befund verschwinden, versteckt bei informativen Bildern aber die Information. Bei Produktbildern in Shops sitzt die Ursache meist in der Medienverwaltung oder den Produktdaten; ein Feld für den Alternativtext beim Hochladen verhindert neue Befunde.

Beschriftungen von Formularen, Buttons und Links (WCAG 4.1.2)

Hier fehlt einem Bedienelement ein zugänglicher Name, also der Text, den ein Screenreader ansagt. Typische Fälle sind Buttons, die nur aus einem Icon bestehen (Lupe, Menü, Schließen-Kreuz), Social-Media-Links mit Logo statt Text und Eingabefelder, die nur einen Platzhalter haben. Der Platzhalter verschwindet beim Tippen und ersetzt keine Beschriftung.

Für Eingabefelder ist ein sichtbares label-Element, das mit dem Feld verknüpft ist, die robusteste Lösung. Icon-Buttons erhalten einen Text, der visuell verborgen sein kann, oder ein aria-label. Der Name sollte die Aktion beschreiben: „Menü öffnen“ sagt mehr als „Button“ oder „Icon“. Steckt das Element in der Kopf- oder Fußzeile, genügt meist eine Korrektur in der Vorlage.

Tastaturbedienung (WCAG 2.1.1)

Befunde in diesem Bereich betreffen Fokusfallen und eine falsche Tab-Reihenfolge. Eine Fokusfalle hält den Tastaturfokus in einem Bereich fest, etwa in einem eingebetteten Rahmen oder einem Dialog, den man ohne Maus nicht mehr verlässt. Eine falsche Reihenfolge entsteht oft durch positive tabindex-Werte, die die natürliche Abfolge im Quelltext überschreiben.

Die Behebung beginnt meist im Code: positive tabindex-Werte entfernen, die Reihenfolge im HTML an die sichtbare Anordnung anpassen und für klickbare Elemente echte button- oder a-Elemente verwenden statt div- oder span-Elemente, die nur auf Mausklicks reagieren. Ob ein Dialog sich per Tastatur wieder schließen lässt, prüfen Sie nach der Korrektur am besten selbst mit der Tab-Taste.

Sprachauszeichnung (WCAG 3.1.1)

Fehlt das lang-Attribut im html-Element oder steht dort die falsche Sprache, liest Vorlesesoftware deutsche Texte mit falscher Aussprache vor. Die Ursache ist oft ein Theme aus einer englischen Vorlage mit fest eingetragenem lang="en" oder eine falsche Spracheinstellung im Redaktionssystem. In WordPress etwa legt die Sprache der Website in den allgemeinen Einstellungen den Wert fest, sofern das Theme ihn ausgibt. Dieser Befund ist meist mit einer einzigen Änderung für die ganze Website erledigt.

Was eine leere Befundliste bedeutet

Wenn der Bericht keine Barrierefreiheitsbefunde mehr zeigt, sind die maschinell messbaren Mängel behoben. Automatisierte Werkzeuge erkennen aber nur etwa 30–40 % der WCAG-Kriterien zuverlässig. Ob Alternativtexte inhaltlich stimmen, Fehlermeldungen verständlich sind oder ein Bestellablauf vollständig per Tastatur funktioniert, zeigt erst eine manuelle Prüfung. Auch die Erklärung zur Barrierefreiheit nach § 14 BFSG lässt sich nicht automatisch prüfen.

Für den vollständigen Nachweis empfehlen wir deshalb, den automatischen Check durch eine manuelle Prüfung zu ergänzen. Ob das BFSG für Ihr Angebot überhaupt gilt, ordnet der Selbsttest auf der Seite zum BFSG-Check ein. Nach jeder Korrektur zeigt ein neuer kostenloser Scan, welche Befunde noch offen sind.