„Nur ein Blog am Prüfstand – Wir testen live die Barrierefreiheit“

Manches wird einigen von euch banal vorkommen. Wie mir Martin Ladstätter versicherte und ich selbst schon feststellen musste, finden sich alle genannten Probleme auch auf teuer bezahlten und von "Profis" gestalteten Websites.

Homepage Nur ein Blog
Lender, Robert

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 Punkte 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 und ist in meinem Blog erstmals am 26. Oktober 2007 veröffentlicht worden.)

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 selben Inhalt hat wie der Linktitel.

Navigation – Sprungmarken funktionieren nicht

Für Menschen, die mit einem Screenreader oder mittels Braillezeile arbeiten, kann man einiges anbieten, um diesen die Navigation zu erleichtern. „Skiplinks“ oder „Sprungmarken“ werden am Anfang einer Seite – nicht sichtbar – platziert, um von dort direkt auf bestimmte wichtige Seitenelemente navigieren zu können, ohne sich den gesamten Text vorlesen lassen zu müssen. Mit gesamtem 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 bei einigen (wie z.B. WebFormator)passiert:

Man springt zum ersten Eingabefeld auf der Seite (zum 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. Mit 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 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 einBlogbeschreibung 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. Schlussendlich 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 Screenreader-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 einem 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, da 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.

Eine 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 selbst 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 umgekehrte Problem 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 aller 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 Tag-Cloud 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 eine 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.“

Hier beginnt der Werbebereich Hier endet der Werbebereich
Hier beginnt der Werbebereich Hier endet der Werbebereich

Hinterlassen Sie einen Kommentar

Pflichtfelder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

0 Kommentare

  • @Herr Webel – Endlich mal ein schlauer Beitrag. Ich seh das auch so. Viele sind sich ja gar nicht bewusst, wenn man einen sauberen und klar strukturierten Quelltext hat und dazu sämtliche Stile in eine CSS wirft, dass man bereits schon mehr als die Hälfte an Barrierefreiheit erreicht hat! Was man da an Geld, Zeit und Nerven spart!

    Ich prüfe meine Arbeiten auch im Watchfire und haben meist die berühmten 3As. Aber klar sollte sein, dass auch der WAI überholungsbedürftig ist und das manche „Emphfehlungen“ nicht für jedes Projekt gilt. Warum empfiehlt mir Watchfire einen Longdesc, wenn es aber nur Grafikelemente sind und eigentlich zum Inhalt der Seite nichts aussagen.

    Klar ist, dass man sich an wichtige Regeln zu halten hat, wie z. B. schlüssige Beschreibungen der Bilder (keinen Roman), acronym für Fachbegriffe, accesskeys in einer Hauptnavigation, titles in Links. Was ist aber mit den Barrieren in Texten? Wer testet denn die Formulierungen auf Barrierefreiheit. Das wäre z. B. auch eine sinnvolle Einrichtung. Ich stell mir das vor allem für gehörlose Nutzer schwierig vor. Für diese Zielgruppe scheint es noch keine all zu große Lobby zu geben. Dabei sind gerade die auf frei zugänglicher Information angewiesen.

    Meines Erachtens sollte jeder Webdesigner, der sich ernsthaft mit Barrierefreiem Webdesign beschäftigen möchte, wenigstens einmal eine Braillzeile in Händen gehalten zu haben.

    Ich würde mir als Betroffene sehr wünschen, wenn man mit Leuten zusammen arbeitet, die nicht nur die WAI-Regeln im Schlaf aufsagen, sondern auch in der Lage sind, sich auf die unterschiedlichsten Userbedürfnisse eingehen können.

    Solche Leute sind mir bei weitem lieber, als diese Theoretiker. Man muss nicht alles wissen, ist auch gar nicht nötig, aber man sollte zumindest bereit sein, sich auf die User einzustellen. Und es gibt ja nicht nur behinderte User. Die Usergruppe der über 50jährigen steigt. Und die Tendenz zur klar strukturierten Webangeboten steigt ebenfalls.

  • Das meiste, was hier gesagt wurde, ist richtig und bekannt. Allein korrektes HTML und CSS sowie ein wenig Gehirnschmalz für die Struktur eines HTML-Dokuments könnten ca 80 % Barrierefreiheit bringen. Man kann es aber damit auch übertreiben. Es ist sicher lästig, aber durchaus tolerierbar, mal ein leeres Eingabefeld vorzufinden. Andererseits ist ein Zuviel an Navigation und Accesskeys selbst eine Barriere vor lauter Barrierefreiheit. Und was Barrierefreiheitskämpfer oft nicht wahrhaben wollen: Auch Sehbehinderte und Sehende finden im Internet kein Rundum-Sorglos-Paket vor.

  • Bezüglich der Frage der Überschriftendefinition gibt es wohl unterschiedliche Meinungen, wie ich aus ersten Reaktionen auf den obigen Artikel feststellen konnte. Eine der KommentatorInnen konnte ich zu einem Gastbeitrag gewinnen: http://www.robertlender.info/blog/archives/2324-Gastbeitrag.html