Barrierefreie Website: Die Checkliste für 2026

Das Barrierefreiheitsstärkungsgesetz (BFSG) ist seit Juni 2025 für viele Unternehmen verbindlich. Wer eine Website betreibt, die Produkte oder Dienstleistungen an Verbraucher anbietet, muss WCAG 2.1 Level AA erfüllen — oder zumindest nachweisen können, dass er sich darum bemüht.

Die gute Nachricht: Viele der wichtigsten Anforderungen lassen sich mit einem strukturierten Selbsttest überprüfen. Diese Checkliste hilft dabei, die häufigsten Barrieren zu finden — bevor es andere für Sie tun.

1. Farbkontraste

Das Kontrastverhältnis zwischen Text und Hintergrund muss mindestens 4,5:1 betragen (normaler Text) bzw. 3:1 für großen Text (ab 18 pt oder 14 pt fett).

Selbsttest:

• Kostenlose Tools wie der WebAIM Contrast Checker (URL im Browser eingeben) zeigen das Verhältnis sofort an.
• Besonders kritisch: hellgrauer Text auf weißem Hintergrund, Texte über Farbfotos, Platzhaltertext in Formularfeldern.

2. Schriftgröße und Zoom

Nutzer müssen Inhalte auf 200 % zoomen können, ohne dass Texte abgeschnitten werden oder der Seiteninhalt horizontal scrollt. Prüfen Sie:

• Zoom auf 200 % im Browser aktivieren — lässt sich noch alles lesen?
• Fließtext mit Mindestgröße 16 px (oder 1 rem) ist eine gute Basis.
• Keine Festlegung von user-scalable=no im Viewport-Meta-Tag.

3. Alt-Texte für Bilder

Jedes informative Bild braucht einen Alt-Text, der den Inhalt beschreibt. Dekorative Bilder erhalten ein leeres Alt-Attribut (alt=""), damit Screenreader sie übergehen.

Typische Fehler:

• alt="image001.jpg" (Dateiname statt Beschreibung)
• alt="Bild" oder alt="Foto" (nichtssagend)
• Fehlendes Alt-Attribut komplett
• Texte in Bildern ohne Alt-Beschreibung des Textinhalts

4. Tastaturbedienung

Alle Funktionen der Website müssen ohne Maus bedienbar sein. Testen Sie:

• Tab-Taste durchdrücken: Kommt man durch alle Links, Buttons und Formularfelder?
• Enter/Leertaste: Lösen Buttons und Links die erwartete Aktion aus?
• Gibt es Tastaturfallen — Bereiche, aus denen man mit der Tastatur nicht mehr herauskommt?

5. Fokus-Indikatoren

Wenn ein Element per Tastatur fokussiert ist, muss dieser Fokus sichtbar sein — ein sichtbarer Rahmen, eine Farbänderung, eine Unterstreichung. Viele Designs setzen outline: none in der CSS, um den Browser-Standard-Fokus zu entfernen, ohne einen eigenen Ersatz anzubieten. Das ist ein klarer WCAG-Verstoß.

Checkliste:

• outline: none oder outline: 0 nur dann setzen, wenn ein eigener Fokus-Stil definiert ist.
• Fokus-Rahmen muss deutlich sichtbar sein, nicht nur ein schwacher Schatten.

6. Formular-Labels

Jedes Eingabefeld braucht ein programmatisch verknüpftes Label — nicht nur Platzhaltertext, der verschwindet, sobald man tippt. Prüfung:

• Ist zu jedem <input> ein <label for="..."> vorhanden?
• Screenreader-Test: Wird beim Fokus auf ein Feld der Feldname vorgelesen?
• Pflichtfelder müssen als solche gekennzeichnet sein — nicht nur durch Farbe.

7. Untertitel und Audiodeskriptionen

Videos mit gesprochenem Inhalt brauchen Untertitel. Audiodateien brauchen Transkripte. Stumme dekorative Videos sind ausgenommen. Wer YouTube-Videos einbindet, sollte prüfen, ob die automatisch generierten Untertitel aktiviert und ausreichend korrekt sind.

8. Semantisches HTML

Screenreader navigieren über HTML-Struktur. Korrekte Semantik ist kein Luxus:

• Überschriften in korrekter Hierarchie (h1 → h2 → h3), keine Sprünge
• <nav>, <main>, <header>, <footer> korrekt eingesetzt
• Keine reinen <div>-Buttons ohne role="button" und tabindex="0"
• Listen mit <ul>/<ol>, nicht mit Bindestrichen als normaler Text

9. ARIA nur wo nötig

ARIA-Attribute können Barrierefreiheit verbessern — oder bei falschem Einsatz verschlechtern. Grundregel: Natives HTML schlägt ARIA. Nur wo semantisches HTML nicht ausreicht (z. B. Custom-Dropdowns, Modal-Dialoge, Live-Regions), sollte ARIA gezielt eingesetzt werden.

Prüfen:

• aria-label und aria-labelledby bei Buttons ohne sichtbaren Text (z. B. Icon-Buttons)
• aria-live für dynamisch aktualisierte Bereiche (z. B. Fehlermeldungen nach Formular-Validierung)
• role-Attribute nicht blind kopieren ohne zu verstehen, was sie bewirken

10. Sprachattribut

Das lang-Attribut im <html>-Tag teilt dem Screenreader mit, welche Sprache er verwenden soll. Ohne korrekte Sprachangabe kann der Screenreader den Text mit einer falschen Aussprache vorlesen.

``html <html lang="de"> ``

Bei mehrsprachigen Seiten müssen abweichende Sprachbereiche mit lang am jeweiligen Element markiert werden.

Selbsttest vs. professioneller BFSG-Check

Diese Checkliste deckt die häufigsten und einfach prüfbaren Punkte ab. Sie ersetzt keine vollständige WCAG-Prüfung.

Wer rechtssicher aufgestellt sein muss — weil das BFSG verpflichtend gilt oder weil eine Barrierefreiheitserklärung benötigt wird — sollte einen BFSG-Check beauftragen. Dieser prüft systematisch nach WCAG 2.1 Level AA, dokumentiert Verstöße mit Screenshot-Belegen und erstellt eine rechtskonforme Barrierefreiheitserklärung.

Als Einstieg, um den aktuellen Stand der Website insgesamt zu beurteilen, eignet sich der Website-Check, der neben Barrierefreiheit auch SEO, Ladezeit, Sicherheit und DSGVO-Grundlagen abdeckt.

Fazit

Barrierefreiheit ist kein Einmalprojekt, sondern ein fortlaufender Prozess — besonders wenn neue Inhalte, Plugins oder Templates hinzukommen. Die Checkliste oben gibt einen guten Einstieg. Für die vollständige Prüfung und rechtssichere Dokumentation empfiehlt sich der BFSG-Check.

Fragen zur Barrierefreiheit Ihrer Website? Wir helfen weiter: info@webagentur-twopixels.de.

Die TwoPixels GmbH hilft dir bei JTL, Shop-Templates, Hosting und IT-Sicherheit — persönlich und unverbindlich.