Lass uns zusammen starten
Von der Idee zur Umsetzung – gemeinsam, effizient, individuell.
Kurzfassung Ein Accessibility-Plugin kann ein paar Komfortfunktionen bieten (z. B. Kontrast-Umschalter), aber es repariert nicht die Dinge, die rechtlich und praktisch zählen: saubere Semantik, Tastaturbedienung, Fokus, Formulare, Struktur, Alternativen, verständliche Inhalte.
Was diese Plugins typischerweise tun – und warum das nicht reicht
Was sie oft anbieten
- „Text größer/kleiner“
- Kontrast-/Farbschemata
- Schriftwechsel (z. B. „Dyslexic Font“)
- Animationen ausschalten
- Vorlese-Funktion / Cursor-Helfer
Das kann für einzelne Nutzer:innen hilfreich sein – ist aber eher Komfort als echte Barrierefreiheit.
Was sie nicht zuverlässig lösen
- fehlende Überschriftenhierarchie (h1…h6)
- unbedienbare Menüs/Slider ohne Tastatur
- schlechter Fokus (nicht sichtbar / springt weg)
- Formulare ohne Labels/Fehlermeldungen
- falsche ARIA-Rollen oder kaputte Semantik
Das sind genau die Baustellen, die über Screenreader- und Keyboard-Nutzung entscheiden.
Merke: Wenn die Website ohne Plugin nicht bedienbar ist, ist sie nicht barrierefrei – mit Plugin meistens auch nicht.
Warum Overlays & „Accessibility-Widgets“ sogar schaden können
1) Sie ändern das UI, aber nicht den Code darunter
Barrierefreiheit entsteht nicht im „Aufsatz“, sondern in der Struktur: HTML-Semantik, sinnvolle Reihenfolge, Fokusführung, Labels, Kontraste, Alternativen, verständliche Texte. Ein Overlay legt sich darüber – die eigentlichen Probleme bleiben.
2) Sie können Screenreader & Tastaturbedienung stören
Manche Widgets fügen zusätzliche Fokus-Stopps hinzu, ändern DOM-Reihenfolgen oder triggern Scripts, die Screenreader-Ansagen chaotisch machen. Ergebnis: Die Seite fühlt sich „kaputter“ an als vorher.
3) Sie vermitteln ein falsches Sicherheitsgefühl
„Wir haben doch ein Plugin!“ ist der Klassiker – bis echte Nutzer:innen scheitern oder ein Audit zeigt, dass zentrale Kriterien weiterhin nicht erfüllt sind.
Realitätscheck Wenn euer Kontaktformular ohne Maus nicht abschickbar ist, hilft kein Kontrast-Schalter. Dann fehlt Bedienbarkeit – und die ist Grundanforderung
Was echte Barrierefreiheit in WordPress wirklich bedeutet
Barrierefreiheit ist kein einzelnes Feature, sondern die Summe aus Technik, Inhalt und Design. Hier sind die Bereiche, die in der Praxis am meisten Wirkung haben:
Struktur & Semantik
- Überschriften in logischer Reihenfolge (keine Sprünge nur fürs Design)
- Landmarks (Header, Nav, Main, Footer) sauber und eindeutig
- Listen sind Listen, Buttons sind Buttons (nicht alles div)
Bedienbarkeit
- Alles ist per Tastatur erreichbar und nutzbar
- Fokus sichtbar und logisch geführt
- Keine „Fokus-Fallen“ in Menüs, Modals, Slidern
Formulare
- Jedes Feld hat ein echtes Label
- Fehler sind verständlich und werden korrekt angekündigt
- Pflichtfelder, Hinweise, Erfolgsmeldungen: klar & robust
Medien & Inhalte
- Bilder mit sinnvollem Alt-Text (oder bewusst leer)
- Videos mit Untertiteln / Transkript (wo nötig)
- Texte: verständlich, scannbar, gute Linktexte
„Aber wir müssen BFSG-konform sein – was ist der schnellste Weg?“
Schnell heißt nicht „Plugin drauf“, sondern „die größten Blocker zuerst“. Wenn du eine Seite in kurzer Zeit massiv verbessern willst, geh so vor:
- Keyboard-Test (5 Minuten): Tab durch die Seite. Komme ich überall hin? Komme ich überall wieder raus? Ist der Fokus sichtbar?
- Formulare prüfen: Labels, Fehlermeldungen, Pflichtfelder. Ohne Maus abschickbar?
- Überschriften & Struktur: Eine H1, sinnvolle H2/H3, keine „Design-Überschriften“ ohne Semantik.
- Kontraste & Schrift: Kontrast der Inhalte, Linkzustände, Fokuszustände – direkt im Design lösen, nicht im Overlay.
- Redaktionelle Standards: Alt-Texte, Linktexte, PDF-Check, Inhalte scannbar machen.
Praxis-Tipp Wenn du nur eine Sache diese Woche machst: Keyboard-Bedienbarkeit + sichtbarer Fokus. Das hebt die Nutzbarkeit sofort – für alle.
Wann ein Plugin sinnvoll sein kann (ja, manchmal)
Es gibt legitime Einsatzbereiche – nur eben nicht als „Barrierefreiheitsschalter“:
- Redaktionshilfe: Plugins, die beim Schreiben unterstützen, z. B. Hinweise auf fehlende Alt-Texte, unklare Linktexte oder Überschriftenfehler.
- Technische Ergänzung: Einzelne Funktionen wie Skiplinks oder Fokus-Hilfen, wenn das Theme sie nicht bietet (besser: dauerhaft im Theme oder Code integrieren).
- Monitoring & Reminder: Scans und Reports, um typische Probleme sichtbar zu machen oder Regressionen nach Updates zu erkennen.
- Dokumentation & Qualitätssicherung: Vergleich von Prüfständen (vor/nach Änderungen), hilfreich für Teams, Kund:innen oder wiederkehrende Reviews.
- Sensibilisierung & Schulung: Plugins können Redakteur:innen zeigen, wo Barrieren entstehen – der Lerneffekt ist oft größer als der technische Nutzen.
Wichtig: Ein Scan findet häufig Symptome, aber nicht die echte Nutzererfahrung.
Fazit: Plugins unterstützen Prozesse. Barrierefreiheit entsteht trotzdem außerhalb des Plugins.
Technische Grundlage:
Was unter Barrierefreiheit tatsächlich zählt, ist international klar definiert. Die Anforderungen sind im WCAG-Standard des W3C beschrieben – transparent, technisch und ohne Marketing.
Wer hier einmal durchscrollt, merkt schnell: Das ist nichts, was ein Overlay oder Plugin „nachrüsten“ kann.
Du willst es sauber und nachvollziehbar?
Ich prüfe deine Seite pragmatisch nach BFSG/WCAG (Keyboard, Screenreader-Basics, Formulare, Struktur uv.m.) und du bekommst eine priorisierte To-do-Liste, die du wirklich abarbeiten kannst – oder ich übernehme die Umsetzung für dich.
Technisch korrekt. Praxisnah.
Hinweis: Das ist keine Rechtsberatung – aber solide, technische Praxis.
