TYPO3 und Barrierefreiheit: BFSG-Compliance für Enterprise-Webseiten

TYPO3: Barrierefreiheit als Designprinzip

TYPO3 ist eines der wenigen CMS, die Barrierefreiheit als Kernprinzip verfolgen. Das Backend ist weitgehend barrierefrei, und das System bietet umfangreiche Möglichkeiten für barrierefreie Frontends. Das macht TYPO3 besonders attraktiv für öffentliche Einrichtungen und Unternehmen mit hohen Compliance-Anforderungen.

Im Kontext des BFSG (Barrierefreiheitsstärkungsgesetz, in Kraft seit Juni 2025) ist das relevant: Gemäß § 1 Abs. 2 BFSG müssen Dienstleistungen im elektronischen Geschäftsverkehr die Anforderungen der EN 301 549 erfüllen, die ihrerseits auf die WCAG 2.1 Level AA verweist. TYPO3 liefert dafür die beste Grundlage unter den gängigen Enterprise-CMS – aber nur, wenn Integratoren und Redakteure ihren Teil beitragen.

TYPO3-Bordmittel für Barrierefreiheit

TYPO3 bringt von Haus aus eine Reihe von Features mit, die Barrierefreiheit unterstützen:

Fluid-Templates mit semantischem HTML

Das Fluid-Templating-System erzeugt standardmäßig semantisch korrektes HTML. Content-Elemente wie Textblöcke, Bilder und Listen werden in sinnvolle HTML-Strukturen gerendert. Das ist die Grundlage für SC 1.3.1 (Info und Beziehungen): Informationen und Strukturen müssen programmatisch bestimmbar sein. Weitere Informationen finden Sie im BFSG-Glossar.

Alt-Text-Pflichtfelder im Medienmanager

TYPO3 bietet ein eigenes Feld für Alternativtexte bei jedem Bild im FAL (File Abstraction Layer). In der Site-Konfiguration lässt sich sogar erzwingen, dass Redakteure einen Alt-Text eingeben müssen, bevor ein Bild veröffentlicht wird. Das unterstützt SC 1.1.1 (Nicht-Text-Inhalte) direkt.

Automatische Überschriften-Hierarchie

Content-Elemente in TYPO3 nutzen ein Überschriften-Feld mit Level-Auswahl (h1–h5). In Kombination mit sauber konfigurierten Fluid-Templates entsteht automatisch eine korrekte Heading-Hierarchie – essenziell für SC 1.3.1 und die Navigation per Screenreader.

ARIA-Landmarks in Standard-Layouts

Die Standard-Seitenlayouts von TYPO3 nutzen ARIA-Landmarks wie role="navigation", role="main" und role="contentinfo". Diese ermöglichen es assistiven Technologien, schnell zwischen Seitenbereichen zu wechseln (SC 1.3.1, SC 2.4.1).

TYPO3 v12 und v13: Accessibility-Verbesserungen

Seit TYPO3 v12 LTS gibt es deutliche Verbesserungen: Das Backend selbst wurde gemäß WCAG 2.1 AA überarbeitet, es gibt verbesserte Fokus-Indikatoren, und der Page Tree ist per Tastatur vollständig bedienbar. TYPO3 v13 setzt diesen Kurs fort: Content-Blocks (das neue Content-Element-System) sind von Grund auf auf semantisches HTML ausgelegt, und die FormEngine wurde hinsichtlich Screenreader-Kompatibilität verbessert.

Wo TYPO3-Webseiten trotzdem scheitern

Trotz der guten Grundlagen scheitern viele TYPO3-Projekte an der Umsetzung. Die Ursachen liegen selten im Core, sondern bei Extensions, Custom-Templates und redaktionellen Inhalten.

Extension-Audit: Powermail, News, Solr & Co.

Extensions sind das Rückgrat jeder TYPO3-Installation – und die häufigste Quelle für Barrierefreiheitsprobleme:

Powermail (Formular-Extension): In älteren Versionen fehlen aria-required-Attribute bei Pflichtfeldern und die Fehlermeldungen sind nicht per aria-describedby mit dem jeweiligen Feld verknüpft. Das verstößt gegen SC 3.3.1 (Fehlererkennung) und SC 3.3.3 (Fehlervorschlag). Ab Powermail 8+ ist die Situation besser, aber ein Audit bleibt notwendig. Detaillierte Tipps zu barrierefreien Formularen findest du in unserem Artikel Formulare barrierefrei gestalten.

EXT:news: Die Standard-Templates der News-Extension nutzen häufig <div>-Container statt semantischer Elemente wie <article>, <time> und <nav> für die Paginierung. Außerdem fehlen oft Teaser-Bilder-Alt-Texte, wenn Redakteure das Feld im News-Record leer lassen.

EXT:solr (Suche): Die Autosuggest-Komponente arbeitet mit dynamisch generierten Dropdowns, die ohne role="listbox" und aria-activedescendant für Screenreader unsichtbar sind. Auch die Suchergebnis-Seite selbst muss einen role="status"-Bereich haben, der die Anzahl der Treffer ankündigt (SC 4.1.3 Statusmeldungen).

Custom Fluid-Templates ohne ARIA

Viele Agenturen erstellen individuelle Fluid-Templates für Header, Navigation und Footer. Dabei werden ARIA-Attribute und Landmarks oft vergessen. Ein typisches Beispiel:

Vorher (nicht barrierefrei):

<div class="main-nav">
  <ul>
    <li><a href="/">Start</a></li>
    <li class="dropdown">
      <span>Leistungen</span>
      <ul class="sub">...</ul>
    </li>
  </ul>
</div>

Nachher (barrierefrei):

<nav aria-label="Hauptnavigation">
  <ul role="menubar">
    <li role="none"><a role="menuitem" href="/">Start</a></li>
    <li role="none">
      <button role="menuitem" aria-haspopup="true"
              aria-expanded="false">Leistungen</button>
      <ul role="menu">...</ul>
    </li>
  </ul>
</nav>

Beachte: Das <span>-Element wurde durch ein <button> ersetzt, damit das Dropdown per Tastatur bedienbar ist (SC 2.1.1 Tastatur). Die ARIA-Rollen ermöglichen Screenreadern, das Menü korrekt zu interpretieren (SC 4.1.2 Name, Rolle, Wert).

TypoScript-Konfiguration für Barrierefreiheit

Einige Barrierefreiheits-Einstellungen müssen direkt im TypoScript vorgenommen werden. Wichtige Konfigurationen:

# Sprache im HTML-Tag setzen (SC 3.1.1)
config.htmlTag_langKey = de

# Seitentitel als h1 sicherstellen
lib.contentElement.settings.defaultHeaderType = 1

# Skip-Link aktivieren (SC 2.4.1)
page.headerData.10 = TEXT
page.headerData.10.value = <style>.skip-link{position:absolute;left:-9999px;}.skip-link:focus{left:0;z-index:999;}</style>

# Bildunterschriften als figcaption rendern
tt_content.image.dataProcessing.20.settings.figcaption = 1

Besonders der Skip-Link wird in vielen TYPO3-Projekten vergessen, obwohl SC 2.4.1 (Blöcke umgehen) ihn praktisch voraussetzt.

RTE-Inhalte und redaktionelle Qualität

Die beste Technik nützt nichts, wenn Redakteure Inhalte falsch einpflegen. Typische Probleme:

• Überschriften werden über Fettung statt über Überschriften-Level formatiert
• Tabellen ohne <th>-Köpfe und scope-Attribute (SC 1.3.1)
• Links mit Texten wie „hier klicken“ statt aussagekräftiger Beschreibung (SC 2.4.4 Linkzweck)
• Videos ohne Untertitel oder Audiodeskription (SC 1.2.2, SC 1.2.5)

Ältere TYPO3-Versionen (v8, v9) haben zusätzlich bekannte Accessibility-Probleme im Backend und in Standard-Templates. Ein Upgrade auf v12 LTS oder v13 ist daher nicht nur aus Sicherheits-, sondern auch aus Barrierefreiheitsgründen dringend empfohlen.

Schritt-für-Schritt: TYPO3-Accessibility-Audit

Ein systematischer Audit deckt Probleme auf, bevor es Beschwerden oder Bußgelder gibt. Folge diesem bewährten Ablauf:

Schritt 1: Automatisierten Scan durchführen

Starte mit einem automatisierten BFSG-Scan deiner TYPO3-Webseite. Automatisierte Tools finden rund 30–40 % der typischen Barrieren: fehlende Alt-Texte, Kontrastprobleme, fehlende Labels, ungültige ARIA-Rollen.

Schritt 2: Extension-Inventar erstellen

Liste alle installierten Extensions auf (composer show | grep typo3 oder über das Extension-Manager-Backend). Prüfe für jede Extension, ob sie Frontend-Output erzeugt. Falls ja: Teste diesen Output manuell mit Tastatur und Screenreader.

Schritt 3: Fluid-Templates auditen

Öffne dein Haupt-Template (typisch unter Resources/Private/Templates/) und prüfe:

• Ist <nav> mit aria-label ausgezeichnet?
• Gibt es ein <main>-Element?
• Ist der Footer als <footer> gerendert?
• Gibt es einen Skip-Link vor der Navigation?
• Sind lang-Attribute bei mehrsprachigen Inhalten gesetzt?

Schritt 4: Tastatur-Durchlauf

Navigiere die gesamte Seite nur mit der Tastatur (Tab, Enter, Escape, Pfeiltasten). Achte auf: Ist der Fokus immer sichtbar (SC 2.4.7)? Gibt es Tastaturfallen (SC 2.1.2)? Können alle interaktiven Elemente erreicht und bedient werden?

Schritt 5: Screenreader-Test

Teste mit NVDA (Windows, kostenlos) oder VoiceOver (macOS, integriert). Höre dir an, wie die Seite vorgelesen wird: Werden Überschriften, Landmarks und Formularfelder korrekt angekündigt? Ergibt die Lesereihenfolge Sinn?

Schritt 6: Redaktionelle Richtlinien erstellen

Erstelle ein kurzes Dokument für dein Redaktionsteam: Wie werden Bilder beschriftet? Wie müssen Tabellen aufgebaut sein? Welche Überschriften-Level sind wo zu verwenden? TYPO3 bietet die technische Grundlage – die Inhaltsqualität liegt in den Händen der Redakteure.

Schritt 7: Dokumentation und Monitoring

Halte die Ergebnisse fest: Was wurde geprüft, was wurde behoben, was ist noch offen? Plane regelmäßige Re-Audits ein – spätestens bei jedem TYPO3-Update oder Extension-Wechsel. Gemäß § 3 Abs. 4 BFSG müssen Wirtschaftsakteure die Konformität fortlaufend sicherstellen.

Häufige Fehler bei TYPO3-Barrierefreiheit

Diese Fehler begegnen uns bei TYPO3-Projekten immer wieder:

TypoScript-Defaults nicht überschreiben

TYPO3 setzt viele sinnvolle Defaults – aber manche Integratoren überschreiben sie unbeabsichtigt. Beispiel: config.htmlTag_langKey wird nicht gesetzt, und die Seite rendert ohne lang-Attribut. Das verstößt gegen SC 3.1.1 (Sprache der Seite).

Frontend-Caching verbirgt Probleme

TYPO3s aggressives Caching kann dazu führen, dass Barrierefreiheits-Fixes nicht sofort sichtbar sind. Nach Änderungen an Fluid-Templates oder TypoScript immer den Frontend-Cache leeren (Flush frontend caches) und anschließend erneut testen.

Drittanbieter-JavaScript ignorieren

Viele TYPO3-Seiten laden externe Scripts: Cookie-Banner, Chat-Widgets, Tracking-Pixel. Jedes dieser Scripts kann eigene DOM-Elemente erzeugen, die nicht barrierefrei sind. Das Cookie-Banner ist besonders kritisch, da es den Seiteninhalt überlagert und oft nicht per Tastatur bedienbar ist.

Dieser Artikel dient der allgemeinen Information und ersetzt keine Rechtsberatung. Für eine verbindliche Einschätzung deiner BFSG-Pflichten wende dich an einen spezialisierten Rechtsanwalt.

Häufig gestellte Fragen