Barrierefreie Website nach BFSG: Anforderungen, WCAG & wann ein Relaunch nötig ist

Barrierefreiheit ist mehr als nur eine rechtliche Verpflichtung: Etwa 10 Millionen Menschen in Deutschland leben mit einer Behinderung – viele davon sind potenzielle Kunden, die Sie mit einer nicht-barrierefreien Website ausschließen.

In diesem Artikel erfahren Sie, was eine barrierefreie Website ausmacht, welche technischen Standards gelten und warum Barrierefreiheit komplexer ist, als die meisten Unternehmen zunächst annehmen.

Was ist eine barrierefreie Website?

Eine barrierefreie Website lässt sich von allen Menschen unabhängig von körperlichen, kognitiven oder technischen Einschränkungen vollständig nutzen. Das bedeutet:

• Menschen mit Sehbehinderungen können die Inhalte mit Screenreadern erfassen
• Menschen mit motorischen Einschränkungen navigieren ohne Maus, nur mit der Tastatur
• Menschen mit Hörbehinderungen erhalten Untertitel für Videos
• Menschen mit kognitiven Beeinträchtigungen verstehen die Inhalte durch klare Sprache und Struktur
• Ältere Menschen profitieren von guter Lesbarkeit und intuitiver Bedienung

Barrierefreiheit betrifft mehr Menschen als Sie denken

Etwa 10 Millionen Menschen in Deutschland leben mit einer anerkannten Behinderung. Hinzu kommen:

• Menschen mit temporären Einschränkungen (z. B. nach Augenoperation, gebrochener Arm)
• Ältere Menschen mit altersbedingten Einschränkungen (Sehkraft, Motorik)
• Menschen in schwierigen Nutzungssituationen (laute Umgebung, schlechte Internetverbindung, kleine Bildschirme)

Das sind keine Randgruppen – das sind potenzielle Kunden, Mitarbeiter und Partner.

Was barrierefreie Websites auszeichnet

Barrierefreie Websites sind nicht nur eine rechtliche Verpflichtung, sondern auch wirtschaftlich sinnvoll:

• Größere Zielgruppe: Niemand wird ausgeschlossen
• Bessere User Experience für alle: Klare Struktur, intuitive Navigation, gute Lesbarkeit
• SEO-Vorteile: Suchmaschinen belohnen gut strukturierte, semantisch korrekte Inhalte
• Zukunftssicherheit: Anforderungen werden tendenziell strenger, nicht lockerer
• Rechtssicherheit: Keine Abmahnungen, keine Bußgelder

Das BFSG: Wer ist betroffen?

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die europäische Richtlinie 2019/882 – den sogenannten European Accessibility Act (EAA) – in deutsches Recht um. Anders als bisherige Regelungen wie die BITV (Barrierefreie-Informationstechnik-Verordnung), die primär öffentliche Stellen betraf, richtet sich das BFSG an private Wirtschaftsakteure.

Typischerweise im Fokus des BFSG

Nach aktuellem Kenntnisstand könnten folgende digitale Angebote unter das Gesetz fallen:

• Online-Shops und E-Commerce-Plattformen: Vom Produktkatalog über den Warenkorb bis zum Checkout.
• Buchungs- und Reservierungsportale: Für Reisen, Hotels, Events, Dienstleistungen.
• Kundenportale mit Self-Service-Funktionen: Login-Bereiche, Kontoübersichten, Support-Systeme.
• SaaS-Anwendungen für Endkunden: Cloudbasierte Software, die über den Browser genutzt wird.
• Banking- und Finanzdienstleistungen: Online-Banking, Versicherungsportale, Finanz-Apps.
• E-Books und digitale Publikationen: Mit Ausnahme reiner Audio- oder Video-Inhalte.

Mögliche Ausnahmen (anwaltlich prüfen lassen)

Es gibt Hinweise darauf, dass bestimmte Unternehmen nicht unter das BFSG fallen könnten:

• Kleinstunternehmen: Unter bestimmten Voraussetzungen.
• Reine B2B-Unternehmen: Wenn ausschließlich Geschäftskunden bedient werden.
• Rein informative Websites: Ohne Transaktions- oder Service-Funktionen (z. B. klassische Unternehmenswebsite ohne Shop).

Wichtig: Die genaue Abgrenzung, ob Ihr Unternehmen unter das BFSG fällt, ist eine rechtliche Frage. Wir empfehlen dringend, dies anwaltlich prüfen zu lassen.

Die 4 Prinzipien der Barrierefreiheit (WCAG)

Das BFSG orientiert sich an den Web Content Accessibility Guidelines (WCAG) 2.1 Level AA – einem international anerkannten Standard für digitale Barrierefreiheit. Die WCAG basieren auf vier Grundprinzipien:

1. Wahrnehmbar (Perceivable)

Was bedeutet das? Alle Inhalte müssen für Nutzer wahrnehmbar sein – auch für Menschen mit Seh- oder Hörbehinderungen.

Konkrete Anforderungen:

• Alternative Texte für Bilder: Screenreader können Bilder "vorlesen"
• Untertitel für Videos: Hörbehinderte Menschen verstehen den Inhalt
• Ausreichende Farbkontraste: Mindestens 4,5:1 für normalen Text
• Textalternativen für Audio-Inhalte: Transkripte von Podcasts oder Sprachnachrichten

2. Bedienbar (Operable)

Was bedeutet das? Die Website muss vollständig mit Tastatur, Screenreader oder anderen Hilfsmitteln bedienbar sein.

Konkrete Anforderungen:

• Tastaturnavigation: Alle Funktionen müssen ohne Maus erreichbar sein
• Sichtbarer Fokus: Nutzer erkennen, wo sie sich gerade befinden
• Ausreichend Zeit: Nutzer können Zeitlimits verlängern oder deaktivieren
• Keine Anfall-auslösenden Inhalte: Blinkende Elemente unter 3 Hz vermeiden

3. Verständlich (Understandable)

Was bedeutet das? Inhalte und Bedienung müssen klar und nachvollziehbar sein – auch für Menschen mit kognitiven Einschränkungen.

Konkrete Anforderungen:

• Einfache Sprache: Verständliche Formulierungen, keine unnötigen Fachbegriffe
• Konsistente Navigation: Menüs und Buttons immer an derselben Stelle
• Fehlervermeidung: Hilfreiche Fehlermeldungen mit Korrekturvorschlägen
• Labels für Formularfelder: Jedes Eingabefeld hat eine klare Beschriftung

4. Robust (Robust)

Was bedeutet das? Die Website muss mit verschiedenen Browsern, Geräten und assistiven Technologien funktionieren.

Konkrete Anforderungen:

• Semantisch korrektes HTML: Überschriften als <h1>, <h2>, Buttons als <button>
• ARIA-Attribute: Ergänzende Informationen für Screenreader (bei komplexen Interfaces)
• Kompatibilität mit Hilfstechnologien: Screenreader, Vergrößerungssoftware, Sprachsteuerung
• Zukunftssichere Technik: Standards verwenden, die auch in kommenden Browser-Versionen funktionieren

Warum Barrierefreiheit komplexer ist als gedacht

Viele Unternehmen unterschätzen den Aufwand für eine wirklich barrierefreie Website. Was auf den ersten Blick wie eine einfache Checkliste aussieht, entpuppt sich in der Praxis als hochkomplexes Thema.

„Das ist doch nur HTML“ – Ein teurer Irrtum

Beispiel: Tastaturnavigation

Anforderung klingt simpel: „Alle Elemente müssen per Tab-Taste erreichbar sein.“

In der Praxis:

• Wie navigiert man durch ein Mega-Menü mit mehreren Ebenen?
• Wie schließt man ein Modal-Fenster ohne Maus – und wohin wandert der Fokus danach?
• Wie überspringt man wiederkehrende Elemente (Navigation, Sidebar)?
• Was passiert bei dynamisch nachgeladenen Inhalten?
• Wie verhält sich ein Custom-Slider bei Tastatursteuerung?

Das Ergebnis: Ein einziges Dropdown-Menü kann 15+ WCAG-Verstöße haben, selbst wenn es optisch perfekt funktioniert.

„Wir setzen einfach Alt-Texte“ – Klingt einfach, ist es nicht

Anforderung: Alle Bilder brauchen Alt-Texte.

Was die meisten machen:

1<img src="team-meeting.jpg" alt="team-meeting.jpg">

Was passiert: Screenreader lesen vor: „Bild: team hyphen meeting punkt jay pee gee“ – völlig sinnlos.

Richtig wäre:

1<img src="team-meeting.jpg" alt="Fünf Personen sitzen um einen Konferenztisch und diskutieren Projektpläne">

Aber:

• Dekorative Bilder brauchen alt="" (leer, nicht fehlend!)
• Verlinkte Bilder brauchen Kontext (wohin führt der Link?)
• Icons brauchen zusätzlich aria-label
• Komplexe Infografiken brauchen longdesc oder ausführliche Textalternativen

Die Realität: 90% aller Websites haben fehlerhafte oder sinnlose Alt-Texte.

„Kontrast ist doch egal, sieht man doch“ – 4,49:1 vs. 4,5:1

Anforderung: Farbkontrast mindestens 4,5:1 für normalen Text.

Das Problem:

• Ihr Grauton hat 4,49:1 → Nicht konform
• Sie müssen es für jeden Zustand prüfen: normal, hover, aktiv, deaktiviert, Fehlermeldung
• Auch für Icons, Buttons, Formularfelder
• Auch bei Overlays, Modals, Tooltips

In der Praxis: Designer wählen Farben nach Corporate Design. Dann stellt sich heraus: 70% der Farbkombinationen sind nicht konform. Komplettes Redesign nötig.

„Wir haben doch Überschriften“ – Semantik vs. Optik

Was die meisten machen:

1<div class="heading-style">Das ist eine Überschrift</div>

Was Screenreader sehen: Nichts. Nur Text.

Richtig:

1<h2>Das ist eine Überschrift</h2>

Aber das ist erst der Anfang:

• Überschriften-Hierarchie muss logisch sein (H1 → H2 → H3, keine Sprünge)
• Pro Seite nur eine H1
• Überschriften müssen die Struktur widerspiegeln, nicht das Design
• Listen müssen als <ul> oder <ol> ausgezeichnet sein
• Buttons als <button>, nicht als <div onclick="...">

Die Realität: 80% aller Websites verwenden DIVs statt semantischem HTML – weil es optisch gleich aussieht, aber technisch falsch ist.

Die 3 teuersten Fehler beim DIY-Versuch

Fehler #1: „Wir installieren ein Barrierefreiheits-Plugin“

Was passiert: Viele Unternehmen setzen auf sogenannte Accessibility-Overlays – kleine Plugins, die per Klick Schriftgröße, Kontraste oder Farbschemata ändern.

Warum das scheitert:

• Sie beheben keine strukturellen Probleme: Wenn Ihre Website kein semantisches HTML verwendet, hilft kein Overlay.
• Sie erfüllen die WCAG-Anforderungen nicht vollständig: Nach aktuellem Kenntnisstand reichen sie für BFSG-Konformität nicht aus.
• Sie können neue Barrieren schaffen: Manche Overlays stören Screenreader oder erzeugen Konflikte mit assistiven Technologien.
• Sie täuschen Barrierefreiheit vor: Das kann rechtlich problematisch werden.

Praxisbeispiel: Ein Online-Shop installiert ein Overlay-Tool für 29 €/Monat. Bei einem Audit stellt sich heraus: Die Website hat 180+ WCAG-Verstöße – das Overlay hat davon genau 0 behoben. Stattdessen: 12 neue Barrieren durch das Overlay selbst.

Kosten des Fehlers: 6 Monate verlorene Zeit, kompletter Neuaufbau nötig.

Fehler #2: „Automatische Tests sagen: 0 Fehler“

Was passiert: Unternehmen nutzen Tools wie WAVE, Lighthouse oder axe DevTools. Ergebnis: „0 Fehler gefunden – Website ist barrierefrei!“

Die Wahrheit: Automatische Tools prüfen nur ca. 30% der WCAG-Kriterien. Die restlichen 70% erfordern:

• Manuelle Tests mit echten Screenreadern (NVDA, JAWS, VoiceOver)
• Komplette Tastaturnavigation durchspielen
• Kontext-Prüfung (sind Alt-Texte sinnvoll oder nur technisch vorhanden?)
• Logik-Tests (ist die Tab-Reihenfolge sinnvoll?)
• Nutzer-Tests mit Menschen mit Behinderungen

Praxisbeispiel: Ein Kundenportal besteht alle automatischen Tests. Im manuellen Test:

• Modal-Fenster lässt sich nicht mit ESC schließen
• Nach Schließen wandert der Fokus ins Nirvana
• Fehlermeldungen werden optisch angezeigt, aber Screenreader sagen nichts
• Dropdown-Menü ist mit Tastatur nicht bedienbar
• Dynamische Inhalte werden nicht angekündigt

Ergebnis: 40+ kritische Verstöße, die kein Tool gefunden hat.

Kosten des Fehlers: Website live gegangen → Abmahnung nach 3 Wochen.

Fehler #3: „Wir machen das intern, spart Kosten“

Was passiert: Das Entwickler-Team bekommt die Aufgabe: „Macht die Website barrierefrei.“

Das Problem: Barrierefreiheit ist eine Spezialdisziplin. Selbst erfahrene Entwickler kennen oft nicht:

• Die Feinheiten von ARIA-Attributen
• Wie Screenreader wirklich funktionieren
• Welche WCAG-Erfolgskriterien es gibt (78 Stück in Level AA!)
• Wie man Focus-Management richtig umsetzt
• Wie man dynamische Inhalte barrierefrei macht

Praxisbeispiel: Internes Team arbeitet 3 Monate an Barrierefreiheit. Externes Audit zeigt:

• ARIA-Attribute falsch verwendet → verschlimmern die Situation
• Fokus-Reihenfolge chaotisch
• Formulare nicht richtig verknüpft
• PDFs nicht barrierefrei (wurden vergessen)
• Mobile-Version komplett anders → muss auch konform sein

Kosten des Fehlers: 3 Monate Entwicklerzeit verschwendet (ca. 30.000 €), kompletter Neustart mit Experten nötig.

Scheinbar barrierefrei ≠ BFSG-konform

Viele Websites sehen auf den ersten Blick barrierefrei aus, sind es aber nicht.

„Die Website funktioniert doch mit Tastatur“ – Wirklich?

Was getestet wird: Tab-Taste drücken, ein paar Elemente anspringen → funktioniert.

Was fehlt:

• Ist der Fokus immer sichtbar? (Auch bei Custom-Elementen?)
• Ist die Reihenfolge logisch? (Nicht: Header → Footer → Content)
• Kann man alles erreichen? (Auch versteckte Elemente in Dropdowns?)
• Kann man Aktionen abbrechen? (ESC schließt Modal, etc.)
• Bleibt der Kontext erhalten? (Wo bin ich nach dem Schließen eines Dialogs?)

„Wir haben überall Alt-Texte“ – Ja, aber welche?

Schlecht:

1<img src="img_2847.jpg" alt="img_2847">
2<img src="logo.png" alt="Logo"> <!-- Welches Logo? Wofür? -->
3<img src="icon.svg" alt="Icon"> <!-- Welches Icon? -->

Besser, aber immer noch falsch:

1<img src="team.jpg" alt="Team"> <!-- Zu unspezifisch -->

Richtig:

1<img src="team.jpg" alt="Fünf Personen des Marketing-Teams bei der Strategieplanung">

Noch komplexer:

• Dekorative Bilder: alt="" (leer!)
• Verlinkte Bilder: Alt-Text muss Link-Ziel beschreiben
• Komplexe Diagramme: Zusätzliche Beschreibung nötig

„Der Kontrast passt doch“ – Bei welchem Zustand?

Kontrast muss geprüft werden für:

• Normaler Zustand
• Hover-Zustand
• Fokus-Zustand
• Aktiv-Zustand
• Deaktiviert-Zustand
• Fehlerzustand
• Alle Farbvarianten (Dark Mode, High Contrast)

Typischer Fehler: Button hat 4,5:1 im Normalzustand, aber nur 3,8:1 im Hover → nicht konform.

Barrierefreie Website: Komplexitäts-Checkliste

Diese Checkliste zeigt nicht, wie Sie Barrierefreiheit umsetzen – sondern wie komplex jeder einzelne Punkt wirklich ist.

Technische Grundlagen

✅ Semantisch korrektes HTML

Klingt simpel, oder?

• Wann verwenden Sie <button> vs. <a>? (Spoiler: 70% aller Websites verwechseln das)
• Wie strukturieren Sie verschachtelte Navigation?
• Was ist mit role="presentation" vs. aria-hidden?
• Wie zeichnen Sie Landmarks aus (<nav>, <main>, <aside>)?

Realität: Selbst erfahrene Entwickler scheitern hier in 8 von 10 Fällen.

✅ Tastaturnavigation vollständig

Was meist fehlt:

• Skip-Links zum Überspringen wiederkehrender Elemente
• Fokus-Falle in Modals (kann man rein, kommt aber nicht mehr raus)
• Logische Tab-Reihenfolge (nicht visuell, sondern DOM-Reihenfolge)
• Fokus-Management bei dynamischen Inhalten

Realität: Ein einziges Modal-Fenster kann 20+ WCAG-Verstöße haben.

✅ Farbkontraste mindestens 4,5:1

Wo überall?

• Text auf Hintergrund (alle Kombinationen!)
• Buttons (normal, hover, aktiv, deaktiviert)
• Formularfelder (leer, ausgefüllt, Fehler)
• Icons und UI-Elemente (mindestens 3:1)
• Overlays, Modals, Tooltips
• Dark Mode / High Contrast Mode

Realität: 90% aller Corporate Designs sind nicht konform und müssen angepasst werden.

✅ Alle Bilder haben Alt-Texte

Aber:

• Dekorative Bilder: alt="" (leer, nicht fehlend)
• Informative Bilder: Beschreibung des Inhalts (nicht des Dateinamens)
• Verlinkte Bilder: Beschreibung des Link-Ziels
• Komplexe Grafiken: longdesc oder ausführliche Alternative
• Icons: Zusätzlich aria-label

Realität: 95% aller Alt-Texte sind sinnlos oder fehlen.

Formulare & Interaktion

✅ Formularfelder mit Labels

Das ist nur der Anfang:

• Labels programmatisch verknüpft (<label for="id">), nicht nur visuell daneben
• Pflichtfelder nicht nur mit *, sondern auch aria-required="true"
• Fehlermeldungen programmatisch verknüpft (aria-describedby)
• Erfolgsmeldungen werden von Screenreadern erkannt (role="alert")
• Autovervollständigung funktioniert mit Screenreader

Realität: 80% aller Formulare sind nicht barrierefrei – auch wenn sie optisch perfekt sind.

✅ Fehlermeldungen erkennbar

Was meist fehlt:

• Nur rote Umrandung (Farbe allein reicht nicht!)
• Fehlermeldung nur visuell, nicht für Screenreader
• Keine Anleitung, wie man den Fehler behebt
• Fehler wird nicht angekündigt (aria-live="polite")

Realität: Nutzer sehen Fehler, Screenreader schweigen.

Navigation & Struktur

✅ Überschriften-Hierarchie korrekt

Typische Fehler:

• Mehrere H1 auf einer Seite
• Sprünge in der Hierarchie (H1 → H3)
• DIVs mit CSS-Styling statt echten <h2>-Tags
• Überschriften nach Design, nicht nach Struktur

Realität: 70% aller Websites haben fehlerhafte Überschriften-Struktur.

✅ Breadcrumbs zur Orientierung

Aber:

• Als <nav> mit aria-label="Breadcrumb" ausgezeichnet
• Liste (<ol>) mit korrektem Markup
• Aktueller Punkt mit aria-current="page"
• Schema.org BreadcrumbList für SEO

Realität: Die meisten Breadcrumbs sind optisch da, semantisch falsch.

Content

✅ Verständliche Sprache

Was heißt das konkret?

• Flesch Reading Ease: 60-70 (8./9. Klasse)
• Kurze Sätze (max. 20 Wörter)
• Keine Fachbegriffe ohne Erklärung
• Aktive statt passive Formulierungen

Realität: Die meisten Unternehmens-Websites liegen bei Flesch 30-40 (Universitätsniveau) – zu komplex.

✅ Videos mit Untertiteln

Aber:

• Nicht automatisch generiert (zu fehlerhaft)
• Synchron mit Audio
• Auch wichtige Geräusche beschrieben („Tür knarrt“, „Telefon klingelt“)
• Für Gebärdensprache-Nutzer: Gebärdensprach-Video zusätzlich

Realität: 90% aller Unternehmens-Videos haben keine oder fehlerhafte Untertitel.

Testing

✅ Mit Screenreader getestet

Womit?

• NVDA (Windows, kostenlos)
• JAWS (Windows, professionell)
• VoiceOver (Mac/iOS, integriert)
• Nicht nur ein Tool – verschiedene verhalten sich unterschiedlich
• Nicht nur Homepage – jede Seite, jeder Zustand

Realität: 99% aller Unternehmen haben nie mit echtem Screenreader getestet.

✅ Automatisierte Tests durchgeführt

Wichtig zu wissen:

• WAVE, axe, Lighthouse finden nur 30% der Probleme
• Jedes Tool findet andere Fehler → alle verwenden
• Automatische Tests sind der Anfang, nicht das Ende

Realität: Die meisten verlassen sich nur auf automatische Tests – und übersehen 70% der Barrieren.

Warum sich eine professionelle Umsetzung lohnt

Zeit & Kosten realistisch einschätzen

DIY-Versuch (typisch):

• 3-6 Monate internes Rumprobieren
• Kosten: 20.000-50.000 € (interne Entwicklerzeit)
• Ergebnis: 60-70% konform (reicht nicht)
• Nacharbeit: Nochmal 2-3 Monate

Professionelle Umsetzung:

• 6-12 Wochen strukturierter Prozess
• Kosten: Transparente Kalkulation nach Ist-Zustand
• Ergebnis: WCAG 2.1 Level AA konform
• Dokumentation & Schulung inklusive

Rechtssicherheit durch Dokumentation

Wir liefern nicht nur eine barrierefreie Website, sondern:

• Konformitätserklärung nach BFSG
• WCAG-Audit-Report mit allen geprüften Kriterien
• Barrierefreiheits-Dokumentation für Ihre Rechtsabteilung
• Schulung Ihres Teams für barrierefreie Pflege
• Wartungsvertrag für kontinuierliche Konformität

Barrierefreiheit ab Konzeption – nicht nachträglich

Der beste Zeitpunkt für Barrierefreiheit: Von Anfang an.

Kosten-Vergleich:

• Barrierefreiheit ab Konzeption: +10-15% Projektkosten
• Nachträgliche Anpassung: +50-100% der ursprünglichen Kosten

Wenn Sie ohnehin einen Website-Relaunch planen: Jetzt ist der ideale Zeitpunkt.

Website-Relaunch: Die Chance für Barrierefreiheit

Die BFSG-Frist ist seit Juni 2025 abgelaufen. Wenn Ihre Website noch nicht konform ist und Sie ohnehin über einen Relaunch nachdenken: Nutzen Sie die Chance.

Warum gerade beim Relaunch?

• Günstiger als nachträgliche Anpassungen: Barrierefreiheit ins Konzept zu integrieren spart 40-60% der Kosten.
• Moderne Technologien nutzen: Neue Frameworks und CMS bringen oft bessere Barrierefreiheits-Features mit.
• Einmalige Chance: Bei einem Relaunch können Sie die Struktur von Grund auf neu denken.
• Kein Legacy-Code: Historisch gewachsene Strukturen werden aufgeräumt – perfekter Zeitpunkt für Barrierefreiheit.

Unser Ansatz: Barrierefreiheit als Standard

Wir bei FeichtMedia bauen Barrierefreiheit standardmäßig in jeden Website-Relaunch ein:

• Barrierefreiheit ab Konzeptionsphase mitdenken
• WCAG 2.1 Level AA als Mindeststandard
• Regelmäßige Tests während der Entwicklung (nicht erst am Ende)
• Dokumentation aller Maßnahmen für Rechtssicherheit
• Schulung Ihres Teams für barrierefreie Content-Pflege

Was Sie jetzt tun sollten

Schritt 1: Rechtliche Situation klären

• Lassen Sie anwaltlich prüfen, ob das BFSG für Ihr Unternehmen gilt
• Klären Sie, welche Bereiche Ihrer Website betroffen sein könnten
• Verschaffen Sie sich Klarheit über mögliche Konsequenzen

Schritt 2: Ist-Zustand analysieren

Wo steht Ihre Website aktuell?

• Welche kritischen Barrieren bestehen?
• Wie groß ist der Handlungsbedarf?
• Was lässt sich schnell beheben, was erfordert Umbau?

Wichtig: Ein professionelles Barrierefreiheits-Audit umfasst:

• Technische Prüfung (Code, Struktur, ARIA)
• Manuelle Tests mit Screenreadern (NVDA, JAWS, VoiceOver)
• Tastaturnavigation-Tests
• Kontrastprüfungen
• Content-Analyse (Sprache, Alt-Texte)

Automatisierte Tools wie WAVE oder Lighthouse geben erste Hinweise, finden aber nur 30% der Probleme.

Schritt 3: Professionelle Umsetzung

Barrierefreie Websites erfordern Know-how in Design UND Entwicklung:

Design:

• Farbkontraste ab 4,5:1
• Schriftgrößen mindestens 16px
• Sichtbare Fokus-Indikatoren
• Touch-Targets mindestens 44×44px
• Konsistente visuelle Hierarchie

Entwicklung:

• Semantisches HTML (<nav>, <main>, <article>, etc.)
• ARIA-Attribute für komplexe Interfaces
• Vollständige Tastaturnavigation
• Screenreader-Tests (NVDA, JAWS, VoiceOver)
• Skip-Links für wiederkehrende Elemente

Content:

• Verständliche Sprache (Flesch Reading Ease ca. 60-70)
• Sinnvolle Alt-Texte (nicht „bild123.jpg“)
• Barrierefreie PDFs
• Untertitel für Videos
• Transkripte für Audio-Inhalte

Als Digitalagentur unterstützen wir Sie bei der Umsetzung einer barrierefreien Website – von der Analyse bis zum Go-Live. Mehr zu unseren Website-Leistungen

Schritt 4: Kontinuierliche Konformität sicherstellen

Barrierefreiheit ist kein einmaliger Zustand, sondern ein kontinuierlicher Prozess:

• Regelmäßige Audits: Mindestens jährlich, nach größeren Updates sofort
• Schulung des Teams: Redakteure, Designer, Entwickler müssen Barrierefreiheit verstehen
• Dokumentation: Welche Maßnahmen wurden ergriffen? Welche Ausnahmen gibt es?
• Wartungsvertrag: Sicherstellt, dass neue Inhalte konform bleiben

Häufig gestellte Fragen zu barrierefreien Websites

Bereit für eine barrierefreie Website?

Die BFSG-Frist ist seit Juni 2025 abgelaufen. Jeder Tag ohne Konformität ist ein Risiko – rechtlich und wirtschaftlich.

Ob aus gesetzlicher Pflicht oder weil Sie alle Nutzer erreichen möchten: Wir unterstützen Sie bei Analyse, Konzeption und Umsetzung einer barrierefreien Website.

Als Digitalagentur mit Fokus auf nachhaltige, zukunftssichere Websites bauen wir Barrierefreiheit von Anfang an ein – als Standard, nicht als Extra.

* Wir sind nicht dazu befugt, Sie rechtlich zu beraten. Entsprechend empfehlen wir Ihnen, vorab anwaltlich prüfen zu lassen, ob und in welcher Form digitale Barrierefreiheit für Sie verpflichtend ist.