Momentan ist Barrierefreiheit (noch) keine verpflichtende Eigenschaft für Themes, die im offiziellen Theme-Verzeichnis gelistet werden. Aber es gibt im Theme-Verzeichnis das Tag „accessibility-ready“.

Accessibility-ready Themes erfüllen die wichtigsten technischen Anforderung für Barrierefreiheit wie sie die WAI (Web Accessibility Initiative) in den Web Content Accessibility Guidelines (WCAG) aufgestellt hat.

Wenn ein Theme im WordPress.org-Theme-Verzeichnis unter dem Stichwort „accessibility-ready“ erscheint, erfüllt es folgende Bedingungen:

  1. Die Seite ist per Tastatur bedienbar
  2. Für Bedienelemente (Buttons, Links und Inputs) wird korrektes HTML verwendet
  3. Links sind verständlich und eindeutig gestaltet
  4. Formulare sind barrierefrei aufgebaut
  5. Das HTML ist semantisch korrekt
  6. HTML-Code ist mit Aria Landmarks gegliedert
  7. Es werden geeignete Farben und gute Kontraste gewählt
  8. Bilder und Medien sind für Seh- und Hörbehinderte zugänglich

In diesem Artikel schauen wir uns die Bedingungen für ein accessibility-ready Themes an und erklären, worum es dabei geht. Alle WordPress-Standard-Themes der Twenty-Reihe sind übrigens accessibility-ready.

1. Bedienbarkeit per Tastatur

  • Alle Links, Buttons und Formularfelder sind über die Tastatur erreichbar, auch Links in Dropdown-Submenüs. Die Enter-Taste aktiviert einen Link oder einen Button, die Leertaste aktiviert Checkboxen und Buttons. Die Pfeiltasten wählen Formular- und Bedienelemente an, z.B. Radio-Buttons, Auswahlfelder, Slider, Reiter oder Menüs mit Baumstruktur. Auch Autocomplete-Vorschläge sind per Pfeiltasten anwählbar.
  • Die style.css enthält die Angaben für a:focus: So können die Besucher erkennen, welches Element sie mit dem Tab gerade angewählt haben.
  • Das CSS für Screenreader-Texte ist so definiert, dass die Texte bei :focus sichtbar werden.
  • Die Tabulator-Reihenfolge wird nicht verändert.
  • Ein Skip-to-Content-Link, der bei :focus sichtbar wird, führt direkt zum zentralen Inhalt.

2. Korrektes HTML für Bedienelemente

  • Die HTML-Elemente button und a sind nicht austauschbar. Ein Button triggert eine JavaScript-Aktion oder ist Teil eines Formulars. Ein Link ist – ein Link und verweist auf eine interne oder externe URL.
  • Soll ein Link wie ein Button aussehen, kommt das Attribut role=”button” ins Spiel. Im HTML steht aber nach wie vor ein a.
  • Damit die Besucher mit Screenreader wissen, welche Funktion ein Element hat, sind manche Bedienelemente mit zusätzlichen Informationen ausgestattet. Das ist gerade bei Buttons wichtig. Auch Links, die eine bestimmte Aktion auslösen – wie z.B. der Edit-Link, die Post-Navigation oder zusätzlichen Menüs – haben ergänzende Screenreader-Texte.

3. Verständliche und eindeutige Links

  • In Anchor-Tags (Links) kommen keine Title-Attribut vor.
  • Von Links, die automatisch ein neues Browserfenster öffnen (target=”blank”), ist abzuraten.
    Es gilt das Prinzip, das Verhalten des Browsers möglichst wenig zu manipulieren. Wer einen Link in einem neuen Fenster öffnen möchte, kann das selbst entscheiden oder sich im Browser einstellen. Die Website sollte diese Entscheidung nicht erzwingen.
    EDIT: Wenn es trotzdem ein target_blank sein muss, sollte man den Nutzer darauf hinweisen. Entweder im Titel oder im Screenreader-text.
  • Im Stylesheet sind a:focus und a:active angegeben.
  • Links, die nicht Teil der Navigation sind, sind unterstrichen. Die Hervorhebung nur durch eine Farbe würde nicht ausreichen.
  • Alle Link enthalten eine valide URL. Beim “read more” Link ist der Titel des Artikels angegeben, auf den der Link verweist.

4. Barrierefreie Formulare

  • Alle Eingabefelder haben ein eindeutiges Label.
  • Formularfelder, die nur für sehende Besucherinnen eindeutig zu erkennen sind – z.B. das Suchfeld, das direkt neben dem “Suchen”-Button steht – erhalten erklärende Informationen über ein aria-label oder einen Screenreader-Text.
  • Felder, die inhaltlich zusammengehören (Radio-Buttons, Checkboxes, Eingabefelder), sind mit einem fieldset-Element als Gruppe gekennzeichnet.
  • Mit Hilfe des legend-Tags bekommt diese Gruppe eine Überschrift, die sie näher beschreibt, z.B. “Kontaktdaten”
  • Fehlermeldungen oder die Bestätigung, z.B. dass die Daten übertragen wurden, sind für alle Besucherinnen zugänglich.

5. Semantisch korrektes HTML

  • Theme-Templates müssen semantisch und hierarchisch korrekt gegliederte Überschriften (H1, H2, H3, H4, H5, H6) haben.
  • Semantisch bedeutet, dass die H1 immer die inhaltlich wichtigste Überschrift auf einer Seite kennzeichnet.
  • Es werden keine Überschriften übersprungen, auf eine H2 folgt eine H3 und nicht eine H4.

6. Orientierung mit ARIA Landmarks

  • Die Theme-Templates sind über Landmarks (z.B. banner, main, complementary, footer, search form, navigation) in sinnvolle Abschnitte gegliedert.
  • Die Landmarks main, banner und contentinfo werden nur einmal auf der Seite verwendet.
  • Es werden die semantischen HTML-Elemente header, footer, nav, aside etc verwendet.

7. Klare Farben und gute Kontraste

Die Wahl der Farben und der Kontrast zwischen diesen Farben hat einen großen Einfluss auf die Bedienbarkeit einer Website. Bei ungünstigen Lichtverhältnissen passiert es leicht, dass die Besucher das Suchfeld mit dem hellgrauen Rand nicht erkennen können. Auch farbenblinde Menschen oder Besucherinnen mit altersbedingten Sehschwächen können schwache Kontraste nur schwer oder gar nicht erkennen.

Das Ziel des WordPress-Projekts ist es, Farbkontraste gemäß WCAG AA level einzuhalten. Um diese Anforderung zu erfüllen, muss der Kontrast zwischen Hintergrund und Vordergrund mindestens das Verhältnis 4,5:1 erreichen. Für Texte in einer Schriftgröße von 24 px (bold: 19 px) genügt ein Verhältnis von 3,1:1.

  • Elemente mit unterschiedlichen Funktionen sollten sich nicht ausschließlich durch die Farbe unterscheiden, sondern auch durch Form, Schriftart und Abstände.
  • Der Farbkontrast zwischen Hintergrund und Vordergrund gilt auch für unterschiedliche Zustände, also z.B. :focus oder :hover, sofern diese Unterschiede nicht auf andere Art verdeutlicht werden.

Viele Themes bieten die Möglichkeit, z.B. über den Customizer Farben zu verändern. Theme-Entwickler können nicht verhindern, dass Nutzerinnen Farbkombinationen wählen, die nicht kontrastreich genug sind. Daher gilt in diesem Fall das Prinzip, dass ein Theme als barrierefrei gilt, wenn die voreingestellten Farben die Kriterien erfüllen.

8. Bilder und Medien für Seh- und Hörbehinderte zugänglich

  • Für alle Bilder wird im Code ein alt-Attribut ausgegeben, in dem Inhalt und Funktion des Bildes beschrieben werden. Das gilt auch für Beitragsbilder.
  • Auch für Icons und Iconfonts wird im Code ein alt-Tag ausgegeben.
    Icons ohne erklärenden Text haben einen Fallback-Text für Screenreader, so dass der Nutzer weiß, wofür das Icon steht.
  • Animierte Elemente wie Slider, ebenso wie Videos oder Audio-Dateien, starten nicht automatisch. Der Nutzer soll selbst entscheiden können, ob und wann er Slider-, Video- oder Audio-Inhalte abspielen möchte.

Fazit

Ein Theme, das sich accessibility-ready nennen darf, ist die perfekte Grundlage für eine barrierefreie WordPress-Website. Aber Vorsicht: Indem man ein accessibility-ready Theme installiert kriegt man nicht automatisch eine barrierefreie Seite. Das Theme ist nur der Ausgangspunkt, nicht die Lösung.

Dieser Artikel stammt ursprünglich aus dem Jahr 2017. Er wurde im Oktober 2019 überarbeitet und aktualisiert.