Libration Accessibility

Das Handbuch zum Barrierefreiheits-Plugin: von der Installation über die Widget-Anpassung bis zu Prüfberichten, Erklärung und KI-Werkzeugen. Alle Einstellungen findest du in WordPress unter Einstellungen → Barrierefreiheit.

Installation

1. Plugin-ZIP im WordPress-Backend unter Plugins → Installieren → Plugin hochladen auswählen und installieren — oder den Ordner libration-accessibility nach /wp-content/plugins/ laden.
2. Plugin in der Plugin-Liste aktivieren. Dort findest du auch direkt den Link Einstellungen.
3. Fertig — das Eingabehilfen-Widget erscheint sofort unten rechts auf deiner Website. Alle Basis-Fixes (Skip-Links, Fokus-Indikator, ARIA-Landmarks) sind ab Werk aktiv.

Lizenz aktivieren Pro

Deinen Lizenzschlüssel findest du in der Bestell-E-Mail und im Kundenbereich.

1. Öffne Einstellungen → Barrierefreiheit → Lizenz.
2. Schlüssel eintragen (Format LIB-XXXX-XXXX-XXXX) und auf Aktivieren klicken.
3. Der Tarif (Pro, Pro AI oder Agency) wird angezeigt und alle enthaltenen Funktionen schalten sich frei — ein Schlüssel für alles, auch die KI-Funktionen.

Agency-Lizenzen lassen sich auf bis zu 25 Websites aktivieren; die Übersicht der belegten Sites zeigt der Lizenz-Tab und der Kundenbereich. Mit „Lizenz von dieser Website lösen" gibst du einen Platz wieder frei — praktisch beim Umzug von Kundenprojekten.

Widget: Funktionen für Besucher

Das Widget bietet Besuchern zehn Anzeige-Modi und vier Regler — alle Einstellungen werden 30 Tage im Browser des Besuchers gespeichert (ohne Tracking, ohne Server-Übertragung):

Im Reiter Widget schaltest du Funktionsgruppen einzeln ab (z. B. Grauskala, Kontrast-Modi, Schrift-Regler, Link-Unterstreichung), wenn du das Panel schlanker halten willst.

Schwebender Button

Alles im Reiter Widget → Schwebender Button:

Du kannst den Button auch komplett ausschalten und das Panel stattdessen selbst platzieren — siehe Einbindung.

Aussehen & Theme

Design-Kopplung per CSS-Variablen

Für Entwickler: Statt fester Farben kannst du das Widget an die CSS-Custom-Properties deines Themes koppeln. Dann folgt es automatisch jedem Design-Wechsel — inklusive Dark-Mode.

Akzentfarbe

Im Feld Akzentfarbe statt eines Hex-Werts einfach die Variable eintragen:

var(--primary)   oder kurz:   --primary

Panel-Hintergrund und Textfarbe

Panel-Theme auf Eigene Variablen stellen und die Variablennamen eintragen, die dein Theme definiert, z. B.:

:root { --site-bg: #ffffff; --site-text: #1d1d1f; }
@media (prefers-color-scheme: dark) {
  :root { --site-bg: #1c1b22; --site-text: #f4f4f5; }
}

Das Widget übernimmt background: var(--site-bg) und color: var(--site-text) und leitet alle Sekundärfarben (Kachel-Hintergründe, Trennlinien, Rahmen) per color-mix() automatisch daraus ab. Wechselt die Website per Media-Query oder Klasse ins Dunkle, zieht das Widget ohne weitere Konfiguration mit.

Gutenberg-Block

Suche im Block-Editor nach „Eingabehilfen-Panel" (Kategorie Widgets). Der Block rendert dasselbe Panel wie der schwebende Button — ideal für Footer, Popups oder eine eigene „Barrierefreiheit"-Seite. In der Block-Seitenleiste stellst du Titel, Titel-Anzeige und Zurücksetzen-Button ein.

Shortcode

Das Panel an beliebiger Stelle — auch in Theme-Dateien via do_shortcode():

[libration_accessibility]

[libration_accessibility title="Hilfe bei der Bedienung" show_title="1" show_reset="0"]

Elementor

Ist Elementor aktiv, erscheint automatisch das Widget „Libration Accessibility – Eingabehilfen" im Elementor-Panel (Kategorie Allgemein, Suchwörter „accessibility", „barrierefreiheit"). Per Drag & Drop platzieren; Titel, Titel-Anzeige und Zurücksetzen-Button stellst du direkt in den Widget-Optionen ein.

WPBakery

Ist WPBakery (Visual Composer) aktiv, findest du das Element „Libration Accessibility – Eingabehilfen" im Element-Katalog unter Inhalt — mit denselben drei Optionen wie Block und Shortcode.

Barrierefreiheitserklärung Pro

Der Reiter Erklärung erzeugt eine fertige Barrierefreiheitserklärung nach BFSG/EAA als WordPress-Seite:

1. Organisation, Kontakt-E-Mail und optional Telefon eintragen.
2. Konformitätsstatus wählen — teilweise vereinbar ist der übliche, ehrliche Stand.
3. Bekannte Einschränkungen ergänzen (z. B. „Ältere PDF-Dokumente sind noch nicht barrierefrei").
4. Sprache wählen — alle 29 Plugin-Sprachen stehen zur Auswahl (Deutsch und Englisch redaktionell gepflegt, weitere folgen).
5. Seite erstellen — die Erklärung erscheint als veröffentlichte Seite; bei Änderungen einfach erneut speichern, die Seite wird aktualisiert.

Externer Scan

Der Reiter Externer Scan lässt deine Website von außen prüfen: Ein echter Browser auf dem Libration-Server öffnet die ausgewählten Seiten und misst sie mit axe-core. Das findet Fehler, die im Backend nicht sichtbar sind – und liefert die Messwerte, auf denen der Kontrast-Assistent aufbaut.

Welche Seiten geprüft werden

Nur die Startseite zu prüfen sagt wenig: Die meisten Fehler stecken in Vorlagen, die erst auf Unterseiten zum Einsatz kommen – Formulare, Listen, Produktansichten, Kasse. Das Plugin schlägt deshalb je Vorlagentyp eine Seite vor und begründet die Auswahl. Du kannst streichen und eigene Adressen ergänzen; Adressen fremder Domains werden verworfen.

Kontingent

Gezählt werden geprüfte Seiten pro Monat, nicht Durchläufe: Free 5, Pro und Pro AI 100, Agency 500. Je Durchlauf sind höchstens 25 Seiten möglich.

Verlauf

Jeder Lauf wird festgehalten und mit dem vorigen verglichen – was neu ist, was häufiger wurde, was behoben ist. Ohne diesen Vergleich sähe ein wiederholter Scan bei unveränderter Website genauso aus wie der alte, und man wüsste nicht, ob überhaupt etwas passiert ist. Einzelne Läufe lassen sich löschen.

Monatlich automatisch Pro

Der Scan kann sich selbst starten und meldet sich per E-Mail – aber nur, wenn sich etwas verschlechtert hat. Der erste Lauf und Verbesserungen lösen keine Mail aus. Barrierefreiheit ist ein Zustand, kein Projekt: Ein Theme-Update kann behobene Fehler zurückbringen.

Kontrast-Assistent

Farbkontraste galten lange als das, was ein Plugin nicht lösen kann – PHP kennt die Farbe eines Elements nicht, sie entsteht erst im Browser aus Kaskade, Vererbung und Theme-Variablen. Genau das misst der externe Scan aber: axe-core liefert je Fundstelle Vordergrund- und Hintergrundfarbe, das erreichte und das nötige Verhältnis sowie Schriftgröße und -gewicht.

Wie der Vorschlag entsteht

Daraus berechnet das Plugin die kleinste Änderung, die den nötigen Wert erreicht: Nur die Helligkeit der Textfarbe wird verschoben, Farbton und Sättigung bleiben erhalten. Deine Marke bleibt damit erkennbar, statt dass alles auf Schwarz-auf-Weiß zusammenfällt. Kommt dieselbe Stelle auf mehreren Seiten mit verschiedenen Hintergründen vor, wird eine Farbe gesucht, die überall genügt.

Wenn nicht die Schrift das Problem ist

Weißer Text auf einer zu hellen Fläche lässt sich nicht sinnvoll abdunkeln – er würde grau, und grauer Text auf einer Farbfläche ist fast immer die falsche Lösung. In solchen Fällen nennt das Plugin die nötige Hintergrundfarbe, wieder unter Beibehaltung des Farbtons, und kann sie auf Wunsch anwenden. Dabei wird unterschieden, ob nur das Element betroffen ist (etwa ein Knopf) oder ein ganzer Bereich – im zweiten Fall kommt vorher eine deutliche Rückfrage, weil es im Layout sichtbar ist. Die Grundfarbe der Seite (body, html) bleibt ausgenommen; die gehört ins Theme.

Freigabe und Ausgabe

Nichts geschieht automatisch. Jede Korrektur zeigt Vorher und Nachher als Farbfläche, den alten und den neuen Kontrastwert und einen Link, der die Stelle im Frontend markiert. Freigegebene Korrekturen werden als CSS im Seitenkopf ausgeliefert – serverseitig, ohne JavaScript – und lassen sich jederzeit zurücknehmen. Mit ?libration-no-contrast an einer Adresse siehst du die Seite zum Vergleich unverändert.

Korrekturliste zum Weitergeben

Was sich nicht per Regel lösen lässt – Flächen mit Verlauf oder Bild, Stellen auf mehreren verschiedenen Hintergründen – landet in einer herunterladbaren Korrekturliste: ein druckbares Dokument mit allen Fundstellen, getrennt nach Textfarben, Flächen und Handarbeit, mit Links ins Frontend und einem fertigen CSS-Block samt Begründung als Kommentar. Gedacht zur Übergabe an Agentur oder Entwicklung.

Prüfbericht & PDF

Der Reiter Prüfbericht bündelt drei Ansichten:

• Übersicht — der Stand aller Bereiche auf einen Blick: Code-Korrekturen mit der Zahl der Eingriffe, letzte externe Prüfung mit Wert und Datum, offene Farbkontraste, Bildbeschreibungen, Bedienfeld, Erklärung, KI-Funktionen und Checkliste. Darunter eine Liste dessen, was offen ist. Hier startest du auch den PDF-Prüfbericht Pro.
• Bilder-Analyse — Detailliste aller Bilder ohne Alt-Text mit Vorschau, Fundstellen und Direktlink zur Bearbeitung. Neben „Alt-Text hinzufügen“ gibt es „Ist dekorativ“ für Bilder, die keine Information tragen: Sie bekommen ein bewusst leeres Alt-Attribut und werden von Screenreadern übersprungen. Vorhandene Alt-Texte werden nie überschrieben. Free zeigt die ersten 50 Bilder; Pro prüft unbegrenzt und exportiert als CSV.
• Checkliste — 33 Kriterien in sechs Abschnitten. 17 davon prüft der externe Scan bereits; sie sind als bestätigt oder beanstandet gekennzeichnet, und ein Knopf hakt die bestätigten auf einmal ab. Von Hand gesetzte Haken bleiben unangetastet.

Welche Fassung der WCAG gilt?

Verbindlich ist derzeit WCAG 2.1 Stufe AA. Darauf stützt sich die harmonisierte Norm EN 301 549 in ihrer geltenden Fassung, auf die BFSG und EAA verweisen. Die Nachfolgefassung der Norm nimmt WCAG 2.2 auf. Deren sechs zusätzliche Kriterien der Stufen A und AA stehen deshalb als eigener Abschnitt in der Checkliste – ausdrücklich als noch nicht verpflichtend gekennzeichnet. Wer heute baut, sollte sie mitdenken, statt später nachzurüsten.

KI-Funktionen Pro AI

Die KI-Funktionen laufen über die Libration-Server in Deutschland und werden über deine Lizenz freigeschaltet. Kontingente je Tarif findest du unter Tarife.

Automatische Alt-Texte

• Beim Upload: Schalter „Alt-Texte automatisch beim Upload" — neue Bilder werden asynchron beschrieben.
• Bestand nachrüsten: „Mediathek prüfen" zählt Bilder ohne Alt-Text, „Jetzt erzeugen" arbeitet sie mit Fortschrittsanzeige ab. Vorhandene Alt-Texte bleiben unangetastet.
• Sprache: folgt der Website-Sprache, überschreibbar im KI-Tab.

Leichte Sprache & KI-Vorlesen

Beide Funktionen sind Bestandteil des Pro-AI-Tarifs und werden automatisch über deine Lizenz freigeschaltet, sobald sie für dein Konto verfügbar sind — du siehst den Status im KI-Tab.

Backend-Optionen

Tarife im Überblick

Preise und Bestellung: libration.io/#pricing · Verwaltung: Kundenbereich

Was Libration Accessibility nicht lösen kann – und wie du es selbst machst

Libration Accessibility arbeitet an der Oberfläche deiner Website: Es ergänzt Skip-Links, einen sichtbaren Fokus-Indikator und ARIA-Landmarks, korrigiert bekannte HTML-Muster serverseitig, findet Bilder ohne Alt-Text und gibt Besuchern Regler für Schrift, Kontrast und Vorlesen. Das deckt einen großen Teil der technischen Prüfpunkte ab — aber nicht alle. Sieben Bereiche bleiben in deiner Hand, weil sie von Inhalt, Design oder fremdem Code abhängen. Ein Werkzeug, das dort automatisch eingreift, müsste raten: Eine falsch geratene Beschriftung oder eine umsortierte Seite ist für Nutzer schlechter als gar keine Korrektur.

Jeder der folgenden Abschnitte nennt den Grund, eine Schritt-für-Schritt-Anleitung und die Stelle, an der du es in WordPress umsetzt.

1. Farbkontraste (WCAG 1.4.3, 1.4.11)

Warum ein Plugin das nicht lösen kann: Kontrast entsteht immer aus zwei Farben — dem Text und dem, was dahinter liegt. Das Dahinter ist oft kein einfacher Farbwert, sondern ein Foto, ein Farbverlauf, eine halbtransparente Fläche oder ein Overlay. Ein Plugin könnte Farben nur global überschreiben; damit wäre dein Markenbild weg und an anderen Stellen entstünden neue Fehler. Die Kontrast-Modi im Widget helfen Besuchern, die sie einschalten — die Standardansicht deiner Seite muss die Werte selbst erfüllen.

Diese Werte sind gefordert:

So gehst du vor:

1. Messen: Vordergrund- und Hintergrundfarbe in den WebAIM Contrast Checker eintragen. Schneller geht es direkt in der Seite — Rechtsklick → Untersuchen, im Bereich Stile auf das Farbfeld klicken: Chrome, Edge und Firefox zeigen im Farbwähler den Kontrastwert und die Linie an, ab der 4,5:1 erreicht ist.
2. Nur die Helligkeit anpassen, den Farbton behalten: Stelle die Farbe in HSL dar und senke bei dunklem Text auf hellem Grund den L-Wert schrittweise, bis der Wert erreicht ist. So bleibt die Marke erkennbar — aus einem zu hellen Firmenblau wird ein dunkleres Firmenblau, kein anderes Blau.
3. Die neue Farbe zentral eintragen, nicht an einzelnen Blöcken: bei Block-Themes unter Design → Editor → Stile → Farben → Palette, bei klassischen Themes unter Design → Customizer → Farben.
4. Pflegst du ein Child-Theme, gehören die Werte in die theme.json unter settings.color.palette. Dann gelten sie in Editor und Frontend gleich und überleben Updates des Eltern-Themes.
5. Zustände nicht vergessen: Hover, Fokus, deaktivierte Buttons, Platzhaltertexte in Formularen, Text in Bildunterschriften. Für Text auf Fotos hilft ein deckender Kasten oder ein Overlay ab etwa 50 % Deckkraft — ein Textschatten genügt nicht.
6. Nach der Änderung eine Handvoll typischer Seiten erneut messen: Startseite, ein Beitrag, ein Formular, die Fußzeile. Die Fußzeile fällt am häufigsten durch, weil dort helle Schrift auf mittelgrauem Grund steht.

Wo Libration Accessibility hilft: Der Reiter Externer Scan misst die Kontraste der geprüften Seiten, listet die Fundstellen mit Farbwerten und markiert sie im Frontend, damit du sie im Theme zuordnen kannst. Die Korrektur selbst passiert im Theme.

2. Untertitel und Audiodeskription (WCAG 1.2.2, 1.2.3)

Warum ein Plugin das nicht lösen kann: Untertitel sind Inhalt, nicht Technik. Sie brauchen die Zuordnung, wer spricht, eine Entscheidung darüber, welche Geräusche wichtig sind, und eine Zeichensetzung, die den Sinn trägt. Automatische Untertitel scheitern verlässlich an Namen, Fachbegriffen, Dialekt und Zahlen und gelten für die Prüfung deshalb nicht als Untertitel. Audiodeskription beschreibt, was zu sehen, aber nicht zu hören ist — das kann nur entscheiden, wer die Aussage des Videos kennt.

So gehst du vor:

1. Bei YouTube die automatische Fassung als Entwurf nutzen, aber korrigieren: YouTube Studio → Untertitel → Sprache → Duplizieren und bearbeiten, Text durchgehen, veröffentlichen. Danach steht im Player „Deutsch" statt „Deutsch (automatisch erzeugt)" — daran erkennst du, dass die geprüfte Fassung aktiv ist.
2. Bei Vimeo: Video → Einstellungen → Untertitel → Datei hochladen, Sprache und Bezeichnung setzen, aktivieren.
3. Eigene Untertiteldatei schreiben: Eine WebVTT-Datei ist eine reine Textdatei mit der Endung .vtt. Zeitmarken, Leerzeile, Text — mehr braucht es nicht:

   WEBVTT
   
   00:00:00.500 --> 00:00:04.000
   Willkommen zu unserem Rundgang.
   
   00:00:04.100 --> 00:00:07.800
   [Türklingel]
   Sprecherin: Hier beginnt der Eingang.

   Ein SRT-Untertitel sieht fast gleich aus: fortlaufende Nummer vor jeder Zeitmarke, Komma statt Punkt bei den Millisekunden, kein WEBVTT in der ersten Zeile.
4. Bei selbst gehosteten Videos die Datei im Video-Element einbinden:

   <video controls src="rundgang.mp4">
     <track kind="captions" src="rundgang-de.vtt" srclang="de" label="Deutsch" default>
   </video>

   WordPress erlaubt .vtt-Uploads nicht in jeder Konfiguration. Klemmt die Mediathek, lege die Datei per FTP neben das Video und verweise mit dem vollständigen Pfad darauf.
5. Transkript unter dem Video als normalen Text anbieten: Fließtext mit Sprecherangaben und einer Beschreibung der wichtigen Bilder. Bei reinen Tonaufnahmen erfüllt das die Anforderung vollständig, bei Videos deckt es einen großen Teil der Audiodeskription ab — und es ist zusätzlich durchsuchbar.
6. Echte Audiodeskription: entweder eine zweite Videofassung mit beschreibender Tonspur verlinken oder — deutlich günstiger — das Video von Anfang an so vertonen, dass alles Wichtige auch gesagt wird („Im Diagramm steigt der Wert von 20 auf 60").

Wo in WordPress: Untertitel eingebetteter Videos pflegst du beim jeweiligen Dienst, nicht in WordPress. Eigene Videos lädst du in die Mediathek; das track-Element ergänzt du im Block „Individuelles HTML" statt im Video-Block. Das Transkript passt gut in den Block „Details" — aufklappbar und ohne JavaScript bedienbar.

3. Verständliche Linktexte und Überschriften (WCAG 2.4.4, 2.4.6)

Warum ein Plugin das nicht lösen kann: Nur du weißt, wohin ein Link führt und welche Rolle ein Satz in der Gliederung spielt. Ein Automat müsste den Linktext aus dem Umfeld raten, und ein falsch geratener Linktext ist schlechter als „hier klicken", weil er in die falsche Richtung schickt. Überschriftenebenen sind Bedeutung, nicht Schriftgröße: Eine automatische Umnummerierung würde die Gliederung deiner Seite verfälschen.

So gehst du vor:

1. Linktexte benennen das Ziel, auch aus dem Zusammenhang gerissen: „Preise ansehen" statt „hier klicken", „Kontaktformular öffnen" statt „mehr". Screenreader lesen auf Wunsch alle Links einer Seite als Liste vor — dort steht kein Kontext daneben.
2. Verlangt das Layout ein kurzes Wort, ergänze die Beschreibung am Link: <a href="/preise/" aria-label="Preise ansehen">Mehr</a>. Das sichtbare Wort muss im Label enthalten sein, sonst können Nutzer von Sprachsteuerung den Link nicht ansprechen.
3. Gleicher Linktext, gleiches Ziel. Drei Links „Weiterlesen" auf drei verschiedene Beiträge sind ein Fehler — hänge den Beitragstitel an.
4. Führt der Link zu einer Datei, gehört das in den Text: „Preisliste (PDF, 1,2 MB)". Öffnet er ein neues Fenster, sag das ebenfalls.
5. Genau eine h1 pro Seite, üblicherweise der Seitentitel. Prüfe, ob dein Theme zusätzlich den Website-Namen als h1 ausgibt; dann muss eines von beiden auf eine tiefere Ebene.
6. Keine Sprünge nach unten: h1 → h2 → h3. Nach einer h2 darf keine h4 folgen. Zurückspringen ist erlaubt, eine h3 darf also wieder von einer h2 gefolgt werden.
7. Überschriften nicht für die Optik verwenden. Willst du nur großen, fetten Text, nimm einen Absatz und stelle Größe und Schriftschnitt unter Typografie ein. Umgekehrt bleibt eine echte Zwischenüberschrift eine Überschrift, auch wenn sie klein aussehen soll.

Wo in WordPress: Im Block-Editor öffnest du oben links die Listenansicht und wechselst auf den Reiter Gliederung (Dokumentübersicht). Dort steht die komplette Überschriftenstruktur, falsche Ebenen sind markiert. Die Ebene änderst du in der Werkzeugleiste des Überschriften-Blocks (H2, H3, …) oder in der Block-Seitenleiste. Bei Elementor und WPBakery sitzt die Ebene in den Optionen des jeweiligen Überschriften-Widgets — dort wird sie besonders häufig nur nach Größe gewählt.

4. Bedienbarkeit eigener und fremder Bausteine (WCAG 2.1.1, 4.1.2)

Warum ein Plugin das nicht lösen kann: Ein Slider, ein Akkordeon oder ein Popup, das aus div-Elementen mit Klick-Handlern besteht, hat keine Rolle, keinen Zustand und keine Tastaturbedienung. Von außen ist nicht erkennbar, was so ein div sein soll — geratene Rollen führen zu falschen Ansagen im Screenreader, und in fremdes JavaScript hineinzupatchen bricht beim nächsten Update. Deshalb prüfst du hier selbst und entscheidest, was bleibt.

Das Testverfahren, rund zehn Minuten pro Seitentyp: Klicke in die Adresszeile des Browsers und lege die Maus weg. Ab jetzt nur noch Tab (vorwärts), Shift+Tab (zurück), Enter und Leertaste (auslösen), Escape (schließen) und die Pfeiltasten (innerhalb von Menüs, Reitern, Slidern).

Das muss funktionieren:

• Jedes Bedienelement ist per Tab erreichbar — auch Slider-Pfeile, Filter, Akkordeon-Köpfe und das Schließen-X.
• Der Fokus ist jederzeit sichtbar. Verschwindet er, hat jemand outline: none gesetzt, ohne Ersatz zu definieren.
• Enter und Leertaste lösen aus, was ein Mausklick auslöst.
• Modals und Popups schließen mit Escape, und der Fokus geht danach zurück auf das Element, das sie geöffnet hat.
• Kein Fokus-Gefängnis: Aus jedem Bereich kommst du per Tab wieder heraus. Umgekehrt darf der Fokus nicht in verborgene Inhalte laufen — versteckte Slides und geschlossene Menüs brauchen display: none, hidden oder inert, nicht nur opacity: 0.
• Bewegung, die länger als fünf Sekunden automatisch läuft, lässt sich anhalten (Auto-Play-Slider, Laufschriften).

Wenn ein Baustein durchfällt:

1. Erst die Einstellungen prüfen: Viele Slider, Menüs und Popups haben eine Option „Tastaturnavigation" oder „Accessibility", die ab Werk aus ist.
2. Fehler beim Hersteller melden, mit Schrittfolge, Browser und erwartetem Verhalten. Bei Plugins von wordpress.org gehört das ins öffentliche Support-Forum, damit andere Betreiber es finden.
3. Ist keine Lösung in Sicht, ersetze den Baustein. Ein Slider mit drei Bildern lässt sich als drei untereinander liegende Bilder abbilden — barrierefrei, schneller und ohne Wartung.
4. Baust du selbst, nimm native Elemente: button für Aktionen, a href für Ziele, details und summary für Aufklapper, label für Formularfelder. Sie bringen Fokus, Tastaturbedienung und Rolle mit. div plus onclick bringt nichts davon mit und macht drei zusätzliche Zeilen ARIA nötig.

Wo in WordPress: Eigenes Markup gehört in den Block „Individuelles HTML" oder ins Child-Theme. Beim Prüfen hilft Libration Accessibility: Der Reiter Tab-Reihenfolge nummeriert für angemeldete Administratoren alle fokussierbaren Elemente im Frontend. Springt die Nummerierung, ist die Reihenfolge falsch; fehlt ein Element ganz, ist es per Tastatur nicht erreichbar.

5. Sinnvolle Reihenfolge und Fokusverlauf (WCAG 1.3.2, 2.4.3)

Warum ein Plugin das nicht lösen kann: Screenreader und Tastatur folgen der Reihenfolge im Quellcode, nicht dem, was das Auge sieht. Welche Reihenfolge gemeint ist, steht nirgends im Code — das weiß nur, wer die Seite gebaut hat. Ein Werkzeug, das den Quellcode nachträglich umsortiert, zerlegt Layout und Skripte.

So gehst du vor:

1. Grundregel: Die Reihenfolge im Quellcode folgt der sichtbaren Reihenfolge. Willst du Inhalte umstellen, stelle die Blöcke wirklich um, statt sie per CSS zu verschieben.
2. Diese CSS-Eigenschaften sortieren visuell um, ohne den Quellcode zu ändern: order in Flex- und Grid-Layouts, flex-direction: row-reverse und column-reverse, grid-template-areas, position: absolute und float. Der häufigste Fall in WordPress ist die Theme- oder Block-Option „Spalten auf Mobilgeräten umkehren".
3. Test ohne Zusatzwerkzeuge: Schalte das Seiten-CSS ab. In Firefox über Ansicht → Webseiten-Stil → Kein Stil. In Chrome und Edge über die Entwicklerwerkzeuge, Reiter Elemente: die Stylesheet-Verweise im head markieren und mit der Taste H ausblenden. Lies die Seite dann von oben nach unten — ergibt die Reihenfolge Sinn, passt es.
4. Zweiter Test: Tab durch die Seite und den Fokus beobachten. Springt er von oben rechts nach unten links und wieder nach oben, weicht die Quellcode-Reihenfolge von der sichtbaren ab.
5. Keine positiven tabindex-Werte verwenden. tabindex="1" und höher reißt Elemente aus der natürlichen Reihenfolge; sinnvoll sind nur 0 und -1.
6. Öffnet sich etwas Neues — Modal, Off-Canvas-Menü, Suchfeld —, setze den Fokus hinein und beim Schließen zurück. Ohne das steht der Fokus unsichtbar hinter dem Overlay, und die nächste Tab-Taste führt ins Leere.

Wo in WordPress: Die Blockreihenfolge änderst du in der Listenansicht per Ziehen oder mit den Pfeilen in der Block-Werkzeugleiste; bei Spalten- und Gruppen-Blöcken verschiebst du die Spalten direkt. Optionen zum Umkehren auf Mobilgeräten stecken im Customizer oder in den Einstellungen des Layout-Blocks. Der Skip-Link von Libration Accessibility hilft, lange Navigationen zu überspringen — eine falsche Reihenfolge im Inhalt repariert er nicht.

6. Formular-Fehlermeldungen (WCAG 3.3.1, 3.3.3)

Warum ein Plugin das nicht lösen kann: Markup, Prüflogik und Meldungstexte kommen vom Formular-Plugin, und die Fehler entstehen erst beim Absenden, oft per Ajax nachgeladen. Von außen ist nicht zu erkennen, welche Meldung zu welchem Feld gehört — und selbst wenn: Was in der Meldung stehen muss, damit sie hilft, ist eine inhaltliche Entscheidung.

So gehst du vor:

1. Die Meldung benennt Feld und Erwartung im Text: „Bitte E-Mail-Adresse angeben" oder „Das Datum bitte als TT.MM.JJJJ eintragen" statt „Ungültige Eingabe".
2. Nie nur die Farbe ändern. Ein roter Rahmen allein ist für viele Nutzer unsichtbar — es braucht Text, gern zusätzlich ein Symbol.
3. Meldung mit dem Feld verknüpfen: Der Fehlertext bekommt eine id, das Feld ein aria-describedby darauf und zusätzlich aria-invalid="true". Dann liest der Screenreader den Fehler direkt beim Feld mit vor.
4. Zusammenfassung über dem Formular ausgeben, mit Sprunglinks zu den betroffenen Feldern, und den Fokus dorthin setzen (Container mit tabindex="-1", dann focus()). Nachgeladene Meldungen bekommen einen Bereich mit role="alert", damit sie angekündigt werden.
5. Pflichtfelder im Label kennzeichnen, nicht nur mit einem Sternchen — und wenn Sternchen, dann mit einer Legende darüber.
6. Beschriftungen als echte label-Elemente, nicht als Platzhalter im Feld. Platzhalter verschwinden beim Tippen und sind ein häufiger Kontrastfehler.

Wo in WordPress: Die Texte pflegst du in den Einstellungen deines Formular-Plugins: Contact Form 7 unter Kontaktformular → Reiter Meldungen, WPForms unter Einstellungen → Validierung (global) und je Feld in den erweiterten Optionen, Gravity Forms in den Formulareinstellungen und je Feld unter „Custom validation message", Fluent Forms unter Globale Einstellungen → Validierungsmeldungen. Ob dein Plugin sauber verknüpft, siehst du am schnellsten so: Formular leer absenden, dann mit Tab in das erste Feld gehen und prüfen, ob der Fehler mitgelesen wird. Fehlt die Verknüpfung, ist das ein Fall für den Hersteller-Support — oder für einen Wechsel des Plugins.

7. PDF- und Office-Dokumente

Warum ein Plugin das nicht lösen kann: Ein PDF ist ein eigenes Dateiformat mit eigener Struktur. Libration Accessibility sieht die HTML-Seite, auf der der Download verlinkt ist, nicht den Inhalt der Datei. Bei eingescannten Dokumenten liegt überhaupt kein Text vor, sondern ein Bild — dort hilft nur neue Texterkennung oder ein neu erstelltes Dokument. Rechtlich zählen verlinkte Dokumente trotzdem mit.

So gehst du vor — in Word:

1. Mit echten Formatvorlagen arbeiten: „Überschrift 1", „Überschrift 2", „Listenabsatz". Fett und größer formatierter Text ist keine Überschrift, auch wenn er so aussieht.
2. Alt-Texte setzen: Rechtsklick auf ein Bild → Alternativtext. Rein dekorative Bilder als dekorativ markieren.
3. Dokumentsprache festlegen unter Überprüfen → Sprache → Sprache für die Korrekturhilfen festlegen. Anderssprachige Zitate im Absatz separat auszeichnen.
4. Tabellen: Tabellenentwurf → Überschriftenzeile aktivieren und unter Layout → Überschriftenzeilen wiederholen setzen. Keine verbundenen Zellen, keine Tabellen fürs Layout.
5. Keine leeren Absätze für Abstände, keine manuellen Zeilenumbrüche in Fließtext. Titel und Autor in den Dokumenteigenschaften ausfüllen.
6. Überprüfen → Barrierefreiheit prüfen laufen lassen und die Meldungen abarbeiten.
7. Export: Datei → Exportieren → PDF/XPS-Dokument erstellen → Optionen, dort „Dokumentstrukturtags für Barrierefreiheit" aktivieren. Nicht über „Drucken → PDF" gehen — dabei gehen alle Tags verloren.

In InDesign: Absatzformate mit Export-Tags versehen (Absatzformat-Optionen → Tags für den Export), die Lesereihenfolge im Artikel-Bedienfeld festlegen, Alt-Texte über Objekt → Objektexportoptionen pflegen und beim Export unter Adobe PDF (interaktiv) bzw. im Bereich Erweitert PDF/UA-1 wählen. Mit Acrobat Pro prüfst du danach über Barrierefreiheit → Vollständige Prüfung und korrigierst den Tag-Baum.

Alternative, die fast immer besser ist: Biete den Inhalt zusätzlich als HTML-Seite an. Eine Preisliste, ein Anmeldeformular oder eine Speisekarte als normale WordPress-Seite ist auf dem Handy lesbar, per Suche findbar und ohne Zusatzaufwand barrierefrei. Das PDF bleibt für den Ausdruck.

Wo in WordPress: Dokumente liegen in der Mediathek; den Linktext mit Format und Größe schreibst du auf der verlinkenden Seite. Ältere Dokumente, die du nicht sofort nacharbeiten kannst, gehören in die Liste der bekannten Einschränkungen im Reiter Erklärung — mit einem Hinweis, wie Nutzer den Inhalt in anderer Form bekommen.

Wie du dauerhaft dranbleibst

Barrierefreiheit ist kein Projekt mit Enddatum, sondern eine Routine. Vier Anlässe genügen:

Halte deine Selbstbewertung in der BFSG-Checkliste aktuell und erzeuge nach größeren Änderungen einen neuen PDF-Prüfbericht. Damit hast du dokumentiert, was du wann geprüft und entschieden hast — genau das ist im Zweifel gefragt.

/wp-content/plugins/libration-accessibility/assets/frontend.js
/wp-content/plugins/libration-accessibility/assets/frontend.css
/wp-content/plugins/libration-accessibility/assets/libration-tts.js
/wp-content/plugins/libration-accessibility/assets/libration-easy-lang.js

Support

Fragen, Fehler, Wünsche? Schreib an support@librationtools.io — Pro-Kunden antworten wir mit Priorität. Hilfreich sind deine WordPress- und Plugin-Version (siehe Plugin-Liste) sowie eine kurze Beschreibung, was du erwartet und was du stattdessen gesehen hast.