Die Web Accessibility Initiative des W3C hat einen aktualisierten Entwurf der User Agent Accessibility Guidelines (UAAG) 2.0 und der Authoring Tool Accessibility Guidelines (ATAG 2.0) veröffentlicht – diese Standards machen neben den WCAG immerhin zwei Drittel des Gesamtbildes ›Barrierefreiheit‹ aus.
Die ATAG beschreiben, wie Autorenwerkzeuge möglichst zugängliche Webinhalte produzieren sollten und wie Autoren und Entwickler in ihrer Arbeit durch Werkzeuge wie Editoren und Redaktionssysteme in der Erstellung barrierefreier Inhalte unterstützt werden. Ein wichtiger Aspekt ist, dass solche Anwendungen natürlich auch für Menschen mit Behinderung bedienbar sein sollen.
Die UAAG definieren, wie Browser, Media Player und andere sog. ›User Agents‹ die barrierefreie Nutzung von Webinhalten durch Menschen mit Behinderungen ermöglichen sollen.
Die Arbeitsgruppe bittet Interessierte darum, die Entwürfe zu lesen und bei Bedarf bis zum 15. September 2011 zu kommentieren. Weitere Infos dazu:
Die Web Accessibility Initiative des W3C hat einen aktualisierten Entwurf der User Agent Accessibility Guidelines (UAAG) 2.0 veröffentlicht. Die UAAG definieren, wie Browser, Media Player und andere sog. ›User Agents‹ die barrierefreie Nutzung von Webinhalten durch Menschen mit Behinderungen ermöglichen sollen. Die Arbeitsgruppe bittet Interessierte darum, den Entwurf zu lesen und bei Bedarf bis zum 9. September 2009 zu kommentieren. Weitere Infos dazu im Call for Review, mehr Details zur Richtlinie bei UAAG Overview.
Wie sich vielleicht schon herumgesprochen hat, ist gestern die finale Version des Internet Explorer 8 zum Download veröffentlicht worden. Haben wir natürlich gleich gemacht, alleine schon um unsere eigenen Seiten komplett durchzutesten – bisher ohne Befund.
Angenehm überrascht hat uns (neben der gesteigerten Geschwindigkeit und den verbesserten Entwickler-Werkzeugen) die vollständige Unterstützung von CSS 2.1 (mit Ausnahme von Appendix A »Aural style sheets«, aber die unterstützt ja auch sonst niemand). Bevor ungeduldige Webdesigner nun einwerfen »Bäh, der kann ja immer noch keine runden Ecken«
– runde Ecken werden erst in CSS 3 spezifiziert werden, und das ist im Gegensatz zu CSS 2.1 noch lange nicht beim Status einer ›Candidate Recommendation‹ angelangt. Also freuen wir uns erstmal über das Erreichte.
Weiterlesen …
Standards
Und das ist eine ganze Menge. Die bereits erwähnte Unterstützung des aktuellen CSS-Standards brauchen wir nicht im Detail aufzudröseln, dafür gibt es im Netz ganz wunderbare Vergleichstabellen:
Weitere Infos zum Browser, zur Unterstützung von Web-Standards und zu deren Weiterentwicklung gibt es in einem Interview mit Chris Wilson, Platform Architect for IE bei Microsoft im SitePoint Podcast #11.
Accessibility
Für uns natürlich besonders interessant der Bereich der Zugänglichkeit des Browsers und der dargestellten Inhalte. Auch da gab es enorme Fortschritte – Jonas Hellwig nennt einige davon:
»In Punkto Barrierefreiheit macht der IE8 ebenfalls große Fortschritte! Die neue Funktion ›Caret Browsing‹ ermöglicht dem User eine vereinfachte Bedienung der Website mittels Tastatur. Hierbei soll ähnlich komfortabel navigiert werden wie innerhalb einer Textverarbeitungssoftware.
Die zweite neue Funktion nennt sich ›Adaptive Zoom‹. Hier muss eine Website nicht immer wieder von neuem gezoomt werden, sondern es kann ein individueller Wert in den Einstellungen vergeben werden. Die gesamte Ansicht innerhalb des IE8 wird dann immer in der gewünschten Zoomstufe dargestellt.«
Ebenso neu dabei ist die Unterstützung von WAI-ARIA. Diese zusätzlichen Rollen, Zustände und Eigenschaften können bereits von geeigneten Hilfsmitteln für die effektive Nutzung von Web-basierten Applikationen ausgewertet werden. Einen aktuellen Test der Unterstützung, nicht nur im IE 8, hat Steve Faulkner erstellt: ARIA roles exposed via MSAA by browsers on Windows - Safari 4, Opera 10, IE 8, Firefox 3 & Chrome 1.
Die komplette Übersicht der Neuerungen im Bereich ›Accessibility‹ gibt es im IEBlog: New Accessibility Features in IE8.
Schwarze Listen
Weniger schön ist der Schalter zur vermeintlichen Verbesserung älterer Web-Inhalte, die auf die fehlerhafte Darstellung in älteren IE-Versionen hin entwickelt wurden, bei Microsoft Compatibility View Blacklist genannt. Auch hierzu hat sich schon halb Klein-Bloggersdorf in epischer Breite ausgelassen; hier zunächst die Position von Microsoft:
… und die Reaktionen der Betroffenen:
Fazit: Alles in Allem ein guter Browser. Ob nun die Zeit gekommen ist, den IE6 komplett zu ignorieren oder ob man seine Website kompatibel für alle Browser macht, muss jeder für sich entscheiden.
Nachtrag 22.03.2009:
Wenn man mal über die vollständige Abwesenheit jeglicher gestalterischer Ansätze hinweg ist, dann ist die neue Übersetzungs-Suchmaschine des W3C ein wahrer Quell der Freuden für alle, die technische Spezifikationen lieber in ihrer Mutterprache lesen wollen: Advanced Search for W3C Translations. Neben der Suche nach z.B. Deutsch lässt sich die Suche auch auf Fachgebiete wie zum Beispiel Accessibility eingrenzen. Gutes Ding.
Dann gibt es vom W3C noch einen aktualisierten Entwurf der User Agent Accessibility Guidelines (UAAG) 2.0 zu vermelden. UAAG definiert, wie Browser, Media Player und andere sog. ›User Agents‹ die barrierefreie Nutzung durch Menschen mit Behinderung unterstützen und mit assistiven Techniken zusammenarbeiten. Kommentare zum Entwurf können bis zum 22. April abgegeben werden; weitere Infos im Call for Review.
Ebenfalls neu ist ein aktualisierter Entwurf der Authoring Tool Accessibility Guidelines (ATAG) 2.0, die nun mit den WCAG 2.0 in Einklang gebracht wurden. In diesen Richtlinien geht es einerseits um den barrierefreien Output von Autorenwerkzeugen (also Editoren, CMSe etc.), andererseits aber auch um die barrierefreie Bedienung solcher Anwendungen. Kommentare können bis zum 16. März abgegeben werden; weitere Infos im Call for Review.
Ein eher strategisches Papier ist der W3C Working Draft vom 10. März 2009 mit dem klangvollen Namen »Improving Access to Government through Better Use of the Web«, in dem die Vorteile offener Standards und offener Daten für die offene Partizipation der Bürger erklärt werden.
Weiterlesen …
Bei der ISO gibt es ebenfalls neue Standards zu Webdesign und Accessibility; leider sind diese kostenpflichtig, daher wissen wir nicht, was da drin steht:
- ISO 9241-20:2008 – Accessibility guidelines for information/communication technology (ICT) equipment and services
- ISO 9241-171:2008 – Guidance on software accessibility
- ISO 9241-151:2008 – Guidance on World Wide Web user interfaces
Warum die englische Übersetzung allerdings beim DIN knapp 300 € kostet (die deutsche Version schlägt mit 174,20 € zu Buche), während sie beim britischen BSI für schlanke 20 £ (umgerechnet 22 €) zu haben ist, will uns nicht in den Kopf.
Hart auf den Fersen der fast fertigen WCAG 2.0 kommen ein paar artverwandte Entwürfe von Standards, die das Bild erst komplett machen:
Man kann es eigentlich nicht oft genug wiederholen: die WCAG sind nur ein Drittel der unabdingbaren Komponenten der Web Accessibility. Wie auch die beiden anderen Richtlinien, WCAG und ATAG, sind die User Agent Accessibility Guidelines 1.0 (UAAG) mittlerweile etwas in die Jahre gekommen. Nun hat die Arbeitsgruppe ein grundlegendes Dokument veröffentlicht, in dem die Ziele der grundlegenden Renovierung beschrieben sind: »User Agent Accessibility Guidelines 2.0 Requirements«, W3C Working Draft vom 31. Oktober 2007.
Ebenfalls neu von der Web Accessibility Initiative ist ein Satz von Präsentations-Materialien zur kommenden WCAG 2.0: »About WCAG 2.0«. OK, gestalterisch ist bei den Folien noch etwas Luft nach oben vorhanden, aber es werden sehr nachvollziehbar die Unterschiede und Vorteile von 2.0 gegenüber 1.0 erklärt, garniert mit Tipps wie man den aktuellen Entwurf auch heute schon verwenden kann. (via)
Bei all den Diskussionen um das Ziel barrierefreier Webangebote fällt eine spannende Frage schon mal gerne hinten runter: wer ist denn eigentlich für die Umsetzung verantwortlich?
Zum Mithören:
Podcast vom 19. Juli
(.mp3, 14′48″, 6,9 MB)
Zum Mitlesen:
Die Mitschrift des Podcasts
Zum Abonnieren:
Der Podcast im iTunes Music Store
Heute wieder mal ausschließlich zu unserem Lieblingsthema:
Er soll einfach nicht in Frieden ruhen: die Firma Netscape hält wohl den einsamen Rekord im Aufwärmen längst totgeglaubter Browser Geschäftsmodelle. Nachdem man mit dem 4er-Modell den Browser-Krieg endgültig verloren hatte gab es ein Vielzahl von Wiederbelebungsversuchen unter verschiedenen Flaggen, die aber alle nicht den Schwund in Richtung Bedeutungslosigkeit aufhalten konnten. Der neueste Versuch steht uns nun in Form des Netscape 9 bevor, der aber dem Vernehmen nach nichts anderes ist als ein Firefox 2.0 mit aufgedeckelter Netscape-Oberfläche. Wie man bei uns im Rheinland (nicht nur zur aktuellen fünften Jahreszeit) so schön sagt: »Bruche mer nit, fott domet«.
Wo wir gerade bei Firefox sind: die kommende Version 3.0 wird dem Vernehmen nach endlich eine Option bieten, um automatische Weiterleitungen oder Aktualisierungen (engl.: meta-refresh) zu unterbinden. Nicht dass diese Vorgabe schon seit über 4 Jahren in den User Agent Accessibility Guidelines stände und auch die WCAG spielen den Ball in diesem Punkt streng genommen den Browserherstellern zu. Aber wir wollen nicht meckern und freuen uns über jeden noch so kleinen Fortschritt.
Nächster Browser: was vom bereits in der Planung befindlichen Nachfolger des neulich erst erschienenen Internet Explorer 7 (Codename: IE.next) zu erwarten ist hat Aaron Gustafson beim Web Standards Project zusammengefasst: »Talking with Microsoft about IE.next«; weitergehende Wünsche äussert David Andersson: »The time to abandon backwards compatibility is now, Microsoft«.
So, mit dem Lesen der aktuellen WCAG 2-Version (wir berichteten) sind wir jetzt zur Hälfte durch. Wohlgemerkt: mit dem reinen Lesen, beim Verstehen liegen wir noch ein paar Runden zurück. Dabei sind uns Dinge aufgefallen, die wir hier zur Diskussion stellen möchten:
Die Vorgängerversion (und somit auch die BITV in 13.6) fordert, dass inhaltlich verwandte oder zusammenhängende Hyperlinks zu gruppieren sind. Die Gruppen sind eindeutig zu benennen und müssen einen Mechanismus enthalten, der das Umgehen der Gruppe ermöglicht.
Nach allgemein akzeptierter Lesart sind mit »Gruppen« wesentliche Bereiche einer Webseite gemeint, zu denen man lokale Sprunglinks anbieten sollte, also zum Beispiel zur Navigation oder zum Inhalt der Seite. Die sollten dann auch schon reichen, wenn man viel mehr dieser Skip Links braucht, hat man als Anbieter wahrscheinlich ein generelles Problem mit dem Aufbau der Seiten.
Nun geht der Entwurf der WCAG 2 weit über das hinaus, was Stand der Technik und Konsens unter den meisten Experten und Nutzern ist. Die Richtlinie in den WCAG 2 selbst liest sich noch ganz vernünftig: Blocks of content that are repeated on multiple perceivable units are implemented so that they can be bypassed.
Diese Richtlinie lässt sich so interpretieren, dass man eine Liste von 5 Links, zum Beispiel eine sich auf mehreren Seiten in der gleichen Form wiederholende Navigation mit Skip Links ausstatten soll. (Zwischenfrage: was ist aber mit einer Liste von 200 Links, die nicht auf anderen Seiten wiederholt wird? Muss der Nutzer sich diese komplett anhören?)
Problematisch wird es dann aber im nachgeordneten Techniques-Dokument, in dem Methoden zur Umsetzung beschrieben werden: The first interactive item in the Web unit is a link to the beginning of the main content.
Sollte die Formulierung The first interactive item
(Betonung hinzugefügt) tatsächlich so in den endgültigen Techniken stehen, so würde dies bedeuten, dass Skip Links immer vor Elementen stehen müsste, die bisher üblicherweise diesen Platz belegten. Bei den meisten Webangeboten wären das üblicherweise Dinge wie der Kopfbereich mit Logo und zusätzlichen Informationen zur Orientierung.
Mal abgesehen davon, dass eine solche Konstruktion ausgesprochen unpraktisch wäre, da der Benutzer des Skip Links unter Umständen gar nicht erfährt, wo er überhaupt ist, worum es in der Seite geht usw., da diese Informationen ja dann nur noch nach dem Skip Link kommen können (wir erinnern uns: der steht immer an erster Stelle) – und somit übersprungen werden.
Daher unsere Frage in die Runde: dass Skip Links eine gute Idee sind, solange nicht alle Browser die strukturierte Navigation beherrschen, wie sie von den User Agent Accessibility Guidelines gefordert wird, steht ausser Frage. Nur – wo genau sollten diese Links stehen? Unmittelbar am Anfang? Oder ist es unter Umständen doch hilfreich, wenn diese erst nach einer (kurzen) Identifizierung der jeweiligen Seiten kommen? Meinungen dazu bitte in den Kommentaren abgeben.
Man kann es nicht oft genug betonen: die Erfüllung der WCAG und der BITV macht nur ein Drittel des Gesamtpaketes ›Barrierefreiheit‹ aus. Gerne vergessen wird immer, dass es ebensogut Empfehlungen für die Eingabe- und Ausgabeseite gibt: ATAG (Authoring Tools Accessibility Guidelines, also die Richtlinien für Redaktionssysteme, Blogtools und Editoren) und die UAAG (User Agent Accessibility Guidelines, also die Richtlinien für Browser & Co.). Weil diese Richtlinien aber bisher nicht nur in Deutschland geflissentlich ignoriert wurden, lag und liegt nahezu die gesamte Last bei den Webentwicklern.
Nun haben sich mehrere Browserhersteller verpflichtet, eine freiwillige Selbsterklärung nach §1194.21 der amerikanischen Section 508 abzugeben, in der die Möglichkeiten zur barrierefreien Wahrnehmung und Bedienung von Webinhalten beschrieben werden. Beispielhaft hierfür ist das Voluntary Product Accessibility Template der Mozilla Foundation. Wie wir im Artikel »Web browsers comply with Section 508« lesen konnten, hat auch Microsoft eine vergleichbare Dokumentation für das gesamte Windows-Betriebssystem erstellt und wird dieses auch für den kommenden Internet Explorer 7 veröffentlichen.
Wie bei Robert Scoble und im IEBlog zu lesen war hat Bill Gates gestern in einer Rede verkündet, daß es nun wohl doch noch einen Internet Explorer mit der Versionsnummer 7 vor dem Erscheinen von Longhorn geben wird. Die Ankündigung macht aber keine Aussage darüber, wann wir mit einer finalen Version rechnen können – die angekündigte beta-Phase kann sich auch gut bis zum Erscheinen des XP-Nachfolgers erstrecken. Sicher ist nur, daß es das Update ausschließlich für Kunden mit Windows XP SP2 geben wird.
Der Fokus wird naturgemäß erst mal auf einer Verbesserung der Sicherheit liegen, evtl. hier und da noch etwas aufgepeppt mit Tabs und ähnlichem. Ob hingegen die Unterstützung für ältere Web-Standards wie HTML 2, HTML 4, XHTML, CSS 1, CSS 2 (das man sich selbst hat patentieren lassen), 24bit-PNG, HTTP 1.1, UAAG 1 usw. etc. pp. geplant ist, war nicht in Erfahrung zu bringen.
Die Ankündigung kommt übrigens just in der Woche, wo der Zähler bei spreadfirefox.com die 22 23 24 25 Millionen-Marke überschritten hat. Ein Schelm…
Am heutigen Donnerstag, den 3. Februar jährt sich zum fünften Mal die Verabschiedung der Authoring Tool Accessibility Guidelines (ATAG) des W3C. Mit diesen Richtlinien sollen einerseits Autoren bei der Erstellung barrierefreier Webinhalte unterstützt werden; andererseits gilt die Richtlinie auch für die Hersteller von Autoren- und Redaktionssystemen, die damit ebenfalls zugängliche Oberflächen für Ihre Anwendungen umsetzen können.
Und wie so häufig in letzter Zeit wird auch diese Richtlinie geflissentlich ignoriert und stattdessen die gesamte Verantwortung für ein barriereärmeres Netz via WCAG und BITV auf die Webautoren abgewälzt. Denn auch beim W3C ist bisher keine Anwendung bekannt, der man eine Konformität zu den ATAG nachsagen könnte.
Dabei funktioniert die Umsetzung der WCAG und der davon abgeleiteten BITV nur im Zusammenhang mit diesen ATAG und einem weiteren Stiefkind in der Diskussion, den User Agent Accessibility Guidelines. Trauriges Fazit: 5 Jahre ATAG und keiner hat's gemerkt.
IBM hat eine neue Version 3.04 des Home Page Reader vorgestellt. Neu sind unter anderem die direkte Unterstützung von getaggten PDF-Dokumenten und barrierefrei aufbereiteten Flash-Filmen. Nach Aussage des Herstellers werden nun auch die W3C-Empfehlungen zu HTML 4.01, WCAG 1.0 und vor allem UAAG 1.0 unterstützt. Die neue Version liest aber nicht mehr nur Webseiten vor, sondern mausert sich zu einem ausgewachsenen Screenreader. So lassen sich jetzt verschiedene Windows-Anwendungen und auch das Betriebssystem selber mit dem HPR navigieren. Weitere Informationen in Englisch und Download bei IBM.
Dey Alexander hat sich die Mühe gemacht und eine Version der verschiedenen Accessibility Guidelines der W3C-WAI (ATAG 1.0, UAAG 1.0, WCAG 1.0) sowie zusätzlich der amerikanischen Section 508 für Apples iPod zusammengebaut: »Web accessibility podGuide«. Das ganze ist komprimiert gerade mal 80 Kilobyte groß und läuft auf jedem iPod der dritten oder vierten Generation (mangels Display natürlich nicht auf den neuen iPodShuffle).
Wenn wir schon dabei sind: von John Alsopp gibt es auch noch den style master css podGuide, weiteren tragbaren Content bei podsites.com.
Einen eher ernüchternden Blick auf den gegenwärtigen Zustand von Autorenwerkzeugen und insbesondere Blog-Tools wirft Joe Clark in »Time to call bullshit on Six Apart« – ernüchternd deswegen, weil die diskutierten Tools allesamt jünger als die Authoring Tools Accessibility Guidelines (ATAG) des W3C sind, aber keines davon auch nur in die Nähe dieser schon etwas länger bestehenden, aber gerne übersehenen Standards kommt. Die Älteren unter uns werden sich noch erinnern: am 5. Februar feiern die ATAG 1.0 ihren fünften Geburtstag und bisher hat es nicht ein Softwarehersteller geschafft, auch nur Teile davon zu erfüllen.
Unterdessen steht beim W3C bereits der Nachfolger in Form eines Last Call Working Draft of Authoring Tool Accessibility Guidelines 2.0 in den Startlöchern. Ende der Frist zur öffentlichen Kommentierung ist der 18. Januar, weitere Infos bei der WAI.
In Deutschland ist die dem Bund per Verordnung vorgeschriebene Barrierefreiheit ja bekanntlich in der BITV geregelt, die wiederum auf den Web Content Accessibility Guidelines (WCAG) der W3C WAI basiert. Weniger bekannt ist der Umstand, daß diese WCAG nur ein knappes Drittel der WAI-Richtlinien ausmachen. Ebenso wichtig zur Erreichung eines barriereärmeren Netzes sind die Richtlinien für Autorenwerkzeuge, die Authoring Tools Accessibility Guidelines (ATAG) und die Richtlinien für die Zugangssoftware (vulgo: Browser), die User Agent Accessibility Guidelines, kurz UAAG.
Die deutsche Internetbranche ist aber bisher aus unerfindlichen Gründen von zwei Dritteln der Richtlinien verschont geblieben. Engagierte Webentwickler werden dadurch von zwei Seiten in die Zange genommen: einerseits müssen sie mit unzureichenden Werkzeugen dafür sorgen, daß das Ergebnis BITV-konform ist. Obwohl die Anwendungen sich ihrerseits an keinen erkennbaren Standard halten, sondern so tun, als ob Netscape 3 immer noch 70% Marktanteil hätte. Andererseits müssen sie sich mit Fehlern in den User Agents, und hier insbesondere den assistiven Werkzeugen, herumschlagen, die nicht in der Lage sind den HTML4-Standard von 1997 korrekt umzusetzen.
In eine ähnliche Kerbe schlägt der Barrierekompass mit seiner Nachberichterstattung der soeben abgelaufenen Contentmanager.days in Leipzig: »ATAG, WCAG und weiter«.
Andere Länder sind da fortschrittlicher: so reguliert die Section 508 des amerikanischen Rehabilitation Act nicht nur das fertig gerenderte Ergebnis im Browser, sondern eine Fülle weiterer Qualitätsmaßstäbe. Vergleichbares findet sich hierzulande nur in einem Wust weiterer Verordnungen mit so komischen Abkürzungen wie BildSchArbV oder Gesetzen wie dem SGB IX.
Theoretisch liesse sich aus der in letzterem enthaltenen Verpflichtung zur barrierefreien Ausstattung von Arbeitsplätzen durchaus ein Anspruch an die Software-Industrie ableiten, nur scheint diese Möglichkeit bisher nicht genutzt zu werden. Anders in USA: durch den Druck des Gesetzgebers ist es mittlerweile sogar möglich, mit dem lange geschmähten MS Frontpage halbwegs barrierearme Ergebnisse zu generieren. Nicht weil die WCAG dies erfordern würden (das tun sie nämlich nicht), sondern weil die amerikanische Bundesregierung ansonsten das Programm nicht mehr kaufen dürfte.
Ein guter Teil der Verantwortung für barrierefreie Informationstechnik liegt auch bei den Nutzern und den Software-Anbietern. Für letztere gelten die User Agent Accessibility Guidelines (UAAG) des W3C, aber auch von den Benutzern kann durchaus verlangt werden, daß sie sich mit den grundlegenden Funktionsweisen der von ihnen benutzten Werkzeugen beschäftigen. Welche Hilfen das alternative Betriebssystem Linux zur Verfügung stellt, fanden wir bei Linux Accessibility HOWTO.
The Linux Accessibility HOWTO covers the use of adaptive technologies that are available for the Linux operating system, as well as the software applications and hardware devices that can be installed to make Linux accessible to users with disabilities. The information provided targets specific groups of individuals with similar disabilities.
Die letzte Woche gemeldete Veröffentlichung einer Studie der britischen Disability Rights Commission war zwar einerseits ganz nett (der Webcast wurde simultan in die Britische Gebärdensprache BSL übersetzt), andererseits hat sie aber auch grundlegende Mängel im Verständnis der etablierten Standards und der Funktionsweise des Webs offenbart. So hat das W3C die geäußerte Kritik an den eigenen Standards bereits zurückgewiesen und, wie wir meinen, zu Recht darauf verwiesen, daß viele Hürden auch durch inadäquate Hilfsmittel entstehen, die nicht den User Agent Accessibility Guidelines (UAAG) entsprechen. Auch kann die Verantwortung für eine weitestgehende Barrierefreiheit nicht zu 100 Prozent den Anbietern in die Schuhe geschoben werden, solange die meisten Anwendungen zur Erstellung und Pflege von Webinhalten noch nicht einmal in die Nähe einer Erfüllung der Authoring Tool Accessibility Guidelines (ATAG) kommen. Mehr dazu bei webstandards.org, outlaw.com und The Register.
Die letzte Woche vermeldete Petition für ein kostenloses JAWS hat mittlerweile einige Kontroversen in der englisch-sprachigen Webentwickler-Szene verursacht. Der Konsens scheint mittlerweile zu sein, dass die Petition wirklich nicht besonders sinnvoll ist und man als unbedarfter User auch nicht unbedingt mit diesem verbreiteten Screenreader testen sollte.
Viel sinnvoller erscheint dagegen auch uns die Beschäftigung mit den tatsächlichen Fähigkeiten und Fehlern der verschiedenen assistiven Werkzeuge. Gez Lemon will sich die Mühe machen und unter Assistive Device Behaviour Chart eine Referenz erstellen, aus der die Unterstützung der wichtigsten WCAG-Vorgaben durch die verschiedenen Programme ersichtlich wird. Eine wahre Mammut-Aufgabe, aber sehr lobens- und beachtenswert.
Eine ebenso wichtige Lektüre für jeden, der sich mit Accessibility beschäftigt, sollte der Web Designer's Guide to JAWS von Kynn Bartlett und der Summary implementation report for UAAG 1.0 beim W3C sein.
