Ratgeber BFSG · Stand 30.10.2026
Welches Content-Management-System eignet sich für eine barrierefreie Website nach BFSG? Was die Projekte selbst zusagen, wo die Grenzen liegen und worauf es in der Praxis ankommt.
Von Patrick Schlesinger, Gründer von CMS ADMINS · WordPress- und Drupal-Betreuung aus München seit 2012
Start › Barrierefreiheit für Websites › Barrierefreies CMS
Kein CMS macht eine Website automatisch barrierefrei. Das System liefert die Grundlage, über das Ergebnis entscheiden Theme, Erweiterungen, Inhalte und die laufende Pflege.
| Kurzantwort | WordPress und Drupal haben sich offiziell auf WCAG 2.2 Stufe AA verpflichtet. Bei TYPO3 ist ein barrierefreies Frontend laut Accessibility-Team möglich, die Redaktionsoberfläche gilt dort selbst noch nicht als barrierefrei. |
| WordPress | Code in WordPress Core, auf WordPress.org und in offiziellen Plugins soll WCAG 2.2 AA erfüllen (WordPress Accessibility Coding Standards). |
| Drupal | Drupal Core zielt auf WCAG 2.2 AA für Website und Verwaltungsoberfläche und orientiert sich für die Redaktion an ATAG 2.0. |
| TYPO3 | Barrierefreies Frontend möglich, Standard-Rendering wird weiter verbessert. Die Redaktionsoberfläche ist nach Aussage des TYPO3-Accessibility-Teams noch nicht barrierefrei. |
| Rechtsrahmen | Das Barrierefreiheitsstärkungsgesetz (BFSG) gilt seit dem 28. Juni 2025 unter anderem für Online-Shops und andere Dienstleistungen im elektronischen Geschäftsverkehr. Prüfmaßstab in der Praxis: EN 301 549 mit WCAG 2.1 AA. |
| Unsere Rolle | CMS ADMINS betreut WordPress- und Drupal-Websites und prüft sie nach BFSG. Details zu Audit, Schulung und Beratung: Barrierefreiheit für Websites. |
Ein barrierefreies CMS erfüllt zwei Aufgaben: Es gibt zugängliche Webseiten aus, und es lässt sich selbst barrierefrei bedienen. Beide Ebenen beschreibt das W3C in eigenen Richtlinien.
Was ist ein barrierefreies CMS?
Ein Content-Management-System, dessen Ausgabe die Web Content Accessibility Guidelines (WCAG) erfüllen kann und dessen Redaktionsoberfläche den Authoring Tool Accessibility Guidelines (ATAG 2.0) folgt. ATAG beschreibt laut W3C, wie Autorenwerkzeuge selbst zugänglich werden und wie sie Redakteure beim Erstellen barrierefreier Inhalte unterstützen.
Ebene 1, die Ausgabe (Frontend): Hier gelten die WCAG. Entscheidend sind semantisches HTML, eine logische Überschriftenstruktur, Tastaturbedienung mit sichtbarem Fokus, ausreichende Kontraste, Alternativtexte und verständliche Formulare.
Ebene 2, die Redaktion (Backend): Menschen mit Behinderung sollen Inhalte auch pflegen können. Ein gutes System hilft außerdem allen Redakteuren, etwa mit Pflichtfeldern für Alternativtexte oder Hinweisen bei fehlenden Überschriften.
Für das BFSG zählt vor allem Ebene 1: Ihr Angebot für Verbraucher muss barrierefrei nutzbar sein. Welche Pflichten und Übergangsfristen konkret gelten, erklären wir im BFSG-Ratgeber mit WordPress-Checkliste.
Die Tabelle fasst zusammen, was die drei Projekte auf ihren offiziellen Seiten zur Barrierefreiheit sagen (Abruf am 30.10.2026). Sie ersetzt keine Prüfung Ihrer konkreten Website.
| Kriterium | WordPress | Drupal | TYPO3 |
|---|---|---|---|
| Offizielles Ziel | WCAG 2.2 Stufe A und AA für Core, WordPress.org und offizielle Plugins | WCAG 2.2 AA für öffentliche und administrative Oberflächen von Drupal Core | Keine WCAG-Version als Ziel genannt; barrierefreies Frontend laut Team möglich |
| Redaktionsoberfläche | Admin-Bereich soll WCAG 2.2 AA erfüllen, soweit möglich; ATAG 2.0 wird für neue Oberflächen empfohlen | ATAG 2.0 dient als Leitlinie für die Redaktion | Laut Accessibility-Team noch nicht barrierefrei |
| Einschränkung laut Projekt | Gilt für Core und offizielle Komponenten, nicht für beliebige Themes und Plugins | Standards bedeuten laut drupal.org nicht, dass jede Drupal-Website oder jedes Modul konform ist | Standard-Rendering soll weiter verbessert werden |
| Was das Ergebnis bestimmt | Theme, Page-Builder, Plugins, Inhalte | Theme, Contrib-Module, Inhalte | Templates, Extensions, Inhalte |
| Betreuung durch CMS ADMINS | WordPress Wartung und BFSG-Audit | Drupal Wartung und BFSG-Audit | Nicht in unserem Leistungsportfolio |
WordPress Core ist auf WCAG 2.2 AA ausgerichtet, die meisten Barrieren entstehen jedoch in Theme, Page-Builder und Plugins. Prüfen Sie deshalb immer die ausgelieferte Seite, nicht das System an sich.
Ein sogenanntes Overlay-Plugin ersetzt diese Arbeit nicht. Ob eine Seite die Anforderungen erfüllt, entscheiden das ausgelieferte Markup und die tatsächliche Bedienbarkeit mit Tastatur und Screenreader.
Drupal nennt Barrierefreiheit ausdrücklich als Ziel für Website und Verwaltungsoberfläche. Das passt zu Organisationen mit vielen Redakteuren und strengen Vorgaben, etwa Verwaltungen. Contrib-Module und eigene Themes müssen trotzdem einzeln geprüft werden, darauf weist drupal.org selbst hin.
TYPO3 erlaubt nach Aussage seines Accessibility-Teams schon heute ein barrierefreies Frontend. Für die Redaktionsoberfläche gilt das nach derselben Quelle noch nicht. Wenn Mitarbeitende mit Behinderung Inhalte pflegen sollen, sollten Sie diesen Punkt vor der Systemwahl klären.
In den meisten Fällen nein. Ein Systemwechsel allein macht keine Website barrierefrei, weil Theme, Templates und Inhalte neu entstehen und erneut geprüft werden müssen.
Sinnvoller ist meist dieser Weg: Zuerst ein Audit der bestehenden Website, danach die Korrektur von Theme, Formularen und Inhalten. Ein Wechsel lohnt sich vor allem dann, wenn ohnehin ein Relaunch ansteht oder das alte System keine Updates mehr erhält. Dann gehört Barrierefreiheit von Anfang an ins Pflichtenheft.
Passende Leistungen: BFSG-Audit und Beratung sowie WordPress-Relaunch.
Eine pauschale Rangfolge gibt es nicht. WordPress und Drupal haben sich offiziell auf WCAG 2.2 AA verpflichtet, bei TYPO3 gilt die Redaktionsoberfläche laut eigenem Accessibility-Team noch nicht als barrierefrei. Entscheidend für Ihre Website sind aber Theme, Erweiterungen und Inhalte. Ein gut umgesetztes Projekt auf jedem der drei Systeme kann barrierefrei sein.
WordPress Core, WordPress.org und offizielle Plugins sollen laut den WordPress Accessibility Coding Standards WCAG 2.2 auf Stufe AA erfüllen. Das gilt nicht automatisch für Themes, Page-Builder und Plugins von Drittanbietern. Ob Ihre WordPress-Website barrierefrei ist, zeigt erst eine Prüfung der ausgelieferten Seiten mit Tastatur, Screenreader und Prüfwerkzeugen.
Drupal Core zielt nach Angaben von drupal.org auf WCAG 2.2 AA für öffentliche und administrative Oberflächen und orientiert sich für die Redaktion an ATAG 2.0. drupal.org betont selbst, dass dies nicht jede Drupal-Website und jedes Zusatzmodul konform macht. Eigene Themes und Contrib-Module müssen deshalb gesondert geprüft werden.
Laut dem TYPO3-Accessibility-Team ist ein barrierefreies Frontend mit TYPO3 bereits möglich, das Standard-Rendering soll weiter verbessert werden. Die Redaktionsoberfläche bezeichnet das Team selbst als noch nicht barrierefrei. Für Websites ist TYPO3 damit nutzbar, für barrierefreie Redaktionsarbeit derzeit eingeschränkt.
Meistens nicht. Das BFSG verlangt ein barrierefreies Angebot, kein bestimmtes System. In der Regel reichen ein Audit und die Korrektur von Theme, Formularen und Inhalten. Ein Wechsel ist vor allem dann sinnvoll, wenn ohnehin ein Relaunch geplant ist oder das bisherige System keine Sicherheitsupdates mehr bekommt.
Nein. Plugins mit Werkzeugleiste oder Overlay ändern nichts an fehlerhaftem Markup, fehlenden Labels oder einer unlogischen Tastaturreihenfolge. Hilfreich sind Plugins höchstens für einzelne Aufgaben, etwa Prüfhinweise im Editor. Die eigentliche Arbeit steckt in Theme, Formularen und Inhalten.
Das BFSG und die Verordnung zum BFSG nennen keine WCAG-Version direkt. In der Praxis dient die europäische Norm EN 301 549 als Prüfmaßstab, die für Webinhalte auf WCAG 2.1 Stufe AA verweist. WCAG 2.2 ist seit dem 12. Dezember 2024 W3C-Empfehlung und baut auf 2.1 auf. Wer nach 2.2 AA arbeitet, erfüllt damit auch 2.1 AA.
Wir prüfen WordPress- und Drupal-Websites sowie Online-Shops nach BFSG und WCAG, mit Fehler-Report und priorisierten Empfehlungen.
Oder per E-Mail: support@cms-admins.de
Stand: 30.10.2026. Dieser Beitrag ist eine fachliche Einordnung und keine Rechtsberatung.
Audit, Schulung und Beratung nach BFSG für Websites und Shops.
Pflichten, Übergangsfristen nach § 38 BFSG und WordPress-Checkliste.