Website barrierefrei machen: woran die meisten Seiten scheitern

Eine Website barrierefrei machen klingt nach Spezialwissen, nach Prüfsiegel und Beratertag. Der Befund aus der Praxis ist nüchterner: Fast jede Seite scheitert an denselben sechs Stellen, und fünf davon kannst du mit Bordmitteln selbst finden. Zu wenig Kontrast, Bilder ohne Alternativtext, Formularfelder ohne Beschriftung, leere Links, leere Buttons, fehlende Sprachangabe. Das ist das Ergebnis einer Auswertung von einer Million Startseiten, dazu gleich mehr.

Was hier nicht steht: ob du musst. Die Pflicht-Frage samt Kleinstunternehmer-Ausnahme habe ich im Beitrag Barrierefreie Website: für wen sie Pflicht ist auseinandergenommen. Hier geht es um das Wie: die sechs Fehler, die Grenzwerte dahinter, und wie du deine eigene Seite in einer Stunde prüfst, ohne ein Werkzeug zu kaufen.

Die sechs Fehler

Woran Websites scheitern: die sechs Fehler, die 96 Prozent ausmachen

WebAIM, ein Institut der Utah State University, prüft jedes Jahr die Startseiten der eine Million meistbesuchten Websites automatisch auf WCAG-Verstöße. Der Report vom Februar 2026 ist der erste seit Jahren, in dem die Zahlen schlechter werden: 95,9 Prozent der Startseiten hatten erkennbare Fehler (2025: 94,8 Prozent), im Schnitt 56,1 pro Seite. Sechs Fehlertypen machen zusammen 96 Prozent aller Funde aus, und die Liste ist seit sieben Jahren dieselbe:

1. Zu wenig Kontrast auf 83,9 Prozent der Seiten
2. Bilder ohne Alternativtext auf 53,1 Prozent
3. Formularfelder ohne Beschriftung auf 51 Prozent
4. Leere Links auf 46,3 Prozent
5. Leere Buttons auf 30,6 Prozent
6. Fehlende Sprachangabe im Dokument auf 13,5 Prozent

Das ist die gute Nachricht in der schlechten: Wer diese sechs Stellen sauber hat, ist an den meisten Seiten im Netz vorbei. Keine davon braucht Spezialwissen. Alle sechs findet ein kostenloses Werkzeug in Sekunden. Und eine siebte, die kein Werkzeug findet, kommt am Ende dazu: die Tastatur.

Kontrast

Kontrast: 4,5 zu 1, und warum Hellgrau auf Weiß nie durchkommt

Die Regel steht in WCAG 1.4.3: Normaler Text braucht ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund, großer Text (ab etwa 24 Pixel, fett ab etwa 19) mindestens 3:1. Für Bedienelemente und Grafiken, die man verstehen muss, gilt seit WCAG 2.1 zusätzlich 3:1 (1.4.11): Rahmen von Eingabefeldern, Icons, der Zustand eines Schalters.

Der typische Bruch ist kein Design-Fehler, sondern Geschmack: das elegante Hellgrau für Fließtext, weißer Text über einem Foto, ein Platzhalter-Text im Formular, der als einzige Beschriftung dient. Hellgrau #999999 auf Weiß kommt auf 2,85:1 und fällt durch. #767676 schafft die 4,5:1 gerade so. Wer Text über Bilder legt, braucht eine Fläche dahinter oder einen Verlauf, sonst hängt der Kontrast vom Foto ab, und das nächste Foto ist heller.

Prüfen: Die Entwicklerwerkzeuge in Chrome zeigen beim Anklicken einer Farbe das Verhältnis direkt an, samt Häkchen für AA. Für ganze Seiten nimmt man WAVE oder Lighthouse, dazu unten mehr.

Alternativtexte

Alt-Texte: was rein muss, und wann leer richtig ist

Ein Screenreader liest bei einem Bild den Alternativtext vor. Fehlt er, liest er oft den Dateinamen, also „IMG_4821.jpg“. WCAG 1.1.1 verlangt für jedes Bild mit Inhalt einen Text, der denselben Zweck erfüllt. Die Praxisregel: Beschreib, was das Bild für den Leser tut, nicht, was darauf zu sehen ist. Für das Team-Foto auf der Über-uns-Seite heißt das „Das Team der Werkstatt Meier vor der Halle in Leipzig“, nicht „Foto“.

Genauso wichtig ist die andere Richtung: Ein rein dekoratives Bild bekommt ein leeres Attribut, alt="". Dann überspringt der Screenreader es, statt „Hintergrundmuster blau“ vorzulesen. Was fehlen darf, ist nur das Attribut selbst, nie der Inhalt. Und ein Klassiker, der beides bricht: Text als Bild. Die Öffnungszeiten als JPG, das Angebot als Grafik. Die gehören als echter Text auf die Seite, dann braucht es keinen Alt-Text, und Google kann sie lesen.

Formulare

Formulare: jedes Feld braucht ein Label, jeder Fehler eine Erklärung

Die Hälfte aller Startseiten hat Formularfelder ohne Beschriftung. Meist ist die Beschriftung sichtbar da, nur nicht verknüpft: Ein Text steht über dem Feld, aber das label-Element fehlt oder zeigt ins Leere. Für Sehende kein Unterschied, für einen Screenreader ist das Feld namenlos. Platzhalter-Text im Feld zählt nicht als Ersatz: Er verschwindet beim Tippen und hat fast immer zu wenig Kontrast.

Dazu WCAG 3.3.1 und 3.3.2: Fehler müssen benannt und beschrieben werden, Pflichtfelder gekennzeichnet. „Bitte prüfen Sie Ihre Eingaben“ in Rot über dem Formular fällt durch, weil niemand erfährt, welches Feld gemeint ist. „E-Mail-Adresse: Es fehlt das @-Zeichen“ direkt am Feld besteht. Wer ein Kontaktformular baut, hat damit die häufigste Barriere seiner ganzen Seite in der Hand.

Links und Buttons

Leere Links und leere Buttons: das Icon ohne Namen

Ein Link ohne Text ist fast immer ein Icon: das Telefon-Symbol im Header, der Pfeil im Slider, das Lupen-Symbol der Suche, die Social-Media-Logos im Footer. Sehende verstehen das Bild, der Screenreader sagt „Link“ und sonst nichts. Dasselbe beim Button mit dem Hamburger-Menü: „Schaltfläche“, ohne Hinweis, was sie öffnet.

Die Lösung ist ein Satz Code: aria-label="Menü öffnen" auf dem Button, ein Alt-Text auf dem Icon oder ein visuell versteckter Text im Link. Dazu gehört auch der Linktext im Fließtext: „hier klicken“ und „mehr“ sagen nichts, wenn man nur die Links einer Seite vorgelesen bekommt, und genau das tun Screenreader-Nutzer, um sich zu orientieren. Der Linktext soll das Ziel benennen, etwa „Preisliste als PDF“.

Sprache und Struktur

Sprachangabe, Überschriften, Zoom: die unsichtbaren Grundlagen

Der sechste Fehler ist der billigste: Das lang-Attribut im HTML-Kopf fehlt. Ohne lang="de" liest ein Screenreader deutschen Text womöglich mit englischer Aussprache. Ein Wort im Code, einmal gesetzt.

Dazu drei Dinge, die die automatische Prüfung nicht als Fehler zählt, an denen trotzdem viele Seiten scheitern. Erstens die Überschriften-Hierarchie: eine h1, darunter h2, darunter h3, ohne Sprünge. Screenreader-Nutzer springen von Überschrift zu Überschrift, so wie Sehende die Seite überfliegen. Zweitens die Vergrößerung: Text muss sich auf 200 Prozent zoomen lassen, ohne dass etwas abgeschnitten wird (1.4.4), und bei 320 Pixel Breite ohne Querscrollen laufen (1.4.10). Drittens die Zielgröße: Seit WCAG 2.2 sollen Klickflächen mindestens 24 mal 24 Pixel groß sein (2.5.8), was vor allem eng gesetzte Icons und Fußzeilen-Links betrifft.

Tastatur

Tastatur und Fokus: der Test, den kein Werkzeug macht

Alles, was mit der Maus geht, muss auch mit der Tastatur gehen (2.1.1). Und man muss sehen, wo man ist: Der Fokus braucht eine sichtbare Markierung (2.4.7) und darf nicht hinter einem festen Header oder Cookie-Banner verschwinden (2.4.11, neu in WCAG 2.2).

Der Test dauert zwei Minuten und findet Fehler, die kein Scanner sieht: Maus weglegen, Tab-Taste drücken, durch die ganze Seite laufen. Springt der Fokus sichtbar von Element zu Element? Lässt sich das Menü öffnen, ein Untermenü aufklappen, ein Modal wieder schließen, mit Enter und Escape? Bleibt der Fokus irgendwo hängen, etwa in einem Slider oder einer eingebetteten Karte? Der häufigste Befund: Jemand hat outline: none ins CSS geschrieben, weil der Fokusrahmen „hässlich“ war. Damit fährt jeder Tastaturnutzer blind durch die Seite.

Prüfen

Website barrierefrei prüfen: die Stunde mit Bordmitteln

Du brauchst keinen Dienstleister für die erste Runde. In dieser Reihenfolge, alles kostenlos:

1. Lighthouse in Chrome (Entwicklerwerkzeuge, Reiter „Lighthouse“, Kategorie Barrierefreiheit): findet Kontrast, Alt-Texte, Labels, Sprachangabe, leere Links und Buttons. Der Wert ist eine Schulnote, die Liste darunter ist das Nützliche.
2. WAVE (Browser-Erweiterung von WebAIM, denselben Leuten wie der Report oben): legt die Fehler direkt über die Seite, mit Erklärung je Fund. Für Nicht-Entwickler der bessere Einstieg.
3. Tab-Test wie oben beschrieben, auf jeder Vorlage einmal: Startseite, Unterseite, Kontaktformular.
4. Screenreader anhören: Auf dem Mac ist VoiceOver eingebaut (Befehlstaste plus F5), unter Windows die Sprachausgabe (Windows-Taste, Strg, Enter). Zehn Minuten die eigene Startseite vorlesen lassen. Du wirst „Link, Link, Link, Grafik“ hören und wissen, wo es fehlt.
5. Zoom auf 200 Prozent und das Handy quer: Wird etwas abgeschnitten, überlappt etwas, muss man seitlich scrollen?

Was die Werkzeuge nicht können: Sie prüfen, ob ein Alt-Text da ist, nicht ob er sinnvoll ist. Sie sehen ein Label, nicht ob es das richtige sagt. WebAIM sagt das über den eigenen Report ausdrücklich: Gezählt wurde nur, was sich automatisch erkennen lässt, die wirkliche Fehlerquote liegt höher. Der Rest ist Lesen, Tabben, Zuhören. Diese Runde gehört in denselben Durchgang wie der Test vor dem Livegang.

Overlays

Was ein Overlay nicht kann

Warum ich von Ein-Klick-Skripten abrate, steht im anderen Beitrag. Hier nur der Test, der die Frage für deine Seite beantwortet: Skript einbauen, Lighthouse noch einmal laufen lassen, Liste vergleichen. Stehen dieselben Funde drin wie vorher, hat sich am HTML nichts geändert, und genau dort sitzen die sechs Fehler von oben. Ein Overlay ist eine Brille für Sehende, kein Reparaturwerkzeug. Die Reparatur selbst geht in jedem Baukasten und jedem CMS, sie dauert nur länger als ein Klick.

Umsetzung

Wie ich das mache

Bei mir ist Barrierefreiheit kein Zusatzpaket, weil das meiste davon schlicht sauberes Handwerk ist: echte Überschriften, echter Text statt Text im Bild, beschriftete Formulare, ein Fokusrahmen, der bleibt. Kontrast prüfe ich beim Farbschema, bevor der erste Screen steht, und der Tab-Test gehört zum Abnahme-Durchgang jeder Seite. Wer will, bekommt die Prüfergebnisse mit. Wie so ein Projekt bei mir abläuft, steht unter Webdesign.

Kurz: Sechs Fehler, eine Stunde Prüfung, ein Nachmittag Nacharbeit. Das ist für die meisten kleinen Websites der ganze Weg zu einer Seite, die mehr Menschen benutzen können als vorher. Ob du musst, steht im anderen Beitrag. Dass es sich lohnt, merkst du beim ersten Tab-Test.