Das Barrierefreiheitsstärkungsgesetz gilt seit dem 28. Juni 2025, und viele Inhaber kleiner Firmen fragen sich gerade: Betrifft mich das überhaupt - und wenn ja, was muss ich konkret tun? Als Webentwickler, der hauptsächlich für kleine und mittlere Unternehmen in Deutschland arbeitet, bekomme ich diese Fragen täglich. Hier ist meine praktische Antwort.

In diesem Artikel zeige ich Ihnen, welche Anforderungen das BFSG stellt, was WCAG 2.1 Level AA in der Praxis bedeutet, und welche Punkte Sie als kleines Unternehmen zuerst angehen sollten. Ich bin Webentwickler, kein Rechtsanwalt - für konkrete rechtliche Fragen zu Ihrer individuellen Situation wenden Sie sich bitte an einen Fachanwalt für IT-Recht.

Wen betrifft das BFSG - und wen nicht?

Bevor ich zur Checkliste komme, eine wichtige Vorfrage: Das BFSG enthält eine Ausnahme für Kleinstunternehmen. Wer weniger als 10 Mitarbeiter beschäftigt und einen Jahresumsatz unter 2 Millionen Euro hat, ist bei der Erbringung von Dienstleistungen vom Gesetz ausgenommen. Das klingt zunächst beruhigend.

Die Einschränkung: Bei Produkten gilt diese Ausnahme nicht. Verkaufen Sie physische Waren über Ihren Online-Shop, können die BFSG-Anforderungen trotzdem greifen - auch als Kleinstunternehmen. Bei einem Kundenprojekt aus Hamburg, einem Kindermöbelshop mit vier Mitarbeitern, hat uns genau diese Abgrenzung mehrere Stunden Rechercheaufwand gekostet. Im Zweifel lohnt eine kurze anwaltliche Klärung, bevor Sie Ressourcen in die falsche Richtung stecken.

Verstöße gegen das BFSG können mit Bußgeldern bis zu 100.000 Euro geahndet werden. Hinzu kommt das Abmahnrisiko durch Wettbewerber und Verbraucherschutzverbände.

Was WCAG 2.1 Level AA konkret bedeutet

Das BFSG verweist auf die EN 301 549, die ihrerseits auf WCAG 2.1 Level AA basiert. WCAG steht für Web Content Accessibility Guidelines - herausgegeben vom W3C, der Organisation, die auch HTML und CSS standardisiert.

Die Richtlinien sind nach vier Prinzipien strukturiert, die sich mit dem englischen Akronym POUR merken lassen:

  • Perceivable (Wahrnehmbar): Inhalte müssen für alle Sinneskanäle zugänglich sein - z.B. Alt-Texte für Bilder, Untertitel für Videos.
  • Operable (Bedienbar): Alle Funktionen müssen per Tastatur erreichbar sein, nicht nur per Maus.
  • Understandable (Verständlich): Texte und Formulare müssen klar und fehlertolerant sein.
  • Robust: Der Code muss so geschrieben sein, dass ihn Hilfstechnologien wie Screen-Reader korrekt interpretieren können.

Level AA umfasst rund 50 Erfolgskriterien. Das klingt viel, aber die meisten lassen sich in wenige konkrete Maßnahmen übersetzen.

50+Erfolgskriterien bei WCAG 2.1 Level AA
4,5:1Mindest-Kontrastverhältnis für normalen Text (AA)
30-40 %Kriterien durch automatische Tools prüfbar
100.000 EURmaximaler Bußgeldrahmen bei BFSG-Verstößen

Schnelltest: Wo stehen Sie gerade?

Bevor Sie anfangen, sollten Sie wissen, wo die größten Baustellen liegen. Dafür reichen drei kostenlose Tools:

1. WAVE (Browser-Extension für Chrome und Firefox): Legt farbige Icons direkt über Ihre Seite - rot für Fehler, gelb für Warnungen. Ideal für einen ersten Überblick.
2. axe DevTools (Chrome-Extension): Liefert detaillierte Befunde mit direkten Verweisen auf WCAG-Kriterien und Code-Beispiele zur Behebung.
3. Google Lighthouse (eingebaut in Chrome DevTools, Tab "Accessibility"): Schnell zugänglich, nutzt die axe-Engine im Hintergrund.

Wichtig: Alle drei zusammen decken nur etwa 30 bis 40 Prozent der WCAG-Kriterien automatisch ab. Ob die Tastaturnavigation wirklich funktioniert oder ob ein Screen-Reader die Seite sinnvoll vorliest, müssen Sie manuell prüfen.

Vergleich kostenloser Barrierefreiheits-Testtools

ToolStärkeSchwäche
WAVEVisuelle Fehleranzeige direkt auf der SeiteWeniger technische Detail-Infos
axe DevToolsWCAG-Verweise und Code-HinweiseErfordert Grundverständnis von Dev-Tools
Google LighthouseDirekt im Browser, kein DownloadNur automatisierbare Prüfungen
NVDA + FirefoxEchter Screen-Reader-TestLernaufwand, Windows-only

Checkliste: Die wichtigsten WCAG-2.1-AA-Punkte

Die folgende Checkliste deckt die häufigsten Problemstellen bei WordPress-Seiten ab. Sie ist nach Priorität sortiert - beginnen Sie oben.

WCAG 2.1 AA Checkliste für Ihre Webseite

  • Kontrast: Text auf Hintergrund mindestens 4,5:1 (Normal-Text), 3:1 (großer Text ab 18pt)
  • Alt-Texte: Jedes inhaltliche Bild hat ein beschreibendes alt-Attribut; rein dekorative Bilder haben alt=""
  • Tastaturnavigation: Alle Links, Buttons und Formulare per Tab-Taste erreichbar und bedienbar
  • Sichtbarer Fokus: Der Fokus-Rahmen beim Tabben ist gut sichtbar, nicht per CSS ausgeblendet
  • Formularlabels: Jedes Eingabefeld hat ein verknüpftes label-Element (nicht nur Placeholder)
  • Seitensprache: Das lang-Attribut im html-Tag ist korrekt gesetzt (lang="de")
  • Überschriftenstruktur: Logische Hierarchie (h1 einmalig, dann h2, h3 - keine Sprünge)
  • Links aussagekräftig: Kein "hier klicken" oder "mehr lesen" ohne Kontext
  • Videos: Untertitel für alle voraufgezeichneten Video-Inhalte
  • Fehlerhinweise: Formulare zeigen klare, textuelle Fehlermeldungen (nicht nur Farbe)
  • Keine Zeitlimits: Kein automatisches Ausloggen ohne Vorwarnung und Verlängerungsmöglichkeit
  • Skip-Link: Ein "Zum Inhalt springen"-Link als erstes Element der Seite

Kontraste: Häufig unterschätzt, schnell geprüft

Das Kontrastverhältnis ist der Befund, der mir bei Audits am häufigsten begegnet - besonders bei Webseiten mit hellem, modernem Design. Helles Grau auf Weiß sieht elegant aus, ist für sehbehinderte Menschen aber kaum lesbar.

Die Regel für WCAG AA: Normaler Text (unter 18pt bzw. 14pt fett) braucht ein Verhältnis von mindestens 4,5:1 zum Hintergrund. Größerer Text kommt mit 3:1 aus. Für die Prüfung nutze ich den WebAIM Contrast Checker (kostenlos, unter webaim.org/resources/contrastchecker) - einfach Vorder- und Hintergrundfarbe eingeben, fertig.

Bei einem Kundenprojekt aus Poznan, einer Kanzleiwebseite, haben wir festgestellt, dass der Fließtext mit #767676 auf Weiß genau an der Grenze liegt - und der Call-to-Action-Button mit einem zartem Hellblau knapp darunter. Zwei Farbwerte geändert, 20 Minuten Arbeit, Problem gelöst.

Chrome DevTools zeigt das Kontrastverhältnis direkt im Color-Picker an, wenn Sie ein Textelement inspizieren. Klicken Sie auf das Farbfeld neben der color-Property - das spart das externe Tool.

Alt-Texte: Was gut gemeint oft falsch macht

Alt-Texte sind schnell erklärt, aber häufig schlecht umgesetzt. Die häufigsten Fehler:

  • Alt-Text fehlt komplett (HTML-Fehler: Screen-Reader liest Dateinamen vor)
  • Alt-Text ist der Dateiname: alt="DSC_4821.jpg"
  • Alt-Text beschreibt nicht den Inhalt, sondern den Kontext: alt="Unser Team" statt alt="Vier Personen sitzen gemeinsam an einem Tisch und schauen in die Kamera"
  • Dekorative Bilder haben einen langen Alt-Text statt alt="" (das unterbricht den Lesefluss des Screen-Readers)

In WordPress können Sie Alt-Texte direkt in der Mediathek pflegen. Für bestehende Seiten empfehle ich das Plugin WP Accessibility von Joe Dolson - es zeigt alle Bilder ohne Alt-Text in einer übersichtlichen Liste.

Tastaturbedienung und sichtbarer Fokus

Das ist der Punkt, bei dem viele WordPress-Themes auf den ersten Blick gut aussehen, in der Praxis aber versagen. Öffnen Sie Ihre Seite und drücken Sie wiederholt Tab - können Sie sehen, wo der Fokus gerade liegt? Bei sehr vielen Themes wird der Standard-Fokusrahmen per CSS mit outline: none oder outline: 0 ausgeblendet, weil er "hässlich" aussieht.

Das ist ein direkter WCAG-Verstoß (Kriterium 2.4.7). Die Lösung: Einen eigenen, gut sichtbaren Fokus-Stil definieren. Ein Beispiel aus meinen Projekten:

:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
  border-radius: 2px;
}

Prüfen Sie außerdem: Sind alle interaktiven Elemente per Tastatur erreichbar? Dropdown-Menüs, Modale, Tabs, Akkordeons - alles muss ohne Maus funktionieren.

Vorteile

  • Barrierefreiheit verbessert gleichzeitig die allgemeine Usability für alle Nutzer
  • Strukturierter HTML-Code hilft SEO-Crawlern und assistiven Technologien gleichermassen
  • Einmal sauber umgesetzt, ist der laufende Pflegeaufwand gering
  • Zeigt gesellschaftliche Verantwortung - relevant für Unternehmensimage

Nachteile

  • Nachträgliche Umsetzung bei bestehenden Seiten ist aufwendiger als Barrierefreiheit von Anfang an
  • Viele populäre WordPress-Themes und Page-Builder-Elemente bringen Barrieren von Haus aus mit
  • Automatische Tools ersetzen keine manuelle Prüfung durch echte Nutzer mit Behinderungen
  • Ohne Dokumentation und Konformitätserklärung ist auch eine technisch gute Umsetzung rechtlich unvollständig

Formulare: Der häufigste Stolperstein

Formulare sind in der Praxis oft die größte Baustelle. Die typischen Fehler:

  • Input-Felder haben kein label-Element, nur einen Placeholder
  • Pflichtfelder sind nur durch rote Farbe markiert, ohne Textzusatz
  • Fehlermeldungen erscheinen visuell, werden aber nicht per ARIA live-region angekündigt
  • Submit-Buttons haben keinen aussagekräftigen Text ("Senden" ohne Kontext)

Ein korrekt gelabeltes Formularfeld sieht so aus:

<label for="email">E-Mail-Adresse (Pflichtfeld)</label>
<input type="email" id="email" name="email" required aria-required="true">

In WordPress löst das Contact Form 7 mit dem WP Accessibility-Plugin besser als viele andere Formular-Plugins. Gravity Forms hat seit Version 2.7 eingebaute Accessibility-Features, die ich für komplexere Formulare bevorzuge.

Die Barrierefreiheitserklärung (Konformitätserklärung) ist ein Pflichtdokument nach BFSG. Sie müssen darin dokumentieren, welche WCAG-Kriterien erfüllt sind, welche nicht, und warum. Verlinken Sie sie gut sichtbar im Footer Ihrer Webseite.

Was kostet das und wie lange dauert es?

Die Frage, die meine Kunden am meisten interessiert. Meine Erfahrungswerte aus aktuellen Projekten:

1.500 - 4.000 EURtypische Kosten für Barrierefreiheits-Retrofit einer kleinen WordPress-Seite
2-5 Tagerealistischer Aufwand bei bestehender Seite ohne Theme-Grundprobleme
5-10 %Mehrkosten für Barrierefreiheit wenn von Anfang an eingeplant
1 TagMindestaufwand für manuelles Audit + Bericht

Wenn das Theme grundlegende Probleme mitbringt - kein semantisches HTML, kein Fokus-Management, keine ARIA-Unterstützung - kann auch ein Themewechsel die wirtschaftlichere Entscheidung sein. Blocksy, GeneratePress und Astra gehören zu den Themes, die Barrierefreiheit ernst nehmen und regelmäßig auditiert werden.

Für Ihre Firmenwebseite empfehle ich: Starten Sie mit dem automatischen Audit per axe und WAVE, beheben Sie die roten Fehler zuerst, und planen Sie dann einen halben Tag für die manuelle Prüfung ein. Das ist kein Hexenwerk - aber es muss jemand machen, der weiß, was er sucht.

Wie ich an BFSG-Projekte herangehe

Mein Standardvorgehen bei einem Barrierefreiheits-Retrofit sieht so aus: Zuerst der automatische Scan mit axe und WAVE, dann eine manuelle Prüfung der Tastaturnavigation und der wichtigsten User Flows, dann Screen-Reader-Test mit NVDA (kostenlos, Windows) auf den fünf wichtigsten Seiten. Das Ergebnis ist eine priorisierte Mängelliste mit Aufwandsschätzung.

Danach werden die Befunde nach Aufwand und Wirkung sortiert: Fehlende Alt-Texte lassen sich oft in zwei Stunden erledigen. Ein komplett neu zu bauendes Megamenü mit Tastaturunterstützung kann zwei Tage kosten. Diese Trennung hilft Kunden, eine realistische Entscheidung zu treffen.

Wenn Sie wissen wollen, was eine barrierefreie Webseite für Ihr Unternehmen konkret bedeutet und was es kostet, können Sie sich gern bei mir melden - ich schaue mir Ihre Seite an und sage Ihnen in einem kurzen Erstgespräch, wo die größten Baustellen liegen.

Häufige Fragen

Gilt das BFSG auch für meine kleine Firmenwebseite?

Das kommt auf Ihre Unternehmensgröße und Art der Tätigkeit an. Kleinstunternehmen mit weniger als 10 Mitarbeitern und maximal 2 Millionen Euro Jahresumsatz sind bei reinen Dienstleistungs-Webseiten vom BFSG ausgenommen. Betreiben Sie dagegen einen Online-Shop, der physische Produkte verkauft, gelten die Pflichten unter Umständen trotzdem - lassen Sie das im Zweifel von einem Rechtsanwalt klären.

Was ist WCAG 2.1 und welches Level muss ich erfüllen?

WCAG steht für Web Content Accessibility Guidelines und ist der internationale Standard für barrierefreie Webinhalte. Das BFSG verlangt Level AA - das mittlere von drei Stufen (A, AA, AAA). Level AA umfasst rund 50 Erfolgskriterien, die von Kontrastverhältnissen über Tastaturnavigation bis zu Formular-Labels reichen.

Wie viel kostet es, eine bestehende WordPress-Seite barrierefrei zu machen?

Das hängt stark vom Ausgangszustand der Seite ab. Bei einer typischen Unternehmenswebseite mit wenigen Seiten und einem soliden Theme rechne ich mit 2 bis 5 Tagen Aufwand - das entspricht ungefähr 1.500 bis 4.000 Euro. Wenn das Theme grundlegende Probleme mitbringt (z.B. kein Fokus-Management, keine semantische Struktur), kann es deutlich teurer werden. Barrierefreiheit von Anfang an einzuplanen kostet dagegen nur 5 bis 10 Prozent mehr.

Welche kostenlosen Tools helfen beim WCAG-Audit?

Drei Tools nutze ich bei jedem Projekt: die WAVE-Browser-Extension (visuell, direkt auf der Seite), axe DevTools (Chrome-Extension mit detaillierten WCAG-Verweisen) und Google Lighthouse (direkt in Chrome DevTools eingebaut). Alle drei zusammen decken aber nur etwa 30 bis 40 Prozent der Kriterien automatisch ab - der Rest erfordert manuelle Prüfung, zum Beispiel Tastaturnavigation und Screen-Reader-Tests.

Was passiert, wenn ich die BFSG-Anforderungen ignoriere?

Der Bußgeldrahmen liegt bei bis zu 100.000 Euro pro Verstoß. Zusätzlich besteht ein Abmahnrisiko durch Wettbewerber und Verbraucherschutzorganisationen. Marktüberwachungsbehörden der Bundesländer sind für die Kontrolle zuständig. Eine Abmahnung wegen fehlender Barrierefreiheitserklärung allein kann schnell mehrere Tausend Euro kosten.

Brauche ich auch eine Barrierefreiheitserklärung auf meiner Webseite?

Ja, das BFSG schreibt eine sogenannte Konformitätserklärung vor. Sie müssen dokumentieren, welche WCAG-Kriterien erfüllt sind, welche nicht und warum - sowie einen Kontaktweg für Hinweise auf Barrieren angeben. Diese Erklärung muss gut auffindbar auf der Webseite verlinkt sein, z.B. im Footer.