Drupal barrierefrei — das System ist auf deiner Seite.

Wen es betrifft.

Die ersten beiden Zeilen sind für Drupal besonders relevant: Das System ist bei Behörden, Hochschulen und Forschungseinrichtungen stark verbreitet — also genau dort, wo Barrierefreiheit seit Jahren Pflicht ist und in Ausschreibungen geprüft wird (Wer ist betroffen).

Ich bin kein Rechtsanwalt; was hier steht, ist mein Verständnis der Lage nach Stand Oktober 2026. Die technische Umsetzung übernehme ich, die rechtliche Einordnung klärst du im Zweifel anwaltlich.

Was Drupal mitbringt.

Mehr als die meisten anderen Systeme. Das Projekt hat eigene Richtlinien zur Barrierefreiheit, prüft Beiträge zum Kern daraufhin und hat über Jahre konsequent nachgebessert. Konkret:

• Semantisch brauchbare Ausgabe in den Kernthemes.
• Ansagen für Statusänderungen — ein eigenes Werkzeug dafür ist im Kern.
• Tastaturbedienung im Verwaltungsbereich, einschließlich der Werkzeuge zum Sortieren.
• Beschriftungen und Fehlerbehandlung im Formularsystem.
• Pflichtfeld für Alternativtexte bei Bildern, standardmäßig aktiv.
• Sprachauszeichnung bei mehrsprachigen Installationen.

Der vorletzte Punkt ist bemerkenswert: Drupal verlangt beim Hochladen eines Bildes standardmäßig einen Alternativtext. Das verhindert eine ganze Klasse von Problemen, bevor sie entsteht — und es ist eine Einstellung, die man keinesfalls abschalten sollte, auch wenn die Redaktion sich beschwert.

Auch der Verwaltungsbereich ist weitgehend bedienbar. Das ist wichtiger, als es klingt: Barrierefreiheit betrifft nicht nur Besucher, sondern auch Mitarbeiter, die mit dem System arbeiten.

Das Theme.

Hier wird der Vorsprung des Kerns regelmäßig wieder abgegeben. Ein individuell gebautes Theme überschreibt Vorlagen — und dabei geht Struktur verloren.

Typische Funde:

• Überschriften nach Schriftgröße statt nach Gliederung gewählt.
• Fokusanzeige abgeschaltet, weil sie im Entwurf störte.
• Schaltflächen als gestaltete Flächen ohne Rolle und Namen.
• Entfernte Ansagebereiche, weil sie unsichtbar sind und überflüssig wirken.
• Sprungmarke entfernt, weil sie im Entwurf nicht vorgesehen war.
• Kontraste nach Markenvorgabe ohne Prüfung.

Punkt vier verdient Aufmerksamkeit: Der Kern erzeugt unsichtbare Bereiche, über die Statusmeldungen angesagt werden. Wer sie aus einer Vorlage entfernt, weil sie im Quelltext stören, nimmt Screenreader-Nutzern genau die Rückmeldung, die sie brauchen (Fokus und Kontraste).

Beim Prüfen hilft der Vergleich mit der Kernvorlage: Was wurde entfernt, und warum?

Formulare.

Drupals Formularsystem erzeugt von sich aus verknüpfte Beschriftungen, Pflichtfeldkennzeichnung und zugeordnete Fehlermeldungen. Das ist eine gute Grundlage — die üblichen Probleme entstehen trotzdem:

• Beschriftungen ausgeblendet zugunsten von Platzhaltertexten.
• Fehlermeldungen umgebaut und dabei die Zuordnung verloren.
• Bildabfrage zur Spamabwehr, die Menschen vollständig ausschließt.
• Mehrstufige Formulare ohne Ansage des Schrittwechsels.
• Beschreibungstexte nicht mit dem Feld verknüpft.

Punkt drei ist bei Behördenformularen ein echter Ausschluss und muss ersetzt werden — durch ein verstecktes Feld, eine Zeitmessung oder eine serverseitige Bewertung (Barrierefreie Formulare, Spamschutz ohne Bildabfrage).

Wer ein Formular-Modul einsetzt, prüft dessen Ausgabe gesondert: Die Qualität schwankt, und die Grundlage des Kerns gilt dort nicht automatisch.

Ansichten.

Ein Drupal-spezifisches Thema, das wenig beachtet wird. Ansichten erzeugen Listen, Tabellen und Blöcke — und die Ausgabeformate unterscheiden sich in ihrer Barrierefreiheit erheblich.

Besonders zu prüfen:

• Tabellenausgabe: Sind Kopfzeilen als solche ausgezeichnet? Gibt es eine Beschriftung der Tabelle?
• Sortierbare Tabellen: Sind die Sortierlinks verständlich benannt?
• Blätternavigation: Sind die Links aussagekräftig, oder stehen dort nur Zahlen?
• Filter: Haben die Felder Beschriftungen, und wird das Ergebnis angesagt?
• Leere Ergebnisse: Gibt es einen verständlichen Hinweis?

Punkt vier ist der häufigste Mangel: Nach dem Filtern tauscht sich die Liste still aus, und wer sie nicht sieht, weiß nicht, ob etwas passiert ist. Eine kurze angesagte Meldung mit der Trefferzahl löst das — Drupal bringt das Werkzeug dafür mit.

Medien und Alternativtexte.

Drupals Medienverwaltung pflegt Alternativtexte zentral und reicht sie an die Ausgabe durch. Dabei zu beachten:

Der Alternativtext kann am Medienobjekt oder an der Verwendung hinterlegt sein. Das ist sinnvoll, weil dasselbe Bild in verschiedenen Zusammenhängen unterschiedliche Beschreibungen braucht — und es ist eine Einstellung, die bewusst getroffen gehört.

Die Regel bleibt: Inhaltstragende Bilder bekommen eine Beschreibung ihrer Aussage, rein dekorative einen leeren Alternativtext. Dass Drupal einen Text erzwingt, ist gut — es verleitet aber dazu, bei Dekobildern etwas Beliebiges einzutragen. Für diesen Fall gibt es die Möglichkeit, das Bild als dekorativ zu kennzeichnen (Alt-Texte vorbereiten).

Beigesteuerte Module.

Hier liegen die echten Ausschlüsse. Die Qualität schwankt erheblich, und die Richtlinien des Kerns gelten für beigesteuerte Module nicht verbindlich.

Die üblichen Problemfälle: Bildergalerien und Schieberegler ohne Tastaturbedienung, Lightboxen ohne Ausstieg, Kartenmodule, Buchungs- und Kalendermodule, Diagrammmodule ohne Textalternative, und Einwilligungsbanner, die den Fokus einsperren.

Das Einwilligungsbanner verdient besondere Aufmerksamkeit: Es ist das Erste, was jeder sieht, und wenn es den Fokus festhält, ist die gesamte Website unbenutzbar (Cookie-Banner, Module bewerten).

Für öffentliche Stellen gehört die Barrierefreiheit eines Moduls deshalb in die Auswahlkriterien — gleichrangig mit der Abdeckung durch das Sicherheitsteam.

Redaktionelle Arbeit.

1. Überschriften als Gliederung, keine Ebene überspringen.
2. Linktexte, die für sich stehen.
3. Kein Text in Bildern, der nicht auch daneben steht.
4. Tabellen nur für Daten, mit Kopfzeile.
5. Dokumente prüfen — eingescannte PDFs sind für Hilfsmittel reine Bilder.
6. Videos mit Untertiteln.
7. Keine Information allein über Farbe.

Punkt fünf ist bei öffentlichen Stellen regelmäßig der größte Posten: Hunderte Satzungen, Merkblätter und Formulare als Scan. Die erste Frage ist nicht, wie man sie barrierefrei macht, sondern welche noch gebraucht werden — und ob der Inhalt nicht besser als Webseite steht.

Drupal hilft hier mit einem einstellbaren Textformat: Wer Redakteuren nur die Auszeichnungen erlaubt, die sinnvoll sind, verhindert einen Teil der Probleme technisch.

Erklärung zur Barrierefreiheit.

Für öffentliche Stellen Pflicht und detailliert geregelt: Stand der Barrierefreiheit, konkret benannte Einschränkungen, Alternativen, Rückmeldeweg, Hinweis auf die Durchsetzungsstelle, Angaben in leichter Sprache und Gebärdensprache.

Der Rückmeldeweg muss funktionieren und darf nicht nur ein Formular sein, das selbst nicht bedienbar ist. Nenn zusätzlich eine Adresse und eine Telefonnummer — und sorg dafür, dass jemand die Meldungen liest (Erklärung erstellen).

Schreib die Erklärung nach der ersten Behebungsrunde, nicht davor. Sonst beschreibt sie Vermutungen statt eines Zustands.

Prüfen.

1. Tastaturtest: Maus weglegen, wichtigsten Weg durchgehen.
2. Fokusanzeige überall sichtbar?
3. Kontraste messen, auch bei Knöpfen und Platzhaltern.
4. Zoom auf 200 und 400 Prozent.
5. Ansichten prüfen — Tabellen, Filter, Blätternavigation.
6. Formulare mit absichtlichen Fehlern testen.
7. Verwaltungsbereich mitprüfen, wenn Redakteure mit Einschränkungen arbeiten.
8. Automatisches Werkzeug als Vorfilter, nicht als Urteil.
9. Befunde nach Wirkung sortieren.

Punkt sieben wird fast immer vergessen und ist bei öffentlichen Stellen eine echte Anforderung: Auch Mitarbeiter haben Anspruch auf ein bedienbares System. Drupals Verwaltungsbereich ist dafür eine gute Grundlage — ein individuell angepasstes Administrations-Theme kann sie zunichtemachen (Richtig prüfen).

Umsetzen.

Die Reihenfolge: erst die echten Ausschlüsse — Tastaturbedienung, Fokus, Formularfehler. Dann Kontraste und Bedienelemente. Dann Theme-Vorlagen systematisch gegen die Kernfassung prüfen. Dann Ansichten. Zuletzt die Inhalte, verteilt über Monate.

Bei Drupal gibt es dabei einen angenehmen Hebel: Weil der Kern eine gute Grundlage liefert, besteht ein erheblicher Teil der Arbeit darin, Abweichungen im Theme zurückzunehmen statt etwas Neues zu bauen. Das ist schneller, als es klingt.

Und wenn ohnehin ein Versionssprung ansteht: dort mitmachen. Nachträglich einzubauen kostet deutlich mehr (Update auf Drupal 11, Aufwand und Kosten).

Wenn du nicht weiterkommst.

Wenn Barrierefreiheit gefordert ist und du wissen musst, was bei deiner Installation konkret ansteht. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Bei einem laufenden Ausfall hilft der Notfall-Support, dauerhaft begleitet die Drupal-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Content-Management-Systeme sind mein Fachgebiet — ich arbeite seit Jahren damit, unterrichte das Thema als Dozent und kenne die Systeme nicht nur aus der Anwendung, sondern von innen: Datenmodell, Rechtekonzept, Templating, Modularchitektur, Caching, Betrieb.

Bei Drupal zahlt sich das besonders aus, weil das System konsequenter durchkonstruiert ist als die meisten anderen: Alles ist Entität, alles hat Felder, alles läuft über definierte Schnittstellen. Wer dieses Modell verstanden hat, findet Fehler schnell — und sieht auch, wo eine Installation gegen das Modell gebaut wurde.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung dazu, ob deine Installation weiterbetrieben, aktualisiert oder abgelöst gehört — auch wenn die Antwort lautet, dass alles so bleiben kann.