Nur ein Blog Accessibility Projekt – Teil 5

Der nachfolgende Artikel ist eine Zusammenfassung der Session „Nur ein Blog am Prüfstand – Wir testen live die Barrierefreiheit“ am BarCamp Vienna 2007.

Martin Ladstätter hat dabei mein Blog auf Probleme mit Accessibility analysiert. Gemeinsam haben wir dann einige der interessantesten Punkt herausgenommen und präsentiert.

Manches wird einigen von euch banal vorkommen. Wie mir Martin versicherte und ich selbst schon feststellen musste finden sich alle genannten Probleme auch auf teuer bezahlten und von „Profis“ gestalteten Websites. Daher kann man es wohl nicht oft genug erwähnen.

Anmerkung: Je nach Zeitpunkt des Lesens dieses Artikels sind einige oder alle dieser Probleme (hoffentlich) nicht mehr in meinem Blog auffindbar. Ich habe jedoch versucht sie so zu beschreiben, dass sie auch ohne dieses plastische Beispiel nachvollziehbar sind. Der Artikel erscheint außerdem im Rahmen der Accessbility Blog Parade.

Nun aber zur Analyse meines Weblogs bzw. zu den Inhalten unserer BarCamp Session.

Navigation – leere Felder

Hier muss ich kurz auf die Internas der von mir verwendeten Blog Software „Serendipity“ eingehen. Diese erlaubt es, dass man bestimmte Eigenschaften von Templates in der Verwaltungsoberfläche steuert. So kann man auch die Links und deren Beschriftung in der horizontalen Navigationsleiste über ein Formular eingeben. Um zwischen zwei Links einen größeren Abstand einzufügen habe ich einfach ein Formularfeld freigelassen. Genau so etwas sollte man nie tun.

Was passierte? Es wurde folgender Code eingefügt:

<li><a href=“/blog/impressum.html“ title=“Impressum“>Impressum</a></li>
<li><a href=““ title=““></a></li>
<li><a href=“/blog/pages/contactform.html“ title=“Kontakt“>Kontakt</a></li>

Bei der Bedienung mit einer Maus fällt einem dabei natürlich nichts auf. Muss man aber die Website mit der Tastatur bedienen und bewegt sich z.B. mit der Tabulator Taste von Auswahlpunkt zu Auswahlpunkt so landet man einfach bei einem leeren Feld.

Außerdem ist die Verwendung des Attributs „title“ in dieser Form nicht sinnvoll, da es den gleichen Inhalt hat wie der Linktitel selbst.

Navigation – Sprungmarken funktionieren nicht

Für Menschen die mit einem Screen Reader oder mittels Brailzeile arbeiten kann man einiges anbieten, um diesen die Navigation zu erleichtern. „Skiplinks“ oder „Sprungmarken“ werden am Anfang einer Seite – nicht sichtbar – plaziert um von dort direkt auf bestimmte wichtige Seitenelemente navigieren zu können ohne sich den gesamten Text vorlesen lassen zu müssen. Mit gesamten Text ist wirklich der gesamte Text gemeint – von der Kopf- bis zur Fußzeile.

Ihr könnt euch vielleicht vorstellen, wie mühsam das sein kann. Insbesondere wenn man zum Lesen von 5 Blogbeiträgen immer wieder alles (die Navigation, den Blogtitel, alles Seitenleistentexte,…) sich neu vorlesen lassen müsste ohne direkt auf die Navigation, auf den jeweiligen Artikel, auf die Seitenleiste springen zu können. In der CSS Datei kann man nun die Sprungmarken entsprechend formatieren, sodass sie für „sehende“ LeserInnen nicht weiter auffallen. Die Entwickler meines Templates haben vorbildlich an solche Sprungmarken gedacht, in meiner CSS Datei war dabei folgendes zu finden:

#skiplinks {
display: none;
}

Das war aber zuviel des Guten, da auch einige Screenreader das „display:none“ so interpretieren, dass man den somit formatierten Text nicht vorlesen soll/muss.

Martin hat stattdessen folgendes vorgeschlagen:

#skiplinks {
position:absolute; left:-1000px; top:-1000px; width:1px; height:
1px; overflow:hidden; display:inline;}

Damit setzt man die Sprungmarken in einen nichtsichtbaren Bereich, diese werden aber bei Bedarf trotzdem vorgelesen oder auf der Braillezeile angezeigt. Auch sollten Sprungmarken sichtbar werden, wenn man mit der Tastatur surft (mit der Tab-Taste).

Suche

Die Suchfunktion hatte ein besonderes Problem. In der früheren Version war neben dem Eingabefeld für das zu suchende Wort kein Eingabebutton vorhanden. Man konnte somit nur das Wort eintippen und mittels drücken der Enter-Taste den Suchbefehl absenden. Nicht jeder Screenreader macht hier Probleme, aber was passiert bei einigen (wie z.B. WebFormator):

Man springt zum ersten Eingabefeld auf der Seite (das Suchfeld). Um im WebFormator ein Eingabefeld auszufüllen, muss man es mit Enter öffnen, den Begriff eintragen und mit Enter wieder schließen. Und genau das ist der Grund, warum man die Suche nicht abschicken kann, weil Enter eben nur immer wieder das Eingabefeld öffnet und schließt.

Um das ganze zu verdeutlichen hat Martin einen solchen Versuch auf Video (bei Youtube) festgehalten. Bei einem entsprechend ausgezeichneten Absendebutton würde das nicht passieren.

Schriftvergrößerung

Endlich ist mein Blog ein positives Beispiel 🙂 Für viele Menschen mit einer Sehbeeinträchtigung (und das sind mehr als man allgemein denkt) reicht es oft vollkommen aus, wenn sie die Schrift auf einer Website etwas vergrößern können.

Dazu darf im CSS die Schriftgröße nicht absolut sondern nur relativ angegeben sein. In meinem Weblog dürfte diese Vergrößerungsmöglichkeit recht gut funktionieren. Wichtig ist, dass das Layout zumindest bei einer zweistufigen Vergrößerung nicht total durcheinander kommen sollte, Texte nicht ineinander rutschen und die Seite dann kaum mehr lesbar ist.

Überschriften

Überschriften sollte man immer mittels Markup auszeichnen bzw. formatieren. Die WCAG Richtlinien besagen:

Verwenden Sie Überschriften-Elemente, um die Struktur eines Dokuments darzustellen und verwenden Sie sie gemäß der Spezifikation.

Das heißt Headlines sollten mit <h1> ausgezeichnet werden und ebenso Subheadlines verwendet werden, die mit <h2>, <h3>,.. auszuzeichnen sind.

Bei meinem Template ergab sich nun folgendes Problem. Im Kopf des Blogs werden der Blogtitel sowie eine Blogbeschreibung angezeigt, die mit <h1> bzw. <h2> ausgezeichnet wurden. Das eigentlich Essentielle – die jeweiligen Titel der Blogartikel – sind erst mit <h4> versehen. Menschen, die sich über Screenreader einen ersten Überblick über eine Seite machen wollen, bekommen damit eine nicht gewollte Gewichtung der Überschriften vermittelt und müssen sich immer wieder durch den Blogtitel etc. bewegen um an eine weitere Artikelüberschrift zu kommen.

Wie mühsam das sein kann hört man ausschnittsweise in der Audiodatei ohnesprungmarken.wav (1,7 MByte). Anmerkung: Ich habe zu dieser Strukturierung meines Blogs auch schon andere Meinungen erhalten, die auch den Header mit einem Überschriften-Elemtent versehen wollen. Dazu wird es vielleicht noch einen Gastbeitrag geben. Schussendlich ist dies auch eine Frage der Akzentierung der Schwerpunkte eines Blogs über die man diskutieren kann.

Bildbeschriftung

Bilder sollten immer mit einem alt Attribut versehen werden, da Screen-Reader BenutzerInnen diesen Alternativtext benötigen. Die Bilder sollten dabei so kurz und aussagekräftig wie möglich beschrieben werden. Es ist nicht nötig im Alternativtext darauf hinzuweisen, dass ein Bild zu sehen ist und der Hinweis auf Copyright-Vermerke bei Fotos hat dort auch nicht seinen Platz.

„Sonnenuntergang am Meeresstrand“ passt durchaus, „Man sieht eine rote Sonne wie sie halb am Himmel stehend den Strand beleuchtet, das Meer schimmert dunkelblau und eine Wolke ist am rechten Rand zu sehen“ wird in kaum einen Fall – außer vielleicht auf einer Website eines Fotokünstlers – eine wirklich wichtige Information darstellen.

Sofern man das Bild selbst verlinkt sollte im alt Text auch das Linkziel angegeben sein. Das title Attribut ist dabei nicht zu verwenden, das es viele Screenreader ausgeschalten haben. Icons neben Textlinks (die z.B. auf externe Links hinweisen) und grafische Listenpunkte sind im CSS zu definieren oder zumindest mit alt=““ zu markieren.

Die interessante Frage war, was man mit Bildern wie in einem Artikel zum BarCamp Vienna macht, die optisch auf einen BarCamp Artikel hinweisen. Martins Meinung ist, dass solche Bilder (die an sich keinen zusätzlichen Informationsmehrwert gegenüber dem Text ergeben) trotzdem kurz und prägnant beschrieben werden sollen, also z.B.
alt="Logo: BarCamp Vienna 2007"

Sprachauszeichnung

Auf einer Website sollte prinzipiell die vorherrschende Sprache ausgezeichnet werden. Im Falle meines Blogs ist das deutsch. Verwendet man nunmehr fremdsprachige Wörter so sind diese speziell auszuzeichnen.

Wie im Beispiel zu den Sprungmarken zu hören war wird der Titel der Seite „BarCamp Vienna User Generated Questions“ von einem Screenreader völlig unverständlich ausgesprochen, da er annimmt, dass es sich um deutsche Worte handelt. Ein Problem, das viele CMS Systeme an sich haben, ist, dass Artikel Überschriften keine HTML-Auszeichnungen erlauben, sodass in Artikel Überschriften auch keine Sprachauszeichnung von einzelnen Wörtern möglich ist.

In den Artikeltexten selber kann man dies aber einfach durchführen. Ein Text wie

User Generated Questions ist eine neue Form der Beteiligung von Leser/innen

wäre dann folgendermaßen auszuzeichnen

<span lang=“en“ xml:lang=“en“>User Generated Questions</span> ist eine neue Form der Beteiligung von Leser/innen

Wobei natürlich „en“ durch die jeweilige Fremdsprache zu ersetzen wäre. Das Problem in die andere Richtung haben meine Accessibility Blog Parade KollegInnen von MAIN entdeckt, nämlich, dass der als englischsprachig ausgezeichnete Web-Dienst Twitter etwaige Eingaben in deutscher Sprache nicht als solche kennzeichnet.

Tag-Cloud

Die Tag-Cloud – also die Anzeige alles Tags (Schlagwörter) auf einer Seite – ist immer wieder ein Diskussionthema. Abgesehen von der Frage ob und wie man Tags einsetzt und ob eine Tag-Cloud sinnvoll ist, gibt es auch bezüglich Accessibility einige Probleme.

Im Falle meiner TagCloud würde ein Screenreader alle Tags in einem Zug ohne Punkt und Beistrich vorlesen. Außerdem – was vielen ja wichtig ist – erkennt der/die Screenreader-LeserIn die Gewichtung der einzelnen Tags nicht, die allein über die Größe (eben nur visuell) dargestellt wird. Martin hat dazu einige Ideen, wie man die Tag-Cloud im „Hintergrund“ Screenreaderfreundlicher machen könnte. Dazu werdet ihr hoffentlich bald mehr lesen können.

Grenzfall Usability / Accessiblity

Das letzte Beispiel – das wir bei unserer Session nicht mehr brachten ist die Vorschau bei Kommentaren. Es ist dies ein typischer Grenzfall zwischen Usability und Accessibility. Was passiert? Wenn man einen Kommentar eintippt und auf Vorschau klickt, dann wird dieser so angezeigt wie er nach dem absenden auch aussehen würde. Nun, das sollte ein Vorschau auch tun, oder?

Ja, aber die Vorschau wird auch an dem Platz angezeigt an dem sie dann zu sehen ist und dies macht das Problem. Nachdem die Seite für die Vorschau neu aufgebaut wird springt die Anzeige auf das Kommentareingabefeld. Bei kleineren Bildschirmgrößen sehe ich nun die Vorschau gar nicht und wundere mich, warum nichts passiert ist.

Leider sehen manche die Usability und die Accessibility von Websites als eine getrennte „Wissenschaft“. Martin meint dazu: „Accessibility ist Teil der Usabilty, weil sonst macht es ja keinen Sinn“.

Schlussbemerkung

Dies waren die einzelnen Punkte die wir in der Session am BarCamp kurz und mittels meines Weblogs dargestellt haben. Dies sind nicht alle Punkte, die Probleme bereiten bzw. bereiten können. Daher gab es auch viele Fragen während unserer Präsentation. Dieser Artikel wirft nur ein paar Schlaglichter auf das viel breitere Thema der Accessibility.

Ich hoffe, dass der Artikel aber auch zeigt, dass man mit ein paar kleinen Änderungen und Überlegungen durchaus etwas zur Barrierefreiheit seines Blogs, seiner Website beitragen kann. Einiges davon liegt gar nicht am Template oder Webdesign sondern (z.B. Sprachauszeichnung, Bildbeschriftung) an dem was man im Editor macht oder eben nicht macht. Hier hoffe ich in Zukunft noch einiges beitragen zu können.

Danken möchte ich Martin für seine Analyse meines Blogs und die gemeinsame Präsentation, die mir sehr viel Spass gemacht hat und für uns beide wohl eine Lernerlebnis war. Ich konnte einiges über Barrierefreiheit (was ich hier gar nicht alles aufzählen kann) erfahren. Martin hat sein erstes BarCamp besucht und sich mit vermehrtem Interesse dem Web 2.0 und den speziellen Fragen die sich dort bezüglich Barrierefreiheit stellen gewidmet.

Das Schlusswort gebührt – als Hauptbeitragender zu diesem Artikel – Martin:

Barrierefreiheit ist ein Prozess, daher ist jeder Schritt in diese Richtung ein wichtiger.