Wer sich mit Barrierefreiheit und WordPress beschäftigt, begegnet früher oder später dem Plugin WP Accessibility von Joe Dolson. Ich habe mir angeschaut, was das Plugin macht und was man damit erreichen kann.
Das Plugin WP Accessibility ist für Seiten gedacht, die ein Theme nutzen, das nicht schon „von Haus aus“ accessibility-ready ist und das ein Stück barrierefreier werden soll.
Je nachdem wo das Theme noch Lücken hat kann man mit dem Plugin folgende Eigenschaften ergänzen:
- Skip-links einbauen für die Navigation per Tastatur
- ARIA landmark roles
- Labels hinzufügen für das WordPress-Such-Formular
- Target-Attribute aus Links entfernen (Links nicht in einem neuen Fenster öffnen)
- Änderungen im Tabindex entfernen
- Links immer unterstrichen darstellen
- Überflüssige Title-Attribute entfernen
- CSS für a:focus nachrüsten (wichtig für die Tastatur-Navigation)
- Lange Beschreibungen für Bilder erlauben
- Post-Titles für „read more“ Links ergänzen
Das Plugin installiert ausserdem zwei Toolbars, mit denen man die Schriftgröße und die Farb-Kontraste verändern kann. Ich persönlich empfinde das eher als Spielerei – die Toolbars tun nichts auf Code-Ebene, es verändert sich nur kurzfristig die Darstellung.
Fazit
Mit WP Accessibility lässt sich ein WordPress-Theme um eine Reihe von wichtigen Aspekten ergänzen. Skip-Links sind ein gutes Beispiel oder auch die Ergänzung der style.css durch Angaben für a:focus. Man muss dazu nichts in den Code eingreifen, sondern kann sich das, was man braucht, bequem aus einer Liste im Backend zusammenklicken.
Das Plugin hakt sich an definierten Punkten in den Theme-Code ein und ergänzt bzw. entfernt dort etwas, wie z.B. ein target=“blank“ bei Links oder überflüssige Title-Attribute.
Wie gut oder wie schlecht das klappt, hängt allerdings von der Code-Qualität des Themes ab. Wenn HTML-Elemente nicht korrekt verwendet werden (z.B. a, div oder span statt button) oder Structural Elements nicht vorkommen (header, main etc.) kann das ein Showstopper sein. Auch unsauberes CSS und JavaScript sind große Hindernisse für die Barrierefreiheit einer Seite.
Kann das Plugin WP Accessibility ein accessibility-ready Theme ersetzen?
Nein, denn das Plugin kommt an viele Dinge nicht ran. Standardkonformes HTML kriegt man nicht per Plugin in den Theme-Code rein. Auch Aspekte, die sich aus dem Zusammenspiel von Theme und Design ergeben – wie z.B. Farben –, kann man nur auf Theme-Ebene verändern. Ähnliches gilt für Details bei der Tastatur-Navigation wie z.B. die richtige focus-Reihenfolge bei der Navigation per Pfeiltaste. Die erschliesst sich erst aus dem Kontext und kann nicht in eine abstrakte Funktion gepackt werden.
Soll ich WP Accessibility dann überhaupt benutzen?
Unbedingt! Eine nicht perfekt barrierefreie Seite ist auf jeden Fall besser als eine Seite voller Hindernisse.
Dieser Artikel stammt ursprünglich aus dem Jahr 2017. Er wurde im Oktober 2019 überarbeitet und aktualisiert.
Kommentare
•
Target = blaknk ist heute kein Problem mehr, da per default ein neuer Tab und kein Fenster geöffnet wird. Man sollte per Title mitteilen, dass der Link ein neues Fenster öffnet, mehr nicht. Der Vorteil ist etwa bei Linklisten, dass man sich nicht merken muss, von welcher Seite man gekommen ist. Manche kennen ja die History-Funktion des Browsers nicht.
•
Hallo, Domingos,
Ich bin persönlich gar kein Freund von target_blank. Weder als Website-Bauer noch als Nutzer. Ich möchte selbst entscheiden, ob ich einen neuen Tab öffnen will oder nicht. Ich sehe übrigens den Unterschied zwischen neuem Fenster und neuem Tab nicht so ganz. In beiden Fällen ist der User plötzlich woanders – oft ohne es zu merken – und der Back-Button funktioniert nicht mehr.
Aber es gibt schon auch Fälle, wo ein neues Fenster sinnvoll ist. Wenn der Link zu einem riesenlangen Formular führt zum Beispiel.
Danke für den Hinweis mit der Mitteilung. Ich würde das im Screenreader-Text machen. Ich werd das mal im Artikel ergänzen.
In den WCAG-Richtlinien ist taget_blank kein K.O.-Kriterium so viel ich weiß, nur eine Empfehlung.
Schöne Grüße,
Kirsten