Barrierefreiheit im Web: Vom Sonderfall zur besseren Nutzererfahrung

In vielen Webprojekten wird über Barrierefreiheit erst ausführlich gesprochen, wenn Design, Texte und Komponenten längst feststehen. Wichtig ist das Thema meist schon vorher, aber offenbar nicht wichtig genug, um von Anfang an mitgedacht zu werden. So landet es irgendwo zwischen gesetzlicher Pflicht, technischer Spezialdisziplin und dem guten Vorsatz, „später noch einmal sauber drüberzugehen“.

Dann fühlt sich Barrierefreiheit schnell wie eine Zusatzaufgabe an. Wie etwas, das man noch irgendwie erfüllen muss, obwohl das eigentliche Produkt schon fertig gedacht ist. In der Praxis zeigt das Thema aber oft erst, ob ein digitales Angebot überhaupt robust genug für die tatsächliche Nutzung ist.

Das Problem liegt nicht bei den Menschen, die ein digitales Angebot unter Bedingungen nutzen, mit denen im Projekt nicht gerechnet wurde. Es liegt in der Projektlogik, die ihre Bedürfnisse als spätes Sonderthema behandelt. Der Idealfall, für den viele digitale Angebote entworfen werden, kommt im Alltag erstaunlich selten vor.

Der Idealfall kommt selten vorbei

Viele digitale Angebote wirken so, als hätten sie eine ziemlich genaue Vorstellung von ihrem Gegenüber: gute Augen, ruhige Umgebung, großer Bildschirm, sichere Mausführung, schnelles Internet, volle Konzentration, vertraute Begriffe und genug Zeit. Diese Nutzungssituation gibt es natürlich. Aber sie ist nur eine von vielen.

In echten Projekten sieht es meistens chaotischer aus. Jemand füllt ein Formular am Smartphone aus, weil kein Laptop greifbar ist. Jemand versteht einen Fachbegriff nicht, weil die Verwaltungssprache unnötig dicht ist. Jemand kann ein Video gerade nicht hören. Jemand erkennt hellgrauen Text auf weißem Hintergrund nicht gut. Und manche Menschen sind dauerhaft auf Screenreader, Vergrößerung, Sprachsteuerung, Tastaturbedienung oder andere assistive Technologien angewiesen.

Barrierefreiheit muss sich allerdings nicht erst dadurch rechtfertigen, dass sie vielen Menschen im Alltag hilft. Für Menschen mit Behinderungen ist sie oft die Voraussetzung, überhaupt teilnehmen zu können. Zugleich machen viele Anforderungen, die für einige Menschen unverzichtbar sind, digitale Angebote auch für andere spürbar besser. Gute Kontraste sind auch draußen in der Sonne nützlich. Klare Beschriftungen lassen sich unter Zeitdruck leichter erfassen. Eine saubere Tastaturbedienung hilft Menschen, die viel ohne Maus arbeiten. Verständliche Fehlermeldungen geben Orientierung, wenn etwas schiefgeht.

Der Blick auf Barrierefreiheit als Sonderthema greift deshalb in jedem Fall zu kurz. Sie ist vielmehr ein Stresstest für Annahmen, die wir über unsere Nutzer:innen treffen.

Die Pflicht ist wichtig, löst allein aber nicht das Problem

Seit dem 28. Juni 2025 gelten in Deutschland die Anforderungen des Barrierefreiheitsstärkungsgesetzes für ausgewählte Produkte und Dienstleistungen. Das Gesetz setzt den European Accessibility Act um und betrifft unter anderem E-Commerce, Bankdienstleistungen, E-Books, bestimmte Selbstbedienungsterminals und weitere verbrauchernahe Angebote. Für öffentliche Stellen sind Barrierefreiheitsanforderungen durch Behindertengleichstellungsgesetz und BITV 2.0 ohnehin seit Jahren Teil der digitalen Realität.

Ich halte diese rechtlichen Vorgaben für wichtig. Ohne verbindliche Regeln würden viele Organisationen Barrierefreiheit weiter vertagen. Nicht aus böser Absicht, sondern weil Projekte fast immer unter Zeitdruck stehen und alles, was nicht hart eingefordert wird, schnell nach hinten rutscht.

Trotzdem reicht die Pflicht allein nicht aus. Man kann eine Website auf einzelne Prüfkriterien hin optimieren und trotzdem ein Angebot bauen, das sich mühsam oder unverständlich anfühlt. Ein Audit kann Probleme sichtbar machen. Es ersetzt aber nicht die grundlegende Frage, ob ein Mensch mit einem konkreten Anliegen wirklich erfolgreich ist.

Die Web Content Accessibility Guidelines des W3C sind dafür ein zentraler Standard. WCAG 2.2 beschreibt Anforderungen entlang der Prinzipien wahrnehmbar, bedienbar, verständlich und robust. Das klingt erst einmal technisch, ist aber eigentlich ein praktischer Denkansatz: Können Menschen Inhalte erfassen, die Oberfläche bedienen, verstehen, was passiert, und das Ganze mit verschiedenen Geräten, Browsern und Hilfsmitteln nutzen?

Wenn man diese Fragen früh stellt, entstehen fast zwangsläufig bessere Produkte. Wenn man sie erst stellt, wenn Design, Text, Komponenten und technische Architektur schon feststehen, wird Barrierefreiheit schnell zur teuren Nachbesserung.

Viele Barrieren sind erstaunlich gewöhnlich

Viele Barrieren in Webprojekten sind keine hochkomplexen Spezialfälle. Sie entstehen durch Dinge, die man jeden Tag sieht. Sie sind so häufig, dass sie einem gar nicht mehr richtig auffallen.

Zu wenig Kontrast. Links, die nur „mehr“ heißen. Icons ohne verständlichen Namen. Überschriften, die visuell schön aussehen, aber semantisch keine Struktur ergeben. Modale Fenster, aus denen man mit der Tastatur nicht sinnvoll herauskommt. Fehlermeldungen, die irgendwo oben auf der Seite stehen, während der Fokus unten im Formular bleibt.

Der WebAIM Million Report 2025 hat auf 94,8 Prozent der untersuchten Startseiten automatisch erkennbare WCAG-Fehler gefunden. Solche Tests finden längst nicht alles, eher im Gegenteil. Interessant ist aber, welche Fehler immer wieder auftauchen: schwache Kontraste, fehlende Alternativtexte, fehlende Formularbeschriftungen, leere Links, leere Buttons und fehlende Sprachangaben. Das sind keine exotischen Randthemen. Das sind Grundlagen.

Hinter diesen Fehlern steckt nicht immer fehlendes Spezialwissen. Oft wird an ihnen sichtbar, wo Design, Inhalt und Technik zu getrennt gedacht wurden.

Schwer wird es, weil diese Grundlagen an vielen Stellen gleichzeitig entstehen: im Designsystem, in Texten, im Komponenten-Code, im Content-Management, in Tests und in der späteren Pflege. Wenn dort niemand bewusst darauf achtet, finden sich kleine Barrieren schnell im Ergebnis wieder.

Saubere Grundlagen schlagen barrierefreie Kosmetik

Ich habe inzwischen eine gewisse Skepsis gegenüber Lösungen entwickelt, die Barrierefreiheit wie eine Schicht behandeln, die man nachträglich über ein Produkt legt. Besonders deutlich wird das bei Barrierefreiheits-Widgets oder Overlays, also nachträglich eingebundenen Bedienfeldern und Skripten, die bessere Kontraste, größere Schrift, Vorlesefunktionen oder Tastaturhilfen versprechen.

Solche Werkzeuge können im Einzelfall nützlich sein. Was sie aber nicht seriös leisten können, ist eine pauschale Garantie: Script einbinden, Anforderungen erfüllt. Die W3C Web Accessibility Initiative weist ausdrücklich darauf hin, dass kein Tool allein feststellen kann, ob eine Website barrierefrei ist. Viele Prüfungen brauchen menschliche Bewertung. Außerdem bezieht sich WCAG-Konformität auf vollständige Seiten und Prozesse, nicht nur auf einzelne Bedienelemente oder ein zusätzliches Bedienfeld, das über einer ansonsten problematischen Oberfläche liegt.

Wenn ein Checkout nicht mit Tastatur funktioniert, wenn ein Formular semantisch kaputt ist oder wenn Fehlermeldungen nicht sinnvoll mit den betroffenen Feldern verbunden sind, löst ein Overlay das Grundproblem nicht zuverlässig. Es kann sogar neue Reibung erzeugen, weil es in die Oberfläche eingreift, ohne deren fachliche und technische Logik wirklich zu verstehen.

Im Web beginnt vieles mit unspektakulär guter Technik. Native HTML-Elemente wie button, input oder a bringen Semantik und Bedienbarkeit mit, die man bei selbstgebauten Komponenten erst wieder herstellen muss. Die Tab-Reihenfolge sollte der sichtbaren und logischen Reihenfolge entsprechen. Wenn sich ein Dialog öffnet, muss klar sein, wo der Fokus ist und wie man wieder herauskommt.

Das ist kein nostalgisches Plädoyer für „früher war HTML besser“. Moderne Webanwendungen brauchen manchmal komplexe Komponenten. Aber je stärker eine Oberfläche vom nativen Verhalten des Browsers abweicht, desto mehr Verantwortung übernimmt das Team selbst. Wer aus einem div einen Button baut, muss anschließend alles nachbauen, was ein echter Button schon mitbringt: Tastaturbedienung, Fokus, Name, Rolle, Zustände und verlässliches Verhalten für assistive Technologien.

An dieser Stelle taucht in Projekten häufig ARIA auf. Die Abkürzung steht für Accessible Rich Internet Applications. Der Standard ermöglicht es Weboberflächen, zusätzliche Informationen an assistive Technologien weiterzugeben. Im HTML geschieht das über Attribute wie aria-expanded, aria-label oder role="dialog". Gedacht ist das vor allem für komplexe UI-Pattern, also wiederkehrende Interaktionsmuster wie Dialoge, Akkordeons, Menüs oder Tab-Navigationen. Ist ein ausklappbarer Bereich gerade offen? Welche Rolle hat ein Dialogfenster? Wie heißt ein Icon-Button, wenn im Button nur ein Symbol steht?

Das ist wertvoll, wenn es für eine Komponente kein passendes natives HTML-Element gibt oder native Elemente ergänzt werden müssen. ARIA ersetzt aber keine klare Oberfläche. Es beschreibt Rollen, Zustände und Beziehungen; es sorgt nicht von allein für Tastaturbedienung, gute Fokusführung oder verständliche Interaktion.

Der WebAIM-Report zeigt seit Jahren eine auffällige Verbindung zwischen viel ARIA und mehr erkennbaren Fehlern. Das heißt nicht automatisch, dass ARIA die Fehler verursacht. Komplexere Seiten nutzen häufiger ARIA. Aber es ist ein gutes Warnsignal: Komplexität macht Zugänglichkeit nicht leichter.

Aus meiner Sicht ist eine der wirksamsten Entscheidungen deshalb oft, weniger clever zu bauen. Sonderverhalten, visuelle Tricks ohne semantische Bedeutung und Komponenten für den Idealfall machen ein Angebot unnötig fragil. Klare Struktur, robuste Interaktion und Inhalte, die nicht gegen das Medium arbeiten, sind in vielen Fällen die bessere Grundlage.

Formulare zeigen uns die Wahrheit

Besonders deutlich wird das bei Formularen. Wahrscheinlich, weil Formulare der Ort sind, an dem digitale Angebote ihre Versprechen einlösen müssen. Eine Startseite kann freundlich wirken. Ein Serviceportal kann modern aussehen. Aber wenn ein Mensch am Ende an einem Pflichtfeld, einer Fehlermeldung oder einem unverständlichen Zwischenschritt scheitert, zählt der Rest wenig.

In Verwaltungsprojekten ist das noch einmal eine Ecke heikler. Bürger:innen suchen sich den Prozess nicht freiwillig aus. Wer einen Antrag stellen muss, eine Leistung braucht oder eine Frist einhalten soll, kann nicht einfach sagen: Dann nehme ich eben einen anderen Anbieter. Gerade deshalb reicht es nicht, digitale Verwaltungsleistungen formal online zu stellen. Sie müssen verständlich, bedienbar und verlässlich sein.

Ein gutes Formular erklärt, was gebraucht wird. Es verwendet nachvollziehbare Begriffe oder erklärt Fachbegriffe dort, wo sie unvermeidbar sind. Es markiert Fehler so, dass sie wahrnehmbar und korrigierbar sind. Es erhält Eingaben, wenn etwas schiefgeht. Es funktioniert auf kleinen Bildschirmen und zwingt Menschen nicht unnötig in Zeitdruck.

Nichts davon ist außergewöhnlich oder spektakulär. Darin liegt jedoch die Qualität: Der Prozess lässt Menschen nicht im falschen Moment allein.

Barrierefreiheit gehört in die laufende Arbeit

Der schwierigste Schritt ist selten, ein einzelnes Problem zu beheben. Der schwierigste Schritt ist, Barrierefreiheit aus der Nacharbeitslogik herauszubekommen.

Wenn ein Team erst kurz vor Veröffentlichung testet, findet es Probleme zu einem Zeitpunkt, an dem Änderungen teuer und unangenehm sind. Dann wird verhandelt: Muss das wirklich noch sein? Reicht das für den Launch? Können wir das in Phase zwei machen? Diese Gespräche kenne ich aus Projekten gut genug. Sie sind selten böse gemeint, aber sie zeigen, dass Barrierefreiheit nicht Teil der normalen Qualitätsdefinition war.

Besser wird es, wenn Zugänglichkeit in den Alltag rutscht: in Designsysteme mit semantisch und interaktiv sauberen Komponenten, in Redaktionsprozesse für Alternativtexte, Linktexte und verständliche Sprache, in Akzeptanzkriterien für die Bedienung jenseits von Maus und großem Bildschirm. Auch Tests gehören in diesen Alltag. Automatisierte Prüfungen sind hilfreich, ersetzen aber weder Tastaturtests und Screenreader-Checks noch echte Nutzungsszenarien.

Das muss nicht heißen, dass jedes Projekt sofort perfekt ist. Perfektion ist ohnehin ein schlechter Maßstab, wenn sie dazu führt, dass niemand anfängt. Aber es macht einen großen Unterschied, ob Barrierefreiheit als gelegentlicher Sondertermin behandelt wird oder als normale Eigenschaft guter Produktarbeit.

Gute Nutzererfahrung muss etwas aushalten

Für mich ist Barrierefreiheit weniger ein separates Fachthema als ein Realitätsabgleich. Sie fragt: Funktioniert unser Angebot auch dann, wenn nicht alle Umstände ideal sind? Wenn jemand anders sieht, hört, liest, navigiert, versteht oder eingibt, als wir es beim Entwerfen angenommen haben?

Diese Frage ist unbequem, weil sie viele Entscheidungen berührt: Gestaltung, Sprache, Code, Komponenten, Content-Management, Beschaffung, Tests, Betrieb. Barrierefreiheit lässt sich nicht vollständig an eine Person im Team delegieren. Das macht sie im Projektalltag manchmal mühsam.

Aber sie ist auch eine der verlässlichsten Methoden, um digitale Angebote besser zu machen: zugänglicher, klarer, stabiler, verständlicher.

Die Pflicht ist dabei kein Gegensatz zur Chance. Sie sorgt dafür, dass das Thema nicht beliebig bleibt. Bessere Nutzererfahrung entsteht im Alltag der Produktarbeit: in Entscheidungen über Sprache, Gestaltung, Komponenten, Tests und Pflege.

Barrierefreiheit gehört deshalb in dieselbe Qualitätsdefinition wie Verständlichkeit, Stabilität und Sicherheit. Dann muss ein Team kurz vor dem Launch nicht mehr fragen, ob dafür noch Zeit ist. Zugänglichkeit ist von Anfang an Teil der Arbeit und eine gemeinsame Aufgabe.