Barrierefreie Website erstellen

Barrierefreiheit im Web bedeutet, dass Websites und digitale Anwendungen so gestaltet sind, dass alle Menschen sie nutzen können. Das schließt Menschen mit Sehbehinderungen, Höreinschränkungen, motorischen Beeinträchtigungen und kognitiven Einschränkungen ein. In Deutschland leben rund 7,9 Millionen Menschen mit einer Schwerbehinderung - das sind 9,3 Prozent der Bevölkerung (Stand: 2023).

Eine barrierefreie Website lässt sich mit der Tastatur bedienen, funktioniert mit Screenreadern, bietet ausreichende Farbkontraste und strukturiert Inhalte logisch. Der Grundgedanke: Wahrnehmung muss über mindestens zwei Sinne möglich sein. Ein Video braucht Untertitel, ein Bild einen Alternativtext, ein Audio-Player ein Transkript.

Barrierefreiheit ist dabei kein reines Nischenthema. Sie verbessert die User Experience für alle Nutzer: Untertitel helfen auch in lauten Umgebungen, große Schaltflächen erleichtern die Bedienung auf Mobilgeräten, und klare Strukturen unterstützen jeden beim schnellen Erfassen von Inhalten. Gerade beim Mobile First Webdesign spielen diese Aspekte eine zentrale Rolle.

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EU-Richtlinie 2019/882 - den European Accessibility Act (EAA) - in deutsches Recht um. Seit dem 28. Juni 2025 müssen Unternehmen ihre digitalen Angebote barrierefrei gestalten. Das betrifft Online-Shops, E-Commerce-Plattformen, Buchungsportale, digitale Bankdienstleistungen und alle Websites mit Verbrauchergeschäften. Neben dem BFSG sollten Sie auch die DSGVO-Anforderungen für Ihre Website beachten.

Konkret bedeutet das: Wenn Sie Produkte oder Dienstleistungen online an Verbraucher verkaufen, muss Ihre Website barrierefrei sein. Das gilt für den gesamten Kaufprozess - von der Produktsuche über den Warenkorb bis zum Checkout und zur Bestätigung.

• E-Commerce und Online-Shops: Alle Webshops, die an Endverbraucher verkaufen, müssen barrierefrei sein - unabhängig von der Unternehmensgröße (mit einer Ausnahme, siehe unten).
• Digitale Dienstleistungen: Online-Terminbuchungen, Kontaktformulare mit Vertragsabschluss, Banking-Apps und Versicherungsportale fallen unter das BFSG.
• B2B-Angebote: Reine B2B-Websites, die ausschließlich Geschäftskunden ansprechen, sind nicht betroffen - aber Vorsicht bei Mischformen.
• Ausnahme für Kleinstunternehmen (nur bei Dienstleistungen): Dienstleister mit weniger als 10 Mitarbeitern und maximal 2 Millionen Euro Jahresumsatz sind ausgenommen. Wichtig: Diese Ausnahme gilt NICHT für Unternehmen, die Produkte herstellen oder verkaufen - diese müssen unabhängig von ihrer Größe barrierefrei sein.

Die Web Content Accessibility Guidelines (WCAG) 2.1 sind der internationale Standard für barrierefreies Webdesign. Sie wurden vom World Wide Web Consortium (W3C) entwickelt und bilden die technische Grundlage für das BFSG. Die Richtlinien definieren drei Konformitätsstufen: A (Basis), AA (empfohlen) und AAA (optimal).

Für die BFSG-Konformität müssen Sie mindestens die Stufe AA erfüllen. WCAG 2.1 umfasst insgesamt 78 Erfolgskriterien, verteilt auf drei Stufen: Level A (30 Kriterien), Level AA (20 zusätzliche, gesamt 50) und Level AAA (28 weitere, gesamt 78). Die Stufe AAA ist für die meisten Websites nicht realistisch umsetzbar und wird auch nicht gesetzlich gefordert. Hinweis: WCAG 2.2 (Oktober 2023) ergänzt diese um 9 neue Kriterien auf insgesamt 87 Erfolgskriterien.

• Stufe A (Mindestanforderung): 25 Kriterien für grundlegende Zugänglichkeit - z.B. Alternativtexte für Bilder, Tastaturbedienbarkeit, keine automatisch abspielenden Medien.
• Stufe AA (gesetzlicher Standard): 13 zusätzliche Kriterien - z.B. Farbkontrast 4,5:1, Textgröße änderbar ohne Funktionsverlust, sichtbarer Tastaturfokus.
• Stufe AAA (optional): 23 weitere Kriterien für maximale Barrierefreiheit - z.B. Gebärdensprache-Videos, erhöhte Kontrastanforderungen von 7:1, keine Zeitlimits.

Die WCAG-Richtlinien basieren auf vier grundlegenden Prinzipien, die unter dem Akronym POUR bekannt sind: Perceivable (Wahrnehmbar), Operable (Bedienbar), Understandable (Verständlich) und Robust (Robust). Diese Prinzipien bilden das Fundament für jede barrierefreie Website.

Wenn Sie diese vier Prinzipien verstehen und konsequent anwenden, haben Sie bereits 80 Prozent der Arbeit geschafft. Sie helfen auch dabei, Prioritäten zu setzen und Barrieren systematisch zu identifizieren.

• Wahrnehmbar (Perceivable): Alle Inhalte müssen für mindestens zwei Sinne zugänglich sein. Bilder brauchen Alternativtexte, Videos brauchen Untertitel, Audioinhalte brauchen Transkripte. Farbkontraste müssen ausreichend sein (mindestens 4,5:1 für normalen Text).
• Bedienbar (Operable): Alle Funktionen müssen mit der Tastatur erreichbar sein. Navigation muss konsistent sein. Es dürfen keine zeitkritischen Aktionen ohne Verlängerungsoption existieren. Animationen müssen pausierbar sein.
• Verständlich (Understandable): Texte müssen klar formuliert sein. Navigation und Seitenaufbau müssen vorhersehbar sein. Formulare müssen verständliche Fehlermeldungen liefern. Die Sprache der Seite muss im HTML definiert sein.
• Robust: Der Code muss valide sein und mit assistiven Technologien wie Screenreadern funktionieren. ARIA-Attribute müssen korrekt eingesetzt werden. Die Website muss auch mit künftigen Technologien kompatibel bleiben.

Theorie ist wichtig, aber Sie wollen wissen, was konkret zu tun ist. Hier sind die 12 wichtigsten Maßnahmen, die ich bei jedem Webdesign-Projekt umsetze. Arbeiten Sie diese Liste systematisch ab, um WCAG 2.1 AA-Konformität zu erreichen.

Struktur und Semantik

• 1. Semantisches HTML verwenden: Nutzen Sie die richtigen HTML-Elemente: <header>, <nav>, <main>, <article>, <aside>, <footer>. Screenreader können damit die Seitenstruktur verstehen.
• 2. Überschriftenhierarchie einhalten: Beginnen Sie mit einer H1, dann H2, H3 usw. Keine Ebenen überspringen. Jede Seite hat genau eine H1.
• 3. Sprache definieren: Setzen Sie das lang-Attribut im HTML-Tag (z.B. lang="de"). Bei fremdsprachigen Passagen ebenfalls das lang-Attribut verwenden.

Bilder und Medien

• 4. Alternativtexte für Bilder: Jedes informative Bild braucht einen beschreibenden Alt-Text. Dekorative Bilder erhalten ein leeres alt-Attribut (alt="").
• 5. Videos mit Untertiteln: Alle Videos benötigen Untertitel oder Captions. Idealerweise auch eine Audiodeskription für visuelle Inhalte.
• 6. Kontrast sicherstellen: Text muss ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund haben. Große Texte (ab 18pt/24px oder 14pt/18,5px fett) benötigen mindestens 3:1.

Navigation und Interaktion

• 7. Tastaturbedienbarkeit: Alle interaktiven Elemente müssen mit Tab erreichbar und mit Enter/Space aktivierbar sein. Der Fokus muss sichtbar sein.
• 8. Skip-Links einbauen: Bieten Sie einen "Zum Inhalt springen"-Link am Seitenanfang an, damit Tastaturnutzer die Navigation überspringen können.
• 9. Fokus-Indikatoren stylen: Der Tastaturfokus muss deutlich sichtbar sein. Entfernen Sie niemals outline: none ohne Alternative.

Formulare und Fehlerbehandlung

• 10. Labels für Formularfelder: Jedes Eingabefeld braucht ein zugeordnetes Label-Element. Placeholder sind kein Ersatz für Labels.
• 11. Verständliche Fehlermeldungen: Fehler müssen klar beschrieben und Lösungen vorgeschlagen werden. Markieren Sie fehlerhafte Felder visuell und programmatisch.
• 12. ARIA sinnvoll einsetzen: Verwenden Sie ARIA-Attribute nur wenn nötig. Natives HTML ist immer vorzuziehen. aria-label, aria-describedby und role-Attribute gezielt nutzen.

Kein einzelnes Tool deckt alle Barrierefreiheitsprobleme ab. Ich empfehle eine Kombination aus automatisierten Tests und manuellen Prüfungen - ähnlich wie bei einem technischen SEO-Audit. Automatisierte Tools finden etwa 30-40 Prozent der Probleme - für den Rest brauchen Sie manuelle Tests, idealerweise mit echten assistiven Technologien.

Automatisierte Test-Tools (kostenlos)

• WAVE (WebAIM): Browser-Extension für Chrome und Firefox. Zeigt Fehler direkt auf der Seite an, kategorisiert nach Errors, Contrast Errors, Alerts, Features. Besonders gut für Kontrastprüfungen und Strukturanalyse.
• axe DevTools (Deque): Leistungsstarke Browser-Extension mit tiefgehenden Regelsets für semantisches HTML und ARIA. Liefert klare Erklärungen und Lösungsvorschläge. Mein Favorit für die Entwicklung.
• Google Lighthouse: Integriert in Chrome DevTools. Prüft Barrierefreiheit zusammen mit Performance, SEO und Best Practices. Gut für einen schnellen Überblick, aber weniger detailliert als axe.

Manuelle Testmethoden

• Tastatur-Test: Navigieren Sie die komplette Website nur mit Tab, Shift+Tab, Enter und Escape. Ist der Fokus immer sichtbar? Kommen Sie überall hin?
• Screenreader-Test: Testen Sie mit NVDA (Windows, kostenlos), VoiceOver (Mac/iOS, integriert) oder JAWS. Werden alle Inhalte sinnvoll vorgelesen?
• Zoom-Test: Vergrößern Sie die Seite auf 200% und 400%. Bleiben alle Inhalte lesbar und bedienbar?

In meiner Arbeit als Webentwickler sehe ich immer wieder dieselben Fehler beim Thema Barrierefreiheit Webdesign. Die gute Nachricht: Die meisten lassen sich mit wenig Aufwand beheben. Hier sind die häufigsten Stolperfallen und wie Sie sie umgehen.

• Fehlende oder nichtssagende Alt-Texte: "Bild1.jpg" oder "Logo" helfen niemandem. Beschreiben Sie, was auf dem Bild zu sehen ist und welche Funktion es hat. Bei Produktbildern: Was zeigt das Bild? Bei Buttons: Wohin führt der Klick?
• Unzureichender Farbkontrast: Hellgrauer Text auf weißem Hintergrund ist ein Klassiker. Nutzen Sie Tools wie den WebAIM Contrast Checker und halten Sie das Minimum von 4,5:1 ein. Auch bei Hover- und Fokus-Zuständen.
• Fokus-Outline entfernt: outline: none; im CSS ist eine der größten Sünden. Wenn Ihnen der Standard-Fokus nicht gefällt, stylen Sie ihn - aber entfernen Sie ihn nie komplett.
• Links ohne erkennbaren Text: "Hier klicken" oder "Mehr" sagt nichts aus. Screenreader-Nutzer navigieren oft per Link-Liste. Jeder Link muss auch ohne Kontext verständlich sein.
• Formulare ohne Labels: Placeholder-Text verschwindet beim Tippen und ist für Screenreader nicht zuverlässig. Jedes Eingabefeld braucht ein sichtbares, verknüpftes Label.
• Automatisch abspielende Medien: Videos oder Audio, die ohne Nutzeraktion starten, sind problematisch. Sie unterbrechen Screenreader und können Nutzer erschrecken oder ablenken.
• Nur mit Maus bedienbare Elemente: Custom-Dropdowns, Slider oder Modals, die nur auf Klick reagieren, schließen Tastaturnutzer aus. Alle interaktiven Elemente müssen Keyboard-Events unterstützen.