Wie ein Kontrast-Checker unser Team eines Besseren belehrt hat

Als wir vor Kurzem unsere Website überarbeitet haben, stand Barrierefreiheit nicht direkt ganz oben auf unserer Liste, bis wir angefangen haben die neuen Farbkombinationen mit einem Kontrast-Checker zu prüfen. Und dabei kam etwas heraus, das uns überrascht hat.

Der Moment, der uns die Augen geöffnet hat

Zuerst haben wir die neuen Farben im Team einfach nach Gefühl beurteilt: “Das ist doch gut lesbar, oder?” Und genau da fing das Problem an. Jede Person im Entwicklerteam hat unterschiedlich eingeschätzt, welche Kombination gut oder schlecht lesbar ist. Für die einen war ein helles Grau auf Weiß völlig unproblematisch, für andere kaum zu entziffern.

Dann haben wir das Kontrast-Tool über die Farben laufen lassen. Ergebnis: Manche Kombinationen, die wir für unproblematisch gehalten hatten, fielen klar durch den Test. Andere, bei denen wir unsicher waren, waren völlig in Ordnung. Es gab danach keine große Grundsatzdiskussion darüber, wer im Team “recht” hatte, das Tool hat einfach entschieden und wir haben uns danach gerichtet.

Die Lektion daraus: Barrierefreiheit lässt sich nicht nach Bauchgefühl beurteilen. Was für dich gut lesbar aussieht, kann für jemand anderen mit anderer Sehstärke, anderem Bildschirm, anderen Lichtverhältnissen oder einer echten Sehbeeinträchtigung komplett unbrauchbar sein. Das eigene Auge ist einfach kein verlässlicher Maßstab.

Was Barrierefreiheitstests eigentlich prüfen

Kontrast ist nur ein kleiner Ausschnitt. Barrierefreiheitstests prüfen insgesamt, ob eine Anwendung für Menschen mit unterschiedlichen Einschränkungen nutzbar ist – Sehbehinderungen, motorische Einschränkungen, kognitive Einschränkungen oder Hörbeeinträchtigungen. Der gängige Referenzrahmen dafür sind die WCAG-Richtlinien (aktuell Version 2.2), die vier Grundprinzipien definieren: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein.

In der Praxis heißt das eine Mischung aus:

• Automatisierten Checks – Tools wie axe, Lighthouse oder eben Kontrast-Checker, die schnell die häufigsten technischen Probleme finden (Kontrast, fehlende Alt-Texte, falsche HTML-Struktur)
• Manuellen Tests – zum Beispiel ohne Maus durch die Seite tabben, mit einem Screenreader (NVDA, VoiceOver) durchklicken, oder im Idealfall echte Nutzer:innen mit Einschränkungen einbeziehen

Wichtig dabei: Automatisierte Tools finden erfahrungsgemäß nur einen Teil der Probleme. Ob eine Screenreader-Ansage tatsächlich Sinn ergibt, merkt man oft erst beim manuellen Testen.

Wie wir das jetzt handhaben

Bei uns ist daraus mittlerweile Routine geworden: Sobald sich etwas an der UI ändert, läuft der Kontrast-Check automatisch mit. Kein großes Extra-Projekt, sondern ein fester Teil des normalen Workflows, genauso selbstverständlich wie ein Cross-Browser-Check.

Was das für euch heißen könnte

Ihr müsst nicht gleich ein komplettes Accessibility-Audit aufsetzen, um von diesem Prinzip zu profitieren. Ein einfacher, oft kostenloser Kontrast-Checker reicht schon, um die eigene Einschätzung im Team zu überprüfen und wahrscheinlich ähnlich überrascht zu sein wie wir.

Habt ihr in eurem Projekt auch schon erlebt, dass ein Tool eure Bauchgefühl-Einschätzung über den Haufen geworfen hat? Schreibt’s uns gerne