News mit tag »Hilfsmittel«

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.

25 Jan 2008

Barrierefreiheit zum Kucken

Die britische Organisation Abilitynet hat sich bei YouTube eine Ecke eingerichtet, in der alle Videos gesammlt werden, die irgendwie mit der Computer-Nutzung von und durch Menschen mit Behinderungen zu tun haben: YouTube - abilitynet's Channel.

22 Jan 2008

Na das hat ja gerade noch gefehlt

Im Blog der Sicherheits-Firma Sophos wird von einem Schädling berichtet, der Screenreader-Software für blinde und sehbehinderte Computernutzer abschießt. Das Problem konnten die betroffenen Nutzer offenbar schnell einkreisen: Für den eingesetzten populären Screenreader JAWS hatten die Anwender einen Crack aus dem Netz geladen und installiert. Dieser Crack hatte jedoch neben der Patch-Routine, die JAWS auch ohne gültige Lizenz lauffähig macht, einen Schädling im Gepäck.

Die ganze Meldung bei heise: »Schädling greift Screen-Reader-Software an«.