Alle Beiträge von Maria Putzhuber

Barrierefreie Webredaktion mit WordPress

WordPress Editor
(c) Pixabay

Die Auswahl bzw. Programmierung barrierefreier Themes und Plugins werden als gegebene Voraussetzung angenommen, um auch Webinhalte mit WordPress barrierefrei zu erstellen. Barrierefrei oder accessible bedeutet benutzbar für Menschen mit Behinderung.
Technisch geht es dabei auch um die Unterstützung von assistiven Technologien, die von Menschen mit Sinnesbehinderungen verwendet werden. Vorallem wichtig sind:

  • Tastaturbedienbarkeit (z.B. von Menüs, Slidern, Accordeons, Kalendern),
  • klare Beschriftung von funktionalen Bildern, Bedienelementen und Links und
  • eine sinnvolle (HTML5) Struktur im Quellcode für Screenreader-Tauglichkeit,
  • für NutzerInnen mit Seheinschränkungen ausreichende Kontraste und
  • Zoombarkeit auch auf Touchscreens.

Messbar und damit testbar wird das anhand des W3C und ISO Standards „WCAG – Web Content Accessibility Guidelines“, derzeit in der Version 2.0.

Für Websites und Apps der öffentlichen Hand besteht eine mittlerweile EU weite gesetzliche Verpflichtung zu WCAG 2.0 Level AA. Einen kurzen Überblick dazu gibt es in einer Präsentation des BKA zur EU Richtlinie der EU , PDF oder im Verwaltungs Wiki.

Für Unternehmenswebsites, die Güter oder Dienstleistungen verkaufen, gibt es in Österreich, gesetzlich  über das BBGstG strenger geregelt als in Deutschland, die Möglichkeit Barrierefreiheit im Einzelfall über ein Schlichtungsverfahren einzufordern, d.h. zumindest das Recht auf Schadenersatz, wenn z.B. ein Ticket nicht online gekauft werden kann, weil der Ticketshop unzugänglich ist.

Die Verantwortung der Redaktion für eine barrierefreie Website wird in der Regel unterschätzt. Gerade bei WordPress, das eine sehr einfache und selbsterklärende Redaktionsoberfläche hat, ist eine Einschulung in die richtige Bedienung nicht selbstverständlich. Dabei wird beim Erstellen von Webinhalten so einiges falsch gemacht und eine ursprünglich vorbildliche WCAG 2.0 AA konforme Website ist es sehr schnell nicht mehr.

Hier folgen nun einige Hinweise für den Redaktionsalltag mit WordPress zur Einhaltung von Barrierefreiheit nach WCAG 2.0 AA Vorgaben, in Klammern stehen die entsprechenden Richtlinien Nummern zum Nachlesen in der WCAG Quickreference.

Einbindung von Bildern (1.1)

Für Screenreadertauglichkeit benötigen Bilder einen Textersatz.

Dateinamen von Bildern sollten keine Umlaute, Sonderzeichen oder Leerzeichen enthalten und sinnvoll kurz sein. Beim Hochladen von Bildern in die Mediathek wird automatisch der Dateiname in das Titelfeld übernommen. Im Titelfeld sollte dann allerdings besser der Dateiname durch „richtigen Text“ überschrieben werden. Die Suchfunktion in der Mediathek funktioniert besser bei sinnvollem Text.

Wichtiger ist das Befüllen des Feldes „Alternativer Text“. Das ist die Information, die Screenreader Software und Suchmaschinen auslesen können. Wieder sinnvoll kurz ist die Devise. Eine pragmatische Lösung ist, Titel und Alternativ-Text gleich zu befüllen und daran zu denken, dass auch blinde LeserInnen an Informationsüberflutung leiden.

Bei nicht wichtigen, nicht verlinkten Bildern darf der Alternativtext leer bleiben. WordPress fügt dann korrekt ein leeres alt-Attribut alt=““ ein und Screenreader ignorieren das Bild.

Verlinkte Bilder müssen unbedingt einen Alternativtext erhalten.

Beitragsbilder (Featured Images) werden üblicherweise als Thumbnails auf Übersichtsseiten angezeigt und sind dort zum Beitrag verlinkt. Auch Galeriebilder sind verlinkte Bilder (zur Großansicht) und benötigen einen individuellen Alternativtext. Alternativtexte wie „Bild1, Bild2, Bild3“ sind nicht aussagekräftig und also ungenügend.

Bei verlinkten Bildern soll das Linkziel im Feld „Alternativer Text“ stehen, also z.B. der verlinkte Seitenname statt einer Bildbeschreibung, bei Galeriebildern eine pragmatisch kurze Bildinhaltsbeschreibung.

Das Feld „Beschriftung“ eignet sich für Copyright Angaben und Text, der unter einem Bild stehen soll. Es kann auch leer bleiben. Das Feld „Beschreibung“ dient nur für interne Zusatzinformationen im Backend.

Fazit: Barrierefreie Bildeinbindung sollte einem einheitlichen Konzept folgen und bedeutet Mehrarbeit für die Redaktion. Ein Tutorial für die richtige Formulierung von Alternativtext findet sich auf der W3C Website.

Videos (1.2)

Hier geht es um Textersatz für Ton und Bild: Untertitel für die Toninformation, Audio Deskription für die Bildinfo und / oder Transkription für beides.

Externe Videos (z.B. von YouTube oder Vimeo und vielen anderen Anbietern) lassen sich sehr simpel über den Videolink einfügen. WordPress bindet sie mittlerweile über einen gut tastaturbedienbaren und beschrifteten HTML5 Player ein.

Für Untertitelung müssen die Video Produzenten sorgen. Sie ist notwendig, damit gehörlose und hörbehinderte Menschen sie auch ohne bzw. mit kaum hörbarem Ton verstehen können.

Bei YouTube gibt es gute Anleitungen zur Untertitelung. Die automatisch erstellten Captions sind auf deutsch noch nicht von ausreichender Qualität. Sie können aber als Ausgangspunkt zur Bearbeitung verwendet werden. Mehr Information zu Video Barrierefreiheit und weiterführende Links bietet der Leitfaden für barrierefreie Online-Videos von BIK für alle.

Fazit: Wenn eingebundene Videos inhaltlich wichtige, sonst nicht transportierte Information enthalten, d.h. mehr sind als ein netter Zusatz, müssen sie barrierefrei sein, auch wenn sie extern gehostet sind.

Textstruktur und HTML Semantik (1.3)

Hier geht es neben einer guten visuellen Struktur vorallem um Screenreadertauglichkeit.

Wichtig ist zuallererst keine Formatierungsangaben aus z.B. Office Programmen zu übernehmen. Im visuellen Editor gibt es dafür den Button „T“ – „als Text einfügen“. Texte können zwar auch nachträglich mit dem Radiergummi Button („Formatierung löschen“) von unnötigen spans, divs und Microsoft classes befreit werden, das funktioniert aber nicht immer zuverlässig. Auch über den Reiter Text (den Texteditor, der auch HTML Code anzeigt) kann Inhalt bereinigt eingefügt werden.

Die Formatierung soll im Editor erfolgen. Semantisch und mit Screenreadern über Kurztasten ansteuerbar sind Überschriften, Absätze, Listen, Zitate. Fettdruck und Kursiv werden von Screenreadern bei entsprechender Konfiguration auch interpretiert, ebenso  Sonderzeichen (* _ > | …) , durchgestrichener Text (z.b. für „Statt“ Preise oder korrigierten Text) üblicherweise nicht.

Überschriften

Die inhaltliche Überschrift einer Seite (üblicherweise automatisch eingefügt über das Titelfeld) sollte eine <h1> sein, Zwischenüberschriften dann in hierarchischer Folge <h2>, <h3>…

Überschriften Levels werden in der Praxis oft übersprungen, weil die jeweilige Formatierung nicht passt. Sie sollte im CSS (dem ausgelagerten Stylesheet mit Formatierungsangaben) angepasst werden, damit die RedakteurInnen die richtigen verwenden können.

Zwischenüberschriften sind besser als Fettdruck <strong>, weil man mit Screenreader direkt dorthin springen, also einen Text quasi via Überschriften scannen kann und weil die Formatierung auch visuell besser steuerbar ist (margin-top höher als margin-bottom, größere Schrift, andere Farbe).

Absätze und Abstände

Absätze erzeugt man im Editor einfach durch eine Leerzeile. Vielfach sind redaktionell größere Abstände gewünscht als ursprünglich vorgesehen. Auch hier sollte das CSS angepasst werden, damit nicht durch Leerzeichen, leere Absätze oder leere Überschriften zusätzliche visuelle Abstände generiert werden, die die Maschinlesbarkeit und responsive Anpassung stören. Ein Screenreader würde „leer, leer, leer“ lesen, am Smartphone würden Löcher im Text visuell stören.

Die Einbindung von Contentbildern neben dem Text in WordPress verursacht manchmal Probleme, wenn der Text nicht lang genug ist, um das Bild zu umfließen. RedakteurInnen helfen sich mit Leerzeilen, die aber bei unterschiedlichen Bildschirmbreiten und Screenreader Nutzung stören.

Für das float clearing bei links- oder rechtsbündig stehenden Bildern könnte ein Quicktag verwendet werden (z.B. über das Plugin „AddQuicktag“), der ein Clearing Element wie <div style=“clear:both;“>&nbsp;</div> einfügt. Der Inlinestyle wirkt auch bereits im Editor.

Die RedakteurInnen können dann unterhalb des Bildes weiterschreiben oder ein neues Bild einfügen, ohne vorher unzählige unsinnige Leerzeilen einzufügen.

Quicktag

Listen

Listen für Aufzählungen bieten den Vorteil von sowohl visueller als auch semantischer Struktur. Ihr Einsatz ist also rundum positiv. Man muss sie allerdings korrekt machen, z.B. darf man nicht für jeden Listenpunkt eine eigene Liste (UL) erstellen oder nur der Optik halber Listen für einen einzelnen Aufzählungspunkt anlegen. Screenreader haben den Mehrwert von zusätzlicher Information (es ist eine Liste mit xx Listenpunkten) und können Listen direkt anspringen bzw. überspringen. Wenn aber z.b. jeder Listenpunkt eine eigene Liste wäre, bekämen sie die gleiche Struktur-Information x-mal.

Geschlechtergerechte Sprache

Blinde NutzerInnen sind üblicherweise von den Versuchen, Sprache geschlechtsneutral zu formulieren, nicht begeistert. Die ideale Lösung gibt es nicht. Als Ausrede, nicht zu gendern, kann man das aber nicht verwenden. Bei Binnen-I machen Sprachausgaben in der Regel – wie sie sollen – eine kleine Sprechpause, Slash / wird als Schrägstrich angesagt, * oder _  je nach Screenreaderversion und Konfiguration möglicherweise unterschiedlich.

Fazit: Es zählt nicht nur die Optik, für eine barrierefreie Website muss auch der Quellcode Qualitätsstandards entsprechen.

Über Themes oder Plugins erstellte Contentelemente (betrifft mehrere WCAG Richtlinien)

Bei zusätzlichen Contentelementen, die nicht dem Standardrepertoir von WordPress (ein Editorfeld für Text, Bilder etc.) entsprechen, ist Vorsicht und auch technische Fachkenntnis gefordert, die RedakteurInnen oft nicht haben werden.

Über ein Bootstrap Theme oder Plugin eingefügte Contentelemente (Grid, Accordeon, Karrusell etc.) sind in der Regel ganz gut zugänglich, weil sie die Accessibilityfeatures des Bootstrap Frameworks nützen. Bootstrap ist aber eben ein eigenes Framework, zusätzlich zu WordPress, löst Dinge anders als WordPress und bläst den Quellcode auf. Bei Plugins, die auf jQuery basieren, ist die Barrierefreiheit des jeweiligen jQuery Codes ausschlaggebend.

Mit visuellen Themebuildern erstellte Contentelemente müssen vorab unbedingt getestet werden hinsichtlich Struktur, leerer Links und Tastaturbedienbarkeit. Visuelle Themebuilder verursachen häufig Performanceprobleme beim Editieren und auch in der Ausgabe.

Bei Kalendern ist in der Regel die Listenansicht barrierefrei, die Kalenderansicht mit Popups für die einzelnen Tage möglicherweise nicht. Auch Filterfunktionen sind häufig nicht tastaturbedienbar.

Beim Erstellen von Formularen mit Formular Plugins muss darauf geachtet werden, dass alle Formularfelder mit Labels versehen werden. Das verwendete Plugin muss das natürlich auch ermöglichen.

Redaktionell erstellte Daten-Tabellen müssen zumindest mit Tableheaderzellen (TH) versehen werden, um screenreadertauglich zu sein.

Slider müssen sich mit Maus und beim Hineintabben mit Tastatur stoppen lassen oder einen Stopp Button haben. Die Bedienelemente müssen beschriftet sein. Die Bilder brauchen Alternativtexte.

Bei Galerie Plugins müssen ebenso Alternativtexte eingepflegt werden. Die Lightbox muss Fokus erhalten und sich mit Tastatur schließen lassen.

Fazit: WordPress NutzerInnen ohne entsprechende technische Fachkenntnisse sollten besser keine zusätzlichen Plugins installieren, wenn Barrierefreiheit ein Thema ist.

Farbe, Kontraste, Stylinganpassungen (1.4)

RedakteurInnen sollten das Styling der Website nicht über den Editor ändern, z.B. Farben oder Einrückungen oder Abstände. Es werden Inline Styles eingefügt, die möglicherweise die Responsivität stören. Eine Einrückung oder erhöhte Abstände bringen das Design am Smartphone durcheinander.

Bei Änderung der Farben z.b. von hervorzuhebendem Text passen möglicherweise die ursprünglich korrekten Kontrastwerte nicht mehr. Unterstreichungen sind Links vorbehalten und nicht verlinkte unterstrichene Texte sind auch aus Usabilitysicht schlecht.

Man kann nicht benötigte Buttons im Tiny Mce Editor deaktivieren oder muss RedakteurInnen darauf hinweisen, was sie möglicherweise verursachen.

Fazit: Nachträglich gewünschte Stylingänderungen sollten besser im CSS ergänzt werden.

Bildtext (1.4)

Werbegrafiken, Aktionenteaser, Heroimages… manchmal reichen die typografischen Möglichkeiten im Web nicht aus und Text wird als Grafik eingefügt. Auch hier ist ein der Bild- bzw. Linkinformation entsprechender Alternativtext ein Muss.

Wenn irgend möglich sollte Text grundsätzlich in Textform vorhanden sein – damit die Information auch bei Screenreadern und Suchmaschinen ankommt.

In visueller Hinsicht ist Text in Bildform nicht mehr so problematisch wie noch vor einigen Jahren, weil Browser besser zoomen und Bildschirm-Auflösungen besser werden. Bilder werden aber in responsiven Ansichten kleiner und Bildtext damit wieder schwerer lesbar. Ausreichende Kontrastwerte sind auch hier ein Thema.

Fazit: Text als Text ist besser für Barrierefreiheit, mobile Geräte und Suchmaschinen.

Seitentitel (2.4)

Ein Theme bzw. SEO Plugin sollte so konfiguriert sein, dass zuerst der Titel einer Seite / eines Beitrages und dann der Websitename im <title> Element stehen.

Der Permalink wird aus dem Seitentitel generiert, kann nachträglich verändert werden und sollte idealerweise nicht zu lang sein.

Bei inhaltlich ähnlichen Subseiten in verschiedenen Bereichen der Website (z.B. mehreren Kontaktseiten) kann es vorkommen, dass der Seitentitel nicht mehr eindeutig ist, wie von den WCAG vorgeschrieben. Das ist vorallem ein Problem für blinde NutzerInnen.

Fazit: Der Seitentitel ist suchmaschinenrelevant, aber nicht zum Unterbringen von vielen Suchmaschinen Keywords gedacht. Denken Sie daran, wie er von einer Sprachausgabe vorgelesen klingt.

Im Kontext verständliche Links (2.4)

Auch hier geht es vorallem um Screenreadertauglichkeit. Links dürfen nicht leer sein, z.b. nur ein Icon oder Bild ohne Alternatitext enthalten, und sie müssen im Kontext verständlich sein. Diese Regel betrifft mehrere gleichlautende Links auf einer Seite wie „Mehr lesen“, oder „Download“ oder „hier“.

Der unmittelbare Kontext, z.B. gleicher Absatz, Listenpunkt oder <article> mit Überschrift oder eine Tabelle bei Vorhandensein von Tableheadern reicht aus, damit wiederholte Linkbezeichnungen für blinde NutzerInnen zuordenbar bleiben.

Eine Linkbezeichnung wie: „Die Einladung zur Pressekonferenz finden Sie hier.“ ist zwar nicht vollständig unzugänglich, sehr sehr viel besser ist aber ein selbsterklärender Link wie: „Hier finden Sie die Einladung zur Pressekonferenz, PDF.“

Auf Wechsel des Dateiformats sollte bereits im Link hingewiesen werden. Bei sehr großen Downloads sollte auch die Dateigröße hingeschrieben werden: „Name des Dokuments, PDF, 2 MB“. Hintergrund ist, dass HTML mit assistiven Technologien (wie Screenreader, Zoomsoftware..) besser bedienbar ist als PDF und man vor dem Anklicken eines Downloads wissen möchte, was ca. passieren wird.

PDFs werden in WordPress über die Mediathek eingefügt, über den „Datei hinzufügen“ Button. Ins Titelfeld im Einfügedialog gehört dann die Linkbezeichnung, samt Datei- und gegebenenfalls Größeninformation.

Datei Einfügedialog

PDF Links sollten besser in einem neuen Reiter/Fenster öffnen. Dazu muss man nach dem Einfügen den PDF Link nochmals anklicken und mit dem angezeigten Bleistift und dann Zahnrad Icon, das den Link Dialog öffnet, bearbeiten.

Link Einfuegedialog

Beim Setzen von Links kann man also anhaken, dass sie in einem neuen Fenster öffnen sollen. Aus Accessiblitysicht ist das eher ein Nachteil. Der Zurückbutton wird gestört, besonders auf mobilen Geräten verliert man den Überblick bei vielen geöffneten Seiten. Man sollte neue Seiten besser selbst gesteuert in einem neuen Reiter aufmachen (mit der rechten Maustaste oder strg Taste). Trotzdem ist es meist Kundenwunsch und eine gängige Praxis bei externen Links. Screenreader bekommen bei externen Links die Information, dass es sich um solche handelt.

Empfehlungen, zusätzliche Information für Screenreader (wie „öffnet neues Fenster“) in einem Link title-Attribut unterzubringen, sind im Redaktionsalltag mit WordPress eher unrealistische Fleißaufgaben. Themeautoren können das eher berücksichtigen.

Links sollten sprechend sein und nicht den gesamten html Pfad anzeigen:
schlecht: https://www.w3.org/WAI/WCAG20/quickref/#navigation-mechanisms-refs
besser: WCAG 2.0 Schnellreferenz- 2.4.4 Linkzweck (im Kontext)

Fazit: Formulieren Sie Links möglichst selbsterklärend und gut lesbar.

Sprachwechsel (3.1)

Bei einer anderen Sprachversion einer Website ist üblicherweise auch der umgebende Rahmen, das Menü etc. anderssprachig und die Sprachangabe wird im html Element gesetzt. Fremdsprachiger Inhalt innerhalb einer deutschsprachigen Seite muss aber redaktionell mit einem Sprachattribut gekennzeichnet werden, damit Screenreader die Sprache umschalten und mit der richtigen Aussprache vorlesen. Sinnvoll ist das nur bei längeren Passagen, ganzen Absätzen oder Phrasen, nicht bei einzelnen Wörtern, vorallem nicht bei gängigen Anglizismen. Anglizismen sollten generell sparsam verwendet werden.

Entweder macht man die Sprachauszeichnung manuell im Texteditor, z.B. <p lang=“en“>This is a paragraph in english.</p> oder über einen zur Verfügung gestellten Quicktag, der ein <div lang=“en“></div> um einen markierten Text legt.

Fazit: Am besten kommt Sprachwechsel innerhalb einer Seite gar nicht vor.

Einfache Sprache (3.1)

Einfache Sprache, „Easy to read“ Text ist eine WCAG Level AAA Vorgabe. Es handelt sich dabei um Übersetzungen von Standardtexten in einfache Sprache, die besonderen Kriterien genügt und von Menschen mit intellektuellen oder sprachlichen Einschränkungen besser verstanden werden kann. Webtexte auf komplexeren Websites können dem üblicherweise nicht entsprechen.

Grundsätzlich sollte Webtext aber webtauglicher formuliert werden als das in der Regel der Fall ist. Das ist aber eigenes nicht CMS spezifisches Thema.

Barrierefreiheit testen

Wave

Barrierefreie Texteinpflege ist Qualitätsarbeit, die Wertschätzung verdient. Sie ist nicht selbstverständlich. RedakteurInnen, die sich darum bemühen, haben vermutlich auch den Wunsch zu kontrollieren, ob sie alles richtig machen.

Eine gute Möglichkeit dazu bietet der Chrome Browser mit dem Addon WAVE. Über den WAVE Button bekommt man dort automatisch testbare Ergebnisse. Rot markierte Fehler sind sehr wahrscheinlich Fehler, bei gelb markierten Warnungen gibt es Interpretationsspielraum. Der „Fähnchen“ Button zeigt Details, in der „No Styles“ Ansicht kann man die Fehler anspringen. Der Reiter Contrast zeigt Kontrastfehler. WAVE ist ursprünglich ein Online Tool von webaim.org.

Barrierefreies Backend

Content Management Systeme sollten auch in der Redaktionsoberfläche barrierefrei sein. Auch dafür gibt es eine W3C Recommendation: die ATAG, Autoring Tool Accessibility Guidelines. Die meisten Systeme entsprechen diesen nicht vollständig. Auch WordPress nicht. Allerdings ist das Backend von WordPress im Vergleich immer noch relativ einfach bedienbar, es gibt gute Bestrebungen in der WordPress Core Entwicklung hinsichtlich Accessibility (Make WordPress Accessible) und es gibt auch Screenreader NutzerInnen, die mit WordPress ganz gut zurechtkommen.

 

Accessibility Checkliste – Formulare

Über barrierefreie Formulare ist soweit alles gesagt worden, so z.B. von Tomas Caspers: Barrierefreie Formulare (2011) oder Roger Hudson: Accessible Forms using WCAG 2.0  (2008). Über barrierefreie Formularvalidierung mit HTML 5 und WAI-ARIA gibt es interessante Artikel mit Beispielen von Paul J. Adam: Accessible Client Side Form Validation (2012) oder Ian Oxley: HTML5 Form Validation (2013). Für Detailfragen sind die Techniken für WCAG 2.0 des W3C ein guter Anhaltspunkt.

Infos zu HTML5 und WAI-ARIA in aller Ausführlichkeit liefert ebenso der W3C – www.w3.org/TR/wai-aria-practices, www.w3.org/TR/aria-in-html. Die Techniques for WCAG 2.0 sind 2014 um einige ARIA Techniken ergänzt worden.

Joshue O Connor: Pro HTML5 Accessibility, Apress 2012 ist ein empfehlenswertes Fachbuch zum Thema.

Eine sehr ansprechende Präsentation von HTML5 Formularfeatures findet sich bei Dive into HTML5 (laufend aktualisiert), basierend auf dem Buch von Mark Pilgrim, HTML5: Up & Running (2010).
Das HTML 5 Handbuch von Stefan Münz und Clemens Gull (2013) ist auch online verfügbar und gibt umfassende Information zu Formularen auf deutsch, allerdings wie Dive into HTML 5 ohne Accessibility Fokus [ergänzt 3.6.2014].

Hier finden Sie nun einige Anmerkungen zum grundsätzlichen Verständnis barrierefreier Formulargestaltung und zum Stand der Dinge bezüglich HTML5 und WAI-ARIA. Genaueres lesen Sie in den obengenannten Fachartikeln. Diese Liste soll als Gedächtnisauffrischung dienen, um sich zu vergewissern, dass man bei der Erstellung der barrierefreien HTML Formulare nichts übersehen hat.

Diese Liste wird aktualisiert, wenn es sich ergibt, zuletzt: 3.6. 2014.

Accessibility Checkliste – Formulare weiterlesen