Barrierrefreie Website mit WordPress am Beispiel der EUTB Köln
Einleitung
Die Themeauswahl
Die nicht sichtbaren Features
Die Pluginauswahl und Anpassung
Die Navigation
Der Inhalt
Die Sprachen
Kleine Anpassungen
Fazit
Vorab: Wenn du erstmal lernen möchtest was barriefreie Websites eigentlich sind und warum man Websites so programmieren und gestalten sollte dann lies hier:
Barrierefreie Websites einfach erklärt.
Einleitung
Die ergänzende, unabhängige Teilhabeberatung des Vereins Selbstbestimmt Leben in Köln brauchte eine barrierefreie WordPress Website. Nach dem ersten Treffen war klar, dass die Website nicht nur barrierefrei im eigentlichen Sinne werden soll, sondern auch Menschen helfen soll, die eventuell erst gerade eingeschränkt wurden und dementsprechend vielleicht noch gar keine helfenden Technologien benutzen oder benutzen können. Auch alten Menschen, die sich vielleicht mit Computern noch nicht so auskennen sollte mit allen Mitteln geholfen werden.
Die Website: EUTB Köln
Die Themeauswahl
Um sich Arbeit zu sparen sucht man sich natürlich ein WordPress-Theme, dass bereits weitestgehend barrierefrei ist. Zusätzlich musste das Theme ausdrücklich nicht den neuen WordPress-Editor Gutenberg unterstützen, denn das diverse Team der EUTB wollte aufgrund der besseren Barrierefreiheit nur mit dem Classic-Editor arbeiten. Fündig wurde ich bei dem großartigen Frontend-Spezialist Sami Keijonen, der mit seinem Kuorinka Theme ein tolles, sogar kostenloses Theme für unsere Zwecke hatte. Trotzdem musste es natürlich noch auf die Wünsche der Kundin und meine Wünsche angepasst werden mittels eines programmierten Child-Themes.
Die nicht sichtbaren Features
Das Theme hat natürlich schon einiges mitgebracht wie z.B. den Direkt-zum-Inhalt-Button, der als erstes erscheint wenn man sich ohne Maus mit der „Tab“-Taste durch die Seite navigiert (Für Menschen die nicht mit der Maus oder über Touch navigieren). Alle Logos und Bilder wurden natürlich mit einem Alternativtext hinterlegt, denn die Kundin ist schließlich blind und kann sich die Bildbeschreibung nur so von ihrem Screenreader vorlesen lassen.
Das Theme brachte auch schon sogenannte Landmarks mit, die man mit helfenden Technologien praktikabel ansteuern kann.
Wenn wir uns jetzt an die Überschriftenhierarchie von HTML halten sollte also nicht mehr allzu viel schiefgehen können.
Die Pluginauswahl und Anpassung
Das umstrittenste Plugin in der Installation ist sicherlich das WP-Accessibility-Plugin. Das ist die Toolbar an der Seite für Kontrast und große Schrift. Ich hatte damals gesagt, dass das eingeschränkte Personen nicht brauchen, da Sie diese Funktionen doch selber über ihren Browser steuern können. Meine Kundin argumentierte, dass wenig technisch affine Menschen, alte Menschen oder Menschen, die erst gerade eingeschränkt wurden, dies aber vielleicht nicht können oder wissen. Da es um eine Beratungsstelle für genau diese Leute geht, sollte man sich auch um diese Kümmern. Das leuchtete mir dann auch ein, also bauten wir es ein.
Die Vergrößerungsfunktion ist relativ unproblematisch, sie vergrößert einfach alles wie es auch über das Keyboard mit der Tastenkombination Strg und + beziehungsweise Command und + am Mac funktioniert.
Die Kontrastfunktion müsste tatsächlich noch jemand testen, dafür haben wir leider noch niemanden gefunden. Es ist nicht immer alles einfach mit der Barrierefreiheit. Die Standardeinstellung sollte aber schon so einiges abdecken.
Hinzuprogrammiert kam noch der Leichte-Sprache-Button mit dem bekannten Icon, um auch diese Zielgruppe zu erreichen. Der Text dafür wurde von einer Expertin erstellt. Damit die Texte in leichter Sprache auch tatsächlich verständlich geschrieben sind, wurden Sie von Menschen der Zielgruppe daraufhin geprüft!
Für die Vorlesen-lassen-Funktion gab es leider kein Plugin, aber zum Glück stellt Responsive Voice für nicht-kommerzielle Zwecke ihren Service mit entprechender Lizenz zur Verfügung. Es musste also nur noch in die Templates eingearbeitet werden und das Ohr-Icon als On-Off-Schalter programmiert werden.
Auch diese Funktion brauchen natürlich keine Menschen, die z.B. schon lange blind sind, weil diese bereits helfende Technologien zum Vorlesen-lassen nutzen. Der Button ist also z.B. tatsächlich für Menschen, denen das hilft, weil das Lesen für Sie zu anstrengend ist.
Die Navigation
Sieht erstmal aus wie ne stinknormale Navigation, muss aber so programmiert sein, dass man sich mit der Tab-Taste durchtabben kann. Das hatte der Theme-Programmierer schon sehr gut hinbekommen. Ein kleines Problem gab es noch mit dem Screen-Reader JAWS meiner Kundin, der keine Unterseiten vorlas, weil es ein Focus-Problem gab, das aber mit ein wenig CSS gelöst werden konnte. Hier zeigt sich allerdings, dass man immer schon früh von Userinnen testen lassen sollte!
Der Inhalt
Der unkomplizierte Inhalt dieser Seiten ist relativ einfach barrierefrei zu halten, so lange man sich daran hält Bilder mit Alternativtext auszustatten, Links vernünftigt benennt und sich and die HTML-Überschriftenhierachie hält. Einer bitte der Kundin bin ich noch nachgegangen: JAWS hat in Listen bei jedem Unterpunkt den Punkt vorne mit vorgelesen. Also habe ich diesen versteckt und durch einen ersetzt, der nicht vorgelesen wird.
Die Blogarchivseite wurde auch optimiert. Wenn man durch Tab oder mit dem Screenreader von Link zu Link navigiert werden die „Weiterlesen“-Links nicht beachtet sondern nur die verlinkten Überschriften. Die Seite hat es allerdings nicht in die endgültige Website geschafft, da hier der Kundin eine einfache Seite für Ihren Bedarf reichte.
Die Sprachen
Auch wenn die EUTB ihre Beratung nur in deutsch anbietet (mit einer Dolmetscherin geht es aber natürlich!) sollte die Seite einmal kurz in vielen Sprachen erklären, was das Angebot der EUTB ist. Das ist in sofern problematisch, da ein Screenreader den Text dann auch in der richtigen Sprache vorlesen muss. Sonst hört sich das dann so an wie Lothar Matthäus auf Englisch und das will ja niemand.
Für die sieben Sprachen wurde dementsprechend die Seite so programmiert, dass das sogenannte „lang“-Attribut den Inhalt umschließt und der Screenreader so weiß, in welcher Sprache er vorlesen soll. Da Responsive Voice für nur wenige Sprachen vorhanden ist haben wir uns gegen das umprogrammieren für die Vorlesen-lassen-Funktion entschieden. Diese wird auf den Sprach-Seiten nicht dargestellt.
Kleine Anpassungen
Beim Testen fallen natürlich auch kleine Sachen auf wie z.B. der „•“, den das SEO-Plugin Yoast im Seitentitel (Text, der oben im Browsertab angezeigt wird) standardmäßig als Trennzeichen benutzt. Der wird blöderweise vorgelesen, was ja vollkommen unnötig ist. Umwandeln zu einem „–“ und alles ist gut. Von dieser Art gab es viele kleine Sachen zum umbauen. Früh Testen hilft!
Fazit
Mit meinen bereits sehr guten Kenntnissen zu barrierefreien Websites komme ich nicht ans Ziel. Das Testen einer Screenreader-Userin ist unheimlich wichtig und sollte schon früh im Website-Erstellungs-Prozess stattfinden und nicht erst mit der fertigen Website beginnen. Gemeinsam kann man so eine optimal Seite erstellen, die für die jeweilige Zielgruppe perfekt angepasst ist, und neben der generell barrierearmen Website noch mehr Menschen den Zugang erleichtert.
Danke
Neben dem Team der EUTB geht großer Dank an Rian Rietveld, die mit mir bereits im Vorfeld das Theme auf seine Tauglichkeit ausgetestet hat und mir überhaupt sehr viel zum Thema barrierefreie Websites beigebracht hat. Sie bietet jetzt beim A11Y Collective Kurse für Content-Ersteller und Programmierer an, die ich jedem wärmstens empfehlen kann!