BFSG

BFSG-konforme Website: Technische Umsetzung

WCAG 2.1 Level AA in HTML, CSS & JavaScript umsetzen. Testing-Tools, Entwickler-Workflows und konkreter Code für Ihr Projekt.

9. November 2025
14 Min. Lesezeit
Aktualisiert: 26. Juni 2026
BFSGBarrierefreiheitWCAGAccessibilityWeb DevelopmentHTMLCSSARIA
Veröffentlicht: Aktualisiert:
Aktualisiert 26. Juni 2026
Inhaltsverzeichnis

Technisch bedeutet BFSG-Konformität: Ihre Website erfüllt WCAG 2.1 Level AA nach EN 301 549 – semantisches HTML, vollständige Tastaturbedienbarkeit, Kontraste von mindestens 4,5:1, beschriftete Formulare, Alternativtexte und korrektes ARIA. Dieser Guide zeigt die Umsetzung mit Code-Beispielen und Testing-Tools – den Einstieg erleichtern unser BFSG-Compliance-Check und unser barrierefreies Webdesign.

Ein Jahr BFSG: Die Kontrollphase läuft

Das Barrierefreiheitsstärkungsgesetz (BFSG) ist seit dem 28. Juni 2025 in Kraft. Alle betroffenen Unternehmen müssen ihre Websites WCAG 2.1 Level AA-konform gestalten. Seit Anfang 2026 ist die Schonfrist vorbei: Die Marktüberwachungsbehörden der Länder kontrollieren aktiv, erste Bußgelder wurden verhängt (bis zu 100.000 €) und spezialisierte Kanzleien verschicken wettbewerbsrechtliche Abmahnungen.

Was bedeutet BFSG technisch?

Die rechtliche Grundlage

AspektDetails
Gesetz Barrierefreiheitsstärkungsgesetz (BFSG)
Inkrafttreten 28. Juni 2025
Verbindliche Norm EN 301 549 V3.2.1 → WCAG 2.1 Level AA
Strafen Bis zu 100.000€ Bußgeld + Abmahnrisiko
Ausnahme Kleinstunternehmen (<10 Beschäftigte und ≤2 Mio. € Umsatz) bei Dienstleistungen
Betroffen Online-Shops, Websites, Web-Apps
WCAG 2.1 ist Pflicht — WCAG 2.2 (noch) nicht

Verbindlich ist die harmonisierte Norm EN 301 549 in der Fassung V3.2.1 (2021-03), die auf WCAG 2.1 Level AA verweist. WCAG 2.2 ist Stand 2026 noch nicht gesetzlich verpflichtend — die Nachfolge-Norm (geplant als V4.1.1) mit Bezug auf WCAG 2.2 ist noch nicht im EU-Amtsblatt veröffentlicht. Wer die zusätzlichen WCAG-2.2-Kriterien jetzt schon umsetzt, ist für die kommende Norm-Aktualisierung gerüstet.

WCAG 2.1 Level AA: Die 4 Prinzipien (POUR)

P

Perceivable (Wahrnehmbar)

Inhalte müssen für alle Sinne zugänglich sein

O

Operable (Bedienbar)

Navigation ohne Maus möglich

U

Understandable (Verständlich)

Klare Sprache, konsistente Bedienung

R

Robust

Kompatibel mit assistiven Technologien

1. Semantisches HTML: Die Basis jeder barrierefreien Website

Problem: Div-Suppe ohne Struktur

Div-Suppe
<div class="header">
  <div class="nav">
    <div class="link">Home</div>
    <div class="link">Über uns</div>
  </div>
</div>
<div class="content">
  <div class="article">
    <div class="title">Überschrift</div>
    <div class="text">Artikeltext...</div>
  </div>
</div>
Semantisch
<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>
  <article>
    <h1>Artikel-Überschrift</h1>
    <p>Artikeltext...</p>
  </article>
</main>

<footer>
  <p>&copy; 2025 Wendermedia</p>
</footer>
Vorteile semantischer HTML5-Elemente
  • Screen Reader erkennen Landmarks (<main>, <nav>, <header>)
  • Nutzer können direkt zum Hauptinhalt springen
  • Bessere SEO durch klare Struktur
  • Konsistente User Experience

Überschriften-Hierarchie

Gebrochene Struktur
<h1>Hauptüberschrift</h1>
<h3>Unterüberschrift</h3> <!-- h2 übersprungen! -->
<h2>Weitere Überschrift</h2> <!-- Falsche Reihenfolge -->
Logische Hierarchie
<h1>Hauptüberschrift</h1>
<h2>Unterüberschrift Ebene 2</h2>
  <h3>Unterüberschrift Ebene 3</h3>
  <h3>Weitere Ebene 3</h3>
<h2>Weitere Ebene 2</h2>
WCAG-Kriterium 1.3.1

Genau eine h1 pro Seite. Logische Hierarchie ohne Sprünge (h1 h2 h3, nicht h1 h3). Keine Überschriften aus rein optischen Gründen.

2. Tastaturnavigation: Alles muss bedienbar sein

Fokus-Management

Maus-only
<div onclick="openModal()">Öffnen</div>
<!-- Funktioniert nur mit Maus! -->
Tastaturzugänglich
<button type="button" id="open-modal">Öffnen</button>

<script>
document.getElementById('open-modal').addEventListener('click', function() {
  openModal();
});

// Escape-Taste zum Schließen
document.addEventListener('keydown', function(e) {
  if (e.key === 'Escape' && modalIsOpen) {
    closeModal();
  }
});
</script>

Fokus-Sichtbarkeit

Fokus versteckt
/* NIEMALS machen! */
*:focus {
  outline: none;
}
Sichtbarer Fokus
a:focus, button:focus, input:focus {
  outline: 3px solid var(--color-light-blue);
  outline-offset: 2px;
}

/* Modernes Focus-visible (nur Tastatur) */
a:focus-visible, button:focus-visible {
  outline: 3px solid var(--color-light-blue);
  outline-offset: 2px;
  box-shadow: var(--shadow-brand-xs);
}

Standard-Tastaturnavigation

TasteFunktion
Tab Nächstes fokussierbares Element
Shift + Tab Vorheriges Element
Enter Links/Buttons aktivieren
Leertaste Buttons/Checkboxen aktivieren
Pfeiltasten Dropdown-Menüs, Radio-Buttons
Escape Modals/Dialoge schließen

Skip-Links implementieren

Ohne Skip-Link
<!-- Kein Skip-Link vorhanden -->
<header>Lange Navigation...</header>
<main>Hauptinhalt</main>
Mit Skip-Link
<a href="#main-content" class="skip-link">
  Zum Hauptinhalt springen
</a>

<header>...</header>

<main id="main-content">
  <!-- Hauptinhalt -->
</main>

<style>
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: var(--color-secondary-900);
  color: var(--color-white);
  padding: var(--space-2);
  z-index: 9999;
}
.skip-link:focus { top: 0; }
</style>

3. Barrierefreie Formulare

Label und Input-Verknüpfung

Ohne Label
<div>Name:</div>
<input type="text" placeholder="Ihr Name" inputmode="text">
<!-- Kein Label, Placeholder verschwindet! -->
Mit Label
<label for="name">Name *</label>
<input type="text" id="name" name="name" required
       aria-required="true" aria-describedby="name-hint" inputmode="text">
<span id="name-hint" class="hint">
  Bitte Vor- und Nachname eingeben
</span>

Fehlermeldungen

Nur Farbe
<input type="email" style="border-color: red;" inputmode="email">
<!-- Nur visuelle Fehleranzeige -->
Mit ARIA
<label for="email">E-Mail-Adresse *</label>
<input type="email" id="email" name="email"
       aria-invalid="true"
       aria-describedby="email-error" inputmode="email">
<span id="email-error" role="alert" class="error">
   Bitte geben Sie eine gültige E-Mail-Adresse ein
</span>

Komplexes Formular-Beispiel

<form method="post" aria-labelledby="form-title">
  <h2 id="form-title">Kontaktformular</h2>

  <fieldset>
    <legend>Persönliche Daten</legend>

    <div class="form-group">
      <label for="firstname">Vorname *</label>
      <input type="text" id="firstname" name="firstname"
             required aria-required="true" autocomplete="given-name">
    </div>

    <div class="form-group">
      <label for="lastname">Nachname *</label>
      <input type="text" id="lastname" name="lastname"
             required aria-required="true" autocomplete="family-name">
    </div>
  </fieldset>

  <button type="submit">Absenden</button>
</form>

Formular Best Practices

4. Farbkontrast & visuelle Gestaltung

Kontrastverhältnisse nach WCAG 2.1

TextartMindestkontrast
Normal Text (unter 18pt) 4.5:1
Großer Text (ab 18pt oder 14pt fett) 3:1
UI-Komponenten (Buttons, Icons) 3:1
Zu wenig
/* Kontrast nur 2.8:1 - NICHT ausreichend! */
.text {
  color: #999999;
  background: var(--color-white);
}
Ausreichend
/* Kontrast 7.0:1 - WCAG AAA konform */
.text {
  color: #333333;
  background: var(--color-white);
}

/* Kontrast 4.6:1 - WCAG AA konform */
.text-inverted {
  color: var(--color-white);
  background: var(--color-light-blue);
}

Farbe allein reicht nicht

Nur Farbe
<p style="color: red;">Fehler</p>
<p style="color: green;">Erfolg</p>
<!-- Nur Farbe für Information! -->
Farbe + Icon + Text
<p class="error">
  <span aria-hidden="true"></span>
  <span class="sr-only">Fehler:</span>
  Fehler aufgetreten
</p>

<p class="success">
  <span aria-hidden="true"></span>
  <span class="sr-only">Erfolg:</span>
  Erfolgreich gespeichert
</p>
WCAG-Kriterium 1.4.1 Use of Color

Farbe darf nicht das einzige Mittel sein, um Informationen zu vermitteln. Nutzen Sie zusätzlich Icons, Text oder andere visuelle Hinweise.

5. Alternative Texte für Bilder

Bilder richtig beschreiben

Nichtssagend
<img src="team.jpg">
<img src="logo.png" alt="Bild">
<img src="chart.png" alt="chart.png">
Beschreibend
<!-- Informatives Bild -->
<img src="team.jpg"
     alt="Unser Team von 5 Mitarbeitern im Büro bei der Arbeit">

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

<!-- Logo -->
<img src="logo.png" alt="Wendermedia - Webdesign aus Halle">

<!-- Komplexes Diagramm -->
<img src="sales-chart.png" alt="Umsatzentwicklung 2024"
     aria-describedby="chart-description">
<div id="chart-description">
  <p>Der Umsatz stieg von 100.000€ im Januar
     auf 250.000€ im Dezember 2024.</p>
</div>

SVG-Icons barrierefrei

Nicht beschrieben
<svg class="icon" aria-hidden="true">...</svg>
<!-- Keine Beschreibung! -->
Barrierefrei
<!-- Dekoratives Icon -->
<svg aria-hidden="true" focusable="false">...</svg>

<!-- Icon-Button mit Label -->
<button aria-label="Suchen">
  <svg aria-hidden="true" focusable="false">
    <!-- Icon-Pfade -->
  </svg>
</button>

<!-- SVG mit Titel und Beschreibung -->
<svg role="img" aria-labelledby="icon-title icon-desc">
  <title id="icon-title">Erfolgreich</title>
  <desc id="icon-desc">Grüner Haken</desc>
  <!-- Icon-Pfade -->
</svg>

6. Video & Audio barrierefrei

Video mit Untertiteln

<video controls>
  <source src="video.mp4" type="video/mp4">

  <!-- Untertitel (Deutsch) -->
  <track kind="subtitles" src="video-de.vtt"
         srclang="de" label="Deutsch" default>

  <!-- Untertitel (Englisch) -->
  <track kind="subtitles" src="video-en.vtt"
         srclang="en" label="English">

  <!-- Audiodeskription -->
  <track kind="descriptions" src="video-ad.vtt"
         srclang="de" label="Audiodeskription">

  <p>Ihr Browser unterstützt kein HTML5 Video.
     <a href="video.mp4">Video herunterladen</a></p>
</video>

<!-- Transkript -->
<details>
  <summary>Vollständiges Transkript</summary>
  <div>
    <p><strong>0:00</strong> - Willkommen...</p>
  </div>
</details>

WCAG-Anforderungen für Videos

LevelAnforderung
Level A Untertitel für aufgezeichnete Videos
Level AA Audiodeskription oder Volltext-Alternative
Level AAA Gebärdensprache-Übersetzung

7. ARIA (Accessible Rich Internet Applications)

Die 5 goldenen ARIA-Regeln
  1. No ARIA is better than bad ARIA - Nutze natives HTML
  2. Don't change native semantics - <button role="link"> ist falsch
  3. All interactive controls must be keyboard accessible
  4. Don't hide focusable elements mit aria-hidden="true"
  5. All interactive elements need an accessible name

ARIA States & Properties

Ohne ARIA
<div onclick="toggle()">Menü</div>
<div id="menu" style="display:none">
  <div>Item 1</div>
</div>
<!-- Keine ARIA-Attribute! -->
Mit ARIA
<!-- aria-expanded für Accordions -->
<button aria-expanded="false" aria-controls="menu">
  Menü
</button>
<ul id="menu" hidden>
  <li>Item 1</li>
</ul>

<!-- aria-live für dynamische Inhalte -->
<div role="status" aria-live="polite" aria-atomic="true">
  <p id="status-message"></p>
</div>

<!-- aria-current für Navigation -->
<nav>
  <a href="/" aria-current="page">Home</a>
  <a href="/blog/">Blog</a>
</nav>

Modal Dialog Pattern

<div role="dialog" aria-labelledby="dialog-title"
     aria-modal="true" class="dialog" hidden>
  <div class="dialog-content">
    <h2 id="dialog-title">Bestätigung</h2>
    <p>Möchten Sie fortfahren?</p>

    <button id="confirm">Ja</button>
    <button id="cancel">Abbrechen</button>

    <button id="close" aria-label="Dialog schließen">×</button>
  </div>
</div>

8. Responsive & Zoom-fähig

320px Breite
Reflow-Anforderung

Inhalte müssen bei 320px Breite ohne horizontales Scrollen lesbar sein (WCAG 1.4.10)

Fixed Width
/* Fixed width - bricht bei kleinen Viewports */
.container {
  width: 1200px;
}
Fluid Width
/* Fluid width */
.container {
  max-width: 1200px;
  width: 100%;
  padding: 0 20px;
  margin: 0 auto;
}

/* Mobile First */
@media (min-width: 768px) {
  .container {
    padding: 0 40px;
  }
}

Text-Skalierung

px-basiert
/* px-basiert - skaliert NICHT mit Browser */
body {
  font-size: 16px;
}
rem-basiert
/* rem-basiert - skaliert mit Browser-Einstellungen */
html {
  font-size: 100%;
}

body {
  font-size: 1rem;     /* 16px */
  line-height: 1.5;    /* Mindestens 1.5 für Lesbarkeit */
}

h1 {
  font-size: 2.5rem;   /* 40px */
  line-height: 1.2;
}

9. Testing & Qualitätssicherung

Automatisierte Tests

axe DevTools

Chrome/Firefox Extension. Findet ca. 57% aller Fehler automatisch.

npm install -g @axe-core/cli

Lighthouse

Integriert in Chrome DevTools. Accessibility-Score von 0-100.

npm install -g lighthouse

Pa11y

CI/CD Integration möglich.

npm install -g pa11y

Manuelle Test-Checkliste

Manuelle Accessibility-Tests

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

Pre-Commit Hook für Accessibility

#!/bin/sh
echo "Running accessibility tests..."
npm run test:a11y

if [ $? -ne 0 ]; then
  echo "[X] Accessibility tests failed. Commit aborted."
  exit 1
fi

echo " Accessibility tests passed."

GitHub Actions Workflow

name: Accessibility Tests
on: [push, pull_request]

jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm ci
      - run: npm run build
      - run: npm run preview &
      - run: npx wait-on http://localhost:4173
      - run: npm run test:a11y
      - run: npx @axe-core/cli http://localhost:4173 --tags wcag2aa

Budget & Zeitaufwand

Neues Projekt (von Anfang an barrierefrei)

Mehraufwand bei neuen Projekten

PhaseAufwandMehrkosten
Planung & Konzeption +10% +800€
Design (Kontraste, Fokus-Stile) +15% +1.200€
Entwicklung (HTML, ARIA) +20% +2.500€
Testing & QA +40% +2.000€
Gesamt Mehraufwand +20-25% +6.500€

Bestehendes Projekt nachrüsten

Nachrüstungskosten

KomplexitätAufwandKosten
Kleine Website (5-10 Seiten) 40-60h 4.000€ - 6.000€
Mittlere Website (20-50 Seiten) 80-120h 8.000€ - 12.000€
Große Website/Shop (100+ Seiten) 200-400h 20.000€ - 40.000€
Web-App (komplex) 400-800h 40.000€ - 80.000€
Wichtig

Bei Planung von Anfang an ist der Mehraufwand minimal (20-25%). Nachträgliche Anpassungen kosten 3-5x mehr.

Fazit: BFSG-Konformität ist machbar

Die technische Umsetzung des BFSG erfordert systematisches Vorgehen, aber keine Raketenwissenschaft. Barrierefreier, semantischer Code zahlt zudem auf Ihre Suchmaschinenoptimierung ein, da Suchmaschinen saubere Strukturen besser verstehen. Wenn Sie die Umsetzung nicht selbst stemmen möchten: Unser barrierefreies Webdesign aus Halle liefert BFSG-Konformität ab Werk:

Die 5 Kern-Prinzipien

BFSG-Umsetzung starten

Wir unterstützen Sie bei der technischen Umsetzung - vom Audit bis zur vollständigen Compliance.

Aktualisiert am 26.06.2026: Aktueller Praxisstand ein Jahr nach Inkrafttreten ergänzt — Marktüberwachung und erste Bußgelder seit Anfang 2026. Verbindliche Norm präzisiert (EN 301 549 V3.2.1 → WCAG 2.1 AA; WCAG 2.2 ist noch nicht verpflichtend) und Kleinstunternehmen-Ausnahme (<10 Beschäftigte und ≤2 Mio. € Umsatz) in die Rechtsgrundlage aufgenommen.

Arnold Wender – Autorenportrait

SEO-Experte & Gründer

Arnold Wender ist Gründer und Geschäftsinhaber der SEO-Agentur Halle (Saale). Mit über 19 Jahren Erfahrung in der Suchmaschinenoptimierung hilft er Unternehmen, ihre Online-Sichtbarkeit nachhaltig zu verbessern.

Profil anzeigen