WordPress barrierefrei machen: Der Praxis-Leitfaden 2026

WordPress ist im Auslieferungszustand nicht automatisch barrierefrei. Der Core wird zwar von der Community eng an den WCAG-Standards entwickelt, doch sobald ein individuelles Theme, ein Page Builder oder zusätzliche Plugins ins Spiel kommen, entstehen schnell neue Barrieren – von unlesbaren Kontrasten bis zu Menüs, die sich per Tastatur nicht bedienen lassen.

Seit dem 28. Juni 2025 ist in Deutschland das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft. Für viele Website-Betreiber ist digitale Barrierefreiheit damit vom „Nice-to-have“ zur gesetzlichen Pflicht geworden. Dieser Leitfaden zeigt dir Schritt für Schritt, worauf es technisch wirklich ankommt – und an welchen Stellen sich professionelle Unterstützung durch eine spezialisierte Agentur auszahlt.

Das Wichtigste in Kürze

• Barrierefreiheit ist Pflicht, nicht Kür: Seit dem BFSG 2025 müssen viele – vor allem endkundenorientierte (B2C) – Websites die WCAG-Kriterien erfüllen. Verstöße können abgemahnt werden.
• Das Fundament entscheidet: Ob eine Seite barrierefrei ist, hängt maßgeblich vom Theme ab. Moderne Block-Themes (Full Site Editing) liefern sauberes, semantisches HTML; viele klassische Page-Builder-Layouts nicht.
• Struktur vor Kosmetik: Eine logische Überschriften-Hierarchie (genau eine H1, danach H2–H6 in Reihenfolge) und HTML5-Landmarks sind die Basis, damit Screenreader eine Seite verstehen.
• Ohne Maus bedienbar: Jede Funktion – Menüs, Formulare, Cookie-Banner, Pop-ups – muss vollständig per Tastatur nutzbar sein, inklusive sichtbarem Fokus.
• Kontraste & Alternativen: Text braucht ein Kontrastverhältnis von mindestens 4,5:1, Bilder brauchen sinnvolle Alt-Texte, Videos Untertitel.
• Plugins sind Ergänzung, kein Ersatz: Accessibility-Overlays verbessern den Komfort, reparieren aber keinen fehlerhaften Theme-Code und ersetzen keine redaktionelle Arbeit.

Was heißt „barrierefrei“ im Web überhaupt?

Digitale Barrierefreiheit bedeutet, dass Menschen mit Behinderungen eine Website eigenständig wahrnehmen, verstehen und bedienen können – unabhängig davon, ob sie sehen, hören, eine Maus benutzen oder auf assistive Technologien wie Screenreader angewiesen sind.

Der internationale Maßstab dafür sind die Web Content Accessibility Guidelines (WCAG), aktuell in Version 2.2. Sie ordnen alle Kriterien vier Prinzipien zu: Inhalte müssen wahrnehmbar, bedienbar, verständlich und robust sein. In Deutschland verweist das BFSG über die europäische Norm EN 301 549 im Kern auf genau diese Kriterien – als Zielniveau gilt in der Praxis die Konformitätsstufe AA.

Kurz gesagt: Wer die WCAG 2.2 auf Stufe AA erfüllt, ist auch für die Anforderungen des BFSG gut aufgestellt.

Bin ich vom BFSG überhaupt betroffen?

Bevor du Zeit und Budget investierst, lohnt sich die rechtliche Einordnung. Das BFSG zielt vor allem auf Produkte und Dienstleistungen für Endverbraucher ab. Betroffen sind unter anderem:

• Online-Shops und E-Commerce (z. B. WooCommerce-Stores)
• Buchungs- und Reservierungssysteme
• Bank-, Zahlungs- und viele Dienstleistungsangebote im B2C-Bereich

Häufig ausgenommen sind reine B2B-Angebote sowie Kleinstunternehmen unter bestimmten Schwellenwerten (weniger als 10 Beschäftigte und maximal 2 Mio. € Jahresumsatz) – allerdings nur bei Dienstleistungen, nicht generell.

Hinweis: Die konkrete Betroffenheit ist im Einzelfall zu prüfen und keine Rechtsberatung. Selbst wer nicht verpflichtet ist, profitiert von Barrierefreiheit: bessere Nutzererfahrung, größere Reichweite und messbare SEO-Vorteile.

Unsicher, ob dein Projekt betroffen ist? Die WordPress-Experten von MEWIGO ordnen deinen Status im Rahmen eines Audits ein und leiten daraus einen realistischen Maßnahmenplan ab.

Die vier Ebenen einer barrierefreien WordPress-Seite

Barrierefreiheit entsteht nicht durch ein einzelnes Plugin, sondern im Zusammenspiel von vier Ebenen. Wer eine davon vernachlässigt, bekommt Lücken, die andere Ebenen nicht ausgleichen können:

1. Fundament (Code): schlankes, semantisches HTML5 mit Landmarks und sauberer Überschriften-Struktur.
2. Interaktion (Technik): vollständige Bedienbarkeit per Tastatur – Menüs, Modals, Formulare.
3. Gestaltung (Design): ausreichende Kontraste, skalierbare Schriften, stabile Layouts beim Zoomen.
4. Inhalt (Redaktion): Alt-Texte, Untertitel, verständliche Sprache und aussagekräftige Linktexte.

Wie ein Screenreader deine Seite „liest“

Ein Screenreader zeigt kein Layout an – er verarbeitet den HTML-Quelltext linear von oben nach unten und gibt ihn als Sprache oder Braille aus. Ob etwas fett, groß oder farbig ist, spielt dabei keine Rolle. Entscheidend ist, ob im Code sauber definiert ist, was Navigation, was Hauptinhalt und was Fußbereich ist. Fehlt diese Semantik, verliert der Nutzer die Orientierung. Deshalb beginnt jede seriöse Optimierung im Code – nicht in der Optik.

Themes & Page Builder: das technische Fundament

Das Theme bestimmt, welchen HTML-Code deine Seite letztlich ausgibt. Ist dieser Code unsauber, hilft auch die beste Redaktionsarbeit nicht mehr.

Das typische Problem klassischer Page Builder: Um flexible Drag-and-drop-Layouts zu ermöglichen, verschachteln viele ältere Builder zahllose bedeutungslose <div>-Container. Für Screenreader ist das ein Problem, weil ein <div> keine semantische Bedeutung trägt – die Software kann Struktur und Inhalt nicht mehr unterscheiden. Zusätzlich sind komplexe Module wie Slider oder Akkordeons dort oft nicht sauber per Tastatur bedienbar.

Der empfohlene Weg: Setze bei neuen Projekten oder Relaunches auf moderne Block-Themes (Full Site Editing), die nativ auf dem Block-Editor aufbauen. Sie liefern von Haus aus schlankes HTML5, tastaturbedienbare Navigationsblöcke und eine Struktur, die nah an den WCAG-Kriterien liegt. Auch etablierte, aktiv gepflegte Themes bringen viele Barrierefreiheits-Funktionen mit – wichtig ist, dass das Theme HTML5-Landmarks unterstützt und regelmäßig aktualisiert wird.

Bei einem stark veralteten Custom-Theme ist ein gezielter Relaunch häufig wirtschaftlicher als das mühsame Nachrüsten Hunderter Einzelbausteine. Ob sich dein Bestands-Theme retten lässt oder ein sauberer Neuaufbau sinnvoller ist, klärt MEWIGO im Rahmen einer Theme-Analyse – bis hin zur kompletten WordPress-Website-Entwicklung auf barrierefreier Basis.

Semantische Struktur & Überschriften

Screenreader-Nutzer lassen sich häufig zuerst alle Überschriften einer Seite auflisten, um wie über ein Inhaltsverzeichnis gezielt zu springen. Ist diese Struktur chaotisch, bricht die Navigation zusammen.

Regeln für eine saubere Hierarchie:

• Pro Seite gibt es genau eine H1 (den Seitentitel).
• Danach folgen H2 bis H6 in logischer Reihenfolge – auf eine H2 folgt eine H3, keine H4.
• Überschriften werden nie zur reinen Optik zweckentfremdet. Kleinere Schrift löst du über CSS, nicht über eine niedrigere Überschriftenebene.

HTML5-Landmarks geben assistiven Technologien die Grobstruktur der Seite. Ein sauberes Grundgerüst sieht sinngemäß so aus:

<header>   <!-- Logo und Hauptnavigation --></header>
<nav aria-label="Hauptmenü"> <!-- Navigationslinks --></nav>
<main id="content"> <!-- Der eigentliche Seiteninhalt --></main>
<footer>   <!-- Impressum, Datenschutz, Kontakt --></footer>

Ebenso wichtig: Der <title> im Seitenkopf ist das erste, was ein Screenreader vorliest. Achte darauf, dass dein SEO-Plugin sprechende, eindeutige Titel pro Unterseite erzeugt (z. B. „Warenkorb – Shopname“ statt nur „Shop“).

Tastaturbedienung & Fokus

Eine Kernanforderung der WCAG ist, dass sich die gesamte Seite ohne Maus bedienen lässt. Das betrifft blinde Nutzer ebenso wie Menschen mit motorischen Einschränkungen.

Der schnelle Selbsttest: Leg die Maus weg und navigiere nur mit Tab (vorwärts) und Shift + Tab (rückwärts). Erreichst du jeden Link? Kommst du ins Dropdown-Menü hinein und wieder heraus? Lässt sich das Cookie-Banner schließen? Wenn nicht, besteht Handlungsbedarf.

Sichtbarer Fokus statt „outline: none“

Der Fokus-Rahmen zeigt, wo man sich beim Tabben gerade befindet. Ihn aus optischen Gründen zu entfernen (outline: none) ist ein klassischer Fehler. Mit :focus-visible lässt sich ein gut sichtbarer Fokus gezielt für Tastaturnutzer setzen, ohne Mausklicks zu stören:

a:focus-visible,
button:focus-visible {
  outline: 3px solid #1a1a1a;
  outline-offset: 2px;
}

Skip-Link zum Hauptinhalt

Ein „Zum Inhalt springen“-Link ganz oben im Quelltext erspart Tastaturnutzern, sich bei jedem Seitenaufruf durch das komplette Menü zu tabben. Er ist visuell versteckt und erscheint erst beim Fokussieren:

<a href="#content" class="skip-link">Zum Hauptinhalt springen</a>

.skip-link {
  position: absolute;
  left: 0;
  top: -100px;
  background: #1a1a1a;
  color: #fff;
  padding: 12px 16px;
  z-index: 100000;
}
.skip-link:focus { top: 0; }

Tastaturfallen in mobilen Menüs vermeiden

Ein häufiger Fehler: Ein geöffnetes Burger-Menü, aus dem der Tastaturfokus nicht mehr herauskommt – oder der im Hintergrund weiterspringt. Barrierefreie Overlays lösen das über drei Bausteine: passende ARIA-Attribute (aria-expanded, aria-controls, role="dialog"), das Sperren des Hintergrunds (inert), sobald das Menü offen ist, und ein gezieltes Fokus-Management, das den Fokus im Menü hält und beim Schließen zum Auslöser zurückgibt. Moderne Block-Themes erledigen das mit dem nativen Navigations-Block bereits automatisch. Bei individuell gebauten Overlays gehört diese Logik zwingend sauber implementiert – eine Aufgabe für erfahrene Entwickler.

Formulare zugänglich gestalten

Kontaktformulare, Newsletter-Anmeldungen und Checkout-Prozesse gehören zu den größten Barrieren im Web.

Echte Labels statt Platzhalter: Ein Platzhalter im Feld ersetzt keine Beschriftung – er verschwindet beim Tippen und wird von Screenreadern nicht zuverlässig vorgelesen. Jedes Feld braucht ein programmatisch verknüpftes <label>:

<label for="email">E-Mail-Adresse *</label>
<input id="email" name="email" type="email" required>

Verständliche Fehlermeldungen: Fehler dürfen nie allein über die Farbe Rot signalisiert werden (Stichwort Rot-Grün-Sehschwäche). Formuliere sie als Text, ergänze ein Icon und verknüpfe die Meldung über aria-describedby mit dem Feld, damit der Screenreader sie sofort vorliest:

<input id="email" type="email" aria-describedby="email-error">
<span id="email-error">Bitte gib eine gültige E-Mail-Adresse ein.</span>

Farben & Kontraste

Barrierefreies Design heißt nicht schwarz-weiß und langweilig – es heißt lesbar, auch bei Sehschwäche, Farbfehlsichtigkeit oder Sonnenlicht auf dem Smartphone. Die WCAG 2.2 macht dazu klare Vorgaben:

• Normaler Fließtext: mindestens 4,5:1
• Großer Text (ab ca. 24 px, oder 19 px fett): mindestens 3:1
• Grafische Bedienelemente (Icons, Button-Rahmen): mindestens 3:1

Diese Werte musst du nicht schätzen. Kostenlose Tools wie der WebAIM Contrast Checker, der Colour Contrast Analyser oder die in Chrome und Firefox integrierten Entwicklerwerkzeuge messen sie exakt. Wichtig: Der Kontrast muss auch im Hover- und Fokus-Zustand stabil bleiben – ein Menüpunkt, der beim Überfahren blass wird, fällt sonst durch.

Bilder, Medien & Sprache

Alt-Texte beschreiben Funktion oder Inhalt eines Bildes – nicht als Keyword-Sammlung, sondern so, dass ein Mensch ohne Sehvermögen die Information trotzdem erhält (z. B. „Balkendiagramm: Umsatzsteigerung um 10 % im Jahr 2026“). Rein dekorative Bilder erhalten ein leeres alt="", damit Screenreader sie überspringen – das Attribut darf aber nicht ganz fehlen.

Videos brauchen Untertitel (für gehörlose Nutzer) und idealerweise eine Audiodeskription. Für Podcasts und andere reine Audio-Inhalte stellst du ein Text-Transkript bereit.

Fremdsprachige Begriffe kennzeichnest du im Code mit einem lang-Attribut (z. B. <span lang="en">…</span>), damit der Screenreader sie korrekt ausspricht.

Plugins & Overlays: sinnvolle Ergänzung, kein Wundermittel

Accessibility-Plugins und Frontend-Widgets können echten Mehrwert liefern – sie ersetzen aber niemals eine saubere technische Basis.

Was Plugins zuverlässig können: fehlende Code-Attribute nachrüsten (z. B. lang), Skip-Links einfügen, störende title-Attribute entfernen oder einen globalen Fokus-Ring erzwingen.

Wobei sie (teils KI-gestützt) assistieren: Alt-Text-Vorschläge, automatische Untertitel, Vereinfachung von Texten in Leichte oder Einfache Sprache – jeweils mit menschlicher Endkontrolle.

Was Plugins nicht leisten: Sie reparieren keine chaotische Informationsarchitektur, keine falsch verschachtelten Überschriften, keine schlecht konzipierten Formulare und kein defektes responsives Design. Ein Overlay-Widget legt sich nur als visuelle Ebene über die fertige Seite – es kann ein technisch unzugängliches Menü oder fehlende Formular-Labels nicht heilen. Als Alibi für ein fehlerhaftes Fundament sind solche Tools ungeeignet.

Die Faustregel: Das Fundament gehört sauber programmiert, Plugins optimieren obendrauf den Komfort.

So testest du die Barrierefreiheit deiner Seite

Ein belastbarer Check kombiniert drei Phasen:

1. Automatische Scans. Tools wie Google Lighthouse (in den Chrome DevTools), die WAVE-Extension oder axe DevTools finden in Sekunden messbare Fehler wie zu geringe Kontraste, fehlende Alt-Texte oder leere Linktexte. Sie erfassen allerdings nur einen Teil der Kriterien.

2. Manuelle Praxistests. Prüfe die Tastaturbedienung, teste bei 200 % Browser-Zoom, ob Inhalte lesbar umbrechen ohne sich zu überlagern, und emuliere über die DevTools Farbfehlsichtigkeiten, um zu sehen, ob Informationen auch ohne Farbe erkennbar bleiben.

3. Der Screenreader-Test. Der ehrlichste Test: Monitor aus (oder Augen zu) und eine konkrete Aufgabe nur mit Tastatur und Screenreader erledigen – etwa ein Produkt in den Warenkorb legen. Jedes System bringt die Werkzeuge mit: VoiceOver (macOS), die Sprachausgabe (Windows) oder das kostenlose NVDA.

Die vier häufigsten Fehler

1. Blindes Vertrauen in „All-in-One“-Plugins. Kein Plugin repariert falsch verschachtelte Überschriften oder errät den Inhalt eines Bildes.
2. Autoplay und unkontrollierbare Slider. Bewegte Elemente brauchen einen sichtbaren, tastaturerreichbaren Stopp-Button.
3. Information nur über Farbe. Kombiniere Farbe immer mit Text und Icon – „Alle Pflichtfelder sind rot“ reicht nicht.
4. Nichtssagende Linktexte. „Hier klicken“ oder „Mehr erfahren“ sind isoliert wertlos. Nutze aussagekräftige Linktexte wie „SEO-Leitfaden für Barrierefreiheit lesen“.

Wie MEWIGO dich bei der Umsetzung unterstützt

Barrierefreiheit ist selten ein Einzel-Task, sondern ein Zusammenspiel aus Recht, Technik, Design und Redaktion. Genau hier setzt MEWIGO als strategischer Partner an:

• Audit & Statusbestimmung: Wir prüfen deine Seite gegen die WCAG 2.2 (Stufe AA) und ordnen deine BFSG-Betroffenheit ein.
• Priorisierter Maßnahmenplan: Du erhältst eine klare Roadmap – von schnellen Redaktions-Fixes bis zu tiefergehenden Code-Optimierungen.
• Technische Umsetzung: Von Fokus-Management über barrierefreie Formulare bis zum kompletten, barrierefreien Relaunch auf Basis moderner Block-Themes.
• Laufende Betreuung: Barrierefreiheit ist kein einmaliges Projekt. Wir halten deine Seite dauerhaft konform.

Du willst wissen, wo deine WordPress-Seite steht? Sprich mit MEWIGO über dein Projekt – wir liefern zuerst eine ehrliche Analyse, bevor auch nur eine Zeile Code angefasst wird.

FAQ: Häufige Fragen zu WordPress & Barrierefreiheit