WordPress Website barrierefrei machen: Der technische Leitfaden (2026)

WordPress ist „out of the box“ nicht barrierefrei. Zwar gibt sich das Core-Team größte Mühe, das CMS an den modernen WCAG-Standards auszurichten, aber sobald man ein eigenes Theme installiert, Page Builder nutzt oder Plugins hinzufügt, reißt das Fundament oft ein.

Seit Mitte 2025 ist das Barrierefreiheitsstärkungsgesetz (BFSG) in Kraft. Eine barrierefreie – oder zumindest barrierearme – Website ist kein optionales Qualitätsmerkmal mehr, sondern für viele Webprojekte gesetzliche Pflicht.

Das Wichtigste in Kürze

• Themes & Page Builder: Barrierefreiheit steht und fällt mit der Code-Basis. Moderne Full Site Editing Themes bieten nativ schlankes HTML5, während klassische Page Builder oft eine unstrukturierte Div-Verschachtelung erzeugen, die Screenreader blockiert.
• HTML-Semantik & Formulare: HTML5-Landmarks und eine chronologische Überschriften-Hierarchie (H1–H6) bilden das Skelett für Screenreader. Formulare benötigen eindeutige -Tags und textbasierte Fehlermeldungen.
• Tastaturnavigation: Die Website muss komplett ohne Maus bedienbar sein. Das erfordert sichtbare Fokus-Ringe im CSS, funktionale Skip-Links und ein aktives Fokus-Management in mobilen Menüs gegen Tastaturfallen.
• Kontraste & Medien: Textkontraste müssen WCAG-konform sein (mindestens 4,5:1). Bilder benötigen kontextuelle ALT-Texte, Videos brauchen Untertitel und Audio-Inhalte ein Text-Transkript.
• Plugins & Overlays: Frontend-Widgets und Code-Fixer verbessern die Usability, sind aber kein Allheilmittel. Sie können weder kaputten Theme-Code im Hintergrund reparieren noch redaktionelle Aufgaben wie Bildbeschreibungen ersetzen.
• Messen & Testen: Ein verlässlicher Check kombiniert automatische Tools (Lighthouse, WAVE) mit manuellen Prüfungen und einem Selbstversuch per System-Screenreader.

Die 4 Säulen der Barrierefreiheit

Barrierefreiheit passiert nicht durch das Installieren eines einzelnen Plugins. Sie ist ein Zusammenspiel aus vier Ebenen:

• Die Code-Ebene: Hier geht es um schlankes, semantisches HTML5. Dazu gehören funktionale Landmarks, eine chronologische Überschriften-Hierarchie (H1 bis H6) sowie die korrekte programmatische Verknüpfung von Elementen (z. B. bei Formularen). Sie sorgt dafür, dass assistive Technologien die Struktur der Seite fehlerfrei interpretieren können.
• Die technische Ebene: Diese Ebene baut auf dem Code auf und bestimmt, wie sich die Website verhält. Kernanforderung ist, dass die gesamte Website – inklusive aller Formulare, Pop-ups und mobilen Menüs – mit der Tastatur ohne Maus-Einsatz steuerbar ist.
• Die Design-Ebene: Sie definiert die globalen Stile im Theme. Hierzu gehören mathematisch saubere Farbkontraste nach den WCAG-Vorgaben, die auch im Hover- und Fokus-Zustand stabil bleiben, sowie flexible, stufenlos skalierbare Schriften und responsive Layouts, die beim Zoomen nicht zerbrechen.
• Die Redaktions-Ebene: Das ist die inhaltliche Arbeit im WordPress-Editor. Dazu gehört das Einpflegen von kontextuellen ALT-Texten für Bilder in der Mediathek, das Bereitstellen von Untertiteln und Transkripten für Videos und Podcasts sowie das Verfassen von Texten in barrierearmer, verständlicher Sprache.

Wie ein Screenreader deine Website liest

Ein Screenreader ist ein Programm, das blinden Menschen oder Menschen mit Sehbeeinträchtigung die Inhalte einer Website vorliest. Damit dies reibungslos funktioniert, muss der Code deiner Website klar strukturiert sein.

Screenreader sehen dein CSS-Layout nicht. Sie lesen den rohen HTML-Code linear von oben nach unten und filtern für den Nutzer die tatsächlichen Inhalte. Wenn in deinem Code nicht genau definiert ist, was z.B. eine Hauptnavigation (<nav>) und was der Hauptinhalt (<main>) ist, verläuft sich der blinde Nutzer auf deiner Seite.

---

Fahrplan: Wo fange ich an? 6 Schritte zum Einstieg

Wenn du eine bestehende WordPress-Seite barrierefrei machen willst, fühlst du dich anfangs vermutlich erschlagen. Keine Panik. So gelingt dir der Einstieg in das Thema:

Schritt 1: Zielsetzung

Bevor du irgendetwas an deiner Website änderst, definiere dein Ziel. Musst du die strengen Anforderungen des BFSG erfüllen, weil du beispielsweise einen WooCommerce-Shop oder eine Buchungsplattform für Endkunden (B2C) betreibst? Oder bist du als reines B2B-Unternehmen gesetzlich ausgenommen und gehst das Projekt an, weil Inklusion für dich ein Qualitätsmerkmal ist?

Kläre diesen Punkt zuerst, um das nötige Budget und die Tiefe der Maßnahmen richtig einzuschätzen. Wenn du rechtlich betroffen bist, ist eine echte WCAG-Konformität dein Ziel.

Schritt 2: Status-Quo-Check

Jetzt geht es an die Bestandsaufnahme. Jage deine Startseite und deine wichtigsten Unterseiten durch kostenlose Tools wie Google Lighthouse (direkt in den Chrome DevTools) oder die WAVE-Extension. So kannst du zum Beispiel herausfinden, ob dein grauer Text auf hellgrauem Hintergrund die Kontrast-Grenzwerte unterschreitet oder ob Links ohne erkennbaren Namen existieren.

Schritt 3: Theme-Analyse

Prüfe die technische Basis deiner Website. Ist dein aktuelles Theme modern und bringt semantisches HTML mit? Oder nutzt du ein stark veraltetes Custom-Theme, das aus unzähligen, unstrukturierten <div>-Containern besteht?

Beispiel: Wenn dein altes Theme die grundlegenden HTML5-Landmark-Rollen (<header>, <main>, <nav>) nicht unterstützt, verschlingt das manuelle Nachrüsten häufig viele Ressourcen. Hier ist ein kompletter Wechsel auf ein modernes FSE-Block-Theme (bspw. das kostenlose Standard-Theme Twenty Twenty-Five) meist der wirtschaftlichere Weg.

Schritt 4: Low-Hanging Fruits

Nun geht es an die Umsetzung. Fixe zuerst die Dinge, die du als Redakteur selbst im WordPress-Backend erledigen kannst.

• Strukturiere die Überschriften-Hierarchie (H1 bis H6) in deinen Beiträgen logisch durch.
• Trage fehlende ALT-Texte (Bildbeschreibungen) in der Mediathek nach.
• Nutze die globalen Stile deines Themes oder Page Builders, um die Kontraste von Fließtexten und Buttons anzuheben. Wenn dir dein Test-Tool aus Schritt 2 ausgibt, dass dein Menü-Text zu blass ist, kannst du die Farbe im WordPress-Editor anpassen, bis das Kontrastverhältnis stimmt.

Das kostet kein Entwickler-Budget, bringt dich aber deutlich näher ans Ziel.

Schritt 5: Tiefergehende Code-Optimierungen

Hier benötigen die meisten Website-Betreiber externe Hilfe. Es geht um die komplexe Bedienbarkeit und Semantik.

Beispiel: Kann ein blinder Nutzer das Dropdown-Menü deiner Website öffnen, ohne eine Maus zu benutzen? Funktioniert die Navigation reibungslos, wenn du dich nur mit der Tabulator-Taste durch die Seite bewegst? Hier müssen Entwickler ran, um Fokus-Ringe via CSS zu setzen oder versteckte ARIA-Labels im Code zu verankern.

Schritt 6: Assistenz-Tools & Overlays

Steht das Fundament im Code, kannst du den Komfort für deine Nutzer maximieren. Hier kommen Lösungen wie Accessibility-Widgets ins Spiel. Solche Overlays bieten dem Besucher eine visuelle Oberfläche, über die er Kontraste verstärken, Schriften vergrößern oder Animationen stoppen kann. Sie sind kein Ersatz für die Code-Arbeit aus Schritt 5, aber eine nützliche Ergänzung, um die Usability individuell anpassbar zu machen.

---

WordPress-Themes & Page Builder

Das Theme ist das statische und dynamische Fundament deiner Barrierefreiheit. Wenn das Theme unsauberen Code ausgibt, kannst du im WordPress-Editor noch so viele ALT-Texte pflegen – die Seite wird den barrierefreien Härtetest nicht bestehen.

Das Problem mit klassischen Page Buildern: DOM-Bloat

Um komplexe visuelle Layouts im Drag-and-Drop-Verfahren zu ermöglichen, verschachteln viele bekannte Page Builder (wie Elementor oder Divi) unzählige bedeutungslose <div>-Container ineinander.

Aus Performance- und SEO-Sicht treibt das die DOM-Größe (Document Object Model) unnötig in die Höhe. Für einen Screenreader ist ein solcher Code-Wust ein Albtraum: Ein <div> besitzt keinerlei semantische Bedeutung. Die Software weiß nicht, wo das Layout aufhört und der eigentliche Inhalt anfängt. Zudem patzen viele ältere Page-Builder-Module bei der nativen Tastaturbedienbarkeit von komplexen Elementen wie Slidern, Akkordeons oder Pop-ups.

Die Lösung: Moderne Block-Themes (Full Site Editing)

Wenn du ein neues Kundenprojekt aufsetzt oder einen Relaunch planst, solltest du auf FSE-Themes (Full Site Editing) setzen, die nativ auf dem WordPress-Block-Editor (Gutenberg) aufbauen. Moderne FSE-Themes wie Ollie oder das Standard-Theme Twenty Twenty-Five sind von Haus aus extrem nah an den offiziellen W3C-Richtlinien (WCAG) programmiert.

Auch andere Themes wie Kadence, Astra oder Blocksy bringen von Haus aus viele Funktionen für eine verbesserte Barrierefreiheit mit.

Solche modernen Themes verzichten auf Code-Balast, nutzen schlankes, semantisches HTML5 und garantieren, dass Kernfunktionen wie die Hauptnavigation direkt mit der Tastatur erreichbar und bedienbar sind – ohne dass du dafür fehleranfällige JavaScript-Workarounds schreiben musst./

---

Überschriften & Struktur

Ein Screenreader liest eine Website nicht wie das menschliche Auge, das Muster und Schriftgrößen scannt. Er arbeitet mit einem linearen Framework. Blinde Nutzer lassen sich oft als Erstes alle Überschriften einer Seite auflisten, um wie in einem Buchverzeichnis dorthin zu springen, wo die gewünschte Information sitzt.

Der <title>-Tag: Das eralste Orientierungsmerkmal

Bevor der Content geladen wird, liest der Screenreader den <title>-Tag im Header der Seite vor. Er ist das wichtigste erste Signal für den Nutzer, um zu wissen, auf welcher Unterseite er sich überhaupt befindet. Achte darauf, dass deine SEO-Plugins (wie Yoast oder Rank Math) so konfiguriert sind, dass sie eindeutige, sprechende Titel generieren (z. B. „Warenkorb – Onlineshop“ statt nur „Shop“).

Die logische Überschriften-Hierarchie

Die H-Struktur (H1 bis H6) wird gerne mal zweckentfremdet, um schnell ein optisches Styling (z. B. „Mach den Text mal etwas kleiner, nimm eine H3“) zu erzwingen. Für die Barrierefreiheit ist das Gift.

• H1: Gibt es genau einmal pro Seite (der Haupttitel).
• H2 bis H6: Müssen chronologisch geschachtelt sein. Auf eine H2 folgt eine H3, nicht eine H4. Wenn das Design eine eine kleinere Schrift vorsieht, wird dies über CSS gelöst, nicht über die HTML-Struktur.

HTML5-Landmark-Rollen verankern

Damit assistierende Technologien die Architektur der WordPress-Seite verstehen, müssen die Kernbereiche im Theme-Template in die entsprechenden HTML5-Tags gehüllt sein. Stelle sicher, dass dein Theme diese Landmarks nutzt:

<header> <!-- Hier liegt das Logo und die Hauptnavigation --> </header>
<nav aria-label="Hauptmenü"> <!-- Die Navigationslinks --> </nav>
<main id="content"> <!-- Der einzigartige Inhalt dieser spezifischen Seite --> </main>
<footer> <!-- Datenschutz, Impressum etc.--> </footer>

---

Tastaturnavigation & Menüs

Eine der wichtigsten Anforderungen des Barrierefreiheitsstärkungsgesetzes (BFSG) ist die vollständige Bedienbarkeit ohne Maus. Das betrifft Menschen mit Sehbehinderungen ebenso wie Nutzer mit motorischen Einschränkungen.

Der „Tab“-Test für deine Website

Lege deine Maus zur Seite und versuche, deine WordPress-Website ausschließlich mit der Tabulator-Taste (vorwärts) und Shift + Tab (rückwärts) zu navigieren. Kannst du jeden Link aktivieren? Kommst du in das Dropdown-Menü hinein? Wenn nicht, besteht Handlungsbedarf.

Der Fokus-Ring (:focus-visible)

Wenn du dich mit der Tab-Taste durch eine Website bewegst, zeigt ein visueller Rahmen (der Fokus-Ring) an, wo du dich gerade befindest. Viele Webdesigner löschen diesen Rahmen aus ästhetischen Gründen im CSS via outline: none. Das ist ein Fehler.

Nutze stattdessen das :focus-visible-Pseudo-Element, um den Fokus-Ring für Tastaturnutzer extrem gut sichtbar zu machen, während er für klassische Maus-Klicker unsichtbar bleibt. So sieht das im CSS aus:

/* Sichtbarer Fokus nur für Tastaturnutzer */
button:focus-visible, 
a:focus-visible {
    outline: 3px solid #ff5a5f; /* Auffällige Farbe passend zur Brand */
    outline-offset: 2px;
}

Skip-Links (Sprungmarken) hinterlegen

Ein Tastaturnutzer muss sich ohne Hilfsmittel bei jedem Seitenwechsel mühsam durch alle Menüpunkte tabben, bevor er zum eigentlichen Inhalt gelangt. Hier helfen Skip-Links. Das sind unsichtbare Links ganz oben im DOM, die erst beim ersten Drücken der Tab-Taste sichtbar werden und direkt zum <main>-Inhalt springen.

HTML-Beispiel:

<!-- Direkt nach dem öffnenden <body> Tag platzieren -->
<a href="#content" class="skip-link">Zum Hauptinhalt springen</a>

Damit das funktioniert, muss das Haupt-Inhaltselement der Seite (meistens der <main>-Tag oder ein umschließender <div>-Container) die passende ID: <main id=“content“>.

Mit der CSS-class skip-link wird sichergestellt, dass der Link visuell unsichtbar ist, sich aber einblendet, sobald ein Tastaturnutzer die Tab-Taste drückt (also den Fokus darauf setzt). Sehende Maus-Nutzer merken von dem Link also gar nichts, während er für Screenreader und Keyboard-User sofort anspringt. Einige moderne Themes nutzen die skip-link class bereits. Falls nicht, musst du das CSS in deine style.css einfügen:

/* Skip-Link standardmäßig visuell aus dem Bildschirm schieben */
.skip-link {
    position: absolute;
    top: -1000px;
    left: 0;
    background: #000000; /* Eure Brand-Farbe */
    color: #ffffff;
    padding: 15px;
    z-index: 99999; /* Muss über dem Header liegen */
    transition: top 0.2s ease;
}

/* Den Link sofort einblenden, sobald er per Tastatur (Tab) fokussiert wird */
.skip-link:focus {
    top: 0;
}

Keyboard Traps in mobilen Menüs verhindern

Ein häufiger Fehler bei responsiven WordPress-Themes: Der Nutzer öffnet das mobile Burger-Menü per Tastatur, der Fokus bleibt aber im Hintergrund auf der eigentlichen Seite gefangen. Oder schlimmer: Er tabbt in das Menü hinein, kommt aber über die Tastatur nicht mehr heraus.

Wenn du ein modales Fenster oder ein mobiles Overlay-Menü barrierefrei umsetzen willst, musst du drei technische Ebenen im Code absichern.

1. Das HTML-Grundgerüst mit ARIA-Attributen

Damit der Trick mit der Hintergrund-Sperre funktioniert, dürfen das Menü-Overlay und der eigentliche Inhalt der Website nicht ineinander verschachtelt sein. Sie müssen als eigenständige Blöcke nebeneinander (als sogenannte Geschwister-Elemente) existieren.

In einem klassischen WordPress-Theme sieht die bereinigte Struktur in der Praxis so aus:

<!-- SITE WRAPPER (In WordPress meistens <div id="page">) -->
<div id="page-site-wrapper">
    
    <header id="masthead" class="site-header">
        <!-- Hier lebt dein normales Logo und die Desktop-Navigation -->
        
        <!-- TRIGGER-BUTTON (Muss in den Header) -->
        <button id="menu-trigger-btn" aria-haspopup="true" aria-expanded="false" aria-controls="mobile-nav-container">
            <span class="screen-reader-text">Menü öffnen</span>
            <!-- Dein Hamburger-Icon (z. B. als SVG) -->
        </button>
    </header>

    <main id="primary" class="site-main">
        <!-- Dein eigentlicher Seiteninhalt / Blogposts / WooCommerce-Shop -->
    </main>

    <footer id="colophon" class="site-footer">
        <!-- Dein Footer -->
    </footer>

</div> <!-- Ende von #page-site-wrapper -->


<!-- MOBILE MENÜ-OVERLAY (Muss AUSSERHALB des Wrappers liegen!) -->
<div id="mobile-nav-container" role="dialog" aria-modal="true" class="mobile-menu-overlay">
    <nav aria-label="Mobile Navigation">
        <ul>
            <li><a href="/">Startseite</a></li>
            <li><a href="/shop">Shop</a></li>
            <li><a href="/kontakt">Kontakt</a></li>
        </ul>
    </nav>
    <!-- 4. DER SCHLIESSEN-BUTTON -->
    <button id="menu-close-btn">Menü schließen</button>
</div>

Der Haupt-Wrapper (#page-site-wrapper) umschließt deine komplette Website – vom Header über den Inhalt bis zum Footer. Dieses Element existiert in fast jedem Theme bereits. Meistens ist es das <div id=“page“> ganz oben in der header.php, das erst in der footer.php wieder geschlossen wird. Du musst es nicht neu erstellen, sondern lediglich seine ID im JavaScript ansprechen. Wenn das Menü öffnet, verpasst das Skript diesem Wrapper das Attribut inert. Dadurch wird die komplette restliche Website für Tastaturnutzer und Screenreader eingefroren.

Der Trigger-Button (#menu-trigger-btn) ist das klassische Hamburger-Icon, das das Menü öffnet.Das ARIA-Attribut aria-haspopup=“true“ sagt dem Screenreader, dass dieser Button ein interaktives Fenster öffnet. aria-expanded=“false“ wechselt per JavaScript auf true, sobald das Menü offen ist, damit blinde Nutzer wissen, ob das Menü gerade aktiv ist. aria-controls verweist exakt auf die ID des folgenden Menü-Containers.

Der Menü-Container (#mobile-nav-container) ist das eigentliche mobile Menü, das sich als Overlay über die Seite legt. Dieses Element darf nicht innerhalb des Haupt-Wrappers liegen. Wenn du dem Haupt-Wrapper nämlich das inert-Attribut (die Sperre) verpasst, würde sich das Menü sonst selbst einfrieren und wäre unbedienbar. Platziere diesen Container in deiner header.php also ganz unten, außerhalb des Wrappers, oder lade ihn direkt über die footer.php kurz vor dem schließenden -Tag.

Die ARIA-Attribute: role=“dialog“ und aria-modal=“true“ signalisieren assistiven Technologien, dass alle Befehle ab jetzt nur noch innerhalb dieses Fensters stattfinden dürfen.

Der Schließen-Button (#menu-close-btn) gibt dem Nutzer eine klare, per Tastatur ansteuerbare Möglichkeit, das Menü wieder zu beenden. Sobald der Nutzer auf den Hamburger-Button drückt, springt der unsichtbare Fokus der Tastatur per JavaScript sofort auf diesen Schließen-Button. Drückt der Nutzer im Menü die Escape-Taste oder klickt auf diesen Button, schließt sich das Menü und der Fokus springt sauber zurück zum Hamburger-Icon.

2. Das JavaScript für Fokus-Management und Hintergrund-Sperre

Um die eine Tastaturfalle zu verhindern, reicht HTML allein nicht aus. Wir benötigen ein skriptbasiertes Fokus-Management, das drei Dinge leistet: Den Statuswechsel der ARIA-Attribute steuern, den Hintergrund über das HTML-Attribut inert für Klicks und Tabs blockieren und den Fokus innerhalb des Menüs im Kreis leiten.

Füge dieses Skript zu den Theme-Dateien deiner WordPress-Seite hinzu:

document.addEventListener('DOMContentLoaded', () => {
    const triggerBtn = document.getElementById('menu-trigger-btn');
    const closeBtn = document.getElementById('menu-close-btn');
    const menuContainer = document.getElementById('mobile-nav-container');
    // Wir greifen uns hier direkt die Standard-WordPress-ID "page"
    const siteWrapper = document.getElementById('page');

    // Alle potenziell fokussierbaren Elemente innerhalb des Menüs sammeln
    const focusableElementsString = 'button, [href], input, select, textarea, [tabindex]:not([-1])';
    
    function openMenu() {
        triggerBtn.setAttribute('aria-expanded', 'true');
        menuContainer.classList.add('is-active'); // Aktiviert dein visuelles CSS-Overlay
        
        // Den gesamten WordPress-Hintergrund (#page) für Tastatur und Maus sperren
        if (siteWrapper) siteWrapper.setAttribute('inert', '');
        
        // Fokus sofort auf das erste Element im Menü setzen (den Schließen-Button)
        if (closeBtn) closeBtn.focus();
        
        // Event-Listener für die Tastatur-Navigation aktivieren
        menuContainer.addEventListener('keydown', trapFocus);
    }

    function closeMenu() {
        triggerBtn.setAttribute('aria-expanded', 'false');
        menuContainer.classList.remove('is-active');
        
        // Den Website-Hintergrund wieder freigeben
        if (siteWrapper) siteWrapper.removeAttribute('inert');
        
        // Fokus zwingend zurück an den ursprünglichen Hamburger-Button übergeben
        triggerBtn.focus();
        
        // Event-Listener wieder entfernen
        menuContainer.removeEventListener('keydown', trapFocus);
    }

    function trapFocus(e) {
        // Schließen des Menüs über die Escape-Taste ermöglichen
        if (e.key === 'Escape') {
            closeMenu();
            return;
        }

        // Wir reagieren nur auf die Tabulator-Taste
        if (e.key !== 'Tab') return;

        const focusableElements = menuContainer.querySelectorAll(focusableElementsString);
        if (focusableElements.length === 0) return;
        
        const firstFocusableElement = focusableElements[0];
        const lastFocusableElement = focusableElements[focusableElements.length - 1];

        if (e.shiftKey) { 
            // Wenn Shift + Tab gedrückt wird und wir am Anfang sind -> zum Ende springen
            if (document.activeElement === firstFocusableElement) {
                lastFocusableElement.focus();
                e.preventDefault();
            }
        } else { 
            // Wenn Tab gedrückt wird und wir am Ende sind -> zum Anfang springen
            if (document.activeElement === lastFocusableElement) {
                firstFocusableElement.focus();
                e.preventDefault();
            }
        }
    }

    // Klick-Events für die Buttons registrieren
    if (triggerBtn && closeBtn && menuContainer) {
        triggerBtn.addEventListener('click', openMenu);
        closeBtn.addEventListener('click', closeMenu);
    }
});

Wo wird das in WordPress eingebunden?

Da klassische WordPress-Themes hierarchisch in verschiedene Dateien aufgeteilt sind, musst du den Code strategisch platzieren:

• Der Trigger-Button (#menu-trigger-btn): Gehört direkt in die header.php deines Child-Themes, exakt an die Stelle innerhalb deines <header>-Tags, wo das mobile Logo und die Navigation sitzen.
• Der Menü-Container (#mobile-nav-container): Da dieses Element außerhalb des Haupt-Wrappers (<div id=“page“>) liegen muss, platzierst du den gesamten HTML-Block für das Overlay am besten ganz unten in der footer.php – und zwar direkt nach dem schließenden </div>, kurz vor dem <?php wp_footer(); ?>-Tag.
• Das JavaScript: Speichere das Skript als separate Datei (z. B. accessibility-menu.js) im Ordner /js/ deines Child-Themes ab. Binde es anschließend über die functions.php mittels wp_enqueue_script ein, damit es performant im Footer geladen wird.

Solltest du ein modernes Block-Theme (Full Site Editing) nutzen, übernimmt der native Navigations-Block von WordPress diese komplexe Steuerung bereits vollautomatisch für dich im Hintergrund. Baut ihr in der Agentur jedoch eigene, hochgradig individuelle Overlay-Menüs über Page Builder oder Custom Blocks, ist dieses Skript die sicherste Methode, um die gesetzlichen Anforderungen des BFSG handwerklich zu erfüllen.

---

Formulare & interaktive Elemente

Formulare (Kontaktformulare, Checkout-Prozesse, Newsletter-Anmeldungen) sind eine der größten Barrieren im Web.

Eindeutige <label>-Tags statt Platzhalter

Einige WordPress-Formular-Plugins blenden die Beschriftung oberhalb des Feldes aus und nutzen nur das placeholder-Attribut innerhalb des Feldes, um ein „cleanes“ Design zu erzeugen. Das ist aus zwei Gründen nicht barrierefrei:

1. Sobald der Nutzer anfängt zu tippen, verschwindet der Platzhalter. Menschen mit kognitiven Einschränkungen vergessen dann oft, was sie eigentlich eingeben sollten.
2. Viele Screenreader lesen Platzhalter nicht zuverlässig vor.

Jedes Eingabefeld benötigt ein echtes, programmatisch verknüpftes <label>:

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

Barrierefreie Fehlermeldungen

Wenn ein Nutzer ein Pflichtfeld vergisst oder eine falsche Telefonnummer eingibt, darf die Fehlermeldung nicht nur über die Farbe Rot signalisiert werden (Stichwort: Rot-Grün-Schwäche).

Die Fehlermeldung muss als Text formuliert sein, ein Icon enthalten und programmatisch über das Attribut aria-describedby mit dem Eingabefeld verknüpft werden, damit der Screenreader den Fehler beim Hineintabben sofort vorliest:

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

---

Farben und Kontraste

Barrierefreies Design bedeutet nicht, dass deine WordPress-Website ab jetzt langweilig oder schwarz-weiß sein muss. Es bedeutet, dass visuelle Informationen so aufbereitet sind, dass sie auch bei Sehschwächen, Farbblindheit oder schlichtweg bei direkter Sonneneinstrahlung auf dem Smartphone lesbar bleiben.

Das mathematische Kontrastverhältnis (WCAG-Vorgaben)

Die Web Content Accessibility Guidelines (WCAG 2.2) machen präzise mathematische Vorgaben für das Kontrastverhältnis zwischen Textfarbe (Vordergrund) und Hintergrundfarbe.

• Standard-Fließtext (AA-Standard): Erfordert ein Kontrastverhältnis von mindestens 4,5:1.
• Großer Text (ab 24px oder 19px fett): Erfordert ein Verhältnis von mindestens 3:1.
• Grafische Bedienelemente (z. B. Button-Rahmen, Icons): Müssen ebenfalls einen Kontrast von 3:1 zum Hintergrund aufweisen.

Wie kann ich Kontraste messen?

Du musst diese Werte nicht schätzen. Es gibt Tools, die diese Arbeit für dich erledigen:

• Colour Contrast Analyser (CCA) von Vispero: Eine kostenlose Desktop-App für Windows und Mac. Mit einer digitalen Pipette (Eyedropper) klickst du die Textfarbe und Hintergrundfarbe an und hast sofort das Ergebnis. Das Tool wird auch im offiziellen BIK BITV-Test eingesetzt.
• WebAIM Contrast Checker: Ein minimalistisches und schnelles Online-Tool. Neben dem reinen Pass/Fail-Ergebnis für AA und AAA bietet es einen Schieberegler (Lightness slider). Wenn deine Farbkombination knapp durchfällt, kannst du die Farbe direkt im Tool so lange minimal abdunkeln oder aufhellen, bis der Kontrast stimmt, und kopierst dir dann den neuen Hex-Code heraus.
• whocanuse.com: Ein Web-Tool, das anhand von zwei eingegebenen Farben prozentual und visuell aufschlüsselt, wie Menschen mit unterschiedlichen Sehschwächen diese Kombination sehen. Es simuliert live auf dem Bildschirm, wie dein Text bspw. für jemanden mit einer Rot-Grün-Schwäche, mit Low Vision oder mit Grauem Star aussieht. Perfekt, um Kunden im Meeting zu zeigen, warum der Kontrast angepasst werden muss.
• Browser-Erweiterungen: Für Chrome und Firefox gibt es einige Erweiterungen, die dir die Farbkontraste deiner Website anzeigen. Nicht alle funktionieren einwandfrei. Getestet haben wir WCAG Contrast checker (Link zum Chrome-Addon, Link zum Firefox-Addon) und Color Contrast Checker (Link zum Chrome-Addon)
• Developer-Tools: Chrome und Firefox bieten über die Developer-Tools bzw. den Inspektor ebenfalls die Möglichkeit, Farbkontraste zu messen.

Achte darauf, dass die Farbkontraste auch im :hover- und :focus-Zustand stabil bleiben. Es nützt nichts, wenn ein Menüpunkt im Ruhezustand perfekt lesbar ist, sich beim Drüberfahren mit der Maus aber in ein kontrastarmes Hellgrau verwandelt.

---

Bilder & Medien

Gutenberg vs. Classic Editor (TinyMCE)

Der moderne Gutenberg-Editor verwaltet Medien-Metadaten wesentlich sauberer als der alte Classic Editor. Wenn du ein Bild im Block-Editor einfügst, greift WordPress automatisch auf die in der Mediathek hinterlegten ALT-Texte zurück und bettet sie semantisch korrekt ein.

Wann braucht ein Bild einen ALT-Text?

Ein ALT-Text ist kein Ort für Keyword-Stuffing, sondern soll die Funktion oder den Inhalt des Bildes beschreiben, z.B.“Säulendiagramm zeigt die Steigerung von Verkäufen im Jahr 2026 um 10 Prozent“. Das Ziel ist, dass der Mensch mit Sehbehinderung den Inhalt des Bildes trotzdem wahrnehmen kann.

Etwas kniffliger ist es bei rein dekorativen Bildern, etwa Stock-Fotos, die rein als Füllmaterial dienen. Hat ein Bild keinen direkten Textbezug, kann das alt-Attribut leer bleiben (alt=””). Es muss aber trotzdem vorhanden sein, darf also nicht einfach weggelassen werden. Dies signalisiert dem Screenreader „ignorieren, Bild ist nur Deko“. 

Allerdings lässt sich auch argumentieren, dass jedes Bild irgendeinen Zweck erfüllt – warum steht es sonst auf der Seite? Um blinden Menschen die gleiche Erfahrung wie sehenden Menschen zu bieten, müsste das alt-Attribut also ausgefüllt sein. Was hier der richtige Weg ist, ist Gefühlssache – eine 100% richtige Antwort gibt es nicht. Wir empfehlen, die Alt-Texte konsequent überall auszufüllen.

Video und Audio

Eingebettete Videos (z. B. via YouTube oder Vimeo) benötigen zwingend Untertitel (für Gehörlose) und idealerweise eine Audiodeskription (für Blinde). Für reine Audio-Inhalte (wie Podcasts im Blog) musst du ein vollständiges Text-Transkript direkt unter dem Player oder als Link zur Verfügung stellen.

---

Barrierefreiheit-PlugIns & Widgets

Accessibility PlugIns und externe Widgets können die technische Umsetzung der Barrierefreiheit beschleunigen. Sie greifen entweder direkt in den Quelltext ein, unterstützen die Redaktion im Backend oder verändern die visuelle Darstellung im Browser. Durch den Einzug von Large Language Models (LLMs) und KI-Schnittstellen ergeben sich neue Möglichkeiten – voll automatisierte Barrierefreiheits-Lösungen gibt es aber nach wie vor nicht.

Was Plugins vollautomatisch lösen können

Diese Aufgaben betreffen standardisierte Protokolle und technische Attribute, die im Quellcode verankert sein müssen:

• Fehlende Code-Attribute injizieren: Wenn das genutzte Theme das HTML-Sprachattribut vergisst, können Plugins dieses global im Header nachrüsten (z. B. <html lang=“de“>).
• Technische Skripte bereitstellen: Sie können die notwendigen HTML- und CSS-Strukturen für funktionale Sprungmarken (Skip-Links) am Anfang des DOM-Baums einfügen.
• Redundante Attribute entfernen: Automatisiertes Löschen von störenden, für Screenreader oft redundanten oder veralteten title-Attributen aus Navigationslinks oder Bild-Tags.
• Standard-CSS-Deklarationen erzwingen: Überschreiben von Theme-Styles, um einen globalen Fokus-Ring (:focus-visible) für die Tastaturnavigation sichtbar zu machen.

Wobei Plugins und KI-Schnittstellen assistieren können

Hier hat sich der Leistungsumfang durch KI-Integrationen drastisch verändert. Werkzeuge können diese Prozesse teilautomatisieren, erfordern jedoch meist eine menschliche Endkontrolle:

• Einfache und barrierefreie Sprache: Plugins binden über APIs spezialisierte Sprachmodelle (z. B. von OpenAI) ein. Diese können komplexe Fachtexte oder Schachtelsätze direkt im WordPress-Editor per Knopfdruck in „Einfache Sprache“ oder „Leichte Sprache“ übersetzen.
• ALT-Texte für Bilder: KI-Erweiterungen nutzen Bilderkennungs-Algorithmen, um beim Upload automatisch WCAG-konforme Beschreibungen zu generieren. Die Einschränkung: Der spezifische redaktionelle Kontext (warum genau dieses Bild im Artikel steht) muss vom Redakteur überprüft werden.
• Untertitel für Medien: Integrierte Transkriptions-Tools können Audio- und Videodateien automatisiert analysieren und synchrone Untertitel-Dateien (VTT/SRT) erzeugen. Auch diese müssen aber manuell überprüft werden.
• Visuelle Anpassungen auf Nutzerseite: Frontend-Widgets bieten dem Besucher Steuerungselemente, um Kontraste, Farben und Schriftgrößen temporär zu verändern. Dies hilft, individuelle Bedürfnisse (z. B. optimierte Schriftschnitte für Menschen mit Legasthenie) flexibel zu bedienen, entbindet den Betreiber jedoch nicht von einem kontrastreichen Standard-Design.

Was Plugins nicht leisten können

Strukturelle Logik, ergonomisches Design und komplexe Code-Architekturen lassen sich nicht per Plugin reparieren:

• Chaotische Informationsarchitektur und Menüs: Wenn die Navigation unlogisch verschachtelt ist, kann kein Plugin die Benutzerführung sinnvoll restrukturieren.
• Schlecht konzipierte Formulare: Layout-Fehler, unklare Benennungen von Feldern oder verwirrende logische Abläufe in Formularen erfordern ein manuelles Redesign der Formular-Logik.
• Strukturelle Textgliederung: Ein Plugin kann keine chaotisch gewürfelten Überschriften (z. B. eine H3 direkt nach einer H1) im Frontend reparieren, ohne das visuelle Layout des Themes zu beschädigen. Das logische Strukturieren bleibt eine redaktionelle Pflicht bei der Inhaltspflege.
• Defektes responsives Design: Wenn ein Theme auf mobilen Geräten Elemente abschneidet oder Buttons unbedienbar macht, kann das nur im CSS/Theme-Code behoben werden.
• Das Design-Fundament ersetzen: Kontraste und Lesbarkeit sollten direkt im Core-Design (Theme/CI) barrierefrei sein. Technische Overlays dürfen nicht als Alibi genutzt werden, um ein fehlerhaftes Standard-Design dauerhaft im Quellcode zu ignorieren.

Empfehlungen zu PlugIns und Tools nach Einsatzzweck

Technische Code-Fixer (Hintergrund-Optimierung)

Diese Werkzeuge greifen direkt in die HTML-Ausgabe des Frontends ein, um strukturelle Mängel des installierten Themes auszugleichen.

• WP Accessibility
  • Funktionsumfang: Fügt funktionale Skip-Links ein und ermöglicht die Steuerung der Mindest-Sichtbarkeit des Fokus-Rings. Es ergänzt fehlende Sprach-Tags im HTML-Dokument und entfernt standardisierte title-Attribute aus Bildern und Links. Zudem bietet es eine Option, um Text-Links zu zwingen, Unterstreichungen anzuzeigen.
• Ally – Web Accessibility & Usability
  • Funktionsumfang: Setzt den Fokus primär auf schnelle CSS-Korrekturen im Stylesheet der Website, wie das Erzwingen von standardisierten Outline-Rahmen für Tastaturnutzer. Es bringt zusätzlich ein optionales, minimalistisches Frontend-Menü mit, über das Nutzer Kontraste und Schriftgrößen rudimentär steuern können.

Backend-Auditoren & KI-Assistenten (Qualitätskontrolle)

Diese Tools dienen der internen Qualitätssicherung im WordPress-Dashboard während der Erstellung von Inhalten.

• Accessibility Checker (Equalize Digital)
  • Funktionsumfang: Das Plugin integriert sich in den Block-Editor. Es scannt den Beitrag oder die Seite vor der Veröffentlichung gegen die WCAG-Standards. Unterhalb des Editors wird ein Bericht ausgegeben, der spezifische Fehler wie fehlerhafte Überschriften-Hierarchien, unzureichende Farbkontraste im Text oder leere Linktexte („Mehr erfahren“) markiert.
• Easy Language (laolaweb)
  • Funktionsumfang: Ermöglicht die Bereitstellung von Inhalten in Einfacher oder Leichter Sprache. Das Plugin verknüpft den WordPress-Editor mit KI-Diensten (OpenAI, SUMM AI oder capito), um bestehende Texte automatisiert zu vereinfachen. Redakteure können das Ergebnis manuell nachbearbeiten. Die Ausgabe erfolgt über einen flexiblen Sprachwechsler im Frontend.

Frontend-Widgets & Overlays (Benutzer-Interfaces)

Diese JavaScript-basierten Oberflächen legen sich als visuelle Ebene über die fertig gerenderte Website und erlauben dem Endnutzer individuelle Darstellungsänderungen.

• iubenda Accessibility Widget (bieten wir bei Raidboxes als optionale Erweiterung an)
  • Funktionsumfang: Es stellt dem Seitenbesucher ein Interface zur Verfügung, um das visuelle Erscheinungsbild anzupassen. Dazu gehören das stufenlose Skalieren von Texten, das Umschalten auf kontrastreiche oder monochrome Farbräume sowie das Ändern der Schriftart (z. B. für Menschen mit Legasthenie). Zudem können Animationen, CSS-Übergänge und automatische Slider über das Menü global angehalten werden, um die kognitive Belastung zu reduzieren.
• UserWay Accessibility Widget
  • Funktionsumfang: Arbeitet als cloudbasiertes JavaScript-Overlay mit einem ähnlichen Funktionsumfang. Es klinkt sich über ein Icon in die Benutzeroberfläche ein und bietet dem Besucher Werkzeuge zur Anpassung von Kontrasten, Textausrichtungen, Mauszeiger-Größen und Tastatur-Navigationshilfen direkt im Browserfenster.

Sind PlugIns für Barrierfreiheit sinnvoll?

Overlays und Plugins können nützliche Werkzeuge sein, um die Bedienbarkeit (Usability) für den Endnutzer zu erhöhen, KI-gestützte Redaktionshilfe zu erhalten oder administrative Standardaufgaben im Code abzufangen.

Sie entbinden Webdesigner und Entwickler jedoch nicht von der Pflicht, die Kernarchitektur der WordPress-Website – insbesondere die Themes, die Formulare und die Tastaturbedienbarkeit des Hauptmenüs – von Grund auf sauber zu programmieren. Ein Widget optimiert die Interaktion auf einer funktionierenden Basis, kann aber ein technisch defektes Fundament nicht ersetzen.

---

Digitale Barrierefreiheit messen: So überprüfst du deine Website

Ein fehlerfreier Code im Editor garantiert noch keine barrierefreie Nutzung in der Realität. Ein valides Testing-Protokoll setzt sich daher aus drei aufeinander aufbauenden Phasen zusammen: dem automatisierten Scan, den manuellen Do-it-yourself-Checks und dem abschließenden Härtetest mit assistiven Technologien.

Schritt 1: Automatische Scans

Automatisierte Tools decken mathematisch messbare Fehler (wie Farbkontraste) und syntaktische Mängel im HTML-Code innerhalb weniger Sekunden auf. Sie sind der effizienteste Einstieg für jedes Audit.

• Google Lighthouse (Chrome DevTools): Direkt im Chrome-Browser integriert (F12 -> Reiter „Lighthouse“). Der Accessibility-Score gibt eine erste Orientierung, erfasst jedoch nur die Oberfläche.
• WAVE Extension (WebAIM): Blendet Fehler-Icons direkt in das gerenderte Frontend ein. Sehr gut geeignet, um fehlende ALT-Texte oder fehlerhafte Überschriften-Hierarchien visuell zu lokalisieren.
• axe DevTools (Deque Systems): Die Engine hinter axe prüft präziser als Lighthouse und liefert detaillierte Entwickler-Anweisungen zur Behebung von ARIA-Fehlern.
• Siteimprove Accessibility Checker: Eine Browser-Erweiterung, die Fehler direkt nach den WCAG-Konformitätsstufen (A, AA, AAA) sortiert und gezielte Handlungsempfehlungen für Agenturen ausgibt.

Schritt 2: Manuelle Do-it-yourself Schnelltests

Nachdem die offensichtlichen Code-Fehler behoben sind, folgen vier praxisnahe Funktionstests, die kein tiefes technisches Vorwissen erfordern, aber typische Barrieren im Alltag aufdecken.

Der 200%-Zoom-Test

Menschen mit Sehschwäche nutzen den Browser-Zoom, um Texte lesbar zu machen.

• Der Test: Drücke Strg + (oder Cmd +), bis der Zoom im Browser 200% (für den AA-Standard) oder 400% (für den mobilen Reflow-Standard) erreicht.
• Worauf zu achten ist: Der Text darf sich nicht mit anderen Elementen oder Bildern überlagern. Es darf keine horizontale Scrollleiste am unteren Bildschirmrand entstehen – die Website muss stattdessen flüssig in ein einspaltiges (quasi mobiles) Layout umbrechen, ohne dass Inhalte abgeschnitten werden.

Tastatursteuerung

Die mauslose Bedienung ist eine Kernanforderung.

• Der Test: Navigiere mit der Tab-Taste ohne Maus-Einsatz durch die gesamte Seite.
• Worauf zu achten ist: Verliere ich den Fokus-Ring zwischendurch aus den Augen? Komme ich in das Cookie-Banner oder das mobile Menü hinein und kann es mit Enter oder Escape auch wieder schließen? Wenn der Fokus im Hintergrund weiterspringt, während das Menü offen ist, liegt eine Tastaturfalle vor.

KI-gestützte Prüfung auf verständliche Sprache

Die Verständlichkeit von Texten ist Teil der kognitiven Barrierefreiheit (WCAG-Kriterium 3.1). Statt teurer Gutachten können etablierte Sprachmodelle (LLMs) für eine erste Textanalyse genutzt werden.

• Der Test: Kopiere wichtige Kerntexte (z. B. aus dem Checkout oder von Service-Seiten) und jage sie mit folgendem Prompt durch ein LLM: „Analysiere den folgenden Text auf Barrierefreiheit nach den Kriterien für Einfache Sprache. Identifiziere Schachtelsätze, Passivkonstruktionen und unklaren Fachjargon. Schlage eine optimierte, barrierefreie Version vor, die dem Sprachniveau B1 entspricht.“

Simulation von Fehlsichtigkeiten

Informationen dürfen niemals ausschließlich über Farben transportiert werden.

• Der Test: Öffne die Entwicklerwerkzeuge deines Browsers (meist über die Taste F12 oder über Rechtsklick -> Untersuchen).
  • In Chromium-Browsern (Google Chrome, Microsoft Edge, Brave): Klicke auf die drei vertikalen Punkte oben rechts in den DevTools, wähle Weitere Tools (More tools) – Rendering und scrolle nach unten zum Bereich Fehlsichtigkeiten emulieren (Emulate vision deficiencies). Alternativ öffnet Strg + Shift + P (Windows) oder Cmd + Shift + P (Mac) das Befehlsmenü, über das du den Punkt „Rendering“ direkt aufrufen kannst.
  • In Mozilla Firefox: Wechsle in den DevTools direkt auf den Reiter Barrierefreiheit (Accessibility). In der oberen Menüleiste dieses Bereichs findest du das Dropdown-Menü Simulieren, über das sich die visuellen Filter direkt zuschalten lassen.
• Worauf zu achten ist: Schalte die Seite auf „Protanopia“ (Rotblindheit) oder „Achromatopsie“ (vollständige Farbenblindheit). Sind Fehlermeldungen in Formularen, aktive Menüpunkte oder Links im Fließtext jetzt immer noch eindeutig als solche erkennbar (z. B. durch zusätzliche Icons oder Unterstreichungen)?

Schritt 3: Die Perspektive der Betroffenen

Der finale Test simuliert die tatsächliche Nutzung durch blinde oder stark sehbehinderte Menschen. Jedes moderne Betriebssystem bringt dafür die nötigen Werkzeuge nativ mit.

Der 2-Minuten-Screenreader-Test

1. Vorbereitung: Schließe die Augen oder schalte den Monitor temporär aus.
2. Aktivierung: Starte den System-Screenreader. Bei macOS ist das VoiceOver (Cmd + F5), bei Windows die integrierte Sprachausgabe (Win + Strg + Enter). Alternativ kannst du das kostenlose Tool NVDA nutzen.
3. Durchführung: Versuche, ausschließlich mittels Tastatur und den akustischen Ansagen des Screenreaders eine gezielte Aktion durchzuführen – beispielsweise ein Produkt in den Warenkorb zu legen oder das Kontaktformular auszufüllen.

Wenn der Screenreader an einer Stelle unverständliche Dateinamen (z. B. bei Bildern ohne ALT-Text), kryptische Zeichenketten oder schlicht überhaupt nichts vorliest, ist diese Funktion für betroffene Nutzer blockiert. Diese Erkenntnisse fließen direkt zurück in die finale Code-Optimierung.

---

Häufige Fehler & Stolperfallen

„Gut gemeint“ heißt nicht immer auch „gut gemacht“. Vermeide diese vier klassischen Fehler im WordPress-Alltag:

Fehler 1: Der blinde Glaube an „All-in-One“-Reparatur-Plugins

Plugins, die versprechen: „Ein Klick und deine Website ist rechtssicher und barrierefrei.“ lügen dich an. Kein Plugin der Welt kann ein logisch falsch verschachteltes Überschriften-Konstrukt reparieren oder erraten, was auf einem Bild zu sehen ist, um einen ALT-Text zu generieren. Solche Tools doktern an den Symptomen herum, heilen aber nicht den kaputten Code.

Fehler 2: Autoplay-Medien und unkontrollierbare Slider

Automatisch abspielende Videos, Hintergrundmusik oder Karussell-Slider, die sich nicht pausieren lassen, sind nicht nur ein Conversion-Killer für die UX, sondern für Menschen mit kognitiven Einschränkungen oder Screenreader-Nutzer eine unüberwindbare Barriere. Jedes bewegte Element muss über einen gut sichtbaren und per Tastatur erreichbaren Stopp-Button verfügen.

Fehler 3: Informationen ausschließlich über Farbe transportieren

„Alle Pflichtfelder sind rot markiert.“ – Ein blinder Nutzer oder jemand mit einer ausgeprägten Rot-Grün-Schwäche sieht diesen Unterschied schlichtweg nicht. Verwende für Erfolgs-, Warn- oder Fehlermeldungen immer eine Kombination aus Farbe, Textzusätzen („Fehler:“) und Icons.

Fehler 4: „Hier klicken“- und „Mehr erfahren“-Links

Ein Screenreader-Nutzer nutzt oft eine Funktion, die ihm ausschließlich alle Links einer Seite als Liste ausgibt. Wenn diese Liste dann zwanzigmal aus dem Text „Hier klicken“, „Mehr erfahren“ oder „Link“ besteht, ist sie völlig nutzlos. Der Linktext muss immer aus sich heraus verständlich und isoliert aussagekräftig sein.

• Falsch: „Um unseren SEO-Leitfaden zu lesen, klicke [hier].“
• Richtig: „Weitere Informationen findest du in unserem [SEO-Leitfaden für Barrierefreiheit].“

---

FAQ: Häufige Fragen zu WordPress & Barrierefreiheit