WordPress und Barrierefreiheit

Ein paar Erfahrungen beim Anpassen eines WordPress-Themes (So nennt WordPress die Handvoll Dateien, die Struktur und Layout und die Kommunikation mit der Datenbank steuern) an die B.I.T.V.-Richtlinien als Anregung für Weblog-Hoster und -Weiterentwickler:
  • Lob: Der WYSIWYG-Editor von WordPress generiert sauberen HTML-Code (im Gegensatz zu den verbreitetsten käuflichen Office-Anwendungen und auch anderen Weblog-Diensten wie z.B. blogg.de, wo u.a. noch b statt strong zum Hervorheben vergeben wird), wünschenswert wären noch Routinen zum Markieren von Sprachwechseln (mit Auswahlliste der Sprachkürzel) und Abkürzungen und eine bessere Kompatibilität des WYSIWYG-Editors zu verschiedenen Browsern
  • Um zu verhindern, dass auf einer Seite zahlreiche mit „more“ bzw. „weiterlesen“- endende Teaser die Orientierung für Benutzer von Screenreadern erschweren, Achtung, jetzt kommt einer 🙂

    kann z.B. im „storycontent“ die entsprechende Zeile wie folgt modifiziert werden:
    php the_content(„Weiterlesen “ . the_title(“,“,false), 0);
    So entsteht ein aussagekräftiger Link (Titel des Postings)

  • Alle Templates könnten „entmistet“ werden, vor allem im Headerbereich wird viel überflüssiger Quelltext erzeugt. Formulare und Navigation könnten klarer strukturiert (verschachtelte Listen) und besser gekennzeichnet sein.
  • Besonders bei Weblogs wird deutlich, wie wichtig die Einhaltung von Standards durch die Autoren ist, hier entstehen die meisten Fehler (nichtssagende Linkbezeichnungen, unstrukturierter Text, mangelnde Hierarchie der Überschriften, Smileyexzesse, Umgangssprache, Rechtschreibfehler, nicht markierte Sprachwechsel (auch bei Anglismen) etc.
  • Um die Zugänglichkeit zu testen, ist der Wave-Validator zu empfehlen, da bei den anderen Testverfahren der Fehler nur über die Zeilennummer im Quelltext auffindbar ist – dies funktioniert nicht bei dynamisch erzeugten Webseiten wie z.B. Weblogs und anderen CMS. Eine automatische Validierung ist aber nur ein Hilfsmittel, um „übersehene“ Fehler aufzuspüren. Die Validatoren erkennen z.B. nicht, ob ein Alternativtext sinnvoll ist, ein Sprachwechsel richtig gekennzeichnet, Die Seitenstruktur und die Funktionen intuitiv erfassbar sind.
  • auch das Einbinden anderer „sozialer Software“ mittels Icons, Tagwolken etc. schleust Barrieren wie JavaScript, alternativtextfreie Grafiken etc. ein. Hier macht vor allem del.icio.us keine gute Figur.
  • Vorsicht ist auch geboten beim Aktivieren von Plugins. In der WordPress-Standardinstallation ist z.B. noch kein Tagging möglich, gleicht man diesen Mangel z.B. mit „Jeromes Keywords“ aus, wird nicht XHTML-konformer Code eingeschleust.
  • Fazit (mit der Bitte um Widerspruch, Ergänzungen, Anregungen): Insgesamt positiver Eindruck mit Verbesserungspotential. WordPress ist gut geeignet als kostenneutrales Redaktionssystem für eine OPL-Webseite, die häufig aktualisiert wird (Neuerwerbungslisten, Öffnungszeiten, Möglichkeit der kolaborativen Erstellung und Pflege der inhalte sowie der Interaktion mit den Lesern). Das Layout lässt sich flexibel an das Corporate Design der Institution anpassen, die Navigation an die Anforderungen der Einrichtung. Die Software wird von einer aktiven Community ständig weiterentwickelt, es gibt Plugins für fast jede Funktion. Mit kleineren Anpassungen der Skripte (HTML, PHP, CSS) werden die Anforderungen der Barrierefreie Informationstechnik-Verordnung erfüllt.
  • AG

Advertisements

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s