Barrierefreie Website und BFSG: Was KMU prüfen sollten und was ein Overlay nicht leistet

Die Anfrage kommt nicht an, und niemand merkt es. Ein Besucher tippt sich per Tabulator durch das Kontaktformular, erreicht das Feld „Betreff“, und plötzlich springt der Fokus ins Leere: Das Dropdown ist ein selbst gebautes Element, das nur auf Mausklicks reagiert. Er gibt auf. In der Auswertung taucht dieser Moment nirgends auf, er sieht aus wie jeder andere Abbruch.

Angenommen, das wäre die Ausgangslage eines kleinen Dienstleisters mit gepflegter, optisch ansprechender Website. Das Design stammt aus einer guten Vorlage, die Texte sind sorgfältig, die Ladezeit stimmt. Dass die Seite für Menschen mit Sehbehinderung, mit Tremor, mit nur einer Hand oder schlicht ohne Maus kaum nutzbar ist, steht in keinem Bericht. Wer sie ausprobieren würde, hätte sie vermutlich längst repariert.

Barrierefreiheit ist deshalb weniger ein Thema der Moral als eines der Wahrnehmung: Man sieht die Barrieren nicht, solange man sie nicht selbst erlebt. Hinzu kommt, dass die Gruppe größer ist, als man denkt. Dauerhafte Einschränkungen gehören dazu, aber auch ein gebrochener Arm, grelles Sonnenlicht auf dem Smartphone, eine altersbedingt nachlassende Sehkraft oder ein schwacher Laptop-Monitor im Büro.

Für kleine Betriebe kommt ein nüchterner Gedanke hinzu: Jede Anfrage zählt. Wo ein Unternehmen nur wenige Kontakte pro Woche erhält, ist ein Formular, das einen Teil der Besucher ausschließt, kein Randthema der Technik, sondern ein verschenkter Auftrag. Wie groß dieser Anteil ist, lässt sich nicht pauschal beziffern. Sicher ist nur, dass er sich nicht von selbst zeigt und erst durch gezieltes Ausprobieren sichtbar wird.

Die Fehlerbilder wiederholen sich so stark, dass sie sich gut sortieren lassen. Grauer Text auf hellgrauem Grund, der edel wirkt und in der Praxis kaum lesbar ist. Ein Menü, das beim Überfahren mit der Maus aufklappt und per Tastatur nicht erreichbar ist. Ein Fokusrahmen, den ein Designer „für ein sauberes Bild“ per CSS entfernt hat. Bilder ohne Beschreibung oder mit dem Dateinamen als Beschreibung. Formularfelder, die nur durch einen Platzhaltertext erklärt werden, der beim Tippen verschwindet.

Dazu kommen Fehler in der Struktur, die man optisch nicht sieht. Überschriften werden nach Schriftgröße statt nach Bedeutung gewählt, Schaltflächen sind in Wirklichkeit anklickbare Textblöcke, ohne Rolle und ohne Tastaturfunktion. Ein Screenreader liest dann „Gruppe, Gruppe, Gruppe“ oder überspringt das Wichtigste. Für sehende Besucher bleibt das unsichtbar, weil das Auge aus Layout und Farbe Bedeutung ableitet, die der Code nicht liefert.

Warum bleibt es so lange unentdeckt? Weil die üblichen Qualitätskontrollen es nicht erfassen. Ein Design-Review prüft den Eindruck, ein Test prüft, ob der Button einen Klick auslöst, und Analytics zeigt Abbrüche ohne Ursache. Barrierefreiheit verlangt einen Blick, den im Alltag niemand einnimmt: die Seite ohne Maus, ohne Farbunterscheidung oder ohne Bild zu benutzen. Wer diesen Blick einmal trainiert hat, findet erstaunlich schnell Befunde.

Die Web Content Accessibility Guidelines, kurz WCAG, gliedern sich in vier Prinzipien. Inhalte müssen wahrnehmbar sein, die Bedienung muss möglich sein, Inhalte und Bedienung müssen verständlich bleiben, und der Code muss robust genug sein, damit unterschiedliche Technik ihn auslegen kann. Aus den Prinzipien ergeben sich Richtlinien und prüfbare Erfolgskriterien, die in drei Stufen A, AA und AAA eingeteilt sind. Für die Praxis spielt vor allem Stufe AA eine Rolle.

Der Nutzen der Prinzipien liegt darin, dass sie Fragen strukturieren. „Wahrnehmbar“ fragt, ob jemand den Inhalt über mindestens einen Sinneskanal erfassen kann. „Bedienbar“ fragt, ob jede Funktion ohne feine Mausführung, ohne Zeitdruck und ohne Gesten nutzbar ist. „Verständlich“ betrifft Sprache, Vorhersehbarkeit und Hilfe bei Fehleingaben. „Robust“ meint saubere Auszeichnung, damit Screenreader und andere Hilfsmittel nicht raten müssen.

Ein Beispiel macht es greifbar. Ein Reiter-Menü für Leistungen ist optisch klar, doch ohne Rollen und Zustände weiß ein Screenreader nicht, welcher Reiter aktiv ist (robust), die Pfeiltasten tun nichts (bedienbar), der aktive Reiter unterscheidet sich nur durch einen Farbton (wahrnehmbar), und die Beschriftungen sind Kürzel, die niemand erklärt (verständlich). Ein einziges Bauteil verletzt hier alle vier Prinzipien zugleich.

Wir setzen dieses Raster als Denkhilfe ein und nicht als Abhakliste. Eine Checkliste verleitet dazu, jedes Kriterium isoliert zu erledigen und das Ganze aus dem Blick zu verlieren. Besser ist die Frage pro Seitentyp: Wer könnte hier scheitern, und woran würde man es bemerken? Daraus entsteht eine Prüfung, die sich an der echten Nutzung orientiert und die Kriterien als Maßstab nutzt.

Der verlockendste Weg ist ein Overlay: ein Skript, das ein Symbol am Seitenrand einblendet und verspricht, die Website mit einer Zeile Code barrierefrei zu machen. Für kleine Betriebe ist das reizvoll, weil es günstig ist, schnell geht und nach Lösung klingt. Das Problem liegt im Mechanismus. Ein Skript, das zur Laufzeit im Browser Eigenschaften nachträglich verändert, kann fehlende Beschriftungen und falsche Struktur nur raten, nicht verlässlich ergänzen.

Hinzu kommt ein praktischer Konflikt. Nutzer von Screenreadern und Tastaturen haben ihre Hilfsmittel bereits eingerichtet, und ein zusätzliches Overlay kann sie stören, statt zu helfen. Dass Overlays fehlerhaften Code nicht beheben, ist in der Fachwelt breit bekannt, und etliche Betroffenenverbände lehnen sie ab. Eine Anzeige „barrierefrei“ auf der Website ersetzt zudem keine Prüfung und beweist keine Konformität.

Das heißt nicht, dass jede Anpassungsleiste nutzlos wäre. Eine Funktion zur Schriftvergrößerung oder zum Kontrastwechsel kann Komfort bringen. Sie ist aber ein Zusatz, kein Fundament. Entscheidend bleibt, dass die Seite ohne jedes Zusatzwerkzeug sauber gebaut ist. Wir empfehlen deshalb, die Ursache im Quellcode und in der Gestaltung zu beheben, was in aller Regel auch kosteneffizienter ist als eine dauerhafte Abo-Lösung, die nichts am Fundament ändert.

Bevor Sie ein solches Produkt einsetzen, lohnen sich drei Fragen an den Anbieter: Was genau wird verändert, und wo bleibt der Quellcode unberührt? Wer haftet, wenn die Seite trotz Siegel Barrieren enthält? Und was passiert mit Ihrer Seite, wenn Sie den Vertrag kündigen? Fallen die Antworten ausweichend aus, ist das selbst schon eine brauchbare Auskunft.

Das Barrierefreiheitsstärkungsgesetz, kurz BFSG, setzt eine europäische Richtlinie um und gilt in Deutschland seit Sommer 2025. Es richtet sich nicht an alle Websites, sondern an bestimmte Produkte und Dienstleistungen, die Verbrauchern angeboten werden. Im Mittelpunkt stehen etwa Online-Shops und andere Angebote, bei denen Verbraucher online einen Vertrag abschließen können. Für sehr kleine Unternehmen sind Ausnahmen vorgesehen, die von der Art der Leistung und der Betriebsgröße abhängen.

Ob Ihr Betrieb betroffen ist, hängt also vom Angebot ab und nicht von der bloßen Existenz einer Website. Ein Handwerksbetrieb, dessen Seite Leistungen vorstellt und Anfragen annimmt, steht anders da als ein Anbieter, der online Verträge mit Verbrauchern schließt. Diese Einordnung ist keine Rechtsberatung. Für verbindliche Aussagen zur eigenen Betroffenheit, zu Fristen, Pflichten und Folgen gehört die Frage an eine Rechtsberatung, die Ihr Angebot kennt.

Unabhängig von der rechtlichen Betroffenheit ist der technische Maßstab brauchbar. Die europäische Norm, auf die sich das Gesetz stützt, orientiert sich bei Webinhalten an den WCAG. Wer seine Website an WCAG 2.x Stufe AA ausrichtet, arbeitet mit einem breit anerkannten Maßstab und tut zugleich etwas für alle Besucher. Wir trennen die beiden Fragen bewusst: Die juristische Bewertung gehört in andere Hände, die technische Qualität lässt sich unabhängig davon verbessern.

Automatische Prüfwerkzeuge wie Lighthouse oder axe finden einen Teil der Fehler zuverlässig: fehlende Alternativtexte, zu geringe Kontraste, Formularfelder ohne Beschriftung, doppelte IDs, fehlende Sprachangabe. Sie erfassen aber nur einen Teil aller möglichen Probleme. Ob ein Alternativtext sinnvoll ist, ob die Fokusreihenfolge logisch verläuft oder ob eine Fehlermeldung verständlich ist, kann ein Skript nicht beurteilen. Ein grüner Wert bedeutet deshalb nicht „barrierefrei“, sondern „keine automatisch erkennbaren Fehler“.

Die zweite Schicht ist die manuelle Prüfung, die weniger aufwendig ist, als sie klingt. Legen Sie die Maus beiseite und arbeiten Sie die Seite mit Tabulator, Umschalt-Tabulator, Enter, Leertaste und Escape durch. Springt der Fokus logisch? Ist er jederzeit sichtbar? Lässt sich jedes Menü und jedes Dialogfenster bedienen und wieder verlassen? Danach vergrößern Sie die Ansicht auf 200 Prozent und prüfen, ob Inhalte abgeschnitten werden oder überlappen.

Die dritte Schicht ist eine Stichprobe mit einem Screenreader, etwa NVDA unter Windows oder VoiceOver auf dem Mac und iPhone. Der Aufwand lohnt sich für wenige Schlüsselwege: Startseite, eine Leistungsseite, das Kontaktformular. Wer den eigenen Betrieb einmal gehört hat, versteht Überschriftenstruktur und Linktexte anders. Die Stichprobe ersetzt keine Prüfung mit Betroffenen, zeigt aber zuverlässig grobe Fehler, die kein Werkzeug meldet.

Ein Beispiel für die Wechselwirkung der Schichten: Ein Werkzeug meldet „Bild hat Alternativtext“, und die manuelle Prüfung stellt fest, dass dort der Dateiname „IMG_2043“ steht. Formal erfüllt, praktisch wertlos. Umgekehrt findet das Werkzeug einen Kontrastwert von 3,2 zu 1 bei grauem Fließtext, den das Auge im Büro noch gut liest. Auf einem Smartphone im Freien wird er zum Hindernis.

Beim Kontrast gelten nach WCAG als Richtwerte ein Verhältnis von mindestens 4,5 zu 1 für normalen Text und 3 zu 1 für großen Text sowie für wichtige Bedienelemente und Grafiken. Prüfen lässt sich das mit Farbwerkzeugen und den Entwicklertools des Browsers. Die Korrektur sitzt meist in den Designvariablen, nicht auf der einzelnen Seite: Wird ein Grauwert im Farbsystem abgedunkelt, verbessern sich alle Stellen zugleich. Das spricht dafür, Farben zentral zu pflegen.

Für Tastatur und Fokus gilt eine einfache Regel: Nehmen Sie, wo möglich, native Elemente. Ein echtes Button-Element, ein echter Link und ein echtes Auswahlfeld bringen Tastaturbedienung, Rolle und Zustand mit. Selbstgebaute Konstrukte aus Div-Elementen müssen alles nachrüsten und scheitern häufig. Der Fokusrahmen sollte nie ohne Ersatz entfernt werden. Ein klarer, kontrastreicher Rahmen kostet wenig und macht die Seite für alle besser bedienbar, auch für jene, die schlicht lieber tippen.

Bei Texten für Bilder kommt es auf die Funktion an. Informative Bilder erhalten eine knappe Beschreibung dessen, was sie vermitteln, dekorative Bilder ein leeres Alt-Attribut, damit sie übersprungen werden. Ein Logo, das als Link zur Startseite dient, braucht den Namen des Ziels, nicht die Beschreibung des Bildes. Linktexte sollten für sich verständlich sein: „Leistungen im Überblick“ statt „mehr“. Bei Formularen gehört zu jedem Feld eine sichtbare, mit dem Feld verbundene Beschriftung, und Fehler werden im Text benannt, nicht nur rot markiert.

Zu den heikelsten Stellen gehören Elemente, die Dritte liefern. Ein Cookie-Banner, das sich über die Seite legt, aber den Fokus nicht verwaltet, kann Tastaturnutzer in einer Falle zurücklassen oder hinter sich weiterklicken lassen. Er muss per Tastatur bedienbar sein, den Fokus sinnvoll setzen und beim Schließen zurückgeben. Dasselbe gilt für eingebettete Karten: Eine interaktive Karte lässt sich per Tastatur oft kaum benutzen, daher gehört die Adresse zusätzlich als Text daneben.

Videos und Audioinhalte brauchen Untertitel oder ein Transkript, damit Gehörlose und Schwerhörige sie nutzen können, und bei reiner Bildinformation eine Beschreibung. Automatisch startende Medien sollten sich stoppen lassen. PDF-Dokumente wie Preislisten, Formulare oder Broschüren sind ein unterschätzter Bereich: Ein Scan ohne Textebene ist für Screenreader leer. Wo möglich, ist eine Seite mit echtem Text die bessere Form, das PDF bleibt als Ergänzung.

Ein weiterer Sonderfall sind Animationen und Bewegung. Wer Bewegungsempfindlichkeit hat, braucht eine Möglichkeit, Effekte zu reduzieren. Moderne Browser melden die Systemeinstellung „Bewegung reduzieren“, und die Gestaltung kann darauf reagieren, indem Parallax-Effekte und automatisch laufende Slider entfallen. Dasselbe gilt für Inhalte, die sich selbst verändern: Ein Karussell, das ohne Pause weiterläuft, nimmt Menschen die Zeit zum Lesen.

Schließlich Drittanbieter-Widgets wie Terminbuchung, Chat oder Bewertungsanzeige. Sie sind Teil Ihres Angebots, aber nicht Ihr Code. Hier lohnt es, vor der Einbindung zu prüfen, ob der Anbieter Barrierefreiheit dokumentiert, und im Zweifel eine Alternative anzubieten, etwa eine Telefonnummer oder ein einfaches Formular. Das ist unbequem, aber ehrlicher, als ein Hindernis hinter einem Siegel zu verstecken.

Eine Verbesserung der Barrierefreiheit erreicht zunächst eines: Mehr Menschen können Ihre Seite benutzen. Ob sich das in mehr Anfragen niederschlägt, lässt sich nicht pauschal sagen und hängt davon ab, wie viele Besucher bisher gescheitert sind. Klar ist, dass eine robuste Struktur, lesbare Kontraste und gut beschriftete Formulare auch Besuchern ohne Einschränkung helfen, weil Seiten klarer und schneller zu bedienen sind. Das ist ein Nebennutzen, aber kein bezifferbares Versprechen.

Messen lässt sich der Fortschritt an Indikatoren, die nah am Mangel liegen. Dazu zählen die Zahl der von Prüfwerkzeugen gemeldeten Verstöße je Seitentyp, die Zahl der Schlüsselwege, die sich vollständig per Tastatur abschließen lassen, und die Ergebnisse der Screenreader-Stichprobe, jeweils vor und nach der Überarbeitung. Auch der Anteil der Formularabbrüche am Kontaktformular ist aussagekräftig, sofern genug Besucher vorhanden sind, um Schwankungen zu überstehen.

Wichtig ist die Grenze: Eine Prüfung belegt, was an einem Stichtag gefunden wurde, keine dauerhafte Konformität. Neue Inhalte, ein Update oder ein Plugin können Barrieren zurückbringen. Ebenso wenig lässt sich aus einer technischen Prüfung ableiten, dass kein rechtliches Risiko besteht. Das wäre eine Aussage, die wir nicht treffen können und deshalb nicht treffen. Realistisch ist ein dokumentierter Stand mit klaren offenen Punkten und einer Routine, ihn zu halten.

Ein praktischer Maßstab für die Wirkung: Nach der Überarbeitung sollte eine Person, die die Seite nicht kennt, das Kontaktformular allein mit der Tastatur abschicken können und dabei jederzeit sehen, wo sie sich befindet. Gelingt das, ist das wichtigste Ziel dieser Phase erreicht, auch wenn weitere Punkte offen bleiben.

Barrierefreiheit ist am günstigsten, wenn sie von Beginn an mitgedacht wird. Eine Farbpalette mit geprüften Kontrasten, native Bedienelemente und eine sinnvolle Überschriftenstruktur kosten beim Bau fast nichts, in der Nachrüstung dagegen Zeit und Nerven. Wer eine Website neu aufsetzt oder überarbeitet, sollte die Kriterien deshalb in den Entwurf aufnehmen, statt sie am Ende zu prüfen. Für bestehende Seiten gilt: Vorlagen zuerst, Einzelseiten danach.

Ein zweiter Punkt betrifft die Redaktion. Technik schafft die Voraussetzungen, aber Alternativtexte, Linktexte und verständliche Sprache entstehen im laufenden Betrieb. Eine kurze Handreichung für alle, die Inhalte pflegen, bringt oft mehr als ein weiterer Prüfdurchgang. Drei Regeln genügen für den Anfang: Bilder beschreiben, Links erklären, Überschriften nach Bedeutung setzen.

Drittens hilft ein ehrlicher Umgang mit Zielkonflikten. Ein sehr dezentes, hellgraues Design und hohe Kontraste vertragen sich schlecht, und ein Karussell auf der Startseite ist selten das, was Besucher suchen. Solche Abwägungen sollten sichtbar entschieden werden: Wo die Gestaltung nachgibt, gewinnt die Lesbarkeit, und wo ein Kompromiss bleibt, wird er dokumentiert, damit die nächste Überarbeitung ihn nicht unbemerkt wiederholt.

Der nächste Schritt ist klein und braucht keine Vorkenntnisse. Rufen Sie Ihr Kontaktformular auf, legen Sie die Maus weg und versuchen Sie, eine Anfrage allein mit der Tastatur abzuschicken. Scheitern Sie, haben Sie einen konkreten Befund. Gelingt es, prüfen Sie den Kontrast Ihres Fließtextes und lassen Sie anschließend Lighthouse laufen. Wenn Sie danach eine Einschätzung wünschen, schauen wir uns Ihre Seite an und sagen Ihnen offen, wo der größte Hebel liegt und was sich nicht pauschal beantworten lässt.