BFSG technische Anforderungen: WCAG 2.1, Tastatur, ARIA und Testing

Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet Unternehmen seit Juni 2025 zur digitalen Barrierefreiheit. Die rechtliche Grundlage ist klar, aber die technische Umsetzung bleibt für viele Teams die größere Hürde. Dieser Leitfaden fasst die zentralen technischen Anforderungen zusammen — von semantischem HTML über Tastaturnavigation und Formulare bis zu ARIA und automatisierten Tests.

Was bedeutet BFSG technisch?

Das BFSG ist die deutsche Umsetzung der EU-Richtlinie 2019/882. Es verpflichtet Anbieter bestimmter Produkte und Dienstleistungen — darunter E-Commerce, Banking, Personenbeförderung und elektronische Kommunikation — zur Barrierefreiheit nach europäisch harmonisierten Normen.

Technisch verweist das BFSG auf die EN 301 549 (europäische Norm für digitale Barrierefreiheit), die ihrerseits auf den WCAG 2.1 Level AA aufbaut. In der Praxis bedeutet das: Wer die WCAG-2.1-AA-Kriterien erfüllt, erfüllt die zentralen technischen Anforderungen des BFSG.

WCAG 2.1 Level AA: Die vier Prinzipien (POUR)

Die WCAG-Kriterien folgen vier Grundprinzipien:

1. Perceivable (Wahrnehmbar): Inhalte müssen auf verschiedene Weise wahrnehmbar sein — Text, Audio, Bild, Untertitel, Alternativtexte.
2. Operable (Bedienbar): Die Nutzeroberfläche muss bedienbar sein — Tastatur, Touch, Sprachsteuerung.
3. Understandable (Verständlich): Inhalte und Bedienung müssen verständlich sein — klare Sprache, vorhersehbares Verhalten.
4. Robust: Inhalte müssen robust genug sein, dass sie von einer breiten Vielfalt von User-Agents (inklusive assistiver Technologien) interpretiert werden können.

1. Semantisches HTML: Die Basis jeder barrierefreien Website

Semantisches HTML ist nicht optional. Es gibt assistiven Technologien — Screenreadern, Sprachsteuerungen, Braille-Displays — die strukturellen Hinweise, die sie zur Navigation benötigen.

Problem: Div-Suppe ohne Struktur

<!-- Nicht zugänglich: Bedeutungsloses Markup -->
<div class="header">
 <div class="nav">
 <div class="link">Home</div>
 <div class="link">Über uns</div>
 </div>
</div>
<div class="main">
 <div class="title">Willkommen</div>
 <div class="content">Lorem ipsum...</div>
</div>

<!-- Zugänglich: Klare semantische Struktur -->
<header>
 <nav aria-label="Hauptnavigation">
 <ul>
 <li><a href="/">Home</a></li>
 <li><a href="/ueber-uns/">Über uns</a></li>
 </ul>
 </nav>
</header>
<main>
 <h1>Willkommen</h1>
 <p>Lorem ipsum...</p>
</main>

Überschriften-Hierarchie

Eine konsistente Hierarchie ist essenziell. Pro Seite genau ein <h1>, danach <h2>–<h6> ohne Sprünge:

<h1>Hauptthema der Seite</h1>
 <h2>Erster Abschnitt</h2>
 <h3>Unterüberschrift Ebene 2</h3>
 <h2>Weitere Hauptebene</h2>
 <h3>Weitere Ebene 2</h3>

Screenreader bieten Nutzern eine Liste aller Überschriften zur schnellen Navigation. Eine kaputte Hierarchie macht diese Liste unbrauchbar.

2. Tastaturnavigation: Alles muss bedienbar sein

Jede interaktive Funktion muss vollständig per Tastatur bedienbar sein — ohne Mausabhängigkeit.

Fokus-Management

• Alle interaktiven Elemente müssen per Tab erreichbar sein
• Tab-Reihenfolge muss logisch sein (DOM-Reihenfolge = visuelle Reihenfolge)
• tabindex="-1" für Elemente, die programmatisch fokussiert werden, aber nicht per Tab erreichbar sein sollen
• tabindex mit positiven Werten vermeiden (bricht natürliche Reihenfolge)

Fokus-Sichtbarkeit

Der Fokusring ist Pflicht. Niemals outline: none ohne sichtbaren Ersatz:

/* Falsch: Fokus unsichtbar machen */
button:focus { outline: none; }

/* Richtig: Sichtbarer Custom-Fokus */
button:focus-visible {
 outline: 2px solid var(--color-focus);
 outline-offset: 2px;
}

Standard-Tastaturnavigation

Element	Erwartete Taste
Buttons, Links	Enter (oder Space bei Buttons)
Checkboxen, Radio	Space
Selects	Arrows, Enter, Escape
Dialoge	Tab (Fokus-Falle), Escape (Schließen)
Tabs	Arrow Keys (laut WAI-ARIA Authoring Practices)
Menüs	Arrow Keys, Escape, Home/End

Skip-Links implementieren

Ein “Zum Inhalt springen”-Link am Anfang jeder Seite erlaubt Tastatur- und Screenreader-Nutzern, repetitive Navigationsbereiche zu überspringen:

<a href="#main" class="skip-link">Zum Inhalt springen</a>
<header>...</header>
<main id="main">...</main>

.skip-link {
 position: absolute;
 left: -9999px;
}
.skip-link:focus {
 position: fixed;
 top: 0;
 left: 0;
 padding: 1rem;
 background: var(--color-bg);
 z-index: 100;
}

3. Barrierefreie Formulare

Label und Input verknüpfen

Jedes Formularfeld braucht ein verknüpftes Label. Drei zulässige Patterns:

<!-- Pattern 1: Label mit for-Attribut -->
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email">

<!-- Pattern 2: Label umschließt Input -->
<label>
 E-Mail-Adresse
 <input type="email" name="email">
</label>

<!-- Pattern 3: aria-label (nur wenn visuelles Label nicht möglich) -->
<input type="search" aria-label="Suche">

placeholder ist kein Label — er verschwindet beim Tippen und hat schlechten Kontrast.

Fehlermeldungen

Fehlermeldungen müssen mit dem Feld verknüpft und für Screenreader zugänglich sein:

<label for="email">E-Mail-Adresse</label>
<input
 type="email"
 id="email"
 aria-invalid="true"
 aria-describedby="email-error"
>
<p id="email-error" role="alert">
 Bitte geben Sie eine gültige E-Mail-Adresse ein.
</p>

4. Farbkontrast und visuelle Gestaltung

WCAG 2.1 AA verlangt definierte Mindestkontraste:

Element	Mindestkontrast (AA)
Normaler Text	4,5 : 1
Großer Text (≥ 18pt oder ≥ 14pt bold)	3 : 1
UI-Komponenten und Grafiken	3 : 1
Fokus-Indikatoren	3 : 1 zur Umgebung

Werkzeuge zur Kontrastprüfung: WebAIM Contrast Checker, Chrome DevTools (Lighthouse + Color Picker), axe DevTools.

Farbe allein reicht nicht

Information darf nie ausschließlich über Farbe vermittelt werden. Pflichtfelder mit Sternchen UND aria-required, Fehlerzustände mit Icon ODER Text — nicht nur “rot”.

5. Alternative Texte für Bilder

<!-- Informationstragendes Bild -->
<img src="/team.jpg" alt="Drei Personen am Konferenztisch bei einer Strategie-Besprechung">

<!-- Dekoratives Bild -->
<img src="/divider.svg" alt="" role="presentation">

<!-- Funktionales Bild (Link/Button) -->
<a href="/profile/">
 <img src="/icon-user.svg" alt="Profilseite öffnen">
</a>

SVG-Icons barrierefrei

<!-- Dekoratives Icon: aria-hidden -->
<button>
 <svg aria-hidden="true">...</svg>
 Speichern
</button>

<!-- Icon-only Button: Label per aria-label -->
<button aria-label="Suche öffnen">
 <svg aria-hidden="true">...</svg>
</button>

6. Video und Audio barrierefrei

<video controls>
 <source src="/video.mp4" type="video/mp4">
 <!-- Untertitel als WebVTT -->
 <track
 kind="captions"
 src="/captions-de.vtt"
 srclang="de"
 label="Deutsch"
 default
 >
 <!-- Audiodeskription (optional, je nach Inhalt) -->
 <track
 kind="descriptions"
 src="/descriptions-de.vtt"
 srclang="de"
 label="Audiodeskription Deutsch"
 >
</video>

Für Pflichtinhalte (Lernen, behördliche Information, gesetzlich relevante Inhalte) ist zusätzlich ein Transkript Best Practice.

7. ARIA (Accessible Rich Internet Applications)

ARIA ergänzt HTML dort, wo natürliche Semantik nicht ausreicht — etwa für Custom-Komponenten. Erste Regel von ARIA: Wenn natives HTML verfügbar ist, ARIA nicht verwenden.

ARIA States and Properties

Attribut	Zweck
aria-label	Label für Element, das keine sichtbare Beschriftung hat
aria-labelledby	Referenz auf ein anderes Element als Label
aria-describedby	Zusätzliche Beschreibung (z. B. für Hilfetexte)
aria-expanded	Status eines aufklappbaren Bereichs
aria-current="page"	Aktive Seite in der Navigation
aria-hidden="true"	Element von Screenreadern verbergen (rein visuell)
aria-live="polite"	Bereich, in dem Aktualisierungen angesagt werden

Modal Dialog Pattern

Ein zugänglicher Dialog benötigt:

• role="dialog" und aria-modal="true"
• aria-labelledby auf den Dialog-Titel
• Fokus-Falle: Tab bleibt innerhalb des Dialogs
• Escape schließt den Dialog
• Fokus springt beim Öffnen in den Dialog, beim Schließen zurück zum Trigger
• Hintergrund per inert (oder aria-hidden="true") für Assistive Tech unsichtbar

8. Responsive und Zoom-fähig

Nutzer müssen die Seite per Browser-Zoom auf mindestens 200 % vergrößern können, ohne dass Funktionalität verloren geht (WCAG 1.4.4).

• Kein user-scalable=no im Viewport-Meta-Tag
• Layouts mit rem/em, nicht ausschließlich px
• Container, die mit clamp() skalieren statt feste Breiten
• Bei 320px Breite und 200 % Zoom muss Inhalt weiter nutzbar sein (Reflow-Test)

9. Testing und Qualitätssicherung

Automatisierte Tests

Automatisierte Tools fangen rund 30 – 40 % aller Barrierefreiheitsprobleme. Sie sind notwendig, aber nicht ausreichend.

Empfohlene Werkzeuge:

• axe-core / axe DevTools — Browser-Erweiterung + CLI
• Lighthouse — in Chrome DevTools integriert
• Pa11y — CLI für CI/CD-Pipelines
• WAVE — visuelles Browser-Tool

Manuelle Test-Checkliste

• Tastatur-Navigation: gesamte Seite ohne Maus bedienbar?
• Screenreader-Test (NVDA Windows / VoiceOver macOS+iOS / TalkBack Android)
• Browser-Zoom 200 %: Inhalt weiter nutzbar?
• Reduced-Motion-Test mit prefers-reduced-motion: reduce
• Hoch-Kontrast-Modus (Windows): kein Layout-Bruch?
• Farbe deaktivieren: Information weiterhin verständlich?

10. Entwickler-Workflow für BFSG-Konformität

Pre-Commit Hook

# .husky/pre-commit
npx pa11y http://localhost:3000 --reporter cli --threshold 0

GitHub Actions

- name: Accessibility audit
 run: |
 npm run build
 npx start-server-and-test 'npm run preview' http://localhost:4321 'npx pa11y http://localhost:4321 --threshold 0'

Code-Review-Checkliste

• Neue interaktive Elemente per Tastatur bedienbar
• Neue Bilder mit sinnvollem alt-Attribut
• Neue Formulare mit verknüpften Labels
• Neue Farbpaarungen über Kontrastprüfung gelaufen
• Bei Custom-Komponenten: ARIA korrekt eingesetzt
• prefers-reduced-motion berücksichtigt

Fazit

BFSG-Konformität entsteht nicht durch ein einmaliges Audit, sondern durch konsistente Entwicklungspraktiken. Die zentralen Hebel sind semantisches HTML, vollständige Tastaturbedienbarkeit, ausreichender Farbkontrast und durchgehend verknüpfte Formularlabels. Wer diese vier Säulen sauber aufstellt, hat den größten Teil der WCAG-2.1-AA-Kriterien erfüllt — der Rest ist Feinjustierung und Testing.

Verwandte Themen

• BFSG 2025: Was das Barrierefreiheitsstärkungsgesetz für Websites bedeutet
• BFSG technisch umsetzen: Semantisches HTML, ARIA und Tastatur-Navigation in Astro
• ARIA Landmarks: Seitenstruktur für Screenreader optimieren
• Web Accessibility Audit: Barrierefreiheit einer Website testen