Bild: Wenn Code plötzlich spricht — Barrierefreiheit aus der Nutzerperspektive.

Einleitung

Letzte Woche habe ich etwas gemacht, das ich als Web-Entwicklerin eigentlich schon lange hätte tun sollen: Ich habe meinen Laptop geschlossen, eine Screenreader-App aktiviert und versucht, eine unserer Uni-Projektseiten nur mit der Tastatur zu bedienen. Das Ergebnis war ernüchternd — und lehrreicher als jedes Tutorial.

Kontext

Barrierefreiheit im Web klingt erstmal nach einer dieser Pflichtaufgaben, die man möglichst schnell abhakt. ARIA-Labels hier, Kontraste dort, und dann weiter zum nächsten Ticket. Doch während meines Studiums und meiner Arbeit als Tech-Journalistin merke ich immer wieder: Wer Barrierefreiheit nicht selbst erlebt, versteht sie nur unvollständig.

Ich wollte wissen, wie es sich anfühlt, wenn eine Website plötzlich nicht mehr nur für mich ist — sondern für jemanden, der alles über Lautsprecher wahrnimmt.

Implementierung

Ich habe drei gängige Screenreader auf meinem Rechner installiert und jeweils 30 Minuten damit verbracht, bekannte Seiten zu erkunden: die Projekt-Webseite unseres Open-Source-Teams, mein Online-Banking und eine Nachrichtenseite.

Was sofort auffiel: Moderne Frameworks wie React und Vue sind standardmäßig nicht barrierefrei. Tabs, die ich mit der Tastatur nicht erreichen konnte. Bilder ohne Alternativtext, die als „Bild 47“ vorgelesen wurden. Formularfelder, die keinen sichtbaren Fokus hatten — bis ich die Maus einfach ausgeschaltet habe.

Was überraschend gut funktionierte: Die Struktur unserer Semantik. Wo wir von Anfang an nav, main und button statt div verwendet hatten, funktionierte der Screenreader erstaunlich flüssig. Kleine Entscheidungen beim Coden machten hier den Unterschied.

Ergebnis

Das wichtigste Learning: Barrierefreiheit ist kein Feature, das man hinzufügt. Sie ist eine Qualitätsentscheidung, die jeden Teil des Entwicklungsprozesses beeinflusst. Nach meinem Selbstversuch haben wir in unserem Team einen „A11y-Check“ für jedes Pull-Request eingeführt — einfache Tastaturnavigation, automatische Kontrastprüfung und ein paar Minuten Screenreader-Test pro Woche.

Offen bleibt für mich, wie wir Barrieren noch früher erkennen. Nicht erst im Testing, sondern bereits im Design und in der Konzeption.

Fazit

Ich kann nur jedem empfehlen, der Websites baut: Schalte den Monitor aus und bediene dein eigenes Produkt eine halbe Stunde lang mit der Tastatur. Es ist ernüchternd — und es wird dein Denken über gutes Interface-Design verändern.

Barrierefreiheit beginnt nicht mit Checklisten. Sie beginnt mit Neugier.