Barrierefreiheit (WCAG 2.2) in 2026: Ist Ihre WordPress-Site legal?

Im Juni 2025 veränderte sich die digitale Landschaft für immer. Der European Accessibility Act (EAA) trat vollständig in Kraft und machte digitale Barrierefreiheit zu einer gesetzlichen Anforderung für fast alle digitalen Unternehmen, die in der EU tätig sind.

Es ist nicht mehr nur “nice to have”. Es ist vergleichbar mit der DSGVO. Bei Nichteinhaltung drohen erhebliche Geldstrafen und Klagen.

Für WordPress-Entwickler und Website-Betreiber ist WCAG 2.2 Level AA der Standard. Dieser Leitfaden (2000+ Wörter) schlüsselt genau auf, was sich 2026 geändert hat und wie Sie sicherstellen, dass Ihr Theme nicht gegen das Gesetz verstößt.

1. Der EAA: Warum 2025 der Wendepunkt war

Früher galten Gesetze zur Barrierefreiheit meist für den öffentlichen Sektor (Regierung/Unis). Der EAA weitete dies auf E-Commerce, Bankwesen, Verkehr und eBooks aus.

• Geltungsbereich: Wenn Sie ein T-Shirt an einen Kunden in Frankreich verkaufen, muss Ihr Checkout-Prozess barrierefrei sein.
• Die Strafe: Geldstrafen variieren je nach Land, können aber schwerwiegend sein, gepaart mit dem Reputationsschaden, 15% der Weltbevölkerung auszuschließen.

2. WCAG 2.2: Die neuen Kriterien erklärt

WCAG 2.2 baute auf 2.1 auf und fügte 9 neue Kriterien hinzu. Die kritischsten für WordPress-Themes sind:

2.4.11 Fokus nicht verdeckt (Minimum) (AA)

• Das Problem: Sie tabben eine Seite hinunter. Ein Element erhält den Fokus, aber Ihr “Sticky Header” oder “Cookie-Banner” verdeckt es. Der Benutzer weiß, dass er irgendwo ist, kann aber nicht sehen wo.
• Die Lösung: Verwenden Sie CSS scroll-padding-top auf dem html-Element, um sicherzustellen, dass fokussierte Elemente in den sichtbaren Bereich unterhalb Ihres Sticky Headers scrollen.

2.5.8 Zielgröße (Minimum) (AA)

• Die Regel: Interaktive Ziele (Buttons) müssen mindestens 24x24 CSS-Pixel groß sein.
• Die Realität: Diese winzigen “X”-Schließen-Buttons auf Ihren Popups? Sie sind illegal. Machen Sie sie größer. Fingertipps sind ungenau.

3.3.8 Zugängliche Authentifizierung (AA)

• Die Regel: Zwingen Sie Benutzer nicht dazu, Rätsel (CAPTCHAs) zu lösen oder Passwörter ohne Hilfe auswendig zu lernen.
• Die Auswirkung auf WordPress: Unterstützen Sie Passwort-Manager (blockieren Sie das Einfügen in Passwortfelder nicht) und verwenden Sie “Magic Links” oder WebAuthn (Biometrie), wo möglich.

3. Semantisches HTML: Das Fundament

90% der Probleme mit Barrierefreiheit werden durch das Schreiben von korrektem HTML gelöst.

• Landmarks: Verwenden Sie <main>, <nav>, <aside>, <footer>. Screenreader-Benutzer springen zwischen diesen Regionen. Ertränken Sie nicht alles in <div>-Suppe.
• Überschriften: h1 bis h6 ist eine Hierarchie, keine Stilwahl. Springen Sie nicht von h2 zu h4, nur weil Sie eine kleinere Schriftart wollen. Verwenden Sie CSS für die Größe.
• Buttons vs. Links:
  • Geht zu einer neuen URL? Verwenden Sie <a>.
  • Ändert etwas auf der aktuellen Seite (öffnet ein Menü)? Verwenden Sie <button>.
  • Verwenden Sie niemals <div onClick="...">. Es ist für Tastaturen unsichtbar.

4. Die “Overlay”-Falle

Sie haben sie gesehen. Das kleine “Männchen im Kreis”-Icon in der Ecke, das ein Menü öffnet, um Kontrast oder Schriftgröße zu ändern. Vermeiden Sie sie.

• Falsche Sicherheit: Sie behaupten, Sie mit einer Zeile JS sofort konform zu machen. Das tun sie nicht. Sie können semantische HTML-Fehler nicht beheben.
• Benutzer-Reibung: Blinde Benutzer haben bereits ihre Screenreader. Sie brauchen Ihr Overlay nicht, das ihre Tools stört.
• Rechtliches Risiko: In den USA wurden Unternehmen, die Overlays verwenden, häufiger verklagt, weil es beweist, dass sie von dem Problem wussten, aber eine “Pflaster”-Lösung wählten.

5. Testen: Automatisiert vs. Manuell

Sie können Barrierefreiheit nicht zu 100% automatisieren.

Der Test-Workflow

1. Automatisiert (30%): Verwenden Sie axe-core oder das Lighthouse “Accessibility”-Audit. Dies fängt fehlenden alt-Text und geringen Kontrast auf.
2. Manuell Tastatur (50%): Ziehen Sie Ihre Maus ab. Können Sie das gesamte Menü navigieren, die Untermenüs öffnen und das Kontaktformular ausfüllen, indem Sie nur die Tab-, Enter- und Leertasten verwenden? Wenn nicht, fallen Sie durch.
3. Screenreader (20%): Schalten Sie VoiceOver (Mac) oder NVDA (Windows) ein. Schließen Sie Ihre Augen. Können Sie verstehen, was passiert?

6. Barrierefreie Formulare in WordPress

Contact Form 7 und Gravity Forms sind beliebt, aber oft falsch konfiguriert.

• Labels: Jedes Input-Feld braucht ein <label>. Platzhalter sind KEINE Labels (sie verschwinden, wenn Sie tippen).
• Fehlermeldungen: “Fehler gefunden” ist nutzlos. “E-Mail-Adresse fehlt das @-Symbol” ist barrierefrei.
• Fokus-Management: Wenn ein Benutzer ein Formular absendet und es einen Fehler gibt, verschieben Sie den Tastaturfokus programmgesteuert auf das erste Fehlerfeld, damit er es sofort beheben kann.

7. Fazit

Barrierefreiheit wird oft als Einschränkung dargestellt. In Wirklichkeit ist es ein Qualitätsindikator. Barrierefreier Code ist sauberer, robuster und besser für SEO. Im Jahr 2026 ist der Aufbau eines inklusiven Webs nicht nur Gesetz – es ist die einzige professionelle Art zu arbeiten.

Brauchen Sie ein Barrierefreiheits-Audit? WPPoland bietet WCAG 2.2-Remediation-Services für Enterprise.