Barrierefreiheit mit TYPO3

TYPO3 wird überdurchschnittlich oft dort eingesetzt, wo Barrierefreiheit nicht verhandelbar ist: in Behörden, Hochschulen, Kliniken und großen Verbänden. Das prägt das System – die mitgelieferten Inhaltselemente sind ordentlich ausgezeichnet, und die Community diskutiert das Thema seit Jahren. Die Barrieren entstehen fast alle in den projektspezifischen Fluid-Templates und in der Redaktion.

Das Wichtigste in Kürze

• Für öffentliche Stellen gilt nicht das BFSG, sondern der öffentliche Rechtsstrang: BGG mit BITV 2.0 beim Bund, das Landesrecht bei Ländern und Kommunen – strenger terminiert und schon länger in Kraft.
• Die BITV verlangt zusätzlich zwei Dinge, die die WCAG nicht kennt: eine Erklärung zur Barrierefreiheit und Basisinformationen in Leichter Sprache und Deutscher Gebärdensprache.
• TYPO3 rendert serverseitig über Fluid. Jedes Template und jedes Inhaltselement ist überschreibbar – das Markup gehört vollständig deinem Projekt, inklusive aller Fehler darin.
• Die drei Stellen mit den meisten Befunden: projektspezifische Fluid-Partials, die Formular-Erweiterung EXT:form und die Redaktion im Rich-Text-Editor.
• Mehrsprachige Websites sind in TYPO3 die Regel. Damit wird 3.1.1 Sprache der Seite und 3.1.2 Sprache von Teilen zu einem Konfigurationsthema, nicht zu einem Redaktionsthema.
• Auch das Backend zählt für öffentliche Stellen: Die BITV erfasst elektronisch unterstützte Verwaltungsabläufe, und dazu gehört das Redaktionssystem, an dem Beschäftigte arbeiten.
• Stand August 2026 gibt es keine Erweiterung, die eine TYPO3-Installation automatisch konform macht. Geprüft wird die ausgelieferte Seite – im öffentlichen Sektor regelmäßig durch einen BITV-Test.

Kein Rechtsrat. Welcher Rechtsstrang für dich gilt und welche Fristen daraus folgen, hängt von der Trägerschaft ab. Die Systematik steht unter Recht als Auslöser, den Einzelfall klärt eine juristische Prüfung.

Warum TYPO3-Projekte einen anderen Maßstab haben

Wer mit TYPO3 arbeitet, baut häufig für eine öffentliche Stelle – und dort ist Barrierefreiheit seit Jahren Pflicht, nicht seit Juni 2025. Das ändert drei Dinge im Projektalltag:

Die Abnahme ist formalisiert. Statt einer Selbsteinschätzung steht am Ende oft ein BITV-Test durch eine Prüfstelle. Der prüft 98 Prüfschritte an mehreren Seiten und dokumentiert jeden einzeln.

Die Erklärung ist Pflicht und öffentlich. Sie muss den Stand benennen, nicht konforme Inhalte auflisten und einen Feedback-Weg anbieten – siehe Barrierefreiheitserklärung erstellen und Feedback & Schlichtungsstelle.

Es gibt eine Beschwerdeinstanz. Nutzerinnen und Nutzer können sich an die Schlichtungsstelle wenden. Das erzeugt eine Rückkopplung, die im privaten Sektor lange gefehlt hat.

Fluid-Templates: alles überschreibbar, alles verantwortbar

TYPO3 liefert für die Standard-Inhaltselemente Fluid-Templates mit, die sauber ausgezeichnet sind: Überschriften als echte Überschriften, Listen als Listen, Bilder mit figure und figcaption. Das ist keine Selbsteinschätzung: Das Introduction Package – die mitgelieferte Beispielinstallation samt Bootstrap Package – wurde von der Prüfstelle BIK nach dem BITV-Test geprüft und mit dem Prüfsiegel ausgezeichnet. Damit gibt es für TYPO3 etwas, das die meisten Systeme nicht vorweisen können: einen belegten Ausgangszustand.

In der Praxis werden diese Templates in fast jedem Projekt überschrieben, weil das Design es verlangt – und genau dabei geht die Semantik verloren. Das Prüfsiegel gilt dem Auslieferungszustand, nicht deiner Website.

Die Stellen, an denen ich zuerst nachsehe:

• Das Kopf-Partial. Logo als h1 ist der Klassiker. Die h1 gehört zum Seitentitel, nicht zur Marke.
• Die Hauptnavigation. Mehrstufige Menüs brauchen aria-expanded an der auslösenden Schaltfläche und müssen mit der Tastatur bedienbar sein – Muster unter Menüs & Dropdowns und Mega-Menüs.
• Der Sprachumschalter. Er braucht hreflang und einen Namen, der die Zielsprache in der Zielsprache nennt.
• Das Akkordeon-Element. Viele Projekte bauen es als div mit Klick-Handler nach, obwohl details/summary reicht – siehe Akkordeons.
• Der Skip-Link. Er fehlt in überschriebenen Layouts überraschend oft (2.4.1 Blöcke umgehen).

Weil all das im Template steckt, gilt der angenehme Umkehrschluss: Eine Korrektur wirkt sofort auf allen Seiten, die das Partial nutzen. TYPO3-Projekte sind deshalb oft in wenigen Tagen deutlich besser – wenn die Befunde einmal sortiert sind.

EXT:form und Formulare

Die Formular-Erweiterung erzeugt Felder mit verknüpften Labels und Fehlermeldungen. Vier Punkte prüfe ich trotzdem jedes Mal:

1. Pflichtfelder im Text kennzeichnen, nicht allein über ein farbiges Sternchen. Ein Sternchen braucht eine Legende, die auch angesagt wird.
2. Fehlermeldungen am Feld, nicht nur als Sammelmeldung oben. Der Zusammenhang entsteht über aria-describedby – Details unter Fehlermeldungen barrierefrei.
3. Gruppen mit fieldset und legend, vor allem bei Radio-Buttons und Checkbox-Gruppen (fieldset & legend).
4. Die Datenschutz-Checkbox ist ein eigener Stolperstein: Ihr Label enthält Links, und die dürfen nicht den zugänglichen Namen der Checkbox überschreiben.

Mehrstufige Formulare – in Verwaltungsverfahren die Regel – brauchen zusätzlich eine klare Schrittanzeige und Fokusführung: siehe Mehrstufige Formulare.

Redaktion: der Rich-Text-Editor entscheidet mit

Der größte Teil der Befunde in einer Inhaltsprüfung stammt nicht aus dem Template, sondern aus dem Editor. Die Regeln, die in eine TYPO3-Redaktionsschulung gehören:

• Überschriftenebene aus dem Format-Auswahlfeld wählen, nicht fetten Text als Überschrift missbrauchen. Die Ebene folgt der Bedeutung (Überschriften-Hierarchie).
• Alt-Texte im Dateiverwaltungs-Datensatz pflegen. In TYPO3 hängt der Alt-Text am Datei-Referenz-Datensatz; wer ihn dort einmal richtig setzt, hat ihn überall.
• Linktexte sprechend formulieren. Der Editor bietet einen Titel an – der ersetzt keinen aussagekräftigen Linktext.
• PDF nicht als Ausweichweg nutzen. Ein hochgeladenes PDF ist ein eigenes Dokument mit eigenen Anforderungen; siehe PDF-Barrierefreiheit und Barrierefreie Office-Dokumente.
• Tabellen mit Kopfzeile anlegen und nicht zum Layouten verwenden.

Das Backend als Arbeitsplatz

Für öffentliche Stellen ist das ein Punkt mit eigener Rechtsfolge, und er wird fast immer vergessen: Die BITV erfasst elektronisch unterstützte Verwaltungsabläufe. Das Redaktionssystem, an dem Beschäftigte täglich arbeiten, gehört dazu.

Praktisch heißt das dreierlei. Erstens: Wenn im Team jemand mit Screenreader, Vergrößerung oder ausschließlich per Tastatur arbeitet, ist das Backend Prüfgegenstand – nicht als Kür, sondern als Voraussetzung für den Arbeitsplatz. Zweitens: Eigene Backend-Module und Erweiterungen fallen genauso darunter wie der Kern; sie sind erfahrungsgemäß der schwächere Teil. Drittens: Selbst ohne betroffene Beschäftigte lohnt der Blick, weil Bewerbungen und Personalwechsel nicht planbar sind – ein Backend, das niemand mit Hilfsmittel bedienen kann, schließt Bewerberinnen faktisch aus.

Der pragmatische Einstieg ist derselbe wie im Frontend: Maus weglegen, ein neues Inhaltselement anlegen, ein Bild samt Alternativtext einpflegen, veröffentlichen. Was dabei nicht funktioniert, ist ein Befund – für den Kern oder für die Erweiterung.

Mehrsprachigkeit sauber auszeichnen

TYPO3 ist stark in Mehrsprachigkeit, und genau deshalb fällt hier auf, was anderswo untergeht. Zwei Kriterien hängen daran:

• lang am html-Element muss die Sprache der ausgelieferten Seite tragen, nicht die Standardsprache der Installation. Ein Screenreader wechselt darüber die Stimme; eine englische Seite mit lang="de" klingt unverständlich.
• Fremdsprachige Zitate und Begriffe im Fließtext brauchen ein eigenes lang-Attribut (3.1.2). Das ist Redaktionsarbeit, aber der Editor kann es.

Für Behördenseiten kommt eine dritte Ebene dazu, die die WCAG nicht kennt: Die BITV verlangt Basisinformationen in Leichter Sprache und in Deutscher Gebärdensprache. Was das konkret bedeutet, steht unter Leichte Sprache & kognitive Barrieren.

So prüfst du deine TYPO3-Website

1. Wähle drei Seitentypen: Startseite, eine Inhaltsseite mit Bildern und Tabellen, ein Formular. Der BITV-Test arbeitet ebenfalls mit einer Seitenauswahl.
2. Tastatur-Durchlauf über alle drei, inklusive Hauptnavigation, Sprachumschalter und Suche.
3. Überschriftenstruktur prüfen – ergibt die Folge ein Inhaltsverzeichnis?
4. Auf 400 % zoomen. Mehrspaltige Layouts und Tabellen sind die üblichen Brecher.
5. Formular absichtlich falsch absenden und den Fokus verfolgen.
6. lang-Attribut in allen Sprachversionen kontrollieren – ein Blick in den Quelltext genügt.
7. axe DevTools laufen lassen und die Befunde nach Template, Erweiterung und Inhalt sortieren.

Der komplette Ablauf steht unter Barrierefreiheit selbst testen; wie eine Prüfstelle vorgeht, unter BITV-Test, Audit & VPAT.

Häufiger Fehler in der Praxis

Die Erklärung zur Barrierefreiheit als Textbaustein behandelt. Sie ist ein Prüfgegenstand: Steht dort „vollständig konform“, während der Test Befunde liefert, ist das ein eigener Mangel. Nicht konforme Inhalte gehören benannt, mit Begründung und Zeitplan.

Das Backend vergessen. Wenn eine Redakteurin mit Screenreader arbeitet, entscheidet das Backend über ihren Arbeitsplatz. Für öffentliche Stellen ist das keine Kür.

Erweiterungen ohne Prüfung eingebunden. Karten, Diagramme, Terminbuchungen und Bildergalerien aus dem Extension-Repository bringen eigenes Markup mit. Sie gehören vor dem Einbau getestet, nicht nach dem Launch.

Nach dem Relaunch nie wieder geprüft. Die BITV verlangt einen aktuellen Stand in der Erklärung. Ein Jahresrhythmus mit kurzem Regressionstest ist das Minimum – und ohnehin die günstigste Variante.

Häufige Fragen

Ist TYPO3 von Haus aus barrierefrei?

Die mitgelieferten Inhaltselemente erzeugen brauchbares, semantisches Markup, und das Projekt nimmt das Thema ernst. Über deine Website entscheiden aber die projektspezifischen Fluid-Templates, die eingesetzten Erweiterungen und die Inhalte. Ein System kann die Grundlage liefern, nicht das Ergebnis garantieren.

Gilt für meine Hochschule das BFSG oder die BITV?

In aller Regel der öffentliche Strang. Staatliche und staatlich anerkannte Hochschulen sind öffentliche Stellen im Sinne des BGG beziehungsweise des jeweiligen Landesrechts – maßgeblich ist die Landes-BITV des Sitzlandes. Die Abgrenzung steht unter Länder-BGG & Landes-BITV.

Muss das TYPO3-Backend barrierefrei sein?

Für öffentliche Stellen ja: Die BITV erfasst auch elektronisch unterstützte Verwaltungsabläufe, und das Redaktionssystem gehört dazu. Für private Betreiber ist es keine BFSG-Frage, aber eine der behinderungsgerechten Arbeitsplatzgestaltung.

Wie viele Seiten muss ich prüfen lassen?

Der BITV-Test arbeitet mit einer repräsentativen Auswahl statt mit allen Seiten: Startseite, typische Inhaltsseiten, ein Formular, eine Suchergebnisseite, häufig auch eine Seite mit Tabellen oder Karten. Für die eigene Vorprüfung reicht dieselbe Auswahl.

Was ist mit den PDFs, die wir seit Jahren veröffentlichen?

Sie fallen unter dieselben Anforderungen, sobald sie nach dem jeweiligen Stichtag veröffentlicht wurden. Die pragmatische Reihenfolge: künftige Dokumente sauber erstellen, häufig abgerufene Altdokumente nacharbeiten, den Rest in der Erklärung als nicht konform benennen. Mehr unter PDF-Barrierefreiheit.

Verwandte Themen

• Barrierefreiheit nach Plattform – die Übersicht über alle Systeme
• Pflichten öffentlicher Stellen – der vollständige Pflichtenkatalog
• BITV 2.0 erklärt – was die Verordnung zusätzlich zur WCAG verlangt
• Leichte Sprache & kognitive Barrieren – die BITV-Anforderung, die kein technisches Werkzeug löst
• BITV-Test, Audit & VPAT – Ablauf und Vorbereitung der formalen Prüfung

Quellen

• Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) (Verordnungstext – § 3 Anforderungen, § 4 Erklärung zur Barrierefreiheit)
• § 12a BGG (Barrierefreie Informationstechnik öffentlicher Stellen des Bundes)
• TYPO3-Dokumentation (TYPO3 – Fluid-Templating und Overrides der Inhaltselemente)
• TYPO3 erreicht WCAG-Standard (TYPO3 – BITV-Test des Introduction Package durch die Prüfstelle BIK)
• BITV-Test (BIK – Prüfschritte und Ablauf der formalen Prüfung)