Website barrierefrei machen: Die Schritt-für-Schritt-Anleitung 2026 (Inklusive Checklisten)

Zuletzt aktualisiert am 20. Oktober 2026

Seit dem 28. Juni 2025 verpflichten das deutsche BFSG und das österreichische BaFG private Unternehmen zur digitalen Barrierefreiheit (gemäß EAA). Bei Verstößen drohen Marktverbote sowie Bußgelder von bis zu 100.000 € (DE) bzw. 80.000 € (AT) pro Fall. Dieser Leitfaden zeigt Ihnen Schritt für Schritt, wie Sie Ihre Website mit einer praktischen Checkliste (Bilder, Formulare, Kontraste, Tastaturbedienung) gesetzeskonform und inklusiv gestalten.

Die Kernpunkte auf einen Blick

Website barrierefrei machen: Die Schritt-für-Schritt-Anleitung

Hier sind die wichtigsten technischen Anpassungen für barrierefreie Inhalte und Funktionen, mit konkreten Beispielen für die praktische Umsetzung Ihrer Inhalte:

Alternativtexte für Bilder und Icons

Screenreader lesen Bilder über das alt-Attribut. Ohne Alternativtext bleibt das Bild für blinde Nutzer:innen unsichtbar.

• Informative Bilder: kurze, aussagekräftige Beschreibung (max. 125 Zeichen).

• Dekorative Bilder: leeres alt-Attribut (alt="").

• Icons mit Funktion: alt-Text oder aria-label, das die Funktion beschreibt.

• Vermeiden Sie „Bild von“ oder „Foto von“ am Anfang.

Tastaturbedienbarkeit und sichtbarer Fokus

• Wer keine Maus nutzen kann, navigiert mit der Tastatur.

• Jedes interaktive Element per Tab erreichbar, in logischer Reihenfolge.

• Sichtbarer Fokus, CSS outline niemals einfach entfernen.

• Aus Modals mit Esc rauskommen, keine Tastatur-Fallen.

Farbkontraste prüfen

WCAG 2.2 verlangt mindestens 4,5:1 für normalen Text, 3:1 für großen Text.

• Nutzen Sie einen Kontrast-Checker wie WebAIM Contrast Checker.

• Prüfen Sie auch Buttons, Links und Formularfelder, nicht nur Fließtext.

• Farbe darf nie die einzige Informationsquelle sein, ergänzen Sie Symbole oder Text.

Formulare barrierefrei gestalten

Formulare sind oft die kritischsten Stellen einer Website. Hier brechen Nutzer:innen am häufigsten ab.

• Sichtbare Labels: label-Element für jedes Feld, programmatisch verknüpft, Placeholder ist kein Label.

• Pflichtfelder erkennbar: nicht nur über Farbe, sondern mit Sternchen oder Text.

• Klare Fehlermeldungen: hilfreich formuliert, mit aria-describedby ans Feld gebunden.

• Volle Tastaturbedienung: vom ersten bis zum letzten Feld.

Barrierefreie Texte und Überschriften

Klare Sprache und logische Struktur helfen allen, vor allem Screenreader-Nutzer:innen, die per Überschriften-Sprung navigieren.

• Eine h1 pro Seite, danach h2 bis h6 in logischer Reihenfolge.

• Keine Ebenen überspringen, Überschriften sind Struktur, nicht Stilmittel.

• Kurze Sätze, aktive Sprache, aussagekräftige Linktexte (nicht „Hier klicken“).

Semantisches HTML

Nutzen Sie die richtigen HTML-Elemente für die richtigen Aufgaben. Browser und Hilfsmittel verstehen sie automatisch.

• Ein Button ist ein <button>, kein gestyltes <div>.

• Listen sind <ul> oder <ol>, Navigation gehört in <nav>, Hauptinhalt in <main>.

• ARIA ist Ergänzung, kein Ersatz für sauberes HTML.

Barrierefreie PDFs und Videos

Auch Ihre Dokumente und Medien zählen mit:

• PDFs: getaggt, logische Lesereihenfolge, Alternativtexte. Mehr in unserem Beitrag zur Barrierefreiheit digitaler Dokumente.

• Videos: Untertitel sind Pflicht, Audio-Beschreibungen empfohlen.

• Audio: Transkripte bereitstellen.

• Für komplexe PDF-Bibliotheken: PDF-Solution-Suite.

Konkret profitieren von einer barrierefreien Website:

• Menschen mit Sehbeeinträchtigung oder Blindheit (nutzen Screenreader und Braille-Zeile)

• Menschen mit motorischen Einschränkungen (Tastatur, Sprachsteuerung statt Maus)

• Menschen mit Hörbeeinträchtigungen (Untertitel, Transkripte)

• Menschen mit kognitiven Einschränkungen oder Legasthenie (klare Sprache, logische Strukturen)

• Ältere Menschen, Sprachlerner:innen und Multitasker:innen (bessere Lesbarkeit und alternative Eingabemöglichkeiten)

Welche WCAG-Anforderungen sind für Websites relevant?

Die Web Content Accessibility Guidelines fassen alles in vier Prinzipien zusammen, kurz POUR. Mehr Details in unserem Beitrag zu WCAG 2.2.

• Wahrnehmbar. Farbkontraste, Alternativtexte, Untertitel.

• Bedienbar. Volle Tastaturbedienung, sichtbarer Fokus, genug Zeit für Eingaben.

• Verständlich. Einfache Sprache, logische Überschriften-Hierarchie, hilfreiche Fehlermeldungen.

• Robust. Semantisches HTML, ARIA als Ergänzung statt Ersatz.

Für die meisten Websites ist WCAG-Stufe AA der richtige Zielwert. Genau diese Anforderungen verlangt auch das BFSG, damit Ihre Inhalte für alle zugänglich werden.

Wer muss seine Website barrierefrei machen?

Das BFSG gilt seit dem 28. Juni 2025 für private Unternehmen in E-Commerce, Banking, Verkehr, Telekommunikation, E-Books und audiovisuellen Mediendiensten. Kleinstunternehmen unter 10 Mitarbeiter:innen und 2 Millionen Euro Umsatz sind teilweise befreit. Öffentliche Stellen fallen unter die BITV 2.0. In Österreich und der Schweiz gelten vergleichbare Rahmen über BaFG und BehiG.

Auch wenn Sie nicht direkt unter das BFSG fallen, lohnt sich die Umsetzung. Sie gewinnen Reichweite, verbessern Ihr SEO und stärken Ihr Image. Mehr zur EU-Richtlinie EAA, aus der das BFSG abgeleitet ist, finden Sie in unserem rechtlichen Leitfaden.

Warum jetzt?

Vier Gründe, warum Sie das Thema nicht weiter aufschieben sollten:

• Recht: Bußgelder bis 100.000 Euro pro Fall, Marktrücknahmen, UKlaG-Klagen.

• Umsatz: 80,7 Prozent der Konsument:innen brechen Online-Vorgänge bei Barrieren ab. Wir haben die Zahlen gesammelt.

• SEO: Semantische Struktur und Alternativtexte verbessern Ihr Ranking.

• Zukunft: AI-Agenten lesen denselben Accessibility Tree wie Screenreader. Wer sauber arbeitet, gewinnt doppelt.

In sechs Schritten zur barrierefreien Website

So gehen Sie strukturiert vor:

1. Audit Ihrer aktuellen Website. Automatisierte Scans, manuelle Prüfung der kritischen Flows, idealerweise Tests mit echten Nutzer:innen. Mehr im Leitfaden zum Testen.

2. Priorisierung. Nach Schwere, Reichweite und Geschäftsrelevanz sortieren. Quick Wins zuerst, große Umbauten in Releases planen.

3. Umsetzung der wichtigsten Barrieren. Die häufigsten Patterns zuerst (siehe unten), Design, Redaktion und Entwicklung koordiniert einbinden.

4. Testen. Mit Screenreadern (NVDA, VoiceOver, TalkBack), idealerweise zusätzlich mit echten Menschen mit Behinderungen über unser User-Testing.

5. Erklärung zur Barrierefreiheit veröffentlichen. Mit Status, Feedback-Möglichkeit und Roadmap, prominent im Footer verlinkt. Die Erklärung zur Barrierefreiheit ist auch rechtlich gefordert.

6. Laufende Pflege. Schulungen über die Accessiway Academy, automatisiertes Monitoring im CI/CD, regelmäßige Stichproben.

Welche Elemente sollten Sie zuerst optimieren?

Wenn Sie nicht alle Inhalte gleichzeitig schaffen, konzentrieren Sie sich auf die größten Hebel. Eine sinnvolle Checkliste für inklusive Nutzer:innen-Erlebnisse:

Wie testen Sie am Ende?

Eine verlässliche Prüfung kombiniert drei Methoden:

• Automatisierte Tools (Accesiway Barrierefreiheits-scanner, WAVE, Lighthouse, axe DevTools). Sie finden etwa 30 Prozent der Probleme.

• Manuelle Screenreader-Prüfung mit NVDA, VoiceOver oder TalkBack. Damit erkennen Sie, was Tools übersehen.

• Nutzer-Tests mit Menschen mit Behinderungen. Der wertvollste Schritt, weil hier echte Reibungspunkte sichtbar werden.

Eine komplette Acht-Schritte-Checkliste finden Sie in unserem Leitfaden zum Testen.

Warum Overlays allein nicht reichen

Vielleicht haben Sie schon von 1-Klick-Lösungen oder Overlays gehört, die per Knopfdruck Barrierefreiheit versprechen. Das Versprechen hält nicht:

• Overlays überlagern Probleme, sie beheben sie nicht im Code.

• Die Europäische Kommission hat 2023 klargestellt: Overlays allein bringen keine Compliance.

• In den USA gibt es zahlreiche Klagen gegen Websites, die nur auf Overlays setzen.

Wir nutzen unser Barrierefreiheits-Widget deshalb nie als Ersatz, sondern als Teil eines vollständigen Compliance-Pakets: sauberer Code, Audit, Remediation, Erklärung zur Barrierefreiheit, laufendes Monitoring.

Wann brauchen Sie Experten?

• DIY ist realistisch bei kleinen Websites, statischen Inhalten, einfachen Formularen.

• Expert:innen lohnen sich bei dynamischen E-Commerce-Anwendungen, großen PDF-Bibliotheken, mehrsprachigen Sites, komplexen Checkouts.

Typische Kosten im DACH-Raum:

• Audit: 600 bis 3.000 Euro.

• Remediation: 1.500 Euro (einfach) bis 15.000 Euro (komplex).

• Monitoring: 100 bis 500 Euro pro Monat.

Unsere Audit- und Remediation-Pakete sind speziell auf den BFSG-Kontext zugeschnitten.

Der Bonus: AI-Agenten lesen denselben Baum

AI-Agenten wie OpenAI Atlas, Microsoft Playwright MCP und Vercels agent-browser navigieren Websites über denselben Accessibility Tree, den auch Screenreader nutzen. Was Screenreader-Nutzer:innen lesen können, können auch Agenten lesen. Eine schwache Implementierung blockiert beide.

Ein konkretes Beispiel:

• Ein:e Nutzer:in bittet einen AI-Agenten, ein Produkt in Ihrem Shop zu kaufen.

• Ihr „In den Warenkorb“-Button ist als <div> mit JavaScript umgesetzt, ohne semantische Rolle, ohne Label.

• Im Baum erscheint der Button als generic ohne Namen. Der Agent findet ihn nicht und bricht ab.

• Als <button>In den Warenkorb</button> implementiert, hätte der Agent ihn sofort gefunden.

Wer heute sauber für Screenreader arbeitet, gewinnt morgen sowohl Menschen mit Behinderungen als auch AI-Agenten.

Häufig gestellte Fragen (FAQ)

Gilt das BFSG / BaFG auch für reine B2B-Websites?

Prinzipiell konzentrieren sich das deutsche BFSG und das österreichische BaFG auf B2C-Angebote (Verbraucherprodukte und -dienstleistungen). B2B-Websites sind jedoch betroffen, wenn sie öffentlich zugängliche E-Commerce-Elemente nutzen, Produkte vertreiben, die letztendlich von Endverbrauchern genutzt werden, oder als Lieferant für den öffentlichen Sektor agieren (E-Beschaffung).

Müssen bereits bestehende Blogbeiträge und Alt-Inhalte nachgebessert werden?

Grundsätzlich betrifft das Gesetz alle aktiven Kerninhalte. Bei archivierten Alt-Inhalten, die nach dem 28. Juni 2025 nicht mehr verändert werden und nicht für wesentliche Geschäfts- oder Verwaltungsprozesse notwendig sind, gibt es Übergangsfristen. Neue Artikel und Haupt-Landingsites müssen ab der Veröffentlichung barrierefrei sein.

Was ist der Hauptunterschied zwischen WCAG 2.1 und WCAG 2.2?

WCAG 2.2 ergänzt die Version 2.1 um 9 neue Kriterien. Diese konzentrieren sich vor allem auf die bessere Bedienbarkeit auf Mobilgeräten (z. B. Touch-Zielgrößen von mindestens 24x24 Pixeln), barrierefreie Authentifizierung (Login ohne Gedächtnistests) sowie sichtbare, nicht verdeckte Fokus-Indikatoren.

Wer haftet im Unternehmen persönlich bei einem BFSG- oder BaFG-Verstoß?

Bußgelder und Anordnungen richten sich primär gegen das Unternehmen selbst. Vertretungsberechtigte Geschäftsführer:innen können jedoch bei eigenen Pflichtverletzungen in der Organisation für die Nichteinhaltung gesetzlicher Barrierefreiheitsstandards persönlich in Haftung genommen werden.

Reicht eine Erklärung zur Barrierefreiheit aus, wenn die Website noch Fehler hat?

Eine Erklärung zur Barrierefreiheit muss transparent offenlegen, welche Bereiche noch nicht barrierefrei sind, die Gründe dafür erläutern und einen konkreten Zeitplan zur Behebung enthalten. Das Vorhandensein einer korrekten Erklärung mindert das rechtliche Risiko, während das Fehlen der Erklärung einen eigenständigen Verstoß darstellt.