News mit tag »Hilfsmittel«

12 Mai 2010

Wie Blinde Websites erkunden

Wie klingt eigentlich eine Website? Das ist eine Frage, die vor allem Blinde beantworten können. Blinde und Sehgeschädigte gehören zu den intensivsten Nutzern des Internet. Wie sie das Netz nutzen, erfahren Sie in dieser dreiteiligen Artikelserie.

Am Beispiel von Texten wollen wir zunächst zeigen, wie Blinde eine optische Oberfläche für sich zugänglich machen. Im zweiten Teil wird es um die Nutzung multimedialer Angebote gehen. Wie Blinde selbst Inhalte im Web bereit stellen, erfahren die Leser im dritten Teil.

Die graphische Benutzeroberfläche und der Screenreader

Um einen Computer nutzen zu können, verwenden Blinde einen Screenreader. Dieses Programm gibt visuelle Inhalte wie Menüs oder Texte als Sprache oder als Blindenschrift auf einem Braille-Display aus. Die Steuerung erfolgt vollständig über die Tastatur. Die Zugänglichkeit der Programme ist sehr unterschiedlich, manche Programme lassen sich sehr gut über Tastatur und Screenreader bedienen, andere gar nicht.

Weiterlesen …

Das Internet gehört zu den wichtigsten Bereichen der Computernutzung und ist über Screenreader generell gut zu erreichen. Der Screenreader orientiert sich nicht am optischen Erscheinungsbild, sondern an der Struktur einer Website. Elemente, die für den sehenden Nutzer parallel erscheinen, sind für den Nutzer von Screenreadern linear angeordnet.

Während der Sehende mit einem Blick wichtige Elemente wie die Navigation und Text von Schmuckelementen wie Bannern oder Werbung unterscheiden kann, gilt es für den Blinden, zunächst alle Elemente der Website einmal zu erfassen, um sich auf der Website zurecht finden zu können. Der Inhalt von Bildern, Graphiken und Animationen bleibt für Blinde unsichtbar.

Texte und Foren

Normale Fließtexte stellen in der Regel kein Problem dar. Die kleine Anwendung RSS hat dabei zu einer wesentlichen Verbesserung geführt. Die Feeds erlauben das bequeme Lesen der Artikel, ohne die jeweiligen Seiten durchnavigieren zu müssen. Schwieriger sieht es bei komplexen Angeboten aus, wir wollen das hier am Beispiel von Foren deutlich machen.

Die klassischen Foren basieren auf der sogenannten Baumstruktur. Die Baumstruktur erlaubt das Erkennen von Diskussionssträngen. Der Nutzer sieht auf den ersten Blick, wer auf wen geantwortet hat. Für den Blinden ist das allerdings nicht erkennbar. Ebenfalls problematisch ist, dass Beiträge nur einzeln angezeigt werden. Der Screenreader muss bei jedem Aufruf die Seite neu einlesen und beginnt am Anfang der Seite. Der Blinde muss bei jedem Seitenaufruf nach dem Anfang des Beitrags suchen, ohne zu wissen, ob tatsächlich etwas lesenswertes in dem Beitrag steht. Manche Diskussionsfäden ziehen sich über Dutzende von Beiträgen, so dass selbst Normal-Sehende hier nicht alle Beiträge lesen würden.

Günstiger sind die Newsboards, wo die Antworten untereinander angeordnet werden, hier ist zumeist auch für den Sehenden nicht erkennbar, wer auf wen geantwortet hat. Das Projekt selfHTML hat das in seinem Forum elegant gelöst: Oben auf der Website wird der Forenbaum angezeigt, darunter werden alle Beiträge untereinander eingeblendet.

E-Mails als Austauschmedium

Viele Blinde bevorzugen für Austausch und Diskussionen E-Mails. Auf der Plattform Blindzeln gibt es über 70 Mailinglisten zu so verschiedenen Themen wie Kochen, Lesen oder Blindenhunden.

Das Mailprogramm bietet ein einheitliches Erscheinungsbild und hat viele Funktionen, die Foren und Newsboards entweder gar nicht bieten oder die für Blinde nur schwer oder gar nicht zugänglich sind:

• die Absender sind leicht erkennbar
• die Nachrichten lassen sich einfach nach Absender, Datum oder Thema sortieren
• die Diskussionsstränge lassen sich anhand der Betreffzeile erkennen

Der größte Vorteil besteht darin, dass alle Funktionen des Mailprogramms per Tastatur zugänglich sind.

Der Nachteil dieser Mailinglisten ist allerdings ebenso offensichtlich: Obwohl auch Menschen ohne Sehschädigung bei Blindzeln willkommen sind, bevorzugen die meisten Sehenden für sie attraktivere Austauschmedien. Was für den Blinden übersichtlich und einfach ist, wirkt auf den Sehenden unübersichtlich und textlastig.

Die Kommunikation verlagert sich zunehmend von E-Mails hin zu Statusmeldungen über Twitter oder zum Nachrichtenaustausch innerhalb der sozialen Netzwerke.

Zudem entgehen den Blinden wichtige Informationen und Hilfsmöglichkeiten, wenn sie gezielt Foren ausweichen. Foren werden gern zur Selbsthilfe genutzt und oftmals sind die hier gegebenen Antworten hilfreicher als die Hilfeseiten professioneller Anbieter.

Komplexe Anwendungen und Interaktion

Komplexe Websites erfordern einen hohen Lernaufwand des blinden Nutzers und sind daher oft nicht attraktiv. Schwierig sind zum Beispiel Shopping-Angebote und Online-Auktionen. Grundlegende Informationen wie Preise, Artikelbeschreibung oder allgemeine Geschäftsbedingungen sind zumeist noch erschließbar. Schwierig ist vor allem die Interaktion mit der Website, wenn es um die Eingabe von Daten und die Zahlungsmodalitäten geht. Die Shop-Betreiber setzen zumeist auf Technologien, die vom Screenreader nicht unterstützt werden, die nicht mit der Tastatur bedienbar sind und deren Rückmeldungen oft nicht verständlich sind.

Die Folgen können hier sehr schwerwiegend sein, wenn etwa aus Versehen falsche Artikel bestellt werden. Deswegen bleiben viele Blinde lieber bei den Webseiten, die sie gut genug kennen, um sie bedienen und überschauen zu können.

Screenreader testen

Mittlerweile hat jeder die Möglichkeit, selbst mit Screenreadern zu experimentieren: Unter Windows gibt es die freien Screenreader NVDA und Thunder, die Linux-Distributionen Ubuntu und Knoppix haben von Haus aus die Screenreader Orca und ADRIANE an Bord. Die Apple-Betriebsysteme werden mit dem Screenreader VoiceOver ausgeliefert. Die professionelle Nutzung eines Screenreaders erfordert allerdings viel Erfahrung und Übung.

25 Mär 2010

Warum ›Einfach für Alle‹ nicht valide ist

Immer wieder erreichen uns Anfragen, warum der Webauftritt von ›Einfach für Alle‹ nicht gegen HTML 4 und CSS 2 validiert. Die Antwort ist einfach: Barrierefreiheit ist uns wichtiger als valider Code. EfA setzt auf neue Techniken aus der WAI-ARIA-Spezifikation des W3C, um die Zugänglichkeit unseres Angebots zu verbessern.

Der letzte Arbeitsentwurf der WAI-ARIA stammt vom 15. Dezember 2009. Ähnlich wie bei HTML5 gelten einige der Spezifikation schon als stabil und werden von aktuellen Browsern und Hilfsprogrammen unterstützt.

WAI-ARIA erlaubt unter anderem das Definieren von Orientierungspunkten einer Website: Wichtige Elemente wie die Navigation oder der Inhaltsbereich können eindeutig benannt und angesteuert werden. Bei Formularen erlaubt WAI-ARIA das eindeutige Kennzeichnen von Pflichtfeldern. Die endgültige Version der WAI-ARIA sieht auch das Steuern von Schiebereglern und die Verwendung komplexer AJAX-Anwendungen vor.

Diese Eigenschaften werden auch von aktuellen Browsern wie dem Firefox 3, dem Screenreader Jaws 10 und einigen anderen Browsern und Hilfsprogrammen unterstützt. Auch das am 1. Februar 2010 gestartete neue Portal der Aktion Mensch verwendet bereits WAI-ARIA.

Die derzeit aktuellen Versionen von HTML – HTML 4.01 und XHTML 1.0 – kennen die WAI-ARIA noch nicht, deshalb lassen sich unsere aktuellen Websites nicht validieren.

11 Sep 2009

Passende Überschrift hier einsetzen

Wenn Sie eine tagewochenlange Diskussion unter Webentwicklern lostreten wollen, dann müssen Sie nur mal in einem Forum oder bei Twitter die Frage stellen, ob man mehr als eine <h1> pro Seite verwenden darf, und wenn ja, wofür. Danach können Sie sich entspannt zurücklehnen und Wetten auf den Zeitpunkt abschliessen, an dem die Diskussion vollends aus dem Ruder läuft.
Dabei findet die ganze Diskussion nur deshalb statt, weil es historisch bedingte Lücken in der HTML-Spezifikation gibt. Warum das so ist, wo diese Lücken sind und wo sie herkommen, was man dagegen machen kann und wie das Thema in Zukunft aussehen wird zeigt der Artikel »Passende Überschrift hier einsetzen«.

01 Sep 2009

Neues in der Werkzeugkiste

Opera

Opera 10 ist ab sofort ohne ›beta‹ und ›release candidate‹ dahinter als fertige Version erhältlich (Download, alternativ per FTP, Packungsbeilage). In der neuen Version ist die WAI-ARIA-Unterstützung ausgebaut worden; viele Neuerungen gab es auch im Bereich CSS – allerdings nur bis zur Version 2.1 (inklusive der HSL- und RGB-Farbräume mit Alpha-Transparenz und Web-Fonts mit @font-face); weitergehende Dinge aus CSS 3 wie das CSS-Column-Modul oder multiple Hintergrund- und Rand-Bilder sind offenbar noch nicht implementiert. Was sonst noch alles neu ist erklärt Chris Mills in der Opera Developer Community: »The Opera 10 experience«, oder im YouTube-Video »Opera 10 Reviewer's Guide«.

JAWS

Eine Nummer weiter ist ab sofort auch der Screenreader JAWS, von dem eine öffentliche Beta der Version 11 bereitsteht (Download, Packungsbeilage). Auch hier hat sich einiges im Bereich der Zugänglichkeit von Web-Applikationen getan – so werden in der neuesten Version ARIA Drag & Drop sowie ARIA Live Regions unterstützt.

27 Jul 2009

Accessibility von Windows 7

Eher was für richtige Programmierer oder solche die es werden wollten: Wenn Sie schon immer mal wissen wollten wie das eigentlich funktioniert, dass ein Screenreader was mit dem Zeugs anfangen kann das da auf dem Bildschirm zu sehen ist – bei code-magazine.com ist vor einiger Zeit ein Sonderheft zum Thema ›Windows Accessibility Focus‹ erschienen, in dem das alles erklärt wird. Die Artikel gibt es entweder als (leider nicht barrierefreies) PDF zum herunterladen oder einzeln in HTML-Form. So zum Beispiel:

• »Accessibility 101«
• »Open Accessibility«
• »Windows Automation API 3.0 Overview«
• »Making Custom Controls Accessible«

Einige der Artikel sind aber auch für profane Web-Entwickler sehr gut zu gebrauchen:

• »Microsoft Accessibility Testing Tools vs. the Ten-ton Gorilla of Accessibility Guidelines Compliance«
• »Internet Explorer 8 New Accessibility Features«
• »Creating Accessibility-aware Silverlight 2 Content«

10 Mär 2009

Literaturbeilage: WAI-ARIA

In der kleinen Laborbericht-Serie zu unserem vergangenen Relaunch hatten wir öfters eine Abkürzung benutzt, die das Potenzial hat, das nächste große Ding zu werden: WAI-ARIA (›Accessible Rich Internet Applications‹). Damit werden Ergänzungen zu HTML beschrieben, die vorhandene Lücken in den Spezifikationen stopfen sollen. So lässt sich zum Beispiel in Web-basierten Applikationen ein Schieberegler auszeichnen – ein Element, dass es in HTML (noch) nicht gibt. Dieser wird dann z.B. in einem Screenreader auch als solcher angesagt und nicht als eine Ansammlung sinnfreier div.

Der Entwurf hat mittlerweile den Status eines Last Call Working Draft erreicht; die übliche Kommentierungs-Phase läuft bis zum 24. März. Es ist also mit einer baldigen Fertigstellung zu rechnen, zumal die Browser- und Hilfsmittel-Hersteller bereits fleißig implementieren.

Deswegen ein paar gesammelte Links als Ergänzung zu unserer Serie, falls Sie tiefer in die Materie einsteigen wollen:

Weiterlesen …

Lesenswertes:

• Stefan Walter hat die Einführung des Accessibility-Experten Gez Lemon übersetzt: »Einführung in WAI ARIA«.
• Eine ähnlich gute, allerdings englischsprachige Einführung gibt es im CodeTalks-Wiki: »Web 2.0 Accessibility with WAI-ARIA FAQ«.
• Steve Faulkner erklärt die Auszeichnung von Seitenbereichen: »Using WAI ARIA Landmark Roles« (dazu passend die ARIA Landmark Role-Tests mit Firefox 3 & Internet Explorer 8 + Assistive Technology).
• Todd Kloots schreibt was zur Verwendung von ARIA im YUI-Framework: »More Accessible YUI Grids Layouts with ARIA Landmark Roles«.
• Roger Johansson macht sich Gedanken um die Validierung: »Validating WAI-ARIA in HTML and XHTML«.
• Marco Zehe gibt eine ganze Reihe Tipps, wie man Widgets mit ARIA anreichern kann: »Easy ARIA tip #3: aria-invalid and role ›alert‹« bzw. zeigt was manche Anbieter bereits jetzt machen: »ARIA in Gmail #1: Alerts« und »ARIA in Gmail #2: Enhancing the Chat experience«.
• Im vergangenen Herbst hatte Martin Kliehm auf dem Wiener A-Tag eine sehenswerte Präsentation dazu abgeliefert: »Accessible Rich Internet Applications (ARIA)«, die dazugehörigen kurzen Demo-Videos finden sich in seinem flickr-Account.
• Thomas Logan hat im CodeTalks-Wiki gleich 5 Videos veröffentlicht, in denen die Entwicklung von zugänglichen Web-Applikationen mit WAI-ARIA zu sehen ist: »ARIA Video Project« (wie es sich gehört mit Mitschrift bzw. untertitelt!).

Ohne die Unterstützung durch Browser und Hilfsmittel geht es natürlich nicht:

• Steve Faulkner freut sich über »JAWS version 10 with WAI-ARIA live region support« und schiebt gleich noch ein paar Testcases hinterher: »Testing WAI-ARIA Role Support«.
• Ebenso erfreulich die Test Cases für den Internet Explorer 8 bei Microsoft im Windows Internet Explorer Testing Center (Beispiel für eine Baum-Navigation); weitere Infos dazu im IEBlog: »Accessibility: Improved ARIA Support in the IE8 RC«
• Bei Mozilla ist man schon seit Firefox 1.5 an dem Thema dran, nun berichtet Marco Zehe von »JAWS 10 public beta’s Firefox 3 support: A review«.
• Wie sich das Ganze dann in JAWS 10 anhört erfährt man in der Folge 26 des FSCast aus dem Januar '09: »FSCast Episode 26 from Freedom Scientific for Blind and Vision Impaired Individuals«.
• Weniger gut ist hingegen die WAI-ARIA-Unterstützung in der aktuellen Beta von Apples Safari 4. Trotz der Ankündigung »Safari supports Accessible Rich Internet Applications (ARIA)« waren wir bisher nicht in der Lage, den Browser zusammen mit dem hauseigenen Screenreader VoiceOver zu überreden, irgendwas sinnvolles mit ARIA anzustellen. Andere scheinen die gleichen Probleme zu haben (z.B. Safari 4 - Quickfire ARIA Testing oder Safari 4 public beta with WAI-ARIA support. Or not?) – aber das kann ja bis zur finalen Version noch werden.

Einen noch zum Schluss: wie man am besten mit Screenreadern testet (oder noch besser: echten Screenreader-Nutzer testen lässt) erklärt Henni Swan von Opera: »Setting up a screen reader test enviroment«.

02 Mär 2009

Laborbericht №9: Semantische Tagclouds – geht das überhaupt?

Wie üblich haben uns auch beim letzten Relaunch viele Rückmeldungen und kritische Anmerkungen (und in seltenen Fällen sogar Lob) per E-Mail oder über die Kontakt- und Kommentarformulare erreicht. Zu einigen Punkten hatten wir ja bereits ausführlich was geschrieben; heute geht es um einen Teil des HTML-Codes dieser Seiten, der schon öfter Anlass zu Diskussionen war: die »Tag Cloud«, auch Schlagwort- oder Stichwortwolke genannt.

Laut Wikipedia ist eine Tag Cloud »eine Methode zur Informationsvisualisierung, bei der eine Liste aus Schlagworten alphabetisch sortiert flächig angezeigt wird, wobei einzelne unterschiedlich gewichtete Wörter größer oder auf andere Weise hervorgehoben dargestellt werden.« Lustigerweise ist die Tag Cloud in der linken Spalte eines der wenigen Code-Fragmente, die nicht nur den letzten Relaunch, sondern auch einige Relaunches davor unbeschadet überstanden hat – das zu Grunde liegende Konstrukt hat sich also seit Jahren nicht geändert. Aber wie bei jedem Relaunch erreichen uns wohl-gemeinte Tipps, wie man diese Tag Clouds besser umsetzen und semantisch anreichern könnte (womit sich mal wieder die alte Regel bewahrheitet, dass die Menge des Diskussionsbedarfs immer umgekehrt proportional zur Komplexität des Problems ist).

Weiterlesen …

So auch diesmal:

»… die Größe eines Links in der Tag-Cloud habt Ihr ja mit "strong in strong in strong …" realisiert. Ich habe gerade mal mit JAWS etwas herumgespielt, vor allem mit dem Konfigurationsmanager, und da keine Einstellung gefunden, mit der ich mir die Anzahl der strong-Tags vorlesen lassen kann. Daher mein Tipp: Schreibt doch die Nummer der strong-Tags als Zahl in Klammern hinter den jeweiligen Link und schiebt das dann per CSS aus dem Viewport. In der Überschrift ›Themen:‹ schreibt Ihr das halt als ›(Beliebtheit als Zahl in Klammern)‹, ebenfalls versteckt, dahinter. Das ist zwar so knapp, dass man erst nicht weiß, ob der Zahlenwert mit der Beliebtheit steigt oder ob es hier umgekehrt proportional gesehen werden muss, aber das wird spätestens bei der vier für HTML klar.«

(Detlef Girke per E-Mail)

Zum Hintergrund des ganzen: unsere Tag Cloud besteht aus einer Liste von Einträgen, die alphabetisch sortiert als Unordered List (UL) angelegt sind, jeder Eintrag steht in einem separatem List Item (LI). Wir bekamen auch einige Mails mit Vorschlägen, statt der UL doch eine geordnete Liste (OL) zu nehmen – danke für die Vorschläge, aber das Kriterium zur Sortierung der Einträge ist das Alphabet – damit sind die (zusätzlichen) Ordnungszahlen komplett überflüssig und bringen dem Nutzer keine brauchbaren Erkenntnisse.

Eine Sortierung nach Häufigkeit würde ebenfalls keinerlei Vorteile für den Nutzer bringen. Zum einen wäre für den Nutzer die Orientierung entlang des Alphabets dahin; zum anderen würde sich diese Sortierung auch laufend ändern. Ein weiteres Problem bleibt dadurch ebenfalls ungelöst: in den vergangenen Jahren haben wir sehr viel über HTML & CSS gebloggt, entsprechend viele Treffer gäbe es bei einer Sortierung nach diesen Tags. Nun gibt es aber Techniken wie z.B. WAI-ARIA, die relativ neu sind und daher in Summe nicht so häufig im Blog vorkommen – aber genau von diesen Beiträgen möchten wir, dass sich unsere Leser damit beschäftigen und eine alleinige Sortierung nach Häufigkeit käme einer Abwertung gleich und ginge somit am Ziel vorbei. Im Ernstfall würde man damit höchstens den Digg-Effekt erreichen, bei dem alle User auf das Ding mit der höchsten Zahl draufklicken.

Im Urzustand sieht unsere listenförmige Tag Cloud folgerichtig so aus:

1. <div id="tagcloud">
2. <h4>Themen:</h4>
3. <ul>
4. <li><a href="/blog/tags/ajax/" rel="tag">AJAX</a></li>
5. <li><a href="/blog/tags/atag/" rel="tag">ATAG</a></li>
6. [...]
7. </ul>
8. </div>

Allerdings ist dies noch nicht alles, und genau daran entzündet sich die Kritik: je nach Häufigkeit des Tags enthält der Link noch ein oder mehrere <strong> – je häufiger, desto mehr <strong> sind dort hineingeschachtelt:

6. <li><a href="/blog/tags/bitv/" rel="tag"><strong><strong>BITV</strong></strong></a></li>

Durch geschicktes Ausnutzen der Vererbungen in CSS wird der enthaltene Linktext immer größer, je öfter strong ineinander verschachtelt ist:

1. #tagcloud li strong {
2. font-size: 1.1em;
3. }

Nun bezieht sich einige Kritik darauf, dass <strong> unsemantisch sei – leider konnte uns jedoch bisher noch niemand eine echte, passendere Alternative aufzeigen. Kurzfristig hatten wir über die Verwendung von <small> & <big> zur Gewichtung der Einträge nachgedacht, aber dann davon abgesehen. Nicht weil es unpassend wäre (wobei: eventuell wäre es sogar passender und damit ehrlicher gewesen), sondern weil dies wohl einen Sturm der Entrüstung hervorgerufen hätte. Das Problem bleibt also: HTML bietet kein 100%-ig passendes Element zur semantisch korrekten Auszeichnung von Gewichtungen in Tag Clouds an. Also läuft es (wie so oft in HTML) auf eine Annäherung hinaus, die nach den Prinzipien der Einfachheit diejenige sein sollte, die am wenigsten stört (›least obtrusive‹) und dem Nutzer nichts vorgaukelt, das effektiv nicht vorhanden ist bzw. die Handhabung für den Nutzer nicht unnötig verkompliziert. Eben einfach.

Daher hatten wir uns damals nach intensivem Nachdenken für <strong> entschieden, eben genau weil mit <strong> ausgezeichneter Text in sämtlichen uns bekannten Screenreadern nicht anders vorgelesen wird als herkömmlicher Text ohne <strong> (wie übrigens bei <big> & <small> auch nicht, neben einer ganzen Reihe anderer, seit über einem Jahrzehnt spezifizierter Elemente).

Gleich mehrere Mails und IMs beschäftigten sich mit der Frage, ob man die Gewichtung dem Screenreader-Nutzer dann nicht besser durch die Ansage der Zahl der gefundenen Treffer mit diesem Tag mitteilen sollte. Auch mit diesem Vorschlag haben wir ein paar Probleme:

1. Wenn die Zahlen einen Nutzwert haben sollen, dann müsste sich der Nutzer beim durchhören der Tag Cloud die Zahlen merken, dann nochmals zurückgehen und dann auf Basis der Zahlen als Entscheidungskriterium (Welcher Zahl? Der höchsten? Der niedrigsten? Dem Mittelwert?) entscheiden, welchem Link er folgt. Was aber nicht das eigentliche Problem des Vorschlags löst, nämlich:
2. Warum sollte ein Nutzer einen Link anklicken, nur weil ihm die (hohe oder niedrige) Zahl irgendwie zusagt? Wenn jemand nach Tipps zu CSS sucht, dann ist es für ihn vollkommen unerheblich, ob da nun 2 oder 20 oder 200 Einträge dahinter sind. Weder wir noch der Benutzer können wissen, ob das Gesuchte gefunden wird (und zwar vollkommen unabhängig von der Anzahl; und nein, die Wahrscheinlichkeit das Gesuchte zu finden steigt nur unwesentlich mit der Zahl der verlinkten Blog-Beiträge).

Die wesentliche Information ist auch jetzt schon der verlinkte Text (›BITV‹, ›CSS‹, …), alles darüber hinaus wäre nicht Beiwerk oder zusätzlicher Komfort, sondern akustischer Müll. Wir glauben nicht, dass allzu viele Nutzer zu EfA kommen nur um nachzulesen, wie viel wir über ein bestimmtes Thema berichten – das ist vielleicht später mal für Archäologen interessant, aber nicht hier und jetzt für die Nutzer, die sich über bestimmte Themen informieren wollen.

Daher können wir auch den Nutzwert einiger Tutorials nicht nachvollziehen, die man zu dem Thema im Netz findet. Mark Norman Francis hatte im Dezember 2006 im Adventskalender von 24 ways eine Anleitung veröffentlicht, die nach seiner Auffassung alle Probleme löst und somit absolut barrierefrei zugänglich sei. Im fertigen Code-Beispiel stehen zusätzliche Informationen über die Anzahl zwar im HTML innerhalb des Links, diese werden aber per CSS aus dem Viewport geschoben.

In die gleiche Richtung geht ein neuerer Artikel »Semantische Tag Cloud« im SELFHTML aktuell Weblog, auf den Wolfgang Wiese per IM hinwies: auch hier werden zusätzliche (für grafische Browser wiederum versteckte) Infos wie »eher selten«, »ausgesprochen häufig«, usw. in die Tag Cloud geschrieben – allerdings ausserhalb der Links:

1. <ul>
2. […]
3. <li><span style="font-size:169%"><a href="linkziel">Arzt-Suchdienst</a></span><span class="ignore"> ausgesprochen häufig</span></li>
4. […]
5. </ul>

Leider zeigen beide Ansätze bei genauerem Hinsehen, dass sie wohl kaum mit echten Screenreader-Nutzern getestet sein können, denn beide Ansätze haben grundsätzliche Probleme:

1. Entweder lässt der Screenreader-Nutzer sich das alles vorlesen – dann steigt der Nutzer nach unserer Erfahrung ob der Menge der unnützen Zusatzinfos nach der Hälfte der Tag Cloud aus; oder
2. Der Screenreader-Nutzer tabbt durch die Tag Cloud (von Link zu Link) – dann wiederum bleibt ihm die Zusatzinfo verborgen, wenn diese ausserhalb der Links steht. Und nein, die Infos in die Links selbst reinzuschreiben ist wie gesagt auch keine Lösung, weil dann wieder Punkt 1 greift.

Und deswegen ist die Tag Cloud so wie sie ist.

Nachtrag:

• Katja Wittrowski: »Sichtweisen auf Tag-Clouds (Teil 1): Wortwolken unter Design-Aspekten«
• Sebastian Preuss: »Sichtweisen auf Tag-Clouds (Teil 2): Usability-Probleme und Lösungsversuche«
• Matthias Rauer: »Sichtweisen auf Tag-Clouds (Teil 3): Auswirkungen auf das Image«

(Tipp von Rainer Schlegel via E-Mail)

09 Feb 2009

Hörtipp: CRE107 - Barrierefreiheit im Web

Im Chaosradio Express №107 unterhalten sich Tim Pritlove, Jan Eric Hellbusch und Tomas Caspers fast zwei Stunden lang über Grundsätzliches und Aktuelles aus dem Bereich Barrierefreiheit im Web – Was man bedenken sollte, wenn man Websites plant und gestaltet (Kommentare, Mitmachseite, Direkter Download der Mediendatei, ca. 80 MB).

Unter anderem geht es um folgende Themen: The Web Standards Project; Auswirkung der Farbwahl in Webseiten für Farbfehlsichtige; Bedeutung der Struktur und semantischem Markup für blinde Nutzer; Vorteile von barrierefreiem Design für nicht-behinderte Nutzer; Screenreader-Programme und vergleichbare Funktionalitäten in Betriebssystemen; Aspekte der Gebärdensprache; Aufbau, Anwendung und Testbarkeit der Web Content Accessibility Guidelines der W3C und WAI-ARIA; Gesetzliche Vorgaben und Verpflichtung zur Barrierefreiheit für Behörden und öffentliche Körperschaften und Accessibility für Podcasts.

31 Okt 2008

Benimmregeln für Datentabellen

Für Webentwickler bedeutete die Umstellung von Tabellen auf CSS, dass sie alte Gewohnheiten vergessen mussten. Sämtliche Techniken und Kniffe aus den Zeiten von Layout-Tabellen sind scheinbar »verlernt«. Das richtige Umsetzen echter Datentabellen erfordert jedoch eine Rückbesinnung: man muss sich wieder mühsam in die Spezifikationen einlesen und in das Tabellenmodell von HTML hineindenken.

Wie man tabellarische Daten so aufbereitet, dass sie nicht nur hübsch aussehen, sondern auch mit den assistiven Programmen von Menschen mit Behinderung optimal nutzbar sind erfahren Sie in unserer neuen Serie: »Benimmregeln für Datentabellen«

26 Jun 2008

Schatten Design links

Einer aus der Serie ›Knapp daneben ist auch vorbei‹: Selamet Aydogdu über »Alternativtexte - Zuviel des Guten«.

25 Jun 2008

ARIA: barrierefreieres Web2.0?

Wer schon mal Web-Applikationen mit einem Screenreader getestet hat, der kennt das Problem: bei asynchronen Änderungen (vulgo: AJAX) ist noch lange nicht garantiert, dass die Änderungen tatsächlich an den Screenreader weitergereicht und von diesem entsprechend vorgelesen werden. Viel öfter passiert es, dass ein veralteter Zustand der Seite aus dem Lautsprecher kommt, der nicht mehr dem aktuellen Inhalt entspricht, so wie er auf dem Bildschirm zu sehen wäre.

Kommt die Änderung hingegen durch ein synchrones Update des DOM zu Stande (z.B. indem der Screenreader-Nutzer ein Formular per Button absendet), so wird der Speicher des Screenreaders korrekt aktualisiert. Nur dann wird der richtige Inhalte vorgelesen. In Zeiten von AJAX und den kurz vor fertigen WCAG 2 hilft das aber auch nichts: Web-Applikationen müssen ganz old-school-mäßig ohne, aber eben auch mit JavaScript funktionieren und zugänglich sein. Zumal sich jede einzelne Nutzeraktion auf diese Weise mit einen Eintrag im Browser-Verlauf verewigt – was je nach Applikation auch nicht unbedingt erwünscht ist.

Und wie so oft liegt das Problem mal wieder am Browser. Genauer gesagt (Sie konnten es sich bestimmt schon denken) am Internet Explorer inklusive der aktuellen Version 7, der solche asynchonen Änderungen nicht über die entsprechende Schnittstelle nach aussen kommuniziert. Auch wenn verbreitete Screenreader wie JAWS ab Version 7.1 mittlerweile eigene Methoden haben, um Änderungen im DOM einer Seite zu beobachten und wiederzugeben, so ist die Freude darüber verfrüht: es betrifft nur einen Screenreader mit einem speziellen Browser; das Verhalten ist (wie vieles in Hilfsmitteln) undokumentiert und entspricht keinem formellen Standard – also sollte man sich besser nicht darauf verlassen.

Auftritt ARIA:

Jetzt wo selbst der kommende IE 8 den zukünftigen WAI-ARIA-Standard unterstützen wird, zeichnet sich ein wenig Entspannung ab (Firefox ab 1.5, Opera ab 9.5 und zuletzt auch Safari hatten bekanntlich hier schon vorgelegt). Also könnte man sich als Anbieter von Web-basierten Applikationen ruhig schon mal mit ARIA beschäftigen.

Mama, der Hixie hat mir das X weggenommen!

Wenn, ja wenn da nicht eine ziemliche Spaßbremse wäre – denn ob der Standard, der ja ursprünglich mal nur als temporäre Zwischenlösung gedacht war, in absehbarer Zeit fertig werden wird steht auf einem anderen Blatt Papier. Mal ganz im Vertrauen und unter uns: die HTML-Arbeitsgruppe des W3C macht im Augenblick nicht den Eindruck, als könne man sich auf den korrekten Belag einer Wurschtsemmel einigen.

Aber was soll's, eigentlich wollten wir nur eine Linkschleuder zum Thema ARIA loswerden, jetzt ist die Einleitung halt was länger geworden. In diesem Sinne:

• Marco Zehe: »Einfaches ARIA Tip #1: Das Attribut aria-required«, »Easy ARIA tip #2: aria-labelledby and aria-describedby«, »Are Ajax and Accessibility mutually exclusive?«
• Hans Hillen: »ARIA Slider, Part 1«, »ARIA Slider, Part 2«, »ARIA Slider, Part 3«
• Steve Faulkner: »AJAX and Screen Readers - Content Access Issues«, »WAI-ARIA It's EASY«, »ARIA Toggle Button and Tri-state Checkbox examples«, »Making Twitter Tweet - Using the TPG Notifier«
• John Resig: »Ajax Accessibility«
• Steven Clark: »Why Hijax (or Ajax) on Forms is No Good«
• Chris Heilmann: »Oh look, using Ajax in a stupid way is not a good idea?«
• Mike Davies: »Ajax and Accessibility talk at AbilityNet's Rich Media workshop«
• Peter Thiessen: »Overview of ARIA Live Regions«
• T.V. Raman: »ARIA For Google Reader: In praise of timely information access«
• Usability HQ: »Internet Explorer 8.0 is going to be a big win for Accessibility«
• msdn: »What's New for Accessibility in Internet Explorer 8«

24 Jun 2008

Accessibility: 1, Microformats: 0

Für Screenreader unzugängliche Microformats fliegen raus. Zumindest bei der BBC, die ab dem nächsten Update ihrer Programmvorschau auf solche Microformats verzichtet, die das umstrittene abbr-Design-Pattern benutzen: »BBC - Radio Labs - Removing Microformats from bbc.co.uk/programmes«. Zur Erinnerung hier nochmal die Gründe:

• Mike Davies: »The accessibility of the date-time pattern in Microformats«
• Bruce Lawson: »hAccessibility, one year on«
• Patrick Lauke: »hAccessibility redux?«
• Alastair Campbell: »ABBR pattern accessibility«
• Ian Lloyd: »BBC Withdrawing Some Microformats over Accessibility Concerns«
• John Allsopp: »BBC drops hCalendar for programme listings, citing accessibility concerns«
• James Edwards: »BBC Rejects hCalendar Microformat Because Of Accessibility Concerns«
• Karl Dubost: »The War of the Worlds«

23 Jun 2008

Gesammelte Werke

Die wöchentliche Accessibility-Debatte.

Teil 1 – die Theorie:

• Eric Eggert: »Barrierefreiheit: Das Gesamtbild zählt«
• Sylvia Egger: »Barrierefreiheit: Je exotischer die Anforderungen, desto besser«
• Martin Kliehm: »BITV 2.0 am grünen Tisch?« (q.v. english abstract)
• Robert Lender: »Der lange Weg eines Bloggers zur Barrierefreiheit«
• Brian Kelly: »Is Accessibility 2.0 Becoming Mainstream?«
• José Manuel Alonso: »Improving access to Government through better use of the Web«
• Chris Heilmann: »Fencing in the habitat - doing things right and getting the accessibility wrong«
• E-Access Blog: »Web Accessibility. Life In the Post-Guideline Age.«

Teil 2 – die Praxis:

• Chris Heilmann: »Making YouTube easier and more accessible« (mit Bastelanleitung und Demo zum ausprobieren)
• Chris Heilmann: »Easy Flickr - just the photos please« (ebenfalls mit Bastelanleitung und Demo zum ausprobieren)
• Dan Jellinek: »Web Accessibility - The Power of Five« (deckt sich mit den Erfahrungen aus dem BIENE-Prüfverfahren: es sind immer die gleichen Fehler, an denen viele Einreichungen schon in der Gruppenphase scheitern)
• Steve Faulkner: »Developer Beware: Using Flash to Detect Screen Readers« (Stimmt uneingeschränkt. Also: bitte nicht nachmachen.)
• Joe Dolson: »Best Practices: Writing for Accessibility« (wobei wir die Forderung, Texte, Interpunktion etc. einzig auf die Fähigkeiten von Hilfsmitteln hin zu optimieren nicht ganz nachvollziehen können)
• T.V. Raman: »Design patterns for accessible, crawlable and indexable content«
• Bruce Lawson: »Is alt text necessary for photo sharing sites?« (Jein.)

17 Apr 2008

Gesammelte Werke: Accessibility

Ungemein Praktisches für den täglichen Gebrauch im Weballtag:

• Martin Ladstätter, Artur Ortega: »Wurde Yahoo! erfolgreich gehackt? Beim letzten Hack-Day der Yahoo!-Entwickler wurde die Barrierefreiheit erhöht.« (und so hört sich das dann an)
• Markus Riesch: »Accesskeys nur für Blinde?«
• Fritz Weisshart: »Farbkontrast und Helligkeitsdifferenz nach W3C«
• T.V. Raman: »Wie ihr zugängliche Sites für User und Crawler erstellt«
• T.V. Raman: »Tipps, um Informationen allgemein zugänglich zu machen«
• Mike Cherim: »Are Lists Becoming the New Tables?«
• Mike Cherim: »Inaccessible Label-Wrapped Form Inputs«
• Joe Dolson: »Developing an effective text-resizing widget«
• Darren Rowse: »How to Make Your Video Posts More Accessible to an Untapped Market of Millions«
• Mike Davies: »Configuring links in Screen readers«
• Mike Davies: »Using titles on form fields«
• Jack Pickard: »Is Accessibility Measurement Harmful?«
• Jared Smith: »The plague of outline:0«

11 Mär 2008

Gesammelte Werke

Barrierefreiheit jenseits des Browsers:

• Golem: »Gnome: 50.000 US-Dollar für Barrierefreiheit«
• Bruce Byfield: »GNOME focuses on accessibility -- with a little help from Mozilla and others«
• Reverend Anthony: »Ramblings of a colorblind gamer«
• Tori Floyd: »Website Makes Gaming Accessible For Everyone«
• Eitan Glinert: »Designing Games That Are Accessible To Everyone«
• WebAIM: »Microsoft Word«
• Steve Lee: »Python Powered Accessibility«
• Wesley Fryer: »Converting text to and from speech for accessibility and convenience«
• E-Access Blog: »Dyslexia and the Civil Service«
• Microsoft UK: »Accessible Technology - A guide for teachers«
• Adam Lehman: »Is Adobe Flex Really Accessible? You bet your robot voice it is!«
• ATMac: »GarageBand Now Accessible For Blind Users«
• Regina Anthony: »Tech finally at hand for India’s 60 mn disabled«
• Joanna Bawa: »Investment in Accessibility is beginning to Pay Off«
• The Customer Respect Group: »Accessibility and business value study«

22 Feb 2008

Barrierefreiheit zum kucken

…und jetzt auch zum mitlesen: den ausgesprochen lehrreichen Film »Wie bedient ein seh­behin­derter oder ein blinder Mensch das Web?« des Instituts für Medi­zinische Lehre der Uni Bern gibt es jetzt auch mit Unter­titeln und Audio­des­kription. Damit ist das Video auch für Blinde als Hörfilm, für Gehörlose, sowie für alle Menschen, die die Schweizer Umgangs­sprache nicht verstehen, dank der Unter­titel zugänglich. Eine Auswahl der verschiedenen Varianten findet sich auf den Seiten des Usability-Labors der Uni Bern.

In dem Film zeigen Thomas Lanter, sehbehinderter Accessibility-Spezialist bei der Stiftung ›Zugang für alle‹ mit der Lupen-Software ZoomText und Jürg Cathomas, blinder IT-Spezialist des Schweizerischen Blinden- und Seh­behin­derten­verbands mit dem Screenreader JAWS, wie barriere­frei nutzbare Web-Angebote aufgebaut sein sollten.

13 Feb 2008

Gesammelte Werke

• Jörg Morsbach: »Epileptische Anfälle - unterschätztes Phänomen«
• Matthias Koch: »Erst Flash - dann Crash: Wenn Screendesign zur Waffe wird«
• Darryll A. DeCoster: »Standards, compliance and what about Flash?«
• Kim Krause Berg: »Is Accessibility Hard To Learn And Implement?«
• Lorelle VanFossen: »Blog Challenge: Testing Your Blog’s Accessibility«
• Rajveer Rathore: »Web accessibility is not hard to learn«
• Ron Graham: »Innovations of iPhone should lead to greater overall web accessibility«
• Laura Whitehead: »Remember accessibilty when using widgets on your website«
• Mike Davies: »Configuring links in Screen readers«
• Bim Egan: »Too much accessibility - the rise and fall of the LONGDESC«
• Vishal Verma: »How to Design Web Accessible Pages for the Colorblind«

06 Feb 2008

W3C veröffentlicht neuen Entwurf von WAI-ARIA

Seit ungefähr zwei Jahren entwickelt die Web Accessibility Initiative des W3C an der WAI-ARIA-Reihe, von der nun ein neuer Entwurf vorgelegt wurde. ARIA steht für »Accessible Rich Internet Applications« und soll als Interims-Lösung dafür sorgen, dass Web-basierte Applikationen für die Hilfsmittel behinderter Nutzer zugänglicher werden.

1. WAI-ARIA Primer ist ein neues Dokument, in dem die Hintergründe und Lösungsansätze der Spezifikation erklärt werden;
2. Accessible Rich Internet Applications (WAI-ARIA) Version 1.0, der aktuelle W3C Working Draft vom 4 Februar 2008, in dem die bisher getrennten Entwürfe für ›Roles‹ und ›States and Properties‹ kombiniert werden;
3. WAI-ARIA Best Practices beschreibt, wie Entwickler heute schon zugängliche Web-Anwendungen schreiben können.

Die Arbeitsgruppe bittet um Kommentare bis zum 3. März 2008, spezifische Fragen finden sich in den o.g. Dokumenten jeweils im Abschnitt »Status of This Document«.

Den besten Einstieg in das gesamte Thema bekommt man beim W3C: »WAI-ARIA Overview« oder in diesem Artikel von Martin Kliehm: »Accessible Web 2.0 Applications with WAI-ARIA« bzw. in der deutschen Übersetzung: »Barrierefreie Web 2.0 Anwendungen mit WAI ARIA«. Woran es zurzeit noch (insbesondere von Seiten der Hilfsmittel her) hapert beschreibt ein Artikel von Steve Faulkner: »AJAX and Screen Readers - Content Access Issues«.

30 Jan 2008

Mikroformatiges

Unsere anfängliche Begeisterung für Microformats ist schon vor einiger Zeit der Ernüchterung gewichen, nachdem wir uns verschiedene Muster mal im Screenreader angehört hatten. Trotz der vielen Möglichkeiten, Dokumente mit Bedeutung und Funktion anzureichern bleibt nach wie vor ein grundlegendes Problem: die Art wie das Element für Abkürzungen eingesetzt wird führt dazu, dass je nach Einstellungen im Screenreader ein vollkommen unverständlicher Zahlen- und Buchstabensalat vorgelesen wird.

Leider hat sich die Microformats-Community als weitestgehend therapieresistent gezeigt und sämtliche Verbesserungsvorschläge abgebügelt – trotz zahlloser Test Cases, in denen die Unbrauchbarkeit nachgewiesen wurde.

Ein Artikel, der die ganze Problematik aufzeigt (hAccessibility von Bruce Lawson und James Craig) ist nun von Michael Jendryschik ins Deutsche übersetzt worden: »hAccessibility« – bevor Sie Microformats unbedacht einsetzen empfiehlt sich die dringende Lektüre!

In die ähnliche Richtung geht ein neuer Artikel von Mike Davies im YUI-Blog, der sich der Problematik von leeren Links in Screenreadern annimmt: »Empty Links and Screen Readers«. Hier geht es um das include pattern, mit dem sich Daten in Seiten einfügen lassen, ohne dass diese als (unnötiges) Duplikat vorliegen.

Auch hier zeigt sich wieder das gleiche Problem: in Ermangelung von Inhalten oder Alternativen machen sich die getesteten Screeenreader wie üblich von alleine auf die Suche nach irgendwas zum Vorlesen und geben im Ernstfall den kompletten URL des leeren Links aus. Daher empfiehlt sich auch hier ganz dringend, die Empfehlungen am Ende des genannten Artikels beim Einbau von Microformats zu beherzigen.

28 Jan 2008

Kleines Helferlein für Farbenblinde

Bekanntlich haben ca. 8 Prozent aller Männer auf diesem Planeten die eine oder andere Form der Farbfehlsichtigkeit, weswegen die BITV hierzu gleich zwei Bedingungen (2.2 und 2.3) hat. Nun gibt es für den Firefox-Browser eine Erweiterung, die Farben von Texten und Bildern so verändert, dass die für bestimmte Formen der Fehlsichtigkeit problematischen Farben besser wahrgenommen bzw. differenziert werden können: ColorBlindExt Firefox Add-on. Das ganze benötigt neben satt RAM zusätzlich auch noch Java für die Filterfunktionen und tut's nur unter Windows.