5 häufige Accessibility-Fehler, die fast jede Website macht

Alt-Texte sind die Textalternativen, die Screenreader vorlesen, wenn sie auf ein Bild stoßen. Fehlen sie, hört ein blinder Nutzer entweder gar nichts — oder schlimmer: den rohen Dateinamen des Bildes, zum Beispiel IMG_0391.jpg. Das ist nutzlos und frustrierend.

Häufig angetroffene Varianten des Fehlers: kein Alt-Attribut vorhanden, Alt-Text lautet „Bild“, „Foto“ oder „image“, oder es wurde schlicht der Dateiname übernommen.

Falsch

<img src="team.jpg" alt="Bild">

Richtig

<img src="team.jpg" alt="Das MyWebsiteService-Team beim Beratungsgespräch in München">

So beheben Sie es

Jedes informationstragende Bild braucht einen beschreibenden Alt-Text, der den Bildinhalt oder -zweck erläutert. Rein dekorative Bilder — Hintergründe, Trennlinien, Schmuckgrafiken — erhalten alt="" (leeres Attribut), damit Screenreader sie bewusst überspringen. In WordPress: Alt-Text beim Bild-Upload im Medienbereich eintragen.

Hellgrauer Text auf weißem Hintergrund wirkt modern und aufgeräumt — für Menschen mit Sehschwäche, Farbfehlsichtigkeit oder bei Sonnenlicht auf dem Bildschirm ist er schlicht nicht lesbar. Schlechte Kontraste gehören zu den am häufigsten festgestellten WCAG-Verstößen weltweit.

WCAG 2.2 AA fordert mindestens 4,5:1 für normalen Text und 3:1 für großen Text (ab 18pt unformatiert oder 14pt fett). Besonders häufig unterschritten: graue Subtexte, Placeholder-Text in Formularen und helle Buttons auf weißem Hintergrund.

Zu wenig (2,9:1)

#999999 auf #ffffff — sieht gut aus, ist aber nicht konform

Ausreichend (7,0:1)

#595959 auf #ffffff — klar lesbar für alle

So beheben Sie es

Prüfen Sie alle Text-Hintergrund-Kombinationen mit dem kostenlosen WebAIM Contrast Checker. Besondere Aufmerksamkeit: Grau auf Weiß, gelbe oder hellblaue Texte, helle CTA-Buttons. Passen Sie die Farben in Ihrem Avada Global Colors-System einmalig an — dann gilt die Korrektur sofort auf der gesamten Website.

Viele Formulare setzen auf Platzhaltertext im Eingabefeld statt auf echte Labels. Das Problem: Sobald der Nutzer zu tippen beginnt, verschwindet der Hinweistext — und wer das Formular mit einem Screenreader oder der Tastatur navigiert, weiß nicht mehr, was das Feld erwartet. Noch gravierender: Manche Formulare haben gar kein Label-Element, sondern nur visuellen Text in der Nähe des Feldes, der technisch nicht mit dem Eingabefeld verknüpft ist.

Falsch

<input type="text" placeholder="Ihr Name" />

Richtig

<label for="name">Ihr Name</label>
<input id="name" type="text">

So beheben Sie es
Jedes Formularfeld braucht ein <label>-Element mit passendem for-Attribut, das auf die id des Eingabefelds verweist. Platzhaltertexte können zusätzlich vorhanden sein, ersetzen aber niemals ein Label. Fehlermeldungen müssen textuell beschreiben, was falsch ist — nicht nur rot hervorgehoben werden.

Viele Websites unterdrücken den Standard-Fokusrahmen des Browsers mit outline: none — weil er „störend“ aussieht. Das Ergebnis: Wer die Website ausschließlich mit der Tastatur navigiert (Menschen mit motorischen Einschränkungen, aber auch Power-User), sieht nicht mehr, wo sie sich auf der Seite befinden. Es gibt buchstäblich keinen Cursor.

In WCAG 2.2 wurde das Fokus-Kriterium deutlich verschärft: Der Fokus-Indikator muss eine Mindestgröße haben und ausreichend kontrastreich sein — nicht nur irgendwie sichtbar.

So beheben Sie es

Niemals outline: none oder outline: 0 verwenden, ohne eine vollwertige Alternative zu definieren. Stattdessen einen eigenen, gut sichtbaren Fokus-Stil setzen:

Der Selektor :focus-visible sorgt dafür, dass der Fokusrahmen nur bei Tastaturnavigation erscheint, nicht bei Mausklicks — das ist die moderne, saubere Lösung.

Für Screenreader-Nutzer sind Überschriften das wichtigste Navigationsmittel auf einer Seite — wie ein Inhaltsverzeichnis, durch das man mit einer Taste springen kann. Wenn Überschriften-Tags aus rein optischen Gründen gewählt werden (z.B. <h4>, weil es die passende Schriftgröße hat), bricht diese Struktur zusammen. Genauso problematisch: Seiten mit gar keiner <h1>, oder solche mit drei <h1>-Tags auf einmal.

Falsch

h1 → h4 → h2 → h5
(nach optischen Kriterien)

Richtig

h1 → h2 → h3 → h2
(logisch verschachtelt)

So beheben Sie es

Jede Seite hat genau eine <h1> (der Haupttitel). Abschnitte sind <h2>, Unterabschnitte <h3> usw. Die Schriftgröße steuern Sie per CSS — unabhängig vom Tag. Im Avada Fusion Builder lassen sich HTML-Tag und visuelle Größe für jedes Heading-Element separat einstellen. Prüfen Sie die Struktur mit der kostenlosen Browser-Extension HeadingsMap.

Schnelltest für Ihre eigene Website

1. Schließen Sie die Maus weg und navigieren Sie Ihre Website 5 Minuten lang nur mit der Tab-Taste. Kommen Sie überall hin? Sehen Sie immer, wo Sie sind?
2. Öffnen Sie den Lighthouse-Audit in Chrome (Entwicklertools → Lighthouse → Accessibility) und schauen Sie, welche Punkte rot markiert sind.
3. Prüfen Sie Ihre wichtigste Textfarbe auf Ihrem häufigsten Hintergrund im WebAIM Contrast Checker.
4. Installieren Sie HeadingsMap und schauen Sie, ob Ihre Überschriften-Hierarchie logisch aufgebaut ist.

Wichtig: Alle fünf Fehler sind behebbar — manche in 10 Minuten, andere brauchen etwas mehr Aufwand. Entscheidend ist, anzufangen. Barrierefreiheit muss nicht von Anfang an perfekt sein, um spürbare Verbesserungen zu bringen.