Drupal hat unter den Open-Source-CMS eine der besten Bilanzen in Sachen Barrierefreiheit – und macht Ihre Website trotzdem nicht barrierefrei. Das sagt Drupal.org selbst: Ob eine fertige Drupal-Website zugänglich ist, hängt von Konfiguration, Inhalten, Contrib-Modulen, Themes und eigenem Code ab [3]. Diese Seite trennt, was der Core mitbringt, von dem, was Ihre Aufgabe bleibt – auf der Behördenwebsite wie im Drupal-Commerce-Shop.
Gilt das BFSG für Ihre Drupal-Website?
Das hängt davon ab, was die Website tut, nicht von Drupal. Das BFSG erfasst bestimmte Dienstleistungen für Verbraucherinnen und Verbraucher: elektronischer Geschäftsverkehr, Bankdienstleistungen, Telekommunikation, E-Books und Personenbeförderung. Wer über Drupal Commerce an Verbraucher verkauft, erbringt eine „Dienstleistung im elektronischen Geschäftsverkehr“ (§ 1 Abs. 3 Nr. 5 BFSG). Dafür gilt das Gesetz seit dem 28. Juni 2025 [1]. Es setzt den European Accessibility Act um; wer in andere EU-Länder verkauft, trifft dort auf vergleichbare nationale Gesetze [2].
Ausgenommen sind Kleinstunternehmen, die Dienstleistungen erbringen: weniger als zehn Beschäftigte und höchstens 2 Mio. € Jahresumsatz oder Jahresbilanzsumme (§ 2 Nr. 17, § 3 Abs. 3 BFSG) [1]. Beide Bedingungen müssen erfüllt sein; Einzelheiten stehen auf unserer Seite zur Ausnahme für Kleinstunternehmen. Ein reiner B2B-Shop erbringt keine Dienstleistung für Verbraucher.
Eine reine Informationswebsite eines Unternehmens ist in der Regel selbst keine der genannten Dienstleistungen – eine Buchungs- oder Bestellfunktion darauf kann es aber sein. Viele Drupal-Websites gehören Hochschulen, Ministerien und Kommunen. Öffentliche Stellen fallen stattdessen unter die BITV 2.0, mit eigener Erklärungs- und Feedbackpflicht. Den vollständigen Anwendungsbereich erklärt BFSG und European Accessibility Act, für Shops unser Überblick BFSG für Onlineshops.
Was Drupal mitbringt – und was nicht
Sie bekommen:
- Einen Core mit WCAG 2.2 AA als Ziel – und ein Gate. Der Drupal-Core zielt für die öffentliche Website wie für die Verwaltungsoberfläche auf WCAG 2.2 Stufe AA und behandelt Barrieren als Bugs: Ein Accessibility-Gate soll Änderungen am Core blockieren, die schwere Barrieren enthalten [3]. Für Redaktionsoberflächen gilt zusätzlich ATAG 2.0 als Maßstab [5].
- Olivero und Claro. Olivero ist das Standard-Frontend-Theme, Claro das Standard-Backend-Theme. Beide wurden mit Barrierefreiheit als Priorität entwickelt, einschließlich Navigationsmustern, Formularen und Fokusindikatoren [3][4].
- Schnittstellen für dynamische Seiten.
Drupal.announce()schickt Text an eine ARIA-Live-Region, und der TabbingManager hält den Tastaturfokus in einer Komponente, wenn das nötig ist [4]. Beides hilft nur dort, wo ein Modul oder Theme es tatsächlich aufruft. - CKEditor 5 mit Alt-Text-Feldern. Bildfelder und CKEditor 5 bieten Eingaben für Alternativtexte; in der Standardkonfiguration des Inhaltstyps „Article“ ist der Alt-Text Pflicht. Das Textformat „Basic HTML“ bietet Überschriften von H2 bis H6 [4].
- Inline Form Errors im Core. Dieses Core-Modul setzt Fehlermeldungen direkt an das betroffene Feld und ergänzt oben eine Zusammenfassung. Laut Drupal-Dokumentation sollten Websites, die WCAG erfüllen müssen und Formulare haben, es verwenden [7].
Sie bekommen nicht:
- Ihr Theme. Kaum eine produktive Website läuft mit einem unveränderten Olivero. Themes bestehen aus Twig-Templates, und jedes Template lässt sich überschreiben [8] – auch die, die Beschriftungen, Landmarks und Skip-Links ausgeben. Das Core-Gate reicht nicht bis in Ihr Theme.
- Barrierefreie Contrib-Module. Die Accessibility Coding Standards binden den Core und Drupals eigene Websites; Contrib-Module sollen sich daran orientieren [5]. Drupal.org sagt ausdrücklich, dass die Installation eines Barrierefreiheitsmoduls eine Website nicht konform macht [6].
- Disziplin in der Redaktion. Ein Textformat mit vollem HTML lässt jedes eingefügte Markup durch, und nichts hindert jemanden daran, eine Überschrift nach Schriftgröße auszuwählen.
- Einen barrierefreien Shop ab Werk. Drupal Commerce ist ein Contrib-Projekt mit eigenen Checkout-Abläufen und einer Zahlungsschnittstelle, die über weitere Module mehr als 100 Zahlungsanbieter anbindet [9]. Eine Zusage zur Barrierefreiheit enthält die Projektseite nicht.
Was wir auf Drupal-Websites finden
Eigene Themes, die Olivero rückgängig machen
Das typische Muster: ein Agentur-Theme, von Grund auf oder auf einem Basis-Theme gebaut, mit entfernten Fokusrahmen im CSS, einem Skip-Link, der aus html.html.twig verschwunden ist, und einer Farbpalette, deren Buttons und Links den Kontrast nicht schaffen. Überschriebene Formular-Templates verlieren manchmal das <label> oder das <fieldset> mit <legend>, das die Form API eigentlich erzeugt. Weil ein Template auf vielen Seiten erscheint, wird aus einem Fehler eine dreistellige Zahl von Befunden.
Menüs und Komponenten aus Contrib-Modulen
Mega-Menüs, Akkordeons, Tabs und Slider kommen meist aus Contrib-Modulen oder aus Komponenten eines Layout-Builders. Untermenüs öffnen sich nur beim Hovern, Aufklapp-Schalter sind Links ohne aria-expanded, und Akkordeon-Paneele sind div-Elemente, die keinen Fokus bekommen. Jedes Modul bringt eigenes Markup mit – zwei Akkordeons auf derselben Website können also auf verschiedene Weise scheitern.
Redaktionsinhalte in CKEditor 5
Auf inhaltsstarken Websites – Hochschulen, Behörden, Verbände – ist die Redaktion die größte Quelle von Befunden. Überschriften werden nach Größe gewählt, die Seite springt von h2 auf h5. Tabellen kommen per Copy-and-paste aus Word, ohne Kopfzellen. Linktexte lauten „mehr“ oder „hier“, untereinander in einer Teaserliste. Wo Bilder auf mehreren Seiten wiederverwendet werden, erscheint ein Alt-Text, der für einen Zusammenhang geschrieben wurde, in einem anderen, in den er nicht passt.
Views-Listen, Filter und Seitennavigation
Listen entstehen mit Views, das zum Core gehört und Filter für Besucher freigeben kann [10]. Laden diese Filter oder die Seitennavigation die Ergebnisse per AJAX nach, wird die Trefferzahl oft nicht angesagt, und der Fokus bleibt stehen oder springt an den Seitenanfang. Teaserlisten wiederholen „Weiterlesen“-Links, die ohne Kontext nichts sagen.
Formulare ohne Fehlermeldung am Feld
Kontaktformulare, Antragsformulare und Formulare aus Formular-Baukästen zeigen Fehler häufig nur gesammelt oben. Browser-Validierung und Drupals eigene Validierung können Unterschiedliches melden; die Drupal-Dokumentation weist darauf hin, dass Screenreader dann wenig hilfreiche Meldungen vorlesen können [7]. Pflichtfelder, die nur ein rotes Sternchen kennzeichnet, und Datumsauswahlen, die nur mit der Maus funktionieren, sind häufig.
Checkout und Zahlung in Drupal Commerce
Im Shop steht am meisten auf dem Spiel. Adressformulare brauchen korrekte autocomplete-Werte, der Warenkorb aktualisiert sich ohne Statusmeldung, und Kartenfelder oder Express-Buttons des Zahlungsanbieters kommen als Iframes, die einen title und eine saubere Fokusreihenfolge brauchen. Davor steht das Cookie-Banner, meist ein Contrib-Modul oder ein externes Skript.
Wo Sie zuerst prüfen sollten
| Kriterium | Warum bei Drupal | Automatisierbar |
|---|---|---|
| 1.3.1 Info und Beziehungen (A) | Eingefügte Tabellen, überschriebene Formular-Templates | Teilweise automatisiert |
| 2.4.6 Überschriften und Beschriftungen (AA) | Überschriften nach Größe in CKEditor 5 | Nur manuell |
| 1.1.1 Nicht-Text-Inhalt (A) | Wiederverwendete Medien, optionale Alt-Felder | Teilweise automatisiert |
| 2.4.4 Linkzweck (im Kontext) (A) | „Weiterlesen“ in Views-Teaserlisten | Teilweise automatisiert |
| 2.1.1 Tastatur (A) | Contrib-Menüs, Akkordeons, Datumsauswahl | Teilweise automatisiert |
| 2.4.7 Fokus sichtbar (AA) | Eigene Themes ohne Fokusrahmen | Teilweise automatisiert |
| 4.1.2 Name, Rolle, Wert (A) | Menü-Schalter, Akkordeon-Paneele | Teilweise automatisiert |
| 4.1.3 Statusmeldungen (AA) | AJAX-Filter, Warenkorb in Commerce | Nur manuell |
| 3.3.1 Fehlererkennung (A) | Formulare ohne Inline Form Errors | Nur manuell |
| 1.4.3 Kontrast (Minimum) (AA) | Theme-Farben, Buttons, Links | Automatisiert |
„Automatisiert“ heißt: Eine Regel kann das Kriterium allein entscheiden. „Teilweise automatisiert“ heißt: Eine Regel findet einen Teil der Fehler, den Rest muss ein Mensch beurteilen. Alle Kriterien stehen in WCAG 2.2 AA, Kriterium für Kriterium.
Eine sinnvolle Reihenfolge
- Ihr Theme an Olivero messen. Lassen Sie eine Staging-Kopie einmal mit Olivero als Frontend-Theme prüfen. Was dort verschwindet, stammt aus Ihrem Theme und seinen Twig-Overrides. Korrigieren Sie diese Templates zuerst – jede Korrektur wirkt auf allen Seiten, die sie ausgeben.
- Textformate einschränken. Geben Sie der Redaktion „Basic HTML“ mit einer CKEditor-5-Werkzeugleiste, die nur anbietet, was gebraucht wird. „Full HTML“ bleibt den wenigen, die es wirklich brauchen. Machen Sie den Alt-Text in Bildfeldern und Medientypen zur Pflicht.
- Inline Form Errors aktivieren und jedes Formular durchgehen. Kontakt-, Antrags- und Checkout-Formulare, mit der Tastatur, einschließlich der Fehlerzustände.
- Contrib-Module inventarisieren. Prüfen Sie für jedes Modul mit Ausgabe auf der öffentlichen Website die Issue-Queue auf Barrierefreiheitsfehler und entscheiden Sie: patchen, ersetzen oder dokumentieren.
- Die wichtigsten Strecken gehen. Im Shop: Kategorie → Filter → Produkt → Warenkorb → Kasse → Zahlung im Testmodus. Auf einer Behördenwebsite: Suche, ein Formular, ein Download.
- Nach Updates erneut prüfen. Core-Minor-Releases, Modul-Updates und eine neue Person in der Redaktion ändern, was die Website ausgibt. Ein regelmäßiger Crawl fängt Rückschritte früh ab.
Was Reviseberg auf Drupal-Websites prüft – und was Sie selbst testen
Reviseberg crawlt Ihre Website einschließlich Listen- und Detailseiten und führt auf jeder Seite alle axe-core-Regeln in einer Desktop-Breite von 1280 Pixeln aus. Die Regeln, deren Ergebnis vom Layout abhängt – etwa Kontrast und Zielgröße –, laufen zusätzlich bei 360 Pixeln. Die Ergebnisse sind WCAG 2.2 A/AA und EN 301 549 zugeordnet. Befunde werden je Regel zu Issues zusammengefasst und danach sortiert, wie viele Punkte ihre Behebung bringt. Ein Fehler in einem Twig-Template erscheint deshalb als ein Issue auf 400 Seiten und nicht als 400 Einzelbefunde.
Der Tastatur-Agent öffnet die Seiten einer Journey, die Sie festlegen – eine Liste, eine Detailseite, ein Formular, den Warenkorb –, drückt auf jeder Tab, Umschalt+Tab und Escape und protokolliert jeden Schritt. Er meldet unerreichbare Elemente, verschwindenden oder unsichtbaren Fokus, fehlende Skip-Links und Tastaturfallen. Formulare füllt er nicht aus, und er bestellt nicht. Fehlerzustände, die Kasse hinter einem gefüllten Warenkorb und das Zahlungs-Iframe gehen Sie also selbst. Der kostenlose Bericht umfasst bis zu 100 Seiten und den Tastatur-Agenten auf einer Seite Ihrer Wahl; eine passwortgeschützte Staging-Website crawlen wir nur aus einem Konto heraus.
Selbst testen müssen Sie weiterhin: ob Alt-Texte das Bild beschreiben, ob Überschriften und Fehlermeldungen verständlich sind und wie sich die Website mit Screenreader und Zoom verhält. Agenten für Screenreader, Zoom und Sprachsteuerung sind noch nicht gebaut. Für diese Kriterien gibt es geführte manuelle Tests in der Plattform, und ein Kriterium, das niemand geprüft hat, gilt als ungeprüft – nie als bestanden. PDF-Dokumente prüfen wir nicht; auf einer Behördenwebsite sollten Sie sie gesondert erfassen. Es gibt kein Drupal-Modul von uns, nichts wird automatisch in Ihre Website eingespielt, und wir setzen kein Overlay-Skript ein.
Geschrieben, um nützlich zu sein, nicht als Rechtsberatung. Stand: 27. September 2026.