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 (WAI) des W3C hat eine aktualisierte Fassung des Entwurfes zu den Authoring Tool Accessibility Guidelines (ATAG 2.0) veröffentlicht und bittet um Kommentare bis zum 30. November. Wichtige Änderungen gibt es zum Beispiel in dem Punkt, wie Autoren bei der Produktion von barrierefreien Inhalten durch die Autoren-Werkzeuge unterstützt werden sowie eine Überarbeitung der Techniken unter Implementing ATAG 2.0.
ATAG ist wie die beiden anderen WAI-Empfehlungen WCAG und UAAG ein wichtiger Baustein zur Barrierefreiheit. Die Richtlinie beschreibt, wie Autorenwerkzeuge möglichst zugängliche Web-Inhalte 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 auch, dass solche Anwendungen natürlich für Menschen mit Behinderung bedienbar und nutzbar sein sollten.
Die Web Accessibility Initiative des W3C hat eine aktualisierte Fassung des Entwurfes zu den Authoring Tool Accessibility Guidelines (ATAG 2.0) veröffentlicht und bittet um Kommentare bis zum 11. Juni. Ziel dieser Runde ist es, den als nächsten Schritt geplanten ›Last Call Working Draft‹ vorzubereiten. Wichtige Änderungen gibt es zum Beispiel in dem Punkt, wie Anwendungen mit Alternativtexten umgehen sollten (z.B. bei Foto-Communities wie flickr); ausserdem ist das Glossar komplett überarbeitet worden.
ATAG ist wie die beiden anderen WAI-Empfehlungen WCAG und UAAG ein wichtiger Baustein zur Barrierefreiheit. Die Richtlinie beschreibt, wie Autorenwerkzeuge möglichst zugängliche Web-Inhalte produzieren sollten und wie Autoren und Entwickler in ihrer Arbeit durch Werkzeuge wie Editoren und Redaktionssysteme darin unterstützt werden, saubere Arbeit ins Netz zu stellen. Ein wichtiger Aspekt ist auch, dass solche Anwendungen natürlich für Menschen mit Behinderung bedienbar und nutzbar sein sollten.
Rückrufaktion
Bei der XHTML2-Kindergarten -Arbeitsgruppe werden hingegen vier Entwürfe zurückgezogen, weil in der vorangegangenen Phase der Publizierung bestehende Einwände gegen die Entwürfe nicht beachtet wurden. Im einzelnen sind dies: XHTML™ 1.1 - Module-based XHTML - Second Edition, XHTML™ Basic 1.1 - Second Edition, XHTML-Print - Second Edition sowie XHTML™ 1.0. Hintergründe zu dieser Entscheidung kann man evtl. in dieser E-Mail von Bjoern Hoehrmann an die W3C-Mailingliste nachlesen.
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:
Letzte Woche hatten wir ja schonmal was über die User Agent Accessibility Guidelines als zweites Standbein der Web Accessibility; heute ist das dritte Standbein dran, die Authoring Tool Accessibility Guidelines (ATAG). Vornerum sauber können ja mittlerweile viele Redaktions- und Content Management-Systeme, aber wie es hinter den Kulissen aussieht ist, nun ja, lassen wir das.
Angie Radtke, Joomla-Anwendern vielleicht durch das barrierefreie und tabellenlose Template Beez bekannt, hat die Version 1.5 des Open-Source-CMS zusammen mit Eva Papst, der blinden Vorsitzenden des Vereins Accessible Media aus Wien zweieinhalb Tage lang getestet. Eine Zusammenfassung des Tests und die detaillierten Testergebnisse hat sie in ihrem Weblog veröffentlicht – da haben die Joomla-Entwickler ja jetzt einiges nachzubessern …
Passend zum Thema: TYPOlight webCMS ist angeblich sowohl auf der Ausgabe- als auch auf der Eingabeseite barrierefrei zu nutzen. Wir haben's nicht selber getestet, aber wenn der SWR darauf hinweist, dann kann's ja nicht soo schlecht sein.
Korrektur: das hat man davon, wenn man einfach alles nachplappert – TYPOLight ist wohl doch nicht so ganz barrierefrei zu nutzen; eine Vielzahl von onclick="this.blur" macht es für Tastaturbedienbar unbrauchbar. Danke an Jan Hellbusch für den Hinweis!
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
Implementation Techniques for Authoring Tool Accessibility Guidelines 2.0, W3C Working Draft vom 23. April 2007. Die Techniken sollen Entwickler von Autoren- und Designwerkzeugen oder Redaktionssystemen bei der Umsetzung der Authoring Tool Accessibility Guidelines (ATAG) unterstützen.
Auch für die Entwickler ganz »normaler« Webseiten und insbesondere für Web-basierte Applikationen sind diese Techniken von Bedeutung, da man ja streng genommen schon ein Autorenwerkzeug bereitstellt, sobald man in seinem Weblog Kommentare zulässt.
Man kann es eigentlich nicht oft genug sagen: die BITV ist nur ein Drittel in der Gleichung, die Barrierefreiheit zum Ergebnis haben soll. Und trotzdem – in Ausschreibungen und Lastenheften für Webauftritte findet man immer wieder Formulierungen wie …das zu liefernde CMS soll zu 100% BITV-konform sein
. Kein Wunder, dass CMS-Hersteller versprechen, ihr System sei selbstverständlich zu 100% BITV-konform, auch wenn dies gar nicht möglich ist und zudem nicht im Sinne der Verordnung. Kaum ein Hersteller verweist jedoch auf die eigentlich anzuwendenen Richtlinien, die ATAG des W3C (Ausnahmen bestätigen die Regel).
Wie entscheidet man sich nun, welches Content Management System das richtige ist? Was sind die Erfolgskriterien? Wie stellt man fest, ob das System auch für Menschen mit Behinderung zu bedienen ist? Das irische Centre for Inclusive Technology (CFIT) hat zehn verbreitete Systeme einem Praxistest unterzogen und eine Reihe gängiger Szenarien durch blinde Nutzer mit verbreiteten Screenreadern testen lassen. Die umfangreichen Ergebnisse wurden nun im Juicy Studio-Blog veröffentlicht: »Choosing an Accessible CMS«. Prädikat: Lesenswert.
Damit es unter der Oberfläche der Seiten nicht aussieht wie bei Bloggers hinter'm Sofa sollte man einen Editor benutzen, der nicht nur schnell und einfach zu bedienen ist, sondern der auch eine durchgängige Code-Qualität produziert. Am besten funktioniert das, wenn sich diese Editoren ihrerseits an die hierfür vorgesehenen Standards (z.B. ATAG) halten – dafür gibt es diese.
Peter Krantz hat sich (wie auch schon im Vorjahr) die Mühe gemacht und die gängigsten WYSIWYG-Editoren getestet, wie man sie in Redaktionssystemen und ähnlichem findet. Die Fragestellung war, wie gut sich ein Beispieldokument mit den verschiedenen Werkzeugen umsetzen liess: »Evaluation of WYSIWYG editors«. Die Testergebnisse mitsamt Benotung gibt es auch in einer tabellarischen Übersicht.
Die WCAG und damit die BITV sind eine wichtige Säule für das barrierefreie Web, aber sie sind auch nur ein Drittel des Gesamtpakets. Ebenso wichtig sind die User Agent Accessibility Guidelines (UAAG) und auch die Authoring Tool Accessibility Guidelines (ATAG). Von Letzteren liegt seit Ende vergangener Woche ein neuer Entwurf für die kommende Version 2.0 vor: »Authoring Tool Accessibility Guidelines 2.0, W3C Working Draft vom 7. Dezember 2006«.
Interessierte Fachleute werden gebeten, eventuelle Kommentare, Anregungen und Verbesserungsvorschläge bis zum 11. Januar 2007 an die Mailingliste w3c-wai-au@w3.org zu senden; die Hersteller von Redaktionssystemen und Autorenwerkzeugen werden gebeten, auch diesen Standard umzusetzen.
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.
Heute nochmal zur Abwechslung zu unserem Kernthema.
Die Web Accessibility Initiative des W3C (W3C WAI WCAG WG) hat eine Reihe neuer Entwürfe von kommenden Richtlinien veröffentlicht:
Die WCAG- und ATAG-Arbeitsgruppen bitten die interessierte Fachöffentlichkeit um die Abgabe von Kommentaren bis zum 21. Dezember an den dafür vorgesehenen Stellen:
Artverwandt und von besonderem Interesse ist auch die aktualisierte W3C Working Group Note: »Inaccessibility of CAPTCHA – Alternatives to Visual Turing Tests on the Web«.
In den kommenden zwei Tagen findet in Kanada ein Treffen der ATAG-Arbeitsgruppe des W3C statt, die seit geraumer Zeit an der Version 2 der ‹Authoring Tool Accessibility Guidelines› arbeitet. Auf dem Programm stehen die eingegangenen Kommentare aus der Final Call-Phase, sodaß wohl in Kürze mit der endgültigen Version zu rechnen ist. Wobei uns ja nach wie vor keine einzige kommerzielle Anwendung bekannt ist, die die Version 1 der ATAG erfüllt…
Wie es hingegen mit den WCAG weitergeht und wann von diesen eine Nachfolgeversion zu erwarten ist steht hingegen seit gestern noch weiter in den Sternen. Matt May, der bisher immer für einen Bezug zur Realität stand, verlässt seinen Posten: »After three years and about 250,000 actual miles of travel, I'm leaving the W3C«.
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.
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.
Via Matt May: die Web Accessibility Initiative des W3C (WAI) hat gestern zwei Dokumente mit dem Status des Last Call Working Draft vorgestellt:
Wie bei allen W3C-Empfehlungen neueren Datums kommt nun die Phase, in der diese kommenden Richtlinien in Beispiel-Implementierungen umgesetzt werden müssen, sonst wird's nichts mit der Verabschiedung. Wenn Sie also gerade an der Entwicklung einer CMS- oder Bloganwendung sitzen: jetzt wäre ein guter Zeitpunkt diese kommenden Richtlinien zu berücksichtigen.
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.
