Barrierefreiheit nachträglich einzubauen ist teuer. Das richtige CMS macht es von Anfang an richtig.
Seit das Barrierefreiheitsstärkungsgesetz im Juni 2025 in Kraft getreten ist, stellen sich viele Website-Betreiber dieselbe Frage: Welches CMS unterstützt Barrierefreiheit wirklich? Und was bedeutet "barrierefrei" in Bezug auf ein CMS überhaupt konkret?
Dieser Vergleich schaut sich vier relevante Systeme ehrlich an: WordPress, TYPO3, Contao und Lotse CMS. Kein Werbetext, keine erfundenen Testergebnisse. Stattdessen eine sachliche Einschätzung, was jedes System leistet und wo die Grenzen liegen.
Als Orientierungsrahmen dient die Checkliste für barrierefreie CMS von web-4-all.de, ergänzt um die Anforderungen der WCAG 2.1 und 2.2 auf Konformitätsstufe AA.
Was macht ein CMS eigentlich barrierefrei?
Hier liegt ein häufiges Missverständnis. Barrierefreiheit eines CMS ist keine einzelne Eigenschaft, sondern ein Zusammenspiel aus zwei Ebenen.
Ebene 1: Frontend-Output
Was gibt das CMS an den Browser aus? Ist der generierte HTML-Code semantisch korrekt? Werden ARIA-Labels korrekt gesetzt? Sind Kontraste im Standard-Theme WCAG-konform? Ist die Tastatursteuerung vollständig? Werden Formular-Labels programmatisch mit Eingabefeldern verknüpft?
Das ist die Ebene, die Endnutzer direkt betrifft. Eine sehbehinderte Person, die einen Screenreader nutzt, erlebt den Frontend-Output des CMS. Wenn der HTML-Code schlecht strukturiert ist, hilft kein Accessibility-Plugin der Welt.
Ebene 2: Backend-Zugänglichkeit
Kann ein Redakteur mit Einschränkungen den Admin-Bereich des CMS bedienen? Ist der Backend-Editor tastaturzugänglich? Können Bilder mit Alt-Texten versehen werden, ohne dass Entwicklerkenntnisse nötig sind? Gibt es Hinweise beim Einpflegen von Inhalten, die barrierefreies Arbeiten unterstützen?
Diese Ebene wird oft vergessen. Ein CMS, das barrierefreies Frontend produziert, aber einen unzugänglichen Admin-Bereich hat, löst das Problem nur halb.
Beide Ebenen zusammen bestimmen, wie barrierefrei eine Website auf einem CMS tatsächlich werden kann.
WordPress
Barrierefreiheit möglich, aber abhängig von Theme und Plugins
WordPress ist das meistgenutzte CMS der Welt, und die Barrierefreiheits-Community hat entsprechend viel Arbeit investiert. Der Gutenberg-Editor hat in den letzten Jahren erhebliche Fortschritte gemacht. Die offizielle WordPress-Accessibility-Gruppe pflegt einen eigenen Zweig, der sich ausschließlich mit Barrierefreiheit beschäftigt.
Was WordPress gut macht: Der Gutenberg-Block-Editor unterstützt Tastaturnavigation. Bilder können mit Alt-Texten versehen werden, mit einer klaren Eingabemaske. Die Überschriften-Hierarchie ist im Editor sichtbar. Für viele Standardfunktionen ist semantisches HTML möglich.
Das zentrale Problem: WordPress selbst ist nur der Kern. Deine Website besteht aus WordPress plus einem Theme plus einer variablen Anzahl Plugins. Und jedes dieser Elemente kann Barrierefreiheit brechen. Ein Theme mit schlechtem Kontrast, ein Slider-Plugin das ARIA-Rollen falsch setzt, ein Cookie-Banner der die Tastaturnavigation blockiert. Die Barrierefreiheit deiner WordPress-Website ist so gut wie das schwächste Glied in dieser Kette.
Backend-Zugänglichkeit: Der WordPress-Admin-Bereich ist grundsätzlich tastaturzugänglich, aber nicht in allen Bereichen vollständig konform. Für Redakteure ohne Einschränkungen funktioniert er gut. Für Nutzer, die auf Screenreader oder Tastatursteuerung angewiesen sind, gibt es Bereiche mit Verbesserungspotenzial.
Fazit WordPress: Barrierefreiheit ist mit WordPress erreichbar, erfordert aber sorgfältige Theme-Auswahl, Plugin-Disziplin und regelmäßige Überprüfung. Jedes Update kann neue Probleme einführen.
TYPO3
Technisch stark, aber komplex
TYPO3 ist im Enterprise-Bereich und bei größeren Organisationen etabliert, darunter viele öffentliche Einrichtungen, die schon länger unter Barrierefreiheitspflichten stehen als private Unternehmen. Das hat Spuren hinterlassen.
Was TYPO3 gut macht: Der Core produziert semantisch korrektes HTML. ARIA-Unterstützung ist tief integriert. TYPO3 hat eine lange Geschichte mit öffentlichen Auftraggebern, die WCAG-Konformität als Anforderung stellen. Es gibt offizielle Erweiterungen speziell für Barrierefreiheit und einen aktiven Accessibility-Arbeitskreis in der Community.
Das zentrale Problem: TYPO3 ist ein mächtiges System für komplexe Anforderungen. Für kleine Unternehmen ist es in den meisten Fällen deutlich überdimensioniert. Die Einrichtung, Pflege und Administration erfordern spezialisiertes Know-how. Ein kleiner Handwerksbetrieb oder ein Verein wird mit TYPO3 nicht glücklich werden, unabhängig von der Barrierefreiheitsqualität.
Backend-Zugänglichkeit: Das TYPO3-Backend hat erhebliche Fortschritte gemacht, ist aber komplex. Für Redakteure ohne technischen Hintergrund ist die Einarbeitungszeit nicht trivial.
Fazit TYPO3: Technisch eine der stärksten Optionen für Barrierefreiheit. Aber nur sinnvoll, wenn die Projektgröße und das Budget den Aufwand rechtfertigen. Für kleine Unternehmen ist es in der Regel keine passende Wahl.
Contao
Solider Track-Record in der deutschen CMS-Szene
Contao ist ein deutsches Open-Source-CMS mit einer aktiven Community und einem guten Ruf im Bereich Barrierefreiheit. Viele Entwickler im DACH-Raum setzen Contao gezielt ein, wenn Barrierefreiheit eine Anforderung ist.
Was Contao gut macht: Semantisches HTML ist im Core fest verankert. Die Contao-Community hat Barrierefreiheit früh ernst genommen, auch bevor das BFSG das Thema in den Fokus gebracht hat. Es gibt spezifische Erweiterungen für barrierefreie Formulare, Navigationselemente und Mediendarstellung. Die Backend-Zugänglichkeit ist besser als bei vielen Wettbewerbern.
Was zu beachten ist: Auch Contao ist ein komplexeres System, das Entwicklerkenntnisse für Einrichtung und Anpassung voraussetzt. Für reine Selbstpflege ohne technischen Hintergrund ist die Lernkurve nicht trivial. Zudem ist das Ökosystem deutlich kleiner als bei WordPress, was die Verfügbarkeit von Entwicklern und Dienstleistern einschränkt.
Backend-Zugänglichkeit: Gut. Contao hat hier einen erkennbaren Vorsprung gegenüber vielen anderen Systemen. Redakteure können in den meisten Bereichen ohne Barrieren arbeiten.
Fazit Contao: Eine ernsthafte Option für Projekte, bei denen Barrierefreiheit eine zentrale Anforderung ist und ein erfahrener Contao-Entwickler verfügbar ist. Kein System für schnelle Selbsteinrichtung.
Papoo
Dedizierte Barrierefreiheits-Positionierung
Papoo ist ein deutsches CMS, das sich explizit als barrierefreies und SEO-freundliches System positioniert. Es ist weniger bekannt als die anderen drei Systeme in diesem Vergleich, hat aber eine klare Ausrichtung.
Was Papoo gut macht: Die Barrierefreiheit ist kein nachträglicher Gedanke, sondern Teil der Kernpositionierung. Das System ist auf WCAG ausgerichtet und wird in der deutschen Barrierefreiheits-Community als Option genannt. Die Positionierung als SEO-freundliches und barrierefreies CMS gleichzeitig ist ein klarer Fokus.
Was zu beachten ist: Das Ökosystem ist sehr klein. Die Community ist überschaubar, die Anzahl verfügbarer Entwickler und Dienstleister gering. Wer langfristig plant und Entwickler-Unabhängigkeit wichtig ist, muss das einkalkulieren. Referenzprojekte und öffentliche Testergebnisse sind weniger verfügbar als bei den größeren Systemen.
Fazit Papoo: Eine Nischenlösung mit ernstem Barrierefreiheitsanspruch, aber begrenztem Ökosystem. Für Projekte geeignet, bei denen der Papoo-Entwickler direkt verfügbar ist.
Lotse CMS
WCAG 2.2 AA als Grundstruktur, ehrliche Einschränkungen
Lotse CMS ist eine deutschsprachige Service-Lösung auf Symfony-Basis, speziell für kleine Unternehmen, Vereine und Handwerksbetriebe entwickelt. Barrierefreiheit ist kein Feature, das man dazubuchen kann, sondern Teil der technischen Grundlage.
Was Lotse CMS gut macht:
WCAG 2.2 AA in der Grundstruktur. Jede Lotse-CMS-Website bringt semantisch korrektes HTML, sichtbare Fokus-Indikatoren, programmatisch verknüpfte Formular-Labels, korrekte ARIA-Rollen und eine kontrastreiche Farbpalette als Standard mit. Das ist nicht konfigurierbar, es ist einfach so.
Tailwind CSS mit barrierefreien Defaults. Das Frontend-Framework ist so konfiguriert, dass Kontraste und Fokus-Stile von Anfang an WCAG-konform sind. Wer eine Lotse-CMS-Website einrichtet, startet nicht bei null.
Kein Plugin-Risiko. Es gibt kein Plugin-Ökosystem, das die Barrierefreiheit brechen kann. Alle Funktionen sind fest integriert und werden gemeinsam entwickelt und getestet. Was heute konform ist, bleibt konform, es sei denn, du pflegst Inhalte ein, die selbst nicht barrierefrei sind.
Service-Modell statt freier Download. Alle Kunden sind bekannt. Wenn sich WCAG-Anforderungen ändern oder Korrekturen nötig sind, werden Kunden direkt informiert. Das ist ein anderes Modell als ein öffentliches Open-Source-CMS, bei dem jeder selbst verantwortlich ist.
Was ehrlich gesagt werden muss: Lotse CMS ist eine neue Marke mit kleinem Ökosystem. Es gibt keinen großen Entwickler-Markt, keine Community-Foren und keine hunderte Referenzprojekte. Die Barrierefreiheit der Grundstruktur ist korrekt umgesetzt, aber externe Audits durch unabhängige Stellen liegen zum Zeitpunkt dieses Artikels noch nicht vor. Und: Inhalte, die Nutzer selbst einpflegen, Bilder ohne Alt-Text, PDFs ohne Struktur, müssen weiterhin barrierefrei gestaltet werden. Das CMS kann das nicht automatisch erledigen.
Backend-Zugänglichkeit: Der Admin-Bereich ist auf die wesentlichen Funktionen reduziert: Texte bearbeiten, Bilder hochladen, Beiträge schreiben. Weniger Komplexität bedeutet weniger potenzielle Barrieren im Backend.
Fazit Lotse CMS: Sinnvoll für kleine Unternehmen, die eine wartungsarme, von Anfang an barrierefreie Website wollen und mit einem festen Ansprechpartner zusammenarbeiten. Nicht geeignet für Projekte, die ein großes Ökosystem, viele Entwickler-Optionen oder umfangreiche Individualentwicklung erfordern.
Du willst wissen, wie barrierefrei deine aktuelle Website ist?
Ich schaue mir die wichtigsten Punkte an und zeige dir, wo Handlungsbedarf besteht.
Kostenlosen Website-Check anfragen
Vergleichstabelle
Kriterium | WordPress | TYPO3 | Contao | Papoo | Lotse CMS |
|---|---|---|---|---|---|
Semantisches HTML | Abhängig von Theme | Gut im Core | Gut im Core | Gut | WCAG 2.2 AA Standard |
ARIA-Unterstützung | Abhängig von Theme/Plugins | Gut integriert | Gut integriert | Vorhanden | Fest integriert |
Kontrast-Management | Theme-abhängig | Theme-abhängig | Theme-abhängig | Fokus auf Kontraste | Tailwind-Defaults WCAG-konform |
Tastatur-Navigation | Abhängig von Theme/Plugins | Gut | Gut | Gut | Vollständig |
Plugin-Risiko | Hoch | Mittel | Niedrig | Niedrig | Keines (kein Plugin-System) |
Backend-Zugänglichkeit | Mittel | Mittel (komplex) | Gut | Gut | Gut (reduziert) |
Wartungsaufwand | Hoch | Hoch | Mittel | Mittel | Niedrig (Service-Modell) |
Ökosystem DACH | Sehr groß | Groß | Mittel | Klein | Sehr klein (neue Marke) |
Geeignet für KMU | Bedingt | Eher nicht | Bedingt | Bedingt | Ja (primäre Zielgruppe) |
Die Tabelle basiert auf öffentlich verfügbaren Informationen zu den jeweiligen Systemen sowie der Checkliste für barrierefreie CMS von web-4-all.de. Keine der Angaben basiert auf eigenen WCAG-Audits der verglichenen Systeme.
Was die Tabelle nicht zeigt
Zahlen und Kreuze in einer Tabelle sind hilfreich, aber sie bilden nicht die ganze Realität ab. Zwei Punkte sind wichtig:
Barrierefreiheit ist kein binärer Zustand. Ein CMS ist nicht "barrierefrei" oder "nicht barrierefrei". Es gibt ein Spektrum von sehr gut über akzeptabel bis problematisch. Und selbst ein CMS mit starker Barrierefreiheitsgrundlage kann durch schlecht eingepflegte Inhalte scheitern. Bilder ohne Alt-Text, PDFs ohne Struktur, Videos ohne Untertitel: Das liegt beim Redakteur, nicht beim CMS.
Die beste Bewertung nützt nichts ohne den richtigen Entwickler. Contao hat einen legitimen Barrierefreiheits-Track-Record. Aber wenn der Entwickler, der deine Contao-Website baut, Barrierefreiheit nicht ernst nimmt, nützt das nichts. Umgekehrt kann ein erfahrener WordPress-Entwickler mit dem richtigen Theme eine sehr barrierefreie Website bauen. Das System ist der Rahmen, der Entwickler füllt ihn aus.
Fazit: Das beste CMS für Barrierefreiheit ist das, dessen Entwickler Barrierefreiheit ernst nehmen
Das klingt wie eine Ausweichantwort. Es ist keine.
Kein CMS garantiert automatisch eine barrierefreie Website. Jedes System in diesem Vergleich kann für eine WCAG-konforme Website genutzt werden. Und jedes System kann scheitern, wenn Barrierefreiheit nicht aktiv mitgedacht wird.
Was ein CMS leisten kann: Es kann die Hürden senken oder erhöhen. Ein System, das semantisches HTML als Standard ausgibt, barrierefreie Fokus-Indikatoren mitliefert und kein Plugin-Ökosystem hat, das die Barrierefreiheit brechen kann, macht es einfacher, konform zu bleiben. Ein System, bei dem jedes neue Plugin ein potenzielles Risiko ist, macht es schwerer.
Wenn du eine neue Website planst und Barrierefreiheit eine Anforderung ist, frag deinen Entwickler konkret: Wie setzt du Tastatursteuerung um? Wie stellst du sicher, dass Formular-Labels korrekt verknüpft sind? Wie gehst du mit Kontrasten um? Die Antworten zeigen mehr als jede CMS-Statistik.
Und wenn du wissen willst, wie deine aktuelle Website in Sachen Barrierefreiheit dasteht:
Weitere Informationen zum BFSG und was es konkret für Website-Betreiber bedeutet, findest du hier: