Website barrierefrei machen: Die wichtigsten WCAG-Schritte für WordPress
Du hast deine Website auf Barrierefreiheit geprüft und weißt jetzt, wo die Probleme liegen. Die nächste Frage: Wie behebst du sie konkret, ohne die Website komplett neu zu bauen?
Der technische Maßstab dahinter sind die WCAG 2.1 auf Level AA. Dieselben Anforderungen, an denen sich auch das BFSG orientiert. Klingt nach Norm-Text, lässt sich aber in überschaubaren, konkreten Schritten umsetzen.
In diesem Artikel gehe ich die fünf Baustellen durch, die ich bei WordPress-Websites am häufigsten finde und wie du sie in der Praxis behebst.
👉 Falls du noch nicht geprüft hast, wo deine Website steht: WordPress-Website auf Barrierefreiheit prüfen: So fängst du an
Baustelle 1: Alt-Texte bei Bildern
Screenreader können Bilder nicht "sehen". Sie lesen vor, was im Alt-Text steht. Fehlt er, wird das Bild für blinde und stark sehbehinderte Nutzer einfach übersprungen, egal wie wichtig es für das Verständnis der Seite ist.
In der Praxis: Beschreibe, was auf dem Bild inhaltlich wichtig ist, nicht wie es aussieht. "Elektriker repariert Sicherungskasten in Altbauwohnung" ist ein guter Alt-Text. "Bild1234.jpg" oder gar kein Alt-Text sind es nicht. Rein dekorative Bilder ohne Informationswert bekommen bewusst einen leeren Alt-Text, damit Screenreader sie überspringen, statt sinnlose Dateinamen vorzulesen.
Baustelle 2: Farbkontraste
Hellgrauer Text auf weißem Hintergrund sieht oft elegant aus. Klar. Das ist für viele Menschen aber kaum lesbar, nicht nur bei Sehbehinderung, sondern auch bei starkem Sonnenlicht auf dem Handydisplay.
WCAG AA verlangt ein Kontrastverhältnis von mindestens 4,5:1 für normalen Fließtext. Kostenlose Kontrastchecker im Browser zeigen dir sofort, ob eine Farbkombination besteht oder nicht. Meist reicht es, den Grauton einmal dunkler zu setzen, um durchgängig zu bestehen.
Baustelle 3: Überschriftenstruktur
Eine Seite hat genau eine H1, danach folgen H2 und H3 in logischer Reihenfolge, ähnlich wie bei einem Inhaltsverzeichnis. Screenreadernutzer springen oft direkt von Überschrift zu Überschrift, um sich zu orientieren. Wenn Überschriftenebenen nur wegen der Optik gewählt werden, statt der tatsächlichen Struktur zu folgen, geht diese Orientierung verloren.
Häufiger Fehler: Ein Text wird einfach fett und größer formatiert, um wie eine Überschrift auszusehen, ohne tatsächlich als Überschrift (H2, H3) ausgezeichnet zu sein. Optisch macht das keinen Unterschied. Strukturell schon.
Baustelle 4: Tastaturbedienbarkeit
Nicht jeder bedient eine Website mit der Maus: aus motorischen Gründen, mit einem Schalter- oder Sprachsteuerungssystem, oder schlicht, weil die Maus gerade defekt ist. Ein einfacher Test: Website nur mit der Tab-Taste durchklicken. Landest du auf jedem Link, jedem Button, jedem Formularfeld in sinnvoller Reihenfolge und sichtbar markiert?
Typisches Problem sind Menüs oder Slider, die zwar mit der Maus, aber nicht per Tastatur bedienbar sind. Oft eine Folge von zu komplexen Page-Builder- oder Slider-Plugins.
Baustelle 5: Formulare
Ein Kontaktformular ohne korrekt verknüpfte Labels ist für Screenreader-Nutzer kaum ausfüllbar. Sie hören nur "Eingabefeld", ohne zu wissen, was hier eingetragen werden soll. Jedes Formularfeld braucht ein sichtbares, programmatisch verknüpftes Label, nicht nur einen Platzhaltertext, der beim Klicken verschwindet.
Was ich bei WordPress-Websites oft übersehen sehe
Viele dieser Probleme entstehen nicht durch Nachlässigkeit, sondern durch die Bauweise: Page-Builder wie Elementor oder Divi erzeugen oft verschachtelten, semantisch unklaren Code. Viele generische "div"-Blöcke statt echter Überschriften, Listen oder Buttons. Das sieht am Bildschirm gut aus, ist für Screenreader aber schwerer zu interpretieren.
Genau deshalb baue ich Websites handgemacht, ohne Page-Builder. Ziel ist direkt ein sauberes, semantisches HTML als Grundlage für Barrierefreiheit.
👉 Warum ich bei WordPress-Projekten bewusst auf Page-Builder verzichte: WordPress Page Builder im Vergleich
👉 Ob und wie stark dich das BFSG rechtlich überhaupt betrifft: BFSG und deine Website: Bist du betroffen?
Häufig gestellte Fragen
Was bedeutet WCAG 2.1 Level AA konkret?
WCAG 2.1 Level AA ist der technische Maßstab für Barrierefreiheit im Web und die Grundlage, an der sich auch das BFSG orientiert. Er deckt unter anderem Kontraste, Überschriftenstruktur, Tastaturbedienbarkeit und Alt-Texte ab. Also genau die fünf Baustellen aus diesem Artikel.
Brauche ich für eine barrierefreie Website einen kompletten Relaunch?
Nein. Die meisten Fixes (Alt-Texte, Kontraste, Überschriftenstruktur) lassen sich an bestehenden Inhalten nachziehen, ohne die Website neu zu bauen. Nur Tastaturbedienbarkeit und Formulare brauchen manchmal etwas mehr technisches Verständnis.
Wo sollte ich anfangen, wenn ich wenig Zeit habe?
Bei Alt-Texten und Kontrasten. Beide lassen sich meist an einem Nachmittag durchgehen, ohne Entwickler-Kenntnisse. Und sie bringen den größten Hebel bei geringstem Aufwand.
Hilft Barrierefreiheit auch meinem SEO?
Ja. Alt-Texte, saubere Überschriftenstruktur und semantisches HTML sind dieselben Grundlagen, die auch Google für ein gutes Ranking braucht. Wer Barrierefreiheit verbessert, verbessert automatisch auch die technische Basis für SEO.
Fazit: Kein Großprojekt, sondern konsequente Kleinarbeit
Keine der fünf Baustellen erfordert einen Website-Neubau. Es ist konsequente Kleinarbeit an bestehenden Inhalten. Wer damit anfängt, verbessert nebenbei fast immer auch seinen SEO-Erfolg, weil beide auf denselben Grundlagen aufbauen: klare Struktur und verständliche Inhalte. Für eine Website, die für alle funktioniert.