Was bedeutet Headless und was hat es mit Barrierefreiheit zu tun?

Headless heißt, dass ein CMS oder Shopsystem nur Inhalte verwaltet und über eine Schnittstelle ausliefert. Die Darstellung, der Kopf, wird getrennt davon gebaut, etwa als Website, App oder Sprachausgabe.

Stell dir einen Container voller Inhalte vor, aus dem Leitungen zu Website, Smartphone, Smartwatch und Lautsprecher führen. Ein Text wird einmal gepflegt und landet überall. Das ist der große Vorteil von Headless, und für die Barrierefreiheit Chance und Risiko zugleich.

Denn ein Headless CMS ist weder barrierefrei noch unzugänglich. Ob Menschen mit Screenreader, Tastatur oder Vergrößerung die Inhalte nutzen können, entscheidet sich an zwei Stellen: im Inhaltsmodell des CMS und im Frontend, das die Inhalte darstellt.

Headless ist bei NCA Alltag. Wir arbeiten täglich mit Sulu als CMS und Astro, React und Vue im Frontend. Dabei sehen wir, wo Barrierefreiheit in entkoppelten Systemen verloren geht: im Inhaltsmodell, in der Übergabe von Rich Text und in Komponenten, die jedes Frontend neu erfindet.

Wir helfen Teams, Barrierefreiheit in beide Hälften einzubauen. Im CMS legen wir Pflichtfelder für Alternativtexte, Sprachangaben und Untertitel an. Im Frontend setzen wir die Inhalte mit semantischem HTML und barrierefreien Astro Komponenten um. Für Inhalte, die als Sprachausgabe oder in Apps landen, denken wir Text to Speech und eine saubere Lesereihenfolge gleich mit. Die Qualität halten wir über automatisiertes Accessibility Testing in der Pipeline, eingebettet in unsere Arbeit im barrierefreien Webdesign.

Bei einem klassischen CMS liefert das System das fertige HTML gleich mit. Bei Headless teilt sich die Verantwortung auf zwei Seiten auf:

• Das Inhaltsmodell im CMS: Gibt es ein Feld für den Alternativtext, und ist es Pflicht? Werden Überschriften als Ebenen gespeichert oder nur als fett formatierter Text? Lässt sich bei einem Zitat in einer anderen Sprache die Sprache angeben? Hat ein Video ein Feld für die Untertiteldatei?
• Das Frontend: Macht aus den Daten echtes HTML mit Überschriften, Listen, Buttons und Landmarks. Setzt den Alternativtext ins richtige Attribut. Führt den Fokus bei Seitenwechseln ohne Neuladen.

Fehlt etwas im Inhaltsmodell, kann das beste Frontend es nicht herzaubern. Ist das Inhaltsmodell perfekt, aber das Frontend baut alles aus div Elementen, kommt beim Nutzer trotzdem nichts an. Barrierefreiheit braucht bei Headless beide Hälften.

Der Lohn: Wer es einmal sauber aufsetzt, bekommt Barrierefreiheit auf jedem Kanal. Derselbe Alternativtext landet auf der Website, in der App und in der Sprachausgabe.

Ein gutes Inhaltsmodell macht Barrierefreiheit zur Standardeinstellung statt zur Zusatzaufgabe. Diese Felder und Regeln haben sich bewährt:

• Alternativtext als Pflichtfeld an jedem Bild, mit der Option „dekorativ“, die bewusst angehakt werden muss.
• Strukturierter Rich Text mit echten Überschriften Ebenen, Listen und Links, nicht nur Schriftgröße und Fettdruck.
• Sprachangabe pro Seite und für einzelne Abschnitte in anderen Sprachen, damit Screenreader die richtige Aussprache wählen.
• Untertitel und Transkript als Felder an jedem Video.
• Linktexte statt „hier klicken“: Redaktionshinweise direkt im Feld helfen, aussagekräftige Linktexte zu schreiben.
• Kurzfassung in Einfacher Sprache als optionales Feld für wichtige Inhalte.

In Sulu lassen sich solche Felder direkt in den Seitenvorlagen anlegen und als Pflicht markieren. Andere Headless Systeme bieten vergleichbare Validierungen.

In vielen Headless Projekten ist die Website barrierefrei, aber die App oder der Newsletter nicht. Die Tabelle zeigt, wie weit Barrierefreiheit in einem entkoppelten Setup reicht und was es für die nächste Stufe braucht.

Das Bild aus der API. Ein gutes Inhaltsmodell liefert neben der Bildadresse auch den Alternativtext und die Angabe, ob das Bild dekorativ ist.

Eine Astro Komponente, die nichts vergisst. Ist das Bild dekorativ, bekommt es ein leeres alt. Fehlt der Alternativtext bei einem inhaltlichen Bild, bricht der Build ab, statt eine Lücke auszuliefern.

Alle Kanäle prüfen. Der Cypress Test lädt die Inhalte direkt aus der API und kontrolliert, dass jedes nicht dekorative Bild einen Alternativtext hat, bevor das Frontend sie überhaupt anzeigt.

1. Alternativtext gepflegt, aber nicht ausgegeben. Das Feld existiert im CMS, das Frontend nutzt nur die Bildadresse.
2. Rich Text als HTML Brei. Die API liefert Fließtext mit Inline Styles statt strukturierter Überschriften und Listen.
3. Überschriften frei wählbar. Redakteure nehmen H4, weil die Schrift schöner aussieht, und brechen die Gliederung.
4. Kein Fokus nach Seitenwechsel. Das Frontend lädt Seiten ohne Neuladen, aber Screenreader erfahren nichts davon.
5. Jeder Kanal baut eigene Komponenten. Website, App und Kiosk lösen dieselbe Aufgabe dreimal, mit drei verschiedenen Barrieren.
6. Sprache fehlt. Die API liefert keinen Sprachcode, das Frontend setzt kein lang Attribut.

Der größte Hebel bei Headless liegt im Inhaltsmodell. Eine Stunde, in der Entwicklung und Redaktion gemeinsam festlegen, welche Felder Pflicht sind, spart später hunderte Korrekturen in jedem einzelnen Kanal. Danach braucht es nur noch Komponenten, die diese Felder sauber ausgeben.

Headless berührt viele Themen der Barrierefreiheit. Bilder brauchen gute Regeln für Nicht-Text-Inhalte, Überschriften folgen den Grundsätzen barrierefreier Headlines, und Videos kommen mit Untertiteln. Für verständliche Kurzfassungen helfen die Regeln der Leichten und Einfachen Sprache.

Wie Inhalte im Browser zum Accessibility Tree werden, erklärt die Seite zum Document Object Model. Für Single Page Frontends ist die logische Reihenfolge der Fokusführung besonders wichtig. Den Bezug zu Sulu im Detail zeigt unser Sulu CMS Glossar.

Inhaltsmodell, Frontend, Sulu und mehrere Kanäle: was Teams bei entkoppelten Systemen beachten sollten.