WordPress barrierefrei machen: So geht's wirklich.

WordPress selbst ist für mich nur das Fundament. Der Core wird zwar nach Accessibility-Standards weiterentwickelt, das heißt aber noch lange nicht, dass deine fertige Website automatisch barrierefrei ist. Ob sie es wird, entscheiden drei Dinge, auf die du selbst Einfluss hast: dein Theme, das die HTML-Struktur, die Navigation und das Fokus-Verhalten liefert, deine Plugins, von denen jedes neue Barrieren einbauen kann, und deine Inhalte, also Texte, Bilder und Formulare.

Als Maßstab dienen mir dabei die WCAG, das sind die international anerkannten Richtlinien für barrierefreie Webinhalte, kurz für: Texte müssen sich lesen lassen (Kontrast, Schriftgröße), alles muss ohne Maus bedienbar sein, Bilder brauchen Alt-Texte und Formulare brauchen Beschriftungen. Kein Hexenwerk, aber Arbeit an vielen kleinen Stellen, das erlebe ich bei jedem Projekt aufs Neue.

Das Barrierefreiheitsstärkungsgesetz, kurz BFSG, ist in Kraft: Wer online Produkte oder Dienstleistungen an Verbraucher verkauft, muss seine Website barrierefrei anbieten, das betrifft Onlineshops genauso wie Buchungsstrecken oder Terminvereinbarungen. Wen die Pflicht genau trifft, welche Ausnahmen es gibt und was konkret gefordert ist, habe ich in meinem Ratgeber BFSG: Barrierefreie Website aufgeschlüsselt.

Aber auch ohne diese gesetzliche Pflicht lohnt sich der Aufwand aus meiner Sicht immer: Du schließt niemanden aus, deine Seite wird für alle Besucher leichter bedienbar, und vieles davon, saubere Überschriften, Alt-Texte, verständliche Linktexte, zahlt direkt auf dein SEO ein. Ich sehe Barrierefreiheit selten als verschwendete Arbeit.

Das Theme liefert die technische Basis: HTML-Struktur, Menüs, Fokus-Verhalten, Skip-Links. Ein schlecht gebautes Theme repariere ich hinterher nicht mit ein paar Plugins. Im offiziellen Theme-Verzeichnis hilft mir dabei das Tag „accessibility-ready“: Diese Themes wurden auf Mindeststandards geprüft, Tastatur-Navigation, sichtbarer Fokus, Skip-Links. Kein Zertifikat für eine barrierefreie Website, aber eine solide Basis, die zum Beispiel die Standard-Themes von WordPress mitbringen.

Bei Page-Buildern wie Elementor oder Bricks, mit denen ich selbst arbeite, hängt fast alles davon ab, wie man sie einsetzt: semantische HTML-Tags statt Div-Suppe, die Überschriften-Hierarchie einhalten (H1 bis H3 der Reihe nach, nicht nach Optik), interaktive Elemente wie Slider und Akkordeons kritisch prüfen. Ich baue meine Kundenprojekte als WordPress-Agentur selbst mit einem Builder, und aus dieser Erfahrung weiß ich: Barrierefrei wird das nur, wenn ich von Anfang an darauf achte, nicht als Nachgedanke.

Eine ehrliche Warnung vorweg: Overlay-Widgets, die dir versprechen, deine Website „mit einem Plugin barrierefrei“ zu machen, halten für mich nicht, was sie versprechen. Sie legen eine Werkzeugleiste über die Seite, Kontrast-Schalter, Schriftgrößen-Buttons, beheben aber keinen einzigen Fehler im Code darunter. Screenreader-Nutzer stören solche Overlays in meiner Erfahrung eher, als dass sie helfen, und rechtlich auf der sicheren Seite bist du damit auch nicht.

• Editor-Checks wie Sa11y oder Editoria11y weisen mich direkt im Backend auf fehlende Alt-Texte hin
• sie zeigen übersprungene Überschriften und schwache Linktexte
• sie ersetzen aber nie die eigentliche Arbeit am Theme und an den Inhalten

Solche Plugins sind für mich Werkzeuge, keine Lösungen. Die eigentliche Arbeit passiert immer im Theme und in deinen Inhalten, nicht im Plugin-Verzeichnis.

Die meistgestellte Frage zuerst: Eine feste Mindest-Schriftgröße schreiben die WCAG nicht vor. Bei mir hat sich 16 Pixel (1rem) als Basis für Fließtext bewährt, viel kleiner sollte es nirgends werden, auch nicht im Footer oder in Formular-Hinweisen. Wichtiger als die absolute Zahl ist mir: relative Einheiten (rem/em) statt fester Pixelwerte nutzen, damit die Schriftgrößen-Einstellung des Browsers greift. Und deine Seite muss sich auf 200 % zoomen lassen, ohne dass Inhalte abgeschnitten werden oder sich überlappen.

In WordPress stelle ich das zentral ein, über die theme.json beziehungsweise die Theme-Einstellungen mit sauber definierten Schriftgrößen-Presets, statt Größen pro Seite von Hand zu setzen. Dazu gehören für mich eine Zeilenhöhe von etwa 1,5, angenehme Zeilenlängen und ausreichend Abstand zwischen Absätzen. Wer fluide Typografie mit clamp() nutzt, sollte prüfen, dass das Minimum lesbar bleibt und der Browser-Zoom weiterhin funktioniert.

Der häufigste Fehler, den ich sehe: hellgrauer Text auf weißem Grund. Die WCAG verlangen für normalen Text ein Kontrastverhältnis von 4,5:1, für große Schrift (ab etwa 24 Pixel, oder ab etwa 19 Pixel fett) und für Bedienelemente 3:1. Ich prüfe das kostenlos mit dem WebAIM Contrast Checker oder direkt in den Entwickler-Tools meines Browsers, die zeigen das Verhältnis schon beim Farbwähler an.

Zweite Regel, die ich mir selbst zur Pflicht gemacht habe: Farbe darf nie das einzige Signal sein. Links im Fließtext färbe ich nicht nur ein, sondern unterstreiche sie, Fehler in Formularen markiere ich nicht nur rot, sondern erkläre sie mit Text. In WordPress lohnt es sich, die Farbpalette zentral im Theme zu definieren, dann stimmen die Kontraste überall, statt dass du sie auf jeder Seite einzeln nachbessern musst.

Viele Menschen bedienen Websites ohne Maus, per Tastatur, Schalter oder Screenreader. Mein einfachster Test dafür: Maus weglegen und nur mit der Tab-Taste durch die Seite navigieren. Erreiche ich jedes Menü, jeden Button, jedes Formularfeld? Und sehe ich jederzeit, wo ich gerade bin? Wenn das Theme den Fokus-Ring per CSS entfernt hat, fliegt man blind, einer der häufigsten Fehler, die mir in WordPress-Themes unterkommen.

• ein Skip-Link, der direkt zum Inhalt springt
• Dropdown-Menüs, die sich per Tastatur öffnen und schließen lassen
• Modals oder Offcanvas-Menüs, die den Fokus halten und sich mit Escape schließen lassen

Genau an diesen Stellen patzen viele Page-Builder-Setups: Der Burger-Button ist ein Div statt ein Button, der Slider schluckt den Fokus, das Offcanvas lässt sich öffnen, aber nicht mehr verlassen. Solche Fehler baue ich mir selbst nicht ein, weil ich sie bei fremden Projekten zu oft aufräumen musste.

Jedes Bild, das Inhalt transportiert, braucht einen Alt-Text, in WordPress trage ich ihn direkt in der Mediathek oder am Block ein. Ich beschreibe, was zu sehen ist und welche Funktion das Bild hat, rein dekorative Bilder bekommen bei mir bewusst einen leeren Alt-Text, damit der Screenreader sie überspringt. Kein Keyword-Stuffing, das hilft weder Nutzern noch Google. Bei Videos gilt für mich: Untertitel anbieten, auf Autoplay verzichten.

Formulare sind die zweite große Baustelle: Jedes Feld braucht ein sichtbares Label, ein Platzhalter allein reicht nicht, er verschwindet beim Tippen. Pflichtfelder kennzeichne ich nicht nur farblich, Fehlermeldungen formuliere ich verständlich und gebe sie direkt am betroffenen Feld aus.

Für den ersten Durchgang reichen mir kostenlose Tools: WAVE und axe DevTools finden Kontrastfehler, fehlende Alt-Texte und Label-Probleme direkt auf der Seite. Aber ein grünes Ergebnis heißt für mich noch lange nicht, dass eine Seite barrierefrei ist, automatische Tools finden nur einen Teil der Probleme. Den Rest teste ich selbst: mit der Tastatur durch die Seite, Zoom auf 200 %, und einmal mit einem echten Screenreader. Und weil jedes Update und jedes neue Plugin neue Barrieren einbauen kann, gehört das bei mir in die laufende WordPress-Wartung, nicht auf eine einmalige Checkliste. Willst du das nicht selbst stemmen, baue ich dir barrierefreie Websites von Grund auf, oder mache deine bestehende Seite fit.