Website-Barrierefreiheit: Der praktische BFSG-Guide für Entwickler

11 Min. Lesezeit

Seit dem 28. Juni 2025 gilt in Deutschland das Barrierefreiheitsstärkungsgesetz, kurz BFSG. Falls du davon noch nichts gehört hast oder das Thema bisher vor dir hergeschoben hast – du bist nicht allein. Barrierefreiheit war für viele von uns Entwicklern lange eher ein Randthema. Ein paar Alt-Texte hier, vielleicht mal ein aria-label dort, und gut ist. Das ändert sich jetzt.

Das BFSG macht Barrierefreiheit für viele Websites zur Pflicht. Wer dagegen verstößt, riskiert Bußgelder und Abmahnungen. Aber ehrlich gesagt ist das gar nicht der Hauptgrund, warum ich diesen Artikel schreibe. Eine barrierefreie Website ist schlicht eine bessere Website – für alle, die sie benutzen. Ob jemand einen Screenreader verwendet, nur mit der Tastatur navigiert, oder einfach bei Sonnenlicht auf dem Handy was lesen will.

In diesem Guide schauen wir uns an, was das BFSG konkret bedeutet, welche Fehler am häufigsten vorkommen und wie du deine Website mit überschaubarem Aufwand fit machst. Mit Code-Beispielen und einer Checkliste zum Abhaken.

Website-Barrierefreiheit - Der praktische BFSG-Guide für Entwickler

Website-Barrierefreiheit: Der praktische BFSG-Guide für Entwickler

Was ist das BFSG – und wen betrifft es?

Die Kurzfassung

Das Barrierefreiheitsstärkungsgesetz (BFSG) ist die deutsche Umsetzung der EU-Richtlinie European Accessibility Act (EAA). Das Gesetz wurde am 22. Juli 2021 verabschiedet und ist seit dem 28. Juni 2025 in Kraft. Es verpflichtet Unternehmen, ihre digitalen Produkte und Dienstleistungen barrierefrei zu gestalten. Der technische Standard, an dem sich alles orientiert, ist WCAG 2.1 Level AA – definiert über die europäische Norm EN 301 549.

Wer muss handeln?

Das BFSG betrifft “Dienstleistungen im elektronischen Geschäftsverkehr”. Klingt sperrig, meint aber im Grunde jede Website, über die irgendetwas verkauft oder Dienste angeboten werden. Das fängt bei klassischen Online-Shops an, geht über Terminbuchungs-Systeme und Banking-Dienste bis hin zu Messenger-Apps und anderen Kommunikationsdiensten. Auch wenn du “nur” ein Kontaktformular auf deiner Website hast, über das Kunden dich erreichen können, fällst du unter das Gesetz. Im Zweifel gilt: Wenn du B2C-Dienstleistungen online anbietest, bist du dabei.

Wer ist ausgenommen?

Nicht jeder muss sofort handeln. Es gibt drei Ausnahmen: Kleinunternehmen mit weniger als 10 Mitarbeitern und unter 2 Millionen Euro Jahresumsatz sind außen vor – allerdings müssen beide Kriterien gleichzeitig erfüllt sein. Ein Freelancer mit 500.000 Euro Umsatz ist also betroffen, während ein 15-Personen-Startup mit 1,5 Millionen Umsatz nicht unter das Gesetz fällt. Ebenfalls ausgenommen sind reine B2B-Angebote, also Websites, die sich ausschließlich an Geschäftskunden richten. Und private Websites ohne kommerzielle Absicht – der persönliche Blog über dein Hobby muss nicht WCAG-konform sein.

Die 5 häufigsten Barrierefreiheits-Fehler

Laut der WebAIM Million Studie 2025 sind 94,8% aller Websites nicht WCAG-konform. Im Durchschnitt hat jede Seite 51 automatisch erkennbare Fehler. Das klingt erst mal erschreckend, aber es gibt einen Lichtblick: Die meisten Fehler wiederholen sich. Es sind immer wieder dieselben Probleme. Wenn du die folgenden fünf Punkte in den Griff bekommst, hast du schon einen Großteil geschafft.

1. Fehlende oder nutzlose Alt-Texte

Das ist der häufigste Fehler überhaupt. Bilder ohne Alt-Text sind für Screenreader-Nutzer schlicht unsichtbar. Genauso nutzlos sind Alt-Texte wie “Bild” oder “image.jpg” – die sagen niemandem, was auf dem Bild zu sehen ist.

<!-- FALSCH: Kein Alt-Text -->
<img src="produkt.jpg" />

<!-- FALSCH: Nutzloser Alt-Text -->
<img src="produkt.jpg" alt="Bild" />
<img src="produkt.jpg" alt="produkt-foto-final-v2.jpg" />

<!-- RICHTIG: Beschreibender Alt-Text -->
<img
  src="produkt.jpg"
  alt="Rotes T-Shirt mit V-Ausschnitt, Größe M, 29,99 Euro"
/>

<!-- RICHTIG: Dekoratives Bild (leerer Alt-Text!) -->
<img src="decorative-line.png" alt="" />

Als Faustregel: Wenn ein Bild Information transportiert, braucht es einen beschreibenden Alt-Text. Wenn es rein dekorativ ist – ein Hintergrundbild, ein Trenner, ein Icon neben einem bereits beschreibenden Text – dann bekommt es ein leeres alt=""-Attribut. Das ist wichtig: nicht weglassen, sondern explizit leer setzen. So weiß der Screenreader, dass er das Bild überspringen kann.

2. Zu geringer Farbkontrast

Grauer Text auf hellgrauem Hintergrund mag elegant aussehen, ist aber für Menschen mit Sehbeeinträchtigung kaum lesbar. Die WCAG fordern für normalen Text ein Kontrastverhältnis von mindestens 4,5:1. Für großen Text (ab 18pt oder 14pt fett) und UI-Elemente wie Buttons oder Icons reicht 3:1.

/* FALSCH: Kontrast nur 2,5:1 */
.subtle-text {
  color: #999999;
  background: #ffffff;
}

/* RICHTIG: Kontrast 7:1 */
.readable-text {
  color: #595959;
  background: #ffffff;
}

Zum Prüfen eignet sich der WebAIM Contrast Checker oder die Lighthouse-Prüfung in Chrome.

3. Formulare ohne Labels

Ein Klassiker: Das Eingabefeld hat nur einen Placeholder, aber kein echtes Label. Das Problem: Sobald der Nutzer anfängt zu tippen, verschwindet der Placeholder – und er weiß nicht mehr, was er eingeben sollte.

<!-- FALSCH: Nur Placeholder, kein Label -->
<input type="email" placeholder="E-Mail-Adresse" />

<!-- RICHTIG: Sichtbares Label -->
<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" />

<!-- RICHTIG: Visuell verstecktes Label (wenn Design es erfordert) -->
<label for="email" class="sr-only">E-Mail-Adresse</label>
<input type="email" id="email" name="email" placeholder="E-Mail-Adresse" />

Die Klasse .sr-only (screen-reader-only) versteckt das Label visuell, macht es aber für Screenreader zugänglich:

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

Viele Nutzer können keine Maus verwenden – sei es wegen motorischer Einschränkungen, weil sie blind sind, oder weil sie einfach effizienter mit der Tastatur arbeiten. Wenn deine Website nicht mit Tab, Enter und Escape bedienbar ist, schließt du diese Nutzer aus.

Die üblichen Verdächtigen: Custom-Dropdowns, die nur auf Mausklicks reagieren. Modale Dialoge, die den Fokus nicht einfangen und den Nutzer irgendwo im Hintergrund herumtabben lassen. Onclick-Events auf Divs statt auf echten Buttons. Und der Klassiker – Focus-Styles wurden entfernt, weil der blaue Ring “nicht ins Design passt”. Dann sieht der Tastatur-Nutzer aber nicht mehr, wo er gerade ist.

<!-- FALSCH: Div als klickbares Element -->
<div class="button" onclick="handleClick()">Absenden</div>

<!-- RICHTIG: Echter Button -->
<button type="button" onclick="handleClick()">Absenden</button>

5. Zu viel (oder falsches) ARIA

Das hier ist vielleicht etwas unerwartet: Laut WebAIM haben Websites mit ARIA doppelt so viele Accessibility-Fehler wie Websites ohne ARIA – 57 vs. 27 Fehler pro Seite. ARIA soll eigentlich helfen, wird aber oft falsch eingesetzt und macht dann alles schlimmer.

Die erste Regel von ARIA lautet nicht ohne Grund:

“No ARIA is better than Bad ARIA”

<!-- FALSCH: Unnötiges ARIA -->
<button role="button" aria-label="Absenden">Absenden</button>

<!-- RICHTIG: Semantisches HTML braucht kein ARIA -->
<button type="submit">Absenden</button>

<!-- FALSCH: ARIA überschreibt sichtbares Label -->
<label for="email">E-Mail</label>
<input type="email" id="email" aria-label="Deine E-Mail-Adresse eingeben" />

<!-- RICHTIG: Label ist ausreichend -->
<label for="email">E-Mail</label>
<input type="email" id="email" />

Im Grunde ist es einfach: Verwende zuerst semantisches HTML – also <button>, <nav>, <main>, <header> und so weiter. Diese Elemente bringen ihre Accessibility schon mit. ARIA brauchst du nur, wenn HTML allein nicht ausreicht, etwa für komplexe Widgets wie Tabs oder Accordions.

Deine Website in 10 Minuten testen

Automatisierte Tools finden nur etwa 20-30% aller Accessibility-Probleme. Das ist weniger, als man hoffen würde, aber sie sind trotzdem ein guter Startpunkt. Mit den folgenden vier Tests bekommst du in etwa 10 Minuten einen ersten Überblick:

Test 1: Lighthouse in Chrome

Der schnellste Test überhaupt – direkt im Browser:

Öffne deine Website in Chrome
Drücke F12 (DevTools öffnen)
Gehe zum Tab “Lighthouse”
Wähle nur “Accessibility” aus
Klicke auf “Analyze page load”

Du bekommst einen Score von 0-100 und eine Liste aller gefundenen Probleme mit Erklärungen und Lösungsvorschlägen. Anstreben solltest du mindestens 90 Punkte. Alles unter 70 ist kritisch.

Test 2: WAVE Browser-Extension

WAVE ist eine kostenlose Browser-Extension für Chrome und Firefox. Sie zeigt Accessibility-Probleme direkt auf der Seite an:

Installiere die WAVE Extension
Öffne deine Website
Klicke auf das WAVE-Icon

Du siehst sofort, was Sache ist: Rote Markierungen (Errors) müssen behoben werden, gelbe (Alerts) solltest du prüfen, und grüne (Features) zeigen dir, was bereits korrekt implementiert ist.

Test 3: Der Tastatur-Test

Der wichtigste manuelle Test – dauert 2 Minuten:

Öffne deine Website
Klicke irgendwo auf die Seite
Navigiere nur mit der Tab-Taste durch die gesamte Seite

Achte dabei auf folgende Fragen: Kannst du alle interaktiven Elemente erreichen – Links, Buttons, Formulare? Siehst du immer, wo der Fokus gerade ist? Kannst du Dropdown-Menüs öffnen und schließen? Funktionieren modale Dialoge mit Escape? Und gibt es einen Skip-Link, mit dem du die Navigation überspringen kannst?

Test 4: Der Screenreader-Test

Wenn du Windows nutzt, ist NVDA ein kostenloser Screenreader. Auf Mac ist VoiceOver bereits integriert (Cmd + F5).

Schließe die Augen und versuche, deine Website nur mit dem Screenreader zu bedienen. Du wirst überrascht sein, wie anders das Erlebnis ist.

10 Quick-Wins: Sofort umsetzbare Fixes

Hier sind zehn Fixes, die du sofort umsetzen kannst. Jeder einzelne verbessert die Barrierefreiheit deiner Website.

Ein Skip-Link ermöglicht Tastatur-Nutzern, die Navigation zu überspringen und direkt zum Hauptinhalt zu gelangen:

<!-- Direkt nach dem öffnenden <body>-Tag -->
<a href="#main-content" class="skip-link"> Zum Hauptinhalt springen </a>

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

.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  padding: 8px 16px;
  background: #000;
  color: #fff;
  text-decoration: none;
  z-index: 100;
}

.skip-link:focus {
  top: 0;
}

2. Sprache im HTML-Tag setzen

Screenreader müssen wissen, in welcher Sprache der Inhalt ist, um ihn korrekt vorzulesen:

<!-- FALSCH: Keine Sprache definiert -->
<html>
  ...
</html>

<!-- RICHTIG: Sprache gesetzt -->
<html lang="de">
  ...
</html>

3. Focus-Styles nicht entfernen

Einer der häufigsten Fehler: outline: none auf alles setzen, weil der blaue Fokusring “hässlich” aussieht:

/* FALSCH: Fokus komplett entfernen */
*:focus {
  outline: none;
}

/* RICHTIG: Eigenen Fokus-Style definieren */
*:focus-visible {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

Der Vorteil von :focus-visible gegenüber :focus: Der Fokusring erscheint nur bei Tastatur-Navigation, nicht bei Mausklicks. So hast du beides – gute Sichtbarkeit für Tastatur-Nutzer und ein sauberes Design für Maus-Nutzer.

4. Buttons statt Divs verwenden

Für alles, was eine Aktion auslöst (Formular absenden, Dialog öffnen, etc.), verwende <button>:

<!-- FALSCH -->
<div class="btn" onclick="submit()">Absenden</div>
<a href="#" onclick="openModal()">Mehr erfahren</a>

<!-- RICHTIG -->
<button type="submit">Absenden</button>
<button type="button" onclick="openModal()">Mehr erfahren</button>

5. Überschriften-Hierarchie einhalten

Überschriften sollten eine logische Hierarchie bilden – keine Ebenen überspringen:

<!-- FALSCH: H1 → H3 (H2 übersprungen) -->
<h1>Seitentitel</h1>
<h3>Abschnitt</h3>

<!-- RICHTIG: Logische Hierarchie -->
<h1>Seitentitel</h1>
<h2>Abschnitt</h2>
<h3>Unterabschnitt</h3>

6. Links aussagekräftig benennen

Screenreader können alle Links einer Seite auflisten. “Hier klicken” und “Mehr” sind dann nutzlos:

<!-- FALSCH -->
<a href="/angebot">Hier klicken</a>
<a href="/blog/artikel">Mehr</a>

<!-- RICHTIG -->
<a href="/angebot">Unser Angebot ansehen</a>
<a href="/blog/artikel">Artikel über Barrierefreiheit lesen</a>

7. Formulare richtig labeln

Jedes Eingabefeld braucht ein zugehöriges Label:

<label for="name">Vollständiger Name</label>
<input type="text" id="name" name="name" autocomplete="name" />

<label for="email">E-Mail-Adresse</label>
<input type="email" id="email" name="email" autocomplete="email" />

8. Alt-Texte für alle informativen Bilder

Gehe alle Bilder deiner Website durch und füge beschreibende Alt-Texte hinzu:

<!-- Produktbild -->
<img
  src="laptop.jpg"
  alt="MacBook Pro 14 Zoll, Space Grau, geöffnet mit Code auf dem Bildschirm"
/>

<!-- Team-Foto -->
<img
  src="team.jpg"
  alt="Unser 5-köpfiges Team im Büro, von links: Anna, Max, Lisa, Tom, Sarah"
/>

<!-- Rein dekorativ -->
<img src="divider.png" alt="" />

9. Bewegte Inhalte pausierbar machen

Animationen, Auto-Play-Videos und Karussells müssen pausierbar sein:

<!-- Video mit Kontrollen -->
<video controls>
  <source src="video.mp4" type="video/mp4" />
</video>

<!-- Karussell mit Pause-Button -->
<div class="carousel">
  <button class="carousel-pause" aria-label="Karussell pausieren">⏸</button>
  ...
</div>

10. Ausreichende Touch-Targets

Auf Mobilgeräten sollten klickbare Elemente mindestens 44x44 Pixel groß sein:

.button,
a,
input[type="checkbox"],
input[type="radio"] {
  min-width: 44px;
  min-height: 44px;
}

Die POUR-Prinzipien verstehen

Die WCAG basieren auf vier Grundprinzipien, die das Akronym POUR bilden. Wenn du diese verstehst, kannst du Accessibility-Probleme besser einordnen und lösen.

Perceivable (Wahrnehmbar)

Alle Informationen müssen für alle Sinne zugänglich sein. Bilder brauchen Alt-Texte für blinde Nutzer. Videos brauchen Untertitel für gehörlose Nutzer. Farben dürfen nicht die einzige Information sein, sonst schließt du Farbenblinde aus. Und Kontraste müssen ausreichend sein, damit auch Menschen mit Sehbeeinträchtigung alles lesen können.

Operable (Bedienbar)

Die Website muss mit verschiedenen Eingabemethoden bedienbar sein. Tastatur-Navigation muss vollständig möglich sein. Zeitlimits sollte es nicht geben, oder zumindest mit Verlängerungsmöglichkeit. Blinkende Inhalte können Epilepsie auslösen und sollten vermieden werden. Und Skip-Links helfen bei der Navigation.

Understandable (Verständlich)

Inhalt und Bedienung müssen verständlich sein. Das bedeutet klare Sprache, konsistente Navigation auf allen Seiten, verständliche Fehlermeldungen und Hilfestellungen bei komplexen Eingaben.

Robust

Die Website muss mit verschiedenen Technologien funktionieren. Schreibe valides HTML. Verwende semantische Elemente. Teste mit Screenreadern. Und setze ARIA korrekt ein – oder lass es lieber weg, wenn du dir unsicher bist.

Was passiert, wenn ich nichts tue?

Die möglichen Konsequenzen

Das BFSG sieht verschiedene Sanktionen vor. Bußgelder können bis zu 100.000 Euro pro Verstoß betragen. Dazu kommen mögliche Abmahnungen durch Mitbewerber oder Verbraucherschutzverbände, Unterlassungsklagen mit Schadensersatzforderungen, und im Extremfall sogar Vertriebsverbote – also die Einstellung des Online-Geschäfts. Anders als bei der DSGVO wird hier übrigens nicht erst verwarnt. Die Behörden können direkt Sanktionen verhängen.

Wer kontrolliert das?

Zuständig sind die Marktüberwachungsbehörden der Bundesländer. Aber auch Verbraucherschutzverbände können Verstöße anzeigen, Mitbewerber können abmahnen, und Betroffene selbst können sich beschweren. Das heißt: Selbst wenn keine Behörde aktiv kontrolliert, kann ein Konkurrent oder ein unzufriedener Nutzer eine Prüfung auslösen.

Fazit und Checkliste

Barrierefreiheit ist kein Hexenwerk. Die meisten Probleme lassen sich mit grundlegendem HTML-Wissen beheben. Und eine barrierefreie Website ist schlicht eine bessere Website – nicht nur für Menschen mit Behinderungen, sondern für alle.

Das BFSG gilt seit Juni 2025, und fast 95% aller Websites haben noch Accessibility-Probleme. Die fünf häufigsten Fehler, die wir uns angeschaut haben, sind aber alle recht einfach zu beheben. Semantisches HTML ist dabei wichtiger als ARIA – im Zweifel lieber auf ARIA verzichten als es falsch einzusetzen. Und am besten testest du regelmäßig mit Lighthouse, WAVE und der Tastatur.

Die Checkliste zum Abhaken

Grundlagen:

lang="de" im HTML-Tag gesetzt
Skip-Link zum Hauptinhalt vorhanden
Logische Überschriften-Hierarchie (H1 → H2 → H3)
Keine Überschriften-Ebenen übersprungen

Bilder:

Alle informativen Bilder haben Alt-Texte
Dekorative Bilder haben alt=""
Alt-Texte sind beschreibend, nicht nur “Bild”

Formulare:

Jedes Input hat ein zugehöriges Label
Pflichtfelder sind gekennzeichnet
Fehlermeldungen sind verständlich
Autocomplete-Attribute gesetzt

Navigation:

Alle Elemente mit Tab erreichbar
Fokus ist immer sichtbar
Logische Tab-Reihenfolge
Links haben aussagekräftige Texte

Farben & Kontraste:

Text-Kontrast mindestens 4,5:1
UI-Elemente-Kontrast mindestens 3:1
Farbe nicht einzige Unterscheidungsmerkmal

Interaktive Elemente:

Buttons für Aktionen, Links für Navigation
Touch-Targets mindestens 44x44px
Bewegte Inhalte pausierbar

Tests durchgeführt:

Lighthouse Score über 90
WAVE zeigt keine Errors
Komplette Tastatur-Navigation getestet
Mit Screenreader getestet

Wenn du mehr über Web-Entwicklung lernen möchtest, schau dir meine anderen Artikel an oder melde dich für meinen Newsletter an. Bei Fragen zu diesem Thema schreib mir gerne – ich helfe dir weiter.