Barrierefreiheit in TYPO3: was in der Prüfung auffällt

Kurz: Ob eine TYPO3-Seite barrierefrei ist, entscheidet sich kaum im Core, sondern in den Templates, im JavaScript und in der Redaktion. Bei den Prüfungen unserer Seiten nach dem BFSG fielen immer wieder dieselben Punkte auf: Menüs, Formulare und Widgets, die sich nicht mit der Tastatur bedienen lassen; fehlende Alternativtexte; ein Cookie-Banner, aus dem der Fokus entwischt; Fehlermeldungen, die kein Screenreader vorliest. Fast alles davon löst sauberes HTML – echte Buttons und Links, ARIA nur dort, wo HTML allein nicht reicht.

Wen das BFSG betrifft

Das Barrierefreiheitsstärkungsgesetz gilt seit dem 28. Juni 2025. Es verpflichtet Unternehmen, bestimmte Produkte und Dienstleistungen für Verbraucher barrierefrei anzubieten, darunter den elektronischen Geschäftsverkehr und Bankdienstleistungen. Kleinstunternehmen, die Dienstleistungen erbringen, sind ausgenommen; für öffentliche Stellen gilt schon länger die BITV 2.0. Als Maßstab dient in der Praxis WCAG 2.1 auf Stufe AA. Ob Ihre Seite unter das Gesetz fällt, klären Sie am besten rechtlich – barrierefrei zu bauen lohnt sich unabhängig davon.

Was in den Prüfungen auffiel

Tabs und Akkordeons: welcher Zustand wohin gehört

Für Ihre Entwickler, nach den WAI-ARIA Authoring Practices:

• Tabs: Der aktive Reiter trägt aria-selected="true" und tabindex="0", alle anderen aria-selected="false" und tabindex="-1"; zwischen den Reitern wechseln die Pfeiltasten. Inaktive Panels bekommen das Attribut hidden.
• Akkordeon: Der Auslöser ist ein <button> mit aria-expanded="true" oder "false", das zugeklappte Panel trägt hidden.

Wichtig ist, dass das JavaScript diese Attribute bei jedem Wechsel mitschreibt. Eine CSS-Klasse wie is-open sieht nur, wer den Bildschirm sieht.

Dialoge, Kalender und Cookie-Banner

Alles, was sich über die Seite legt, braucht dieselben drei Regeln:

1. Beim Öffnen den Fokus hineinsetzen, beim Cookie-Banner etwa auf die erste Schaltfläche.
2. Den Fokus drinnen halten, solange das Element offen ist (Fokusfalle), und mit Escape schließen.
3. Beim Schließen den Fokus zurückgeben an das Element, das den Dialog geöffnet hat.

Eine Stolperstelle bei Cookie-Bannern: Wer die Schaltflächen nur per CSS umsortiert, damit etwa „Alle erlauben“ links steht, bricht die Tab-Reihenfolge – die folgt dem HTML, nicht der Optik (WCAG 2.4.3). Consent-Lösungen wie sgalinski/sg-cookie-optin oder Klaro brauchten in unseren Projekten für diese Regeln eigenes JavaScript.

Dasselbe gilt für aufklappende Kalender: Auslöser als <button> mit aria-expanded und aria-controls, Fokusfalle, solange er offen ist, Escape schließt ihn. Und wo ein Klick neue Felder einfügt, etwa „weitere Person hinzufügen“ in einer Anmeldung, gehört der Fokus in das erste neue Feld.

Formulare und Suche

• Fehler vorlesbar machen. Jedes ungültige Feld zeigt per aria-describedby auf seinen Fehlertext und trägt aria-invalid="true", bis die Eingabe stimmt. Sonst hört ein Screenreader-Nutzer nur, dass der Fokus gesprungen ist, aber nicht, warum.
• Nicht beim Tippen suchen. Eine Suche, die bei jedem Tastendruck die Ergebnisse austauscht, verwirrt Screenreader (WCAG 3.2.2). Besser: eine Absenden-Schaltfläche und die Zahl der Treffer in einem aria-live-Bereich ansagen (WCAG 4.1.3).
• Zusammengehörige Optionen gruppieren. Radio-Buttons stehen in einem <fieldset> mit <legend> oder in einer role="radiogroup" mit Beschriftung.
• Auch unsichtbare Iframes beschriften. Jeder <iframe> braucht einen title – auch der <noscript>-Iframe des Google Tag Managers, den Prüfwerkzeuge sonst anmahnen.

Was die Redaktion beiträgt

• Alternativtexte gehören in die Dateiliste. In den Metadaten der Datei gepflegt, gelten sie überall, wo das Bild eingebunden ist. Bei mehrsprachigen Seiten bekommt jede Sprache eine eigene Übersetzung der Metadaten – nicht beide Sprachen in einem Feld.
• Rein dekorative Bilder bekommen einen leeren Alternativtext, dann überspringt der Screenreader sie.
• Überschriften in der richtigen Reihenfolge und Linktexte, die für sich sprechen – „Jahresbericht 2025 (PDF)“ statt „hier klicken“.

So prüfen Sie selbst

• Mit der Tastatur: Die Seite nur mit Tab, Shift+Tab, Enter, Leertaste und Escape bedienen. Ist der Fokus immer zu sehen? Kommen Sie in jedes Menü und wieder heraus?
• Mit einem Prüfwerkzeug als Browser-Erweiterung, etwa axe oder WAVE. Es findet fehlende Alternativtexte, Kontraste und Beschriftungen – aber nicht, ob die Bedienung sinnvoll ist.
• Mit einem Screenreader: VoiceOver ist auf dem Mac eingebaut, NVDA für Windows kostenlos. Schon ein Durchlauf durch ein Formular zeigt die meisten Lücken.

Barrierefreiheit lässt sich nachrüsten, günstiger wird sie aber, wenn sie von Anfang an in den Templates steckt. Beim TYPO3 Relaunch planen wir sie von Beginn an ein – oder schreiben Sie uns über das Formular unten.

Stand: 24.9.2026 · Quellen: Barrierefreiheitsstärkungsgesetz (BFSG), Bundesfachstelle Barrierefreiheit: BFSG, WCAG 2.1, WAI-ARIA Authoring Practices: Tabs, WAI-ARIA Authoring Practices: Akkordeon