Barrierefreies CMS: Damit alle Inhalte erstellen können

Ein barrierefreies CMS hat zwei Seiten

Bei einer barrierefreien Website denken viele zuerst an die Menschen, die sie besuchen. Sie sollen Texte lesen, Formulare ausfüllen und alle Funktionen bedienen können. Doch vor der Veröffentlichung arbeiten andere Menschen mit dem Inhalt: Redakteur:innen laden Bilder hoch, schreiben Texte und aktualisieren Seiten.

Auch sie können auf eine Tastatur, einen Screenreader, starke Vergrösserung oder eine besonders übersichtliche Bedienung angewiesen sein. Ein CMS ist deshalb erst dann eine gute Grundlage, wenn es beide Seiten berücksichtigt:

• Menschen mit Behinderungen können das Redaktionssystem bedienen.
• Das System hilft allen Redakteur:innen, barrierefreie Inhalte zu erstellen.

Was muss im Backend zugänglich sein?

Das Backend ist der geschützte Arbeitsbereich einer Website. Dort entstehen Beiträge, Seiten, Veranstaltungen oder Produkte. Ein zugängliches Backend ermöglicht es beispielsweise, dass Redakteur:innen:

• alle wichtigen Funktionen mit der Tastatur erreichen,
• Felder und Schaltflächen mit einem Screenreader verstehen,
• den aktuellen Fokus deutlich erkennen,
• Fehlermeldungen wahrnehmen und den betroffenen Feldern zuordnen,
• auch bei starker Vergrösserung ohne Informationsverlust arbeiten.

Das betrifft nicht nur den Texteditor. Auch Medienbibliothek, Navigation, Dialogfenster, Vorschau und Veröffentlichung gehören zum Arbeitsablauf. Schon eine unbedienbare Bildauswahl kann verhindern, dass jemand einen Beitrag selbstständig fertigstellt.

Wie hilft ein CMS bei barrierefreien Inhalten?

Nicht jede Barriere entsteht beim Programmieren. Auch ein neuer Inhalt kann eine zugängliche Website verschlechtern – etwa durch unverständliche Linktexte, eine falsche Überschriftenfolge oder ein Bild ohne Beschreibung.

Ein sinnvoll eingerichtetes CMS versucht deshalb, Fehler gar nicht erst entstehen zu lassen:

• Die verfügbaren Inhaltsbausteine haben eine klare Aufgabe.
• Felder sind verständlich benannt und bei Bedarf erklärt.
• Ungeeignete Formatierungen stehen gar nicht zur Auswahl.
• Vor der Veröffentlichung werden wichtige Angaben verlangt.
• Redakteur:innen erhalten verständliche Hinweise statt technischer Fehlermeldungen.

Bei Bildern sollte beispielsweise eine bewusste Entscheidung erforderlich sein: Braucht das Bild eine aussagekräftige Beschreibung oder ist es rein dekorativ? Ein blosses Pflichtfeld genügt nicht, wenn dort anschliessend bedeutungslose Texte eingetragen werden.

Ist ein Headless CMS automatisch barrierefreier?

Bei einem klassischen CMS gehören Redaktionssystem und sichtbare Website eng zusammen. Ein Headless CMS trennt die Inhalte von ihrer Darstellung. Vereinfacht gesagt: Das CMS verwaltet die Inhalte, während die Website unabhängig davon entwickelt wird.

Das schafft mehr Freiheit. Das Entwicklungsteam kann die öffentliche Website ohne die Vorgaben eines fertigen Themes oder Page Builders umsetzen. Gleichzeitig trägt es mehr Verantwortung: Struktur, Bedienung und Ausgabe entstehen nicht automatisch. Headless ist deshalb kein Gütesiegel für Barrierefreiheit.

Der Vorteil liegt an einer anderen Stelle: Redaktionsoberfläche, Inhaltsmodell und Website können gezielt auf das Projekt abgestimmt werden. Redakteur:innen müssen dann nicht aus unzähligen Gestaltungsmöglichkeiten wählen, sondern arbeiten mit verständlichen und geprüften Bausteinen.

Warum wir für individuelle Websites Payload CMS einsetzen

Für die Entwicklung individuell konzipierter barrierefreier Websites haben wir uns bei Digital Barrierefrei für Payload CMS als Headless CMS entschieden. Ausschlaggebend ist seine Flexibilität: Wir können nicht nur die sichtbare Website entwickeln, sondern auch den Redaktionsbereich passend zu den Menschen und Aufgaben im Projekt gestalten.

In der Praxis kann das bedeuten:

• Redakteur:innen sehen nur die Felder und Funktionen, die sie wirklich benötigen.
• Komplexe Inhalte werden in verständliche Abschnitte gegliedert.
• Bei Bildern wird eine Beschreibung oder die Kennzeichnung als dekorativ verlangt.
• Eigene Eingabefelder und Bedienelemente können zugänglich umgesetzt werden.
• Regeln verhindern, dass wichtige Angaben versehentlich fehlen.

Payloads Redaktionsoberfläche lässt sich mit eigenen Komponenten erweitern. Diese Freiheit ist wertvoll, aber sie ist kein automatischer Nachweis für Barrierefreiheit: Jede Anpassung muss sorgfältig entwickelt und mit Tastatur sowie assistiven Technologien geprüft werden.

Auch Payload selbst beschreibt die vollständige Konformität seines Adminbereichs mit WCAG 2.2 AA derzeit noch als laufende Arbeit. Das ist eine wichtige Einschränkung – und zugleich ein Zeichen dafür, dass Accessibility öffentlich dokumentiert und systematisch getestet wird.

Welche CMS beschäftigen sich mit Backend-Barrierefreiheit?

Ein pauschales Ranking wäre unseriös. CMS entwickeln sich laufend weiter, und Erweiterungen oder individuelle Anpassungen können die Bedienung verbessern oder verschlechtern. Trotzdem lohnt sich ein Blick darauf, wie offen die Hersteller mit dem Thema umgehen.

WordPress

WordPress verfügt über eine grosse Accessibility-Community und verfolgt eigene Ziele für die Zugänglichkeit des Backends. Wie gut der konkrete Arbeitsablauf funktioniert, hängt jedoch stark von Editor, Plugins und individuellen Anpassungen ab. Mehr dazu erfährst du in unserem Artikel WordPress und Barrierefreiheit.

Payload CMS

Payload dokumentiert seine Arbeit in Richtung WCAG 2.2 AA und nennt automatisierte sowie manuelle Tests. Die vollständige Konformität des Adminbereichs ist noch nicht erreicht. Seine besondere Stärke ist die Möglichkeit, Datenmodell und Redaktionsoberfläche gezielt anzupassen.

Craft CMS

Craft CMS fällt durch seine Transparenz positiv auf. Das Team veröffentlicht sowohl einen Bericht zur Zugänglichkeit des Redaktionsbereichs als auch eine Auswertung nach den Richtlinien für Autorenwerkzeuge. Darin werden erreichte Kriterien ebenso genannt wie bestehende Probleme und Umgehungsmöglichkeiten. Vollständig barrierefrei ist Craft damit nicht automatisch – die offene Dokumentation ermöglicht aber eine fundiertere Beurteilung.

Directus

Directus dokumentiert konkrete Hilfen wie Tastaturnavigation, Sprungmenüs und Tastaturkürzel für seine Redaktionsoberfläche. Einen mit Craft vergleichbaren umfassenden Konformitätsbericht haben wir nicht gefunden. Deshalb gilt auch hier: Die entscheidenden redaktionellen Abläufe müssen im konkreten Projekt getestet werden.

Checkliste: Welches CMS passt zu deinem Team?

Die beste Wahl hängt nicht nur von einer Produktliste ab. Prüfe das CMS mit den Menschen, die später täglich damit arbeiten.

• Aufgaben: Können Beiträge, Bilder und andere wichtige Inhalte vollständig bearbeitet werden?
• Bedienung: Funktionieren diese Abläufe mit Tastatur, Screenreader und Vergrösserung?
• Übersicht: Lässt sich die Oberfläche auf wirklich benötigte Funktionen reduzieren?
• Inhalte: Unterstützt das System gute Überschriften, Bildbeschreibungen und verständliche Links?
• Fehler: Sind Hinweise verständlich und am richtigen Ort wahrnehmbar?
• Erweiterungen: Bleibt die Zugänglichkeit auch mit zusätzlichen Komponenten erhalten?
• Pflege: Wer prüft nach Updates und neuen Inhaltsbausteinen weiter?

Fazit: Barrierefreiheit beginnt vor der Veröffentlichung

Ein CMS verwaltet nicht einfach nur Daten. Es bestimmt mit, wer Inhalte erstellen kann und welche Fehler bei der täglichen Pflege entstehen. Ein zugängliches Backend schafft Selbstständigkeit für Redakteur:innen mit Behinderungen. Gute Leitplanken helfen gleichzeitig dem gesamten Team, barrierefreie Inhalte dauerhaft zu pflegen.

Ob WordPress, Payload, Craft oder Directus: Kein Produktname ersetzt die Prüfung der tatsächlichen Arbeitsabläufe. Entscheidend ist, das System passend zu den Menschen, Inhalten und Aufgaben des Projekts auszuwählen und einzurichten.

Quellen und weiterführende Informationen

• W3C: Authoring Tool Accessibility Guidelines (ATAG)
• Payload CMS: Accessibility des Admin Panels
• Craft CMS: Accessibility Conformance Report und ATAG Report
• Directus: Accessibility der Redaktionsoberfläche