Barrierefreie Website mit Drupal nach dem BFSG umsetzen

Eine barrierefreie Website können Menschen mit Behinderungen ohne fremde Hilfe nutzen: mit der Tastatur statt der Maus, mit vergrößerter Schrift oder mit einem Screenreader, einem Programm, das den Bildschirminhalt vorliest. Seit dem 28. Juni 2025 schreibt das Barrierefreiheitsstärkungsgesetz (BFSG) das für viele Online-Angebote an Verbraucher vor.

Drupal bringt dafür viel mit. Die eigentliche Arbeit steckt im Theme, also der Vorlage, die das Aussehen der Website bestimmt, und in den Inhalten. Unsere eigene Website redorbit.de haben wir im Oktober 2026 neu aufgesetzt und dabei nach diesen Anforderungen gebaut.

Wer seit Juni 2025 unter das BFSG fällt

Das BFSG gilt laut § 1 für Dienstleistungen, die nach dem 28. Juni 2025 für Verbraucher erbracht werden. Für Websites zählt vor allem, was das Gesetz „Dienstleistungen im elektronischen Geschäftsverkehr“ nennt. Gemeint sind Angebote, über die Verbraucher auf einer Website oder in einer App einen Vertrag anbahnen oder abschließen. Beispiele sind ein Onlineshop, eine Reisebuchung oder eine Terminbuchung.

Ausgenommen sind Kleinstunternehmen, die Dienstleistungen anbieten. Das Gesetz versteht darunter Unternehmen mit weniger als zehn Beschäftigten und höchstens zwei Millionen Euro Jahresumsatz oder Jahresbilanzsumme. Für Produkte gilt diese Ausnahme nicht.

Angebote nur für Geschäftskunden sind nach Einschätzung der Bundesfachstelle Barrierefreiheit, der zentralen Beratungsstelle des Bundes, voraussichtlich nicht betroffen. Das Gleiche gilt für reine Informationsseiten, über die keine Dienstleistung für Verbraucher angeboten wird.

Fällt Ihr Angebot unter das Gesetz, müssen Sie nach § 14 außerdem öffentlich und barrierefrei erklären, wie es die Anforderungen erfüllt. Zuständig für die Kontrolle sind die Marktüberwachungsbehörden der Länder. Wer vorsätzlich oder fahrlässig eine Dienstleistung anbietet, die die Anforderungen nicht erfüllt, handelt ordnungswidrig. Nach § 37 Abs. 1 Nr. 8 droht dann eine Geldbuße von bis zu 100.000 Euro.

Dieser Beitrag ist keine Rechtsberatung. Ob Ihr Angebot betroffen ist, klären Sie im Einzelfall mit einer Anwältin oder einem Anwalt.

Die Kriterien für eine barrierefreie Website

Eine eigene Checkliste enthält das BFSG nicht. Für Websites verweist die Bundesfachstelle auf die europäische Norm EN 301 549, die Anforderungen an barrierefreie Informationstechnik festlegt. Diese Norm übernimmt die Web Content Accessibility Guidelines (WCAG) 2.1. Herausgeber ist das W3C, das Gremium, das die Standards des Webs entwickelt.

Jedes Kriterium der WCAG gehört zu einer Stufe: A ist das Minimum, AA der übliche Maßstab, AAA geht darüber hinaus. Die EN 301 549 nennt für Websites die Stufen A und AA.

Mehrere Kriterien betreffen das Kontrastverhältnis. Es vergleicht die Helligkeit von Schrift und Hintergrund, von 1:1 ohne Unterschied bis 21:1 für Schwarz auf Weiß. Hellgraue Schrift auf weißem Grund fällt oft durch. Für jede Website relevant sind unter anderem diese Kriterien:

WCAG 2.2 ergänzt weitere Kriterien, darunter Klickflächen von mindestens 24 mal 24 Pixeln. Wer jetzt neu baut, sollte sie gleich einplanen, denn die nächste Fassung der EN 301 549 soll auf WCAG 2.2 verweisen.

Was Drupal ab Werk mitbringt

Der Core, also das Grundsystem von Drupal ohne Erweiterungen, hat ein festes Ziel: WCAG 2.2 in der Stufe AA, für die öffentliche Website und für die Verwaltungsoberfläche. Größere Änderungen am Core müssen dafür eine Prüfung auf Barrierefreiheit bestehen. Laut Drupal-Dokumentation ersetzt diese Prüfung keine vollständige Konformitätsbewertung.

Umgesetzt wird das Ziel in den beiden Standard-Themes. Olivero ist das Theme für die öffentlichen Seiten, Claro die Oberfläche, in der Redakteure arbeiten.

Für die Inhalte gibt es zwei Hilfen. Im Bildfeld ist der Alternativtext standardmäßig ein Pflichtfeld. Im Texteditor CKEditor 5 fragt Drupal nach dem Hochladen eines Bildes nach dem Alternativtext und zeigt einen Hinweis, solange er fehlt.

Fehlermeldungen in Formularen stehen bei Drupal normalerweise gesammelt oben auf der Seite. Das Core-Modul Inline Form Errors setzt sie direkt an das betroffene Feld. Es ist ab Werk ausgeschaltet.

Was das Theme leisten muss

Wer ein eigenes Design umsetzt, ersetzt Olivero durch ein eigenes Theme. Wie barrierefrei die Website dann ist, hängt davon ab, wie sorgfältig es gebaut ist.

• Kontrast. Alle Farbpaare aus dem Design werden nachgemessen, auch Text auf Fotos und Schrift auf farbigen Flächen.
• Fokus. Jedes Bedienelement bekommt eine sichtbare Markierung, die sich auch auf dunklem oder farbigem Hintergrund abhebt.
• Überschriften. Die Reihenfolge von H1 bis H3 folgt dem Inhalt, nicht der gewünschten Schriftgröße.
• Formulare. Jedes Feld hat eine Beschriftung, Pflichtfelder sind im Text erklärt, Fehler stehen am Feld.
• Bewegung. Animationen dürfen Inhalte nicht verdecken oder blass erscheinen lassen.

Wo HTML allein nicht reicht, hilft ARIA. ARIA ist eine Sammlung zusätzlicher Attribute im Code. Sie sagen Screenreadern zum Beispiel, welcher Hinweistext zu einem Feld gehört oder ob ein Menü geöffnet ist. ARIA ersetzt weder eine saubere HTML-Struktur noch die Bedienung per Tastatur.

Was wir bei redorbit.de geändert haben

Im neuen Theme von redorbit.de hat die Prüfung mehrere Stellen aufgedeckt, die im Design gut aussahen. Fließtext wurde beim Scrollen eingeblendet und war beim Laden halb durchsichtig, mit einem Kontrast unter 4,5:1. Heute gleitet er nur leicht ins Bild und ist dabei sofort voll sichtbar.

Auf der roten Fläche am Seitenende war der Fokusring nicht zu sehen, dort ist er jetzt weiß. Die Rahmen der Eingabefelder erreichten kein Kontrastverhältnis von 3:1 und sind dunkler geworden.

Links im Fließtext und in den FAQ-Antworten sind unterstrichen, weil Farbe allein als Unterscheidung nicht genügt. Kleine Links wie „Alle Referenzen“ haben eine Klickfläche von mindestens 24 mal 24 Pixeln.

Im Kontaktformular haben wir Inline Form Errors aktiviert. Jedes Feld ist über das Attribut aria-describedby mit seinem Hinweistext verbunden. Ein Satz oben im Formular erklärt die Pflichtfelder. Über das Attribut autocomplete kann der Browser Name und E-Mail-Adresse selbst eintragen.

Für die Redaktion gibt es Leitplanken. In unseren Inhaltsbausteinen mit Bild ist der Alternativtext Pflicht. Tabellen wie die in diesem Beitrag haben eine Beschriftung für Screenreader und ausgezeichnete Kopfzellen.

Nach dem Start der neuen Website erreichten Startseite und Kontaktseite in Lighthouse, dem Prüfwerkzeug in Google Chrome, 100 Punkte für Barrierefreiheit. Das gilt auch mit eingeblendetem Cookie-Banner. Wie wir Themes von Anfang an so planen, beschreiben wir auf der Seite zur Drupal-Theme-Entwicklung.

Ähnliche Funktionen haben wir mit Drupal-Modulen auch für Kunden umgesetzt, etwa bei Die Mitterfelder und Desideria.

Eine Website in sieben Schritten prüfen und barrierefrei machen

Automatische Tests finden nur einen Teil der Probleme. Lighthouse nennt selbst Punkte, die es nicht messen kann. Dazu gehört die Reihenfolge beim Springen mit der Tabulatortaste. Bei einer bestehenden Drupal-Website empfehlen wir dieses Vorgehen:

1. Seitentypen auswählen. Startseite, eine typische Inhaltsseite, ein Formular und der Bestellvorgang oder die Buchung decken die meisten Seitenarten ab.
2. Automatisch prüfen. Lighthouse oder ein vergleichbares Werkzeug zeigt fehlende Alternativtexte, zu schwache Kontraste und Felder ohne Beschriftung.
3. Mit der Tastatur durchgehen. Ohne Maus jede Funktion erreichen, vom Menü über den Cookie-Banner bis zum Absenden des Formulars. Der Fokus muss dabei immer sichtbar sein.
4. Mit einem Screenreader anhören. Die Screenreader NVDA unter Windows oder VoiceOver auf dem Mac zeigen, ob Überschriften, Links und Fehlermeldungen verständlich vorgelesen werden.
5. Vergrößern. Bei 200 Prozent Textgröße und auf dem Smartphone darf nichts abgeschnitten oder überlagert sein.
6. Inhalte prüfen. Alternativtexte, verständliche Linktexte und PDF-Dateien gehören ebenso dazu wie die Gestaltung.
7. Ergebnis festhalten. Die Liste der Befunde wird zum Arbeitsplan und später zur Grundlage der Erklärung zur Barrierefreiheit nach § 14 BFSG.

Was danach zu tun ist, hängt vom Zustand der Vorlage ab. Ein gepflegtes Theme lässt sich meist gezielt verbessern. Bei alten Vorlagen, etwa aus Drupal 7, ist ein Neubau oft der kürzere Weg. Darauf gehen wir auch im Beitrag zum Drupal-7-Update ein.

Wo Ihre Website steht, zeigt schon eine Prüfung der wichtigsten Seitentypen. Welche Schritte sich danach lohnen, klären wir gern in einer Drupal-Beratung.