Die digitale Barrierefreiheit rückt für Unternehmen jetzt in den Fokus: Ab 28. Juni 2025 wird das Barrierefreiheitsstärkungsgesetz (BFSG) wirksam, das für viele Websites zur Pflicht macht, was bisher nur öffentliche Stellen betraf.
Deine Unternehmenswebsite muss dann möglicherweise die WCAG-Richtlinien erfüllen – besonders wenn du Online-Shops betreibst, Termine buchbar machst oder andere interaktive Dienste anbietest.
Doch keine Sorge: Mit dem richtigen Wissen und einer strukturierten Herangehensweise kannst du nicht nur die gesetzlichen Anforderungen erfüllen, sondern auch die Nutzererfahrung und Reichweite deiner digitalen Angebote deutlich verbessern.
Dieser Beitrag zeigt dir, was die WCAG-Standards wirklich bedeuten, welche konkreten Anforderungen auf dein Unternehmen zukommen und wie du sie Schritt für Schritt umsetzen kannst – mit praktischen Beispielen und ohne unnötige technische Komplikationen.
Prüfstandards WCAG 2.1 und WCAG 2.2
Welche Version ist wann anzuwenden?
- WCAG 2.1 ist aktuell (Stand Mai 2025) rechtlich bindend:
- Für öffentliche Stellen in Deutschland, da die geltende EN 301 549 v3.2.1 auf WCAG 2.1 verweist
- Für Websites und mobile Anwendungen, die unter die EU-Richtlinie 2102 fallen
- WCAG 2.2 ist empfohlen, aber noch nicht formal verpflichtend:
- Für zukunftssichere Implementierungen sollten neue Projekte bereits WCAG 2.2 berücksichtigen
- Es wird erwartet, dass die europäische Norm in naher Zukunft aktualisiert wird, um WCAG 2.2 zu referenzieren
- Empfehlung für die Praxis:
- Bei vorhandenen Websites: Mindestens WCAG 2.1 AA umsetzen, um rechtlich konform zu sein
- Bei Neugestaltungen: WCAG 2.2 implementieren, um zukunftssicher zu sein und Menschen mit Behinderungen bessere Zugänglichkeit zu bieten
- Die neun neuen Erfolgskriterien der WCAG 2.2 berücksichtigen, da sie Verbesserungen darstellen, die die Barrierefreiheit erhöhen
Für wen ist die Barrierefreiheit nach WCAG 2.1 Pflicht?
Die Verpflichtung zur Einhaltung der WCAG 2.1-Richtlinien variiert je nach Rechtsrahmen, Art der Organisation und Art der digitalen Inhalte. Hier ist eine detaillierte Analyse verschiedener Szenarien:
1. Öffentliche Stellen und Behörden
In der Europäischen Union:
- Die EU-Richtlinie 2102 regelt den barrierefreien Zugang zu Websites und mobilen Anwendungen öffentlicher Stellen
- Öffentliche Stellen auf Bundes-, Landes- und kommunaler Ebene müssen ihre digitalen Angebote barrierefrei gestalten
- Darunter fallen:
- Ministerien und Bundesbehörden
- Landesbehörden
- Kommunalverwaltungen und Rathäuser
- Öffentliche Universitäten und Hochschulen
- Öffentliche Krankenhäuser
- Öffentlicher Nahverkehr
- Bundesagentur für Arbeit und ähnliche Einrichtungen
In Deutschland speziell:
- Die EU-Richtlinie wurde im Behindertengleichstellungsgesetz (BGG) verankert
- Die konkrete Umsetzung erfolgt durch die Barrierefreie-Informationstechnik-Verordnung (BITV) 2.0
- Auf Landesebene gibt es zusätzliche Regelungen durch die jeweiligen Landes-Behindertengleichstellungsgesetze
Welche digitalen Angebote fallen darunter:
- Öffentlich zugängliche Websites
- Intranets und Extranets, die nach dem 23. September 2019 veröffentlicht wurden
- Mobile Anwendungen (Apps)
- Elektronische Verwaltungsabläufe (spätestens ab dem 23. Juni 2021)
2. Privatwirtschaft und Unternehmen
Allgemeine kommerzielle Websites:
- EU-weit: Für allgemeine Unternehmenswebsites gab es bis zum Inkrafttreten des Barrierefreiheitsstärkungsgesetzes keine gesetzliche Verpflichtung zur Einhaltung der WCAG 2.1
E-Commerce und wichtige Dienstleistungen:
- Mit dem Barrierefreiheitsstärkungsgesetz (BFSG):
- Das BFSG tritt am 28. Juni 2025 in Kraft
- Ab diesem Datum müssen Dienstleistungen gegenüber Verbrauchern barrierefrei erbracht werden
- Betrifft: Online-Shops, Websites mit Terminbuchungen/Reservierungen, Kontaktaufnahmemöglichkeiten und Interaktionsmöglichkeiten als wesentliche Zwischenschritte zu Verbraucherverträgen
Ausnahmen für Unternehmen:
- Kleinstunternehmen sind ausgenommen (unter 10 Personen und max. 2 Millionen Euro Jahresumsatz)
- Reine Präsentationswebsites ohne Interaktionsmöglichkeiten müssen die Anforderungen nicht erfüllen
- Blogs ohne Interaktionsmöglichkeiten sind ebenfalls ausgenommen
3. Besondere Anwendungsfälle
Banken und Finanzdienstleister:
- EU-weit: Banken-Websites und Online-Banking fallen unter die Verpflichtungen, insbesondere mit dem Barrierefreiheitsstärkungsgesetz
- Diese müssen sowohl die Website als auch die Authentifizierungsverfahren barrierefrei gestalten
Bildungseinrichtungen:
- Öffentliche Bildungseinrichtungen: Verpflichtet zur Einhaltung der WCAG 2.1
- Private Bildungseinrichtungen: Grundsätzlich nicht verpflichtet, sofern sie nicht unter andere Regelungen fallen (z.B. als Anbieter von E-Commerce-Dienstleistungen)
- Ausnahme: Wenn lokale Gesetze zur Barrierefreiheit im Bildungswesen existieren
Gesundheitswesen:
- Öffentliche Gesundheitseinrichtungen: Müssen WCAG 2.1 einhalten
- Private Gesundheitsanbieter: Ab 2025 mit dem BFSG, wenn sie Terminbuchungssysteme oder Online-Dienstleistungen anbieten
Vereine und Non-Profit-Organisationen:
- Grundsätzlich nicht verpflichtet, sofern sie nicht öffentlich finanziert werden
- Ausnahme: Wenn sie bestimmte Dienstleistungen im elektronischen Geschäftsverkehr anbieten (ab 2025)
4. Konformitätsstufen und Umsetzungstiefe
Die Verpflichtungen beziehen sich in der Regel auf bestimmte Konformitätsstufen:
- Die EU-Norm EN 301 549 referenziert nur die Erfolgskriterien der Stufen A und AA
- Diese Stufen gelten als Muss-Kriterien für öffentliche Stellen
- In Deutschland wird WCAG 2.0 AA als gesetzlicher Standard anerkannt, aber die aktuelle Norm verweist auf WCAG 2.1 AA
Besonderheiten:
- In Sachsen-Anhalt beispielsweise fordert die BGGVO LSA für bestimmte Angebote sogar die Erfüllung der Stufe AAA
5. Praktische Unterscheidungen nach Nutzungsszenarien
Szenario 1: Kleine Unternehmenswebsite ohne Shop
Ein Handwerksbetrieb mit 5 Mitarbeitern hat eine einfache Website mit Firmeninformationen, aber ohne Online-Shop oder Terminbuchung:
- Bis 2025: Keine gesetzliche Verpflichtung zur WCAG 2.1-Konformität
- Ab 2025: Weiterhin keine Verpflichtung, da Kleinstunternehmen und keine relevanten Dienstleistungen
Szenario 2: Online-Shop eines mittelständischen Unternehmens
Ein Unternehmen mit 30 Mitarbeitern betreibt einen Online-Shop für seine Produkte:
- Bis 2025: Keine gesetzliche Verpflichtung zur WCAG 2.1-Konformität
- Ab 2025: Volle Verpflichtung zur Einhaltung der WCAG 2.1 (Stufen A und AA) durch das BFSG
Szenario 3: Verein mit Spendenplattform
Ein gemeinnütziger Verein sammelt über seine Website Spenden:
- Bis 2025: Keine gesetzliche Verpflichtung
- Ab 2025: Verpflichtung für den Spendenprozess als Dienstleistung im elektronischen Geschäftsverkehr, wenn der Verein keine Kleinstorganisation ist
Szenario 4: Arztpraxis mit Terminbuchung
Eine private Arztpraxis bietet Online-Terminbuchung an:
- Bis 2025: Keine gesetzliche Verpflichtung
- Ab 2025: Verpflichtung zur Barrierefreiheit für das Terminbuchungssystem, außer die Praxis gilt als Kleinstunternehmen
Szenario 5: Städtische Website
Die Website einer Stadt mit Bürgerservices:
- Seit 2019: Verpflichtung zur vollständigen WCAG 2.1-Konformität (Level AA)
- Muss zusätzlich eine Erklärung zur Barrierefreiheit bereitstellen und Feedback-Möglichkeiten anbieten
Die Frage nach der Barrierefreiheitspflicht für B2B-Unternehmen ist wichtig und erfordert eine differenzierte Betrachtung:
Gilt die Barrierefreiheit auch für B2B Unternehmen?
Das Barrierefreiheitsstärkungsgesetz (BFSG) fokussiert hauptsächlich auf Dienstleistungen im elektronischen Geschäftsverkehr gegenüber Verbrauchern (B2C). Bei reinen B2B-Unternehmen gilt daher folgende Unterscheidung:
Grundsätzlich nicht verpflichtend für:
- Reine B2B-Webseiten, die ausschließlich für gewerbliche Kunden zugänglich sind
- Interne Portale und Plattformen, die nur für Geschäftskunden oder Partner bestimmt sind
- B2B-Produktkataloge und -Preislisten, sofern sie nicht auch Verbrauchern zugänglich gemacht werden
Verpflichtend können jedoch sein:
- Gemischte Geschäftsmodelle:
- Wenn dein B2B-Unternehmen auch Dienstleistungen für Endverbraucher anbietet
- Wenn die Website Terminbuchungen, Kontaktaufnahmemöglichkeiten oder andere interaktive Funktionen enthält, die als „wesentliche Zwischenschritte zum Abschluss eines Verbrauchervertrages“ gelten könnten
- Öffentlich zugängliche Bereiche:
- Falls deine Website öffentlich zugänglich ist und Verbraucher sie nutzen können, auch wenn sie nicht die primäre Zielgruppe sind
- Login-Bereiche für Bestandskunden fallen dabei oft in eine Grauzone
- Ausnahme Kleinstunternehmen:
- Unternehmen mit weniger als 10 Beschäftigten und einem Jahresumsatz oder einer Jahresbilanzsumme von höchstens 2 Millionen Euro sind von der Verpflichtung ausgenommen
Checkliste für Barrierefreiheit nach WCAG 2.1 und 2.2
Diese Checkliste basiert auf den WCAG-Richtlinien und den Prinzipien der Barrierefreiheit: Wahrnehmbar, Bedienbar, Verständlich und Robust. Die Liste enthält konkrete Anforderungen mit Beispielen und Umsetzungsmaßnahmen.
WCAG 2.1 Anforderungen (Basis)
Prinzip 1: Wahrnehmbar
1.1 Textalternativen für Nicht-Text-Inhalte
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Alternativtexte für Bilder | Ein Diagramm, das Verkaufszahlen zeigt | <img src="verkauf.jpg" alt="Diagramm: Verkaufssteigerung um 25% im 2. Quartal 2024"> |
| Leere Alt-Attribute für dekorative Bilder | Dekoratives Trennelement | <img src="linie.png" alt=""> oder <img src="linie.png" role="presentation"> |
1.2 Zeitbasierte Medien
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Untertitel für Videos | Interview-Video | Untertitel als .vtt-Datei bereitstellen und via <track> einbinden |
| Audiodeskription oder Transkript für Videos | Tutorial-Video mit visuellen Anleitungen | Zusätzliche Audiospur oder Textdokument bereitstellen, das visuelle Inhalte beschreibt |
1.3 Anpassbare Inhalte
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Semantische HTML-Struktur | Überschriftenstruktur einer Webseite | <h1>, <h2>, <h3> etc. in logischer Hierarchie verwenden |
| Tabellen korrekt auszeichnen | Datentabelle mit Umsatzzahlen | <th> für Spalten-/Zeilenüberschriften, <caption> für Tabellenbeschreibung |
| Formularfelder beschriften | Kontaktformular | <label for="email">E-Mail:</label><input id="email" type="email"> |
1.4 Unterscheidbarkeit
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Ausreichender Farbkontrast | Text auf farbigem Hintergrund | Kontrastverhältnis von mindestens 4,5:1 für normalen Text, mit Tools wie WebAIM Contrast Checker prüfen |
| Nicht nur Farbe zur Informationsvermittlung | Fehler in einem Formular | Neben roter Farbe auch ein Symbol (z.B. Ausrufezeichen) und Text verwenden |
| Textvergrößerung ohne Funktionsverlust | Navigation bei Zoom | Responsive Design, das auch bei 200% Zoom funktioniert ohne horizontales Scrollen |
Prinzip 2: Bedienbar
2.1 Tastaturzugänglichkeit
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Alle Funktionen per Tastatur bedienbar | Dropdown-Menü | Mit Tab-Taste fokussierbar und mit Enter/Leertaste aktivierbar machen, keine exklusiven Mausaktionen |
| Keine Tastaturfallen | Modal-Dialog | Sicherstellen, dass der Fokus nicht im Dialog gefangen bleibt, ESC-Taste zum Schließen implementieren |
2.2 Ausreichend Zeit
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Zeitlimits anpassbar | Session-Timeout | Benutzer vor Ablauf warnen und Möglichkeit zur Verlängerung geben |
| Bewegung anhalten, stoppen, ausblenden | Auto-Carousel | Pause-Button anbieten, Animation bei Hover/Fokus stoppen |
2.3 Keine Anfälle auslösen
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Keine blinkenden Inhalte | Werbeanimation | Auf Blitzeffekte verzichten, max. 3 Blitze pro Sekunde |
2.4 Navigierbar
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Sinnvolle Dokumenttitel | Browser-Tab-Titel | <title>Produktkatalog - Unternehmen XYZ</title> |
| Skip-Links | Navigation überspringen | <a href="#content" class="skip-link">Zum Inhalt springen</a> |
| Fokus sichtbar | Aktives Formularfeld | CSS-Fokus-Stil definieren: input:focus { outline: 2px solid #1976d2; } |
| Beschreibende Link-Texte | Link zu Download | „Produktbroschüre herunterladen (PDF, 2 MB)“ statt „Hier klicken“ |
2.5 Eingabemodalitäten (neu in WCAG 2.1)
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Zeigergesten-Alternativen | Wisch-Geste zum Blättern | Zusätzlich Vor/Zurück-Buttons anbieten |
| Pointer Cancellation | Drag & Drop | Aktion erst bei Loslassen (mouseup) ausführen, nicht bei Berührung |
| Beschriftung im Namen | Button mit Symbol | Sichtbarer Text muss im barrierefreien Namen enthalten sein |
Prinzip 3: Verständlich
3.1 Lesbar
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Seitensprache festlegen | Deutsch | <html lang="de"> |
| Sprachwechsel kennzeichnen | Englisches Zitat | <blockquote lang="en">The future is now</blockquote> |
3.2 Vorhersehbar
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Keine Kontextänderung bei Fokus | Dropdown-Navigation | Menü erst bei Klick/Enter öffnen, nicht schon bei Fokus |
| Konsistente Navigation | Hauptmenü | Menü an gleicher Position und mit gleicher Reihenfolge auf allen Seiten |
3.3 Eingabehilfe
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Fehlererkennung | Formularvalidierung | Fehler klar markieren und beschreiben: „Bitte geben Sie eine gültige E-Mail-Adresse ein“ |
| Beschriftungen und Anweisungen | Datumsfeld | Label + Hinweis: „Geburtsdatum (TT.MM.JJJJ)“ |
Prinzip 4: Robust
4.1 Kompatibel
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| Name, Rolle, Wert für UI-Komponenten | Custom Dropdown | ARIA-Attribute verwenden: role="combobox", aria-expanded="false" |
| Statusmeldungen | Formular abgeschickt | aria-live="polite" für Meldungen, die nicht sofort Aufmerksamkeit erfordern |
Zusätzliche WCAG 2.2 Anforderungen
Prinzip 2: Bedienbar
2.4 Navigierbar (Erweiterungen)
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| 2.4.11 Fokus nicht verdeckt (AA) | Modal-Dialog über fokussiertem Element | Sicherstellen, dass fokussierte Elemente nicht von Overlays verdeckt werden, mindestens teilweise sichtbar bleiben |
| 2.4.12 Fokus nicht verdeckt (erweiterter Schutz) (AAA) | Tooltip verdeckt fokussiertes Element | Sicherstellen, dass fokussierte Elemente vollständig sichtbar bleiben |
| 2.4.13 Erscheinungsbild des Fokus (AAA) | Fokus-Indikator | Mindestens 2 CSS-Pixel breiter Umriss mit Kontrastverhältnis von mindestens 3:1 zum umgebenden Inhalt |
2.5 Eingabemodalitäten (Erweiterungen)
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| 2.5.7 Ziehende Bewegungen (AA) | Karte verschieben | Alternative durch Klick auf Pfeile/Buttons anbieten, nicht nur Drag & Drop |
| 2.5.8 Zielgröße (Minimum) (AA) | Klickbare Elemente | Zielgröße von mindestens 24×24 Pixeln oder Mindestabstand von 24 Pixeln zu anderen klickbaren Elementen sicherstellen |
Prinzip 3: Verständlich
3.2 Vorhersehbar (Erweiterungen)
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| 3.2.6 Konsistente Hilfe (A) | Hilfefunktionen | Hilfefunktionen (Kontakt, Hilfe, Feedback, etc.) an gleicher Position auf allen Seiten platzieren |
3.3 Eingabehilfe (Erweiterungen)
| Anforderung | Beispiel | Umsetzungsmaßnahmen |
|---|---|---|
| 3.3.7 Redundante Eingabe (A) | Mehrere Formularschritte | Bereits eingegebene Informationen (z.B. Adresse) vorausfüllen, wenn sie erneut benötigt werden |
| 3.3.8 Barrierefreie Authentifizierung (AA) | Login-Prozess | Alternative zu CAPTCHAs anbieten, kognitive Funktionstests vermeiden oder Alternativen bereitstellen |
| 3.3.9 Barrierefreie Authentifizierung (ohne Ausnahmen) (AAA) | 2-Faktor-Authentifizierung | Keine kognitiven Funktionstests in irgendeinem Schritt der Authentifizierung |
Praktische Umsetzungstipps
- Validierung und Tests:
- HTML- und CSS-Validierung durchführen
- Tests mit Screen Readern (z.B. NVDA, JAWS, VoiceOver)
- Tastaturnavigation überprüfen
- Farbkontrast mit Tools wie WebAIM Contrast Checker testen
- Entwicklungsprozess:
- Barrierefreiheit von Anfang an berücksichtigen
- Regelmäßige Audits durchführen
- Feedback von Nutzern mit Behinderungen einholen
- Dokumentation:
- Barrierefreiheitserklärung erstellen und aktuell halten
- Ansprechpartner für Feedback benennen
- Alternative Kontaktmöglichkeiten anbieten
- Technik und Code:
- Semantisches HTML verwenden
- JavaScript so einsetzen, dass es bei Deaktivierung keine kritischen Funktionen beeinträchtigt
- WAI-ARIA nur bei Bedarf und korrekt einsetzen
- Responsive Design umsetzen
- Content-Management:
- Redakteure in barrierefreier Inhaltserstellung schulen
- CMS-Plugins für Barrierefreiheit nutzen
- Qualitätssicherung für nutzergenerierte Inhalte
Schriftgrößen und Kontraste: Pflicht oder Empfehlung?
Anpassbare Schriftgrößen:
Nach den WCAG-Richtlinien ist es nicht zwingend erforderlich, dass Websites eine dedizierte Funktion zur Änderung der Schriftgröße anbieten müssen. Stattdessen muss folgendes gewährleistet sein:
- Es müssen Zoom-Optionen für Web-Inhalte angeboten werden
- Gemäß WCAG 2.1, Erfolgskriterium 1.4.4 (AA): Text muss bis zu 200% vergrößert werden können, ohne dass Funktionalität verloren geht oder horizontales Scrollen nötig wird
- Die Website muss mit den Standard-Browserfunktionen zum Vergrößern (Strg/Cmd + Plus, Browser-Zoom) korrekt funktionieren
- Der Text muss bei Vergrößerung lesbar bleiben und darf nicht abgeschnitten werden oder andere Inhalte überlagern
Es ist also keine separate Schriftgrößenanpassungsfunktion auf der Website selbst erforderlich, solange die Website mit den eingebauten Browser-Zoomfunktionen korrekt skaliert.
Kontrasteinstellungen:
Bezüglich anpassbarer Kontraste:
- Es ist nicht verpflichtend, dass eine Website Funktionen zur individuellen Kontrastanpassung anbietet
- WCAG 2.1, Erfolgskriterium 1.4.3 (AA) fordert jedoch: Kontrastverhältnis von mindestens 4,5:1 für normalen Text und 3:1 für großen Text
- WCAG 2.1, Erfolgskriterium 1.4.11 (AA) verlangt zudem einen Kontrast von 3:1 für Bedienelemente und grafische Objekte
- In einigen spezifischen Situationen gibt es Ausnahmen, z.B. für Logos, dekorative Elemente oder inaktive Bedienelemente
Wichtig ist, dass die Website in ihrer Standard-Darstellung die Mindestkontrastverhältnisse erfüllt. Eine zusätzliche Kontrastumschaltung (z.B. „Hoher Kontrast“ oder „Dunkelmodus“) ist empfehlenswert, aber nicht verpflichtend.
Zusammenfassung:
- Pflicht: Texte müssen mit Browserfunktionen auf 200% vergrößerbar sein; ausreichende Kontrastverhältnisse müssen in der Standardansicht gegeben sein
- Keine Pflicht: Dedizierte Funktionen zur Schriftgrößen- oder Kontrastanpassung direkt auf der Website
Für eine bessere Nutzererfahrung und eine inklusivere Website ist es jedoch empfehlenswert, zusätzliche Anpassungsoptionen anzubieten, wie z.B.:
- Schaltflächen zur Textvergrößerung
- Kontrastumschalter (z.B. Dunkelmodus oder hoher Kontrast)
- Möglichkeit, Schriftarten zu ändern
Diese zusätzlichen Optionen verbessern die Barrierefreiheit über die Mindestanforderungen hinaus und werden von vielen Nutzern mit und ohne Behinderungen geschätzt.
