Eintippen, Knopf drücken, fertig: Diskussionen in Foren und Kommentare in Blogs, soziale Interaktion in Communities, das Hochladen eigener Inhalte in Videoportalen, Jobangebote und -gesuche in Stellenbörsen, Fahrplanauskünfte und Tickets bei der Bahn oder Bestellungen und Bezahlung in Online-Shops, ja sogar das Einstellen von Inhalten in Redaktionssystemen und Weblogs – all das funktioniert nur mit Formularen. In Zeiten des Mitmach-Webs werden Formulare immer wichtiger. Formulare sind die technische Basis interaktiver Angebote und die Grundlage der Kommunikation zwischen Anbietern und Nutzern einer Webseite.
Weiterlesen …
Gerade bei Formularen gelten die POUR-Prinzipien der WCAG 2.0 in Reinform: Formulare müssen wahrnehmbar (im Englischen: perceivable), bedienbar (engl. operable), verständlich (understandable) und robust (robust) sein. In den Richtlinien finden sich nur wenige direkte Vorgaben zu Formularen, aber fast alle Punkte der WCAG sind anwendbar – von HTML über CSS und WAI-ARIA bis zu JavaScript und der serverseitigen Verarbeitung der eingegebenen Daten. Obwohl HTML seit Jahren viele Elemente für barrierefreie und damit bedienerfreundliche Formulare enthält, setzen Webdesigner sie zu wenig ein.
Die technischen Grundfunktionen eines Formulars – erfassen, ausfüllen und abschicken – müssen mit allen möglichen Mitteln der Ein- und Ausgabe gelingen. Konkret heisst das, Anbieter von Webseiten müssen assistierende Techniken wie z.B. Screenreader, Sprachsteuerung oder Spezialtastaturen berücksichtigen. Für öffentliche Anbieter, die den Vorgaben der Barrierefreie Informationstechnik-Verordnung (BITV) unterliegen, ist der Einsatz dieser Mittel klar geregelt: die Verordnung verlangt die Verwendung der korrekten HTML-Elemente und den Einsatz von CSS für die Gestaltung, das gilt auch für Formulare. Alle anderen Anbieter profitieren ebenfalls von einer einfachen und barrierefreien Nutzbarkeit ihrer Formulare.
Die Konzeption der Formulare oder der Anwendung steht vor der technischen Umsetzung. Der Webentwickler Timo Wirth hat die Perspektive der Nutzer in einer Präsentation einmal so formuliert: »Ein Formular ist kein Datenbankprozess, es ist der Anfang eines Gesprächs«
. Damit ein gelungener Dialog entsteht, gibt diese Serie Hinweise zur barrierefreien Umsetzung von Formularen.
Die Serie ist in fünf Teile gegliedert:
Im ersten Teil »Toleranz und Rücksicht« geht es um Grundlagen und Konzeption von Formularen. Der zweite Teil – »Formulardesign: der wichtige erste Eindruck« – dreht sich um die Gestaltung, Nutzerführung und Usability. Das technische Grundgerüst und damit die Markup-Grundlage von Formularen und das Layout per CSS ist Inhalt des dritten Teils »HTML & CSS für Formulare«.
Neben den für die Struktur benötigten HTML-Elementen und CSS für die Gestaltung kommt in vielen Formularen JavaScript für das Verhalten zum Einsatz. In Teil 4 geht es um »Dynamik in Formularen – JavaScript & AJAX«.
Im letzten Teil zeigen wir, wie Sie eine erste Qualitätssicherung vornehmen können und geben Tipps für Tests mit echten Nutzern: »Testen von Formularen und web-basierten Anwendungen«.
Die Verwendung simulierter Dialogfenster oder »Lightboxes« – wie man im Englischen kurz und treffend zu sagen pflegt – ist aus dem Internet und der Web2.0-Welt eigentlich kaum noch wegzudenken, zu weit verbreitet scheint ihre Verwendung – zur Freude und zum dem Ärgernis der Nutzer.
Oliver Siemoneit zeigt in seinem Beitrag die gängigen Probleme aus Sicht der Nutzer und stellt den Prototypen einer zugänglichen Lightbox vor:
»Eine kleine Untersuchung zur Barrierefreiheit von Lightboxes«
Ergänzend zum vorstehenden Artikel hier noch ein paar zusätzliche Gedanken, Anforderungen und weiterführende Links zum Thema ›Barrierefreie Lightboxes‹.
Weiterlesen …
Kontext & Anforderungen
Manchmal muss man Benutzern ein reduziertes Interface präsentieren, das den Fokus auf die wesentlichen Informationen oder auf Formularfelder setzt und die Interface-Elemente versteckt, die für die gerade zu erledigende Aufgabe unnötig sind. Wenn dies in Form eines Overlays (auch ›Lightbox‹ genannt) implementiert wird, erscheint der Inhalt als Pop-Up-Fenster oder als simulierter Dialog. Die Lightbox überlagert den Inhalt der Webseite, der Hintergrund wird typischerweise ausgegraut.
Eine Lightbox kann modal sein, d.h. der Benutzer kann nur mit der Lightbox und deren Inhalt interagieren. Oder sie kann nicht-modal sein, d.h. der Benutzer kann in diesem Fall sowohl mit der Lightbox und ihrem Inhalt, als auch mit anderen Elementen der ursprünglichen Seite interagieren.
Hürden & Schwierigkeiten
In Sachen Barrierefreiheit bringt die Benutzung von Lightboxes einige Probleme für verschiedene Gruppen von Menschen mit Behinderungen mit sich. Mögliche Schwierigkeiten sind unter anderem:
- Die Möglichkeit, die Lightbox ohne die Hilfe einer Maus oder anderer Zeigewerkzeuge über eine Tastatur-Schnittstelle zu öffnen und zu schließen.
- Die Benachrichtigung des Benutzers über die Generierung einer Lightbox bzw. das Einfügen des benötigten Codes in die Seite (dies schließt Benutzer von Vergrößerungssoftware ein, die möglicherweise das plötzliche Erscheinen einer Lightbox nicht bemerken, da dies außerhalb ihres Sichtfeldes passiert ist).
- Der Zugriff per Tastatur auf die Lightbox selber (und auf deren Position im DOM-Tree in Relation zu dem auslösenden Element) und auf die Tab-Reihenfolge (und damit die Lesereihenfolge) zu jeglichen Formular-Elementen, Steuerelementen, Links usw., die in der Lightbox enthalten sind.
- Die visuellen Grenzen der Lightbox für Benutzer mit eingeschränktem Sehvermögen oder blinde Benutzer verständlich zu machen und die Notwendigkeit, den Zugriff des Benutzers auf Inhalte innerhalb einer modalen Lightbox zu beschränken.
- Die meisten Lightbox-Scripte setzen einen relativ großen Bildschirm voraus und scheitern bei mobilen Geräten (oder verkleinern nicht auf elegante Art und Weise).
- Die meisten Lightbox-Skripte unterstützen das Drucken nicht.
Barrierefreie Lösungen
Eine Lightbox und ihr Inhalt kann durch die Benutzung einer Reihe von Techniken barrierefrei gemacht werden, wenn man Best Practices der Barrierefreiheit (wie zum Beispiel die Techniques der WCAG 2.0) einsetzt:
- Beim Öffnen der Lightbox sollte der Tastatur-Fokus auf die Lightbox gesetzt werden (idealerweise auf das erste fokussierbare Element, bei dem es sich um einen Link, ein Formular-Label oder ähnliches handeln könnte).
- Beim Schließen der Lightbox muss der Tastatur-Fokus wieder zu der exakt gleichen Stelle zurückkehren, bei der er war, als die Lightbox geöffnet wurde (normalerweise das anfänglich benutzte Element zum Öffnen des modalen Dialogs). Die ursprüngliche Tab-Reihenfolge sollte wiederhergestellt werden und der Benutzer sollte nicht länger in der Lage sein, sich per Tab zu Inhalten innerhalb des modalen Dialogs zu bewegen (d.h. die Lightbox sollte nicht einfach nur aus dem Viewport bewegt werden, sondern sollte ganz aus dem Dokumenten-Baum entfernt werden);
- Das Lightbox-Script sollte die Bedienung per Tastatur vollständig unterstützen (z.B. Esc. zum Schließen der Lightbox, Pfeiltasten zum Blättern in einer Diaschau, Home- & End-Schaltflächen wie auf einer normalen Webseite). Es sollte ein deutlich sichtbarer Fokus-Indikator vorhanden sein und Tastaturbefehle sollten in der Lightbox dokumentiert sein (z.B. »Zum Schließen drücken Sie Esc«).
- Das Lightbox-Script sollte einen vollständigen Browser-Verlauf bieten und die Änderung des
title unterstützen (z.B. über jQuery Address).
- Der Inhalt innerhalb der Lightbox muss voll skalierbar sein (z.B. mit unterschiedlichen Textgrößen).
- Das Design der Lightbox sollte robust genug sein, damit es komplett wahrnehmbar ist, wenn benutzer-definierte Farben (z.B. ein Windows Kontrast-Schema) benutzt wird.
- In modalen Dialogen sollte der Benutzer nicht zu irgendwelchen Elementen außerhalb der Lightbox navigieren können. Stattdessen muss der Tastatur-Fokus innerhalb der Lightbox verbleiben, bis der Benutzer diese absichtlich schließt, entweder indem er Esc drückt oder auf einen Schließen-Link oder eine Schließen-Schaltfläche klickt. Vor allem wenn Formulare in einer Lightbox präsentiert werden, sollte das Tabben über die Lightbox hinaus diese nicht schließen, um einen Datenverlust zu verhindern. Dies kann allerdings in anderen Fällen, wie zum Beispiel bei einer Galerie, genau das erwartete Verhalten sein.
- Die Benutzung von ARIA-Rollen & -Eigenschaften (wie zum Beispiel
aria-role="dialog"oder role="button" für das »Schließen«-Symbol), ARIA-Live-Regions und zusätzlichen ARIA-Attributen, die Beziehungen beschreiben, wie zum Beispiel aria-owns.
Anwendbare Standards & verwandte Techniken
Literatur zum Thema
Beispiele ›aus der freien Wildbahn‹
Code-Beispiele & Downloads
Barrierefreie Seiten zeichnen sich dadurch aus, dass sie auch unter den widrigsten Umständen noch Leistung abliefern. Das geht natürlich nur mit einem grundsoliden technischen Fundament, bei dem Browser nicht erst mal zahllose Fehler korrigieren müssen, bevor die Seite dargestellt werden kann. Das vereinfacht nicht nur die Verarbeitung, sondern hilft auch den Nutzern bei der eindeutigen Wahrnehmung und Bedienung, wie in den folgenden WCAG-Techniken erklärt wird:
Weiterlesen …
Allgemeine Techniken
HTML-Techniken
Client-seitige Scripting-Techniken
Typische Fehler
Ebenso wie Weiterleitungen können periodische Aktualisierungen und dynamische Änderungen am Seiteninhalt in vielen assistiven Hilfsmitteln dazu führen, dass die Nutzbarkeit eines Angebots stark eingeschränkt oder sogar unmöglich gemacht wird. Tipps zur Vermeidung, aber auch immer wieder gern gemachte Fehler finden Sie in den folgenden WCAG-Techniken:
Weiterlesen …
Allgemeine Techniken
- G10: Durch die Benutzung einer Technik, welche die API-Barrierefreiheitsfunktion der Plattform, auf dem der Benutzeragent laufen wird, unterstützt, werden Bestandteilen erstellt, um Namen und Rollen offenzulegen, um eine direkte Festlegung der vom Benutzer festzulegenden Eigenschaften zu ermöglichen und eine Benachrichtigung über Änderungen zur Verfügung zu stellen
- G75: Bereitstellung eines Mechanismus, um jegliche Aktualisierung des Inhalts aufzuschieben
- G76: Bereitstellung eines Mechanismus, um die Aktualisierung von Inhalten anzufordern statt einer automatischen Aktualisierung
- G108: Benutzung von Auszeichnungsfunktionen, um Name und Rolle offenzulegen, um es zu ermöglichen, vom Benutzer einzustellende Properties direkt festzulegen und um Benachrichtigungen über Änderungen zur Verfügung zu stellen
- G135: Benutzung der API Barrierefreiheitsfunktionen einer Technik, um Namen und Rollen offenzulegen, um eine direkte Festlegung der vom Benutzer festzulegenden Eigenschaften zu ermöglichen und eine Benachrichtigung über Änderungen zur Verfügung zu stellen
Client-seitige Scripting-Techniken
Typische Fehler
- F16: Fehler bei Erfolgskriterium 2.2.2, weil scrollende Inhalte enthalten sind, bei denen die Bewegung für die Handlung nicht unentbehrlich ist, ohne zusätzlich einen Mechanismus aufzunehmen, um Inhalte anzuhalten und wieder zu starten
- F59: Fehler bei Erfolgskriterium 4.1.2, weil Script benutzt wird, um div oder span zu einem Steuerelement der Benutzerschnittstelle in HTML zu machen
- F60: Fehler bei Erfolgskriterium 3.2.5, weil ein neues Fenster geöffnet wird, wenn ein Benutzer Text in einem Eingabefeld eingibt
- F61: Fehler bei Erfolgskriterium 3.2.5, weil der Hauptinhalt durch eine automatische Aktualisierung, die der Benutzer aus dem Inhalt heraus nicht deaktivieren kann, komplett geändert wird
- F76: Fehler bei Erfolgskriterium 3.2.2, weil in einem Element der Benutzerschnittstelle an einem Ort, den Benutzer umgehen können, Material mit Anweisungen zu den Änderungen des Kontextes durch die Änderung der Einstellungen bereitgestellt wird
Bei der Verwendung von Skripten zur dynamischen Änderung von Formularen gibt es eine ganze Reihe Aspekte der Barrierefreiheit zu beachten, wie in den folgenden WCAG-Techniken erklärt wird:
Weiterlesen …
Allgemeine Techniken
Client-seitige Scripting-Techniken
Typische Fehler
Widgets ade
Fast täglich erreichen uns in der EfA-Redaktion Mails mit der Frage nach dem Verbleib des EfA-Fontsize-Skriptes, das den letzten Relaunch nicht überlebt hat. Die kurze Antwort: es war weg, ist weg und wird auch weg bleiben. Die lange Version der Antwort wollen wir unseren Lesern aber auch nicht vorenthalten:
Eine fiktive aber durchaus realistische Diskussion zwischen einem Frontend-Entwickler (im folgenden F. genannt) und einem Projektmanager (im folgenden P. genannt; eventuelle Ähnlichkeiten mit tatsächlichen Personen sind rein zufällig und unbeabsichtigt).
Projektmanager (P.): »Die Website muss ganz dringend barrierefrei sein. Deswegen brauchen wir da noch unbedingt so ein Ding, womit man die Schriftgröße ändern kann.«
Entwickler (F.): »Aber warum? Wir haben doch ganz andere Probleme mit der Website!«
P.: »Egal, wir brauchen so ein Ding, damit endlich diese Mails und Anrufe aufhören, wo sich Besucher über die Unzugänglichkeit der Website beschweren.«
F.: »Das wäre aber doch nur an den Symptomen rumgedoktert und würde nicht die Ursachen kurieren. Und ausserdem kann das doch jeder Browser…«
P.: »Aber unsere Statistiken sagen, dass immer noch 20% aller Besucher den IE6 benutzen. Und ich habe gehört dass der keine Schriften vergrößern kann.«
F.: »Kann er wohl…«
P.: »Egal, der Kunde will das so und basta…«
An dieser Stelle endet unsere Aufzeichnung des Gesprächs, weil F. mit dem Kopf auf die Tischplatte aufgeschlagen ist.
Weiterlesen …
Der Häufigkeit nach zu urteilen, mit der man diese »Widgets« zur Schriftskalierung oder Kontrastverstärkung auf Web-Seiten findet, muss es solche Gespräche in der ein oder anderen Form wohl häufig gegeben haben.
Zugegeben, wir sind daran nicht ganz unschuldig, denn viele davon basieren auf einem Skript, dass wir in den Anfangstagen von ›Einfach für Alle‹ veröffentlicht und auf diesen Seiten eingesetzt haben. Nun ist es aber weg und unsere Redaktion erreichen fast täglich Mails und Anrufe, wo denn das Skript geblieben sei. Es ist weg, und es wird auch nicht wiederkommen.
Warum war das Skript früher mal gut und jetzt auf einmal nicht mehr?
Machen wir einen kleinen Ausflug in die Zeit, in der das Skript entstanden ist. Damals, d.h. so um die Jahrtausendwende, waren Web-Standards nur eine nette Idee, die sich aber in den Browsern der vierten Generation nur von Spezialisten in mühsamer Handarbeit umsetzen liessen (und auch das nur höchst lückenhaft). Modernere Browser wie Firefox, Opera, Safari & Co. waren teils noch gar nicht auf dem Markt oder ausgesprochene Exoten; Microsoft hatte gerade die Weiterentwicklung des marktführenden IE 6 effektiv eingestellt. Ein »Page Zoom« war noch nicht erfunden, und damalige CSS-Layouts waren noch relativ instabil und gingen bei der kleinsten Änderung kaputt.
Dazu kam, dass (ausser dem IE/Mac) kein Browser in der Werkseinstellung über Knöpfe verfügte, mit denen Benutzer die Schriftgröße mit einem Klick verändern konnte. In den meisten Browsern waren die entsprechenden Optionen sehr gut vor dem Nutzer versteckt – so gut versteckt dass sich der Mythos festsetzen konnte, der IE könne keine in px bemaßten Schriften skalieren. Und damals wie heute galt, dass man es bei der Wahl der Schriftgröße nicht immer allen Recht machen kann: Für manche Nutzer ist die gewählte Schrift zu klein, für manche zu groß. Wie Sie sehen hatte das Skript also zur damaligen Zeit durchaus seine Berechtigung.
Allerdings bieten mittlerweile sämtliche aktuellen Browser die Möglichkeit, Seiten komplett zu skalieren, d.h. das gesamte Layout zoomt und bleibt intakt (und der kommende IE 8 korrigiert hierbei einige Fehler der Vorgängerversion und zieht so mit Firefox, Opera, Safari & Co. gleich). Mittlerweile sind moderne Browser wie der Firefox 3 sogar in der Lage, sich die vom Nutzer eingestellten Schriftgrade für jede Website einzeln zu merken. Zudem lässt sich in vielen Browsern eine Mindestschriftgröße angeben, die vom Ersteller der Seiten durch nichts überschreiben werden kann.
Solange Microsoft den Vista-Nachfolger nicht wieder mit dem IE 6 oder IE 7 ausliefert, wird die Zahl der Nutzer der problematischen Browser weiterhin stetig abnehmen; die Zahl der Nutzer mit moderneren Browsern nimmt jedoch täglich zu (relativ und absolut) – warum also Ressourcen für ein vermeintliches Problem aufwenden, wenn sich das Problem mittelfristig in Luft auflöst?
Ähnlich sieht dies übrigens auch das W3C, dass in den User Agent Accessibility Guidelines (UAAG 1.0 Checkpoint 4.1) die Verantwortung für solche Funktionalitäten eindeutig den Browser-Herstellern zuschiebt. Von den Erstellern einer Seite kann man lediglich verlangen, dass der Web-Inhalt weiterhin benutzbar bleibt, wenn der Nutzer eine entsprechende Funktion betätigt – mehr nicht.
Traditionelle Textskalierung ist damit also eindeutig ein Ding der Vergangenheit.
Ok, aber was ist mit den Nutzern?
Ganz einfach:
- Bei blinden Nutzern ist der gewählte Schriftgrad egal. Per gesetzlicher Definition verfügt ein blinder Nutzer höchstens über einen Sehrest, der nicht wirklich nutzbar ist. Die Frage nach der richtigen Größe für Schrift stellt sich hier also erst garnicht.
- Bei stark sehbehinderten Nutzern kann man in der Regel davon ausgehen, dass der Computer an die individuellen Bedürfnisse angepasst ist und Hilfsmittel benutzt werden, mit denen diese Diskussion ebenso irrelevant wird.
- Dann wäre da die große Grauzone von Nutzern, die zwar die ein oder andere Form der Behinderung haben, jedoch (noch) keine speziellen Hilfsmittel benutzen. Dies sind nicht nur leicht sehbehinderte Nutzer, sondern auch Menschen mit Lernbehinderungen oder anderen kognitiven Behinderungen, die unter Umständen von größerer Schrift profitieren würden. Aber auch bei dieser Gruppe stellt sich die Frage, ob solch ein Schriftskalierungs-Widget irgendwem wirklich nachhaltig hilft – und das nicht nur weil es letztendlich nur eine Funktionalität dupliziert, die der verwendete Browser bereits von sich aus anbietet. Diese Benutzer werden immer und immer wieder auf das gleiche Problem stoßen und über kurz oder lang mehr Zeit mit der Nachjustierung von Schrift verbringen als mit der Aufnahme von Informationen.
- Bleibt noch die den unerfahrenen Nutzern nachgesagte Angst vor dem Computer und davor »etwas kaputtzumachen«. Nutzer, die oftmals nicht wissen welchen Browser sie benutzen, geschweige denn was ein Browser ist. Ob ausgerechnet diese Nutzer auf (fremden) Webseiten auf einmal alle möglichen Knöpfe drücken, wenn sie schon Angst haben auf Ihrem (eigenen) Computer irgendwelche Knöpfe zu betätigen? Daran wird man wohl zweifeln dürfen. Sind dies die Nutzer, die einen 20"-Monitor auf 800×600 stellen weil dann die Schrift so schön groß ist? Und was ist wenn die Sehkraft weiter nachlässt? Stellen die Nutzer den Monitor dann auf 640×480? Wenn die Nutzer Probleme mit zu kleinen Schriften haben – wie sind sie dann auf die Seiten gekommen? Wie kommen sie mit dem Rest des Computers zurecht?
Sie sehen: solche Widgets lösen das Problem nur temporär, denn spätestens auf der nächsten Web-Seite steht der Benutzer wieder vor dem selben Problem. Die Widgets helfen also nicht bei der Lösung des Problems, sondern führen den Nutzer effektiv weiter von einer echten Problemlösung fort, indem sie an den Symptomen herumdoktern, statt die Ursachen zu beheben. Streng genommen erweist man seinen Benutzern sogar einen Bärendienst, da man eine Erwartungshaltung schürt, die nur von den wenigsten Websites erfüllt wird.
Wesentlich sinnvoller und von nachhaltigerem Effekt sind hier Ansätze wie bei der BBC-Seite »My Web My Way - Making text larger in Internet Explorer«, wo Nutzern erklärt wird wie sie das Problem dauerhaft beheben können. Wenn man also schon Ressourcen in diese Thematik steckt, dann doch wohl besser so, dass dem Nutzer wirklich geholfen wird.
Darüber hinaus stellt sich an diesem Punkt auch eine philosophische Frage: können wir einerseits verlangen, dass Webdesigner möglichst viel Kontrolle über das Erscheinungsbild aufgeben und dann wiederum das genau Gegenteil fordern? Standard-konforme Webdesigner machen nur Vorschläge - das C in CSS steht für die Kaskade (engl.: Cascading), und die endet beim Nutzer – dieser hat das letzte Wort über die Größe der Schrift.
Merke: wenn Browser oder Hilfsmittel in der Lage sind, ein Accessibility-Problem zu lösen, dann müssen Sie als Anbieter einer Seite dies nicht mehr machen. Und deswegen ist das fontsize-Skript weg.
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«
Zur Abwechslung nochmal was mit JavaScript:
Alles was der moderne Web-Entwickler so wissen muss:
Die JavaScript-Goodies der Woche:
Wer soll das eigentlich alles lesen? Nun gut, hier die Linkschleuder zum Wochenbeginn, frisch aus dem Stehsatz und der besseren Übersicht halber fein säuberlich sortiert. Wobei es gegen diese Sortierung auch durchaus nachvollziehbare Einwände gibt: »Behaviour, Content and Presentation: why the 3 layer model is wrong«.
Die Struktur-Ebene:
Die Präsentations-Ebene:
Die Verhaltens-Ebene:
In diversen Artikeln und Tutorials hatten wir immer wieder auf die großartige Web Accessibility Toolbar 2.0 für den Internet Explorer hingewiesen, die bisher nur als englischsprachige Version zu haben war. Benjamin Griessmann von Web For All und Martin Kliehm haben das jetzt geändert und das Werkzeug ins Deutsche übersetzt: Web Accessibility Toolbar DE - Version 2.0 (1,3 MB große .exe).
Ebenfalls empfehlenswert ist die Kombination aus Firefox Accessibility-Erweiterung zusammen mit dem Functional Web Accessibility Evaluator (FAE) der Universität von Illinois. Während die meisten Prüf-Tools nur den einmal vom Server geladenen HTML-Code überprüfen können, so kann man mit der o.g. Kombo auch dynamische Web-Applikationen testen. Mit der Accessibility-Extension kann man neuerdings auch den aktuellen Zustand des Dokumentes testen, wenn dieses von Skripten verändert wurde. Dazu wird von der Erweiterung ein jeweils aktueller Schnappschuss des Document Object Models an den FAE zur weiteren Analyse gesendet.
Passend zum heutigen Blaue-Mützchen-Tag ein paar Veranstaltungstipps:
Falls Sie zufällig in Hannover sind und noch nichts vorhaben: heute abend um 18:45h wird die einhundertste Folge des Webstandards-Podcast Technikwürze beim örtlichen Web Montag live aufgezeichnet.
In Wien gibt es heute eine Veranstaltung des Sozialministeriums und des Kanzleramts unter dem Titel »Online ohne Ausnahme«, bei der Unternehmen von den Vorteilen des Themas Barrierefreiheit im Internet überzeugt werden sollen. Experten informieren darüber, was barrierefreies Webdesign leisten kann und welche Unterstützungsmöglichkeiten bei der Umsetzung von barrierefreien Webangeboten bestehen. (via)
Wer beim Symposium »Best of Accessibility« anwesend war, konnte die Unterlagen schon herunterladen; nun gibt es die gesammelten Tagungsunterlagen als frei verfügbaren Download für jedermann: »Unterlagen zum BOA-Symposium 2007 verfügbar«, Download der Veranstaltungs-Unterlagen.
Eine Nachlese zur neulich in London gelaufenen @media Ajax 2007 findet sich unter anderem bei PPK und bei Christian Heilmann.
Charles L. Chen, bekannt durch die Firefox-Erweiterung Fire Vox und mittlerweile bei Google angestellt (wie alle Entwickler, die nicht bei Yahoo! arbeiten), hat eine JavaScript-Bibliothek namens AxsJAX vorgestellt, mit der sich die Accessibility-Features von WAI-ARIA in Web-basierten Applikationen nutzen lassen.
T.V. Raman, bekannt durch Emacspeak und mittlerweile auch bei Google angestellt (wie alle Entwickler, die nicht bei Yahoo! arbeiten), erklärt im Google Code Blog die Hintergründe: »Introducing AxsJAX -- Access-Enabling AJAX«.
ARIA steht für Accessible Rich Internet Applications und ist vom W3C als Interimslösung gedacht, um Hilfsmitteln den Zugang zu Interface-Elementen zu geben, die bisher im HTML-Standard nicht vorgesehen sind. Dazu gehören echte Menüstrukturen, erweiterte Bedienelemente wie z. B. Schieberegler, aber auch Methoden um Nutzer auf Änderungen in einer Seite Applikation hinzuweisen (sog. Live Regions).
Benötigt wird ein halbwegs moderner Web-Browser wie Firefox ab 1.5 (besser noch 2.0) und aktuelle Versionen von Hilfsmitteln (bei Screenreadern sind dies z. B. Window Eyes ab Version 5.5 und JAWS ab Version 7.1). Eine Übersicht, welche ARIA-Rollen (engl.: roles) bzw. Eigenschaften (engl.: properties) aktuell mit welcher Hilfsmittel-Browser-Kombination funktionieren finden Sie bei developer.mozilla.org: »Supported roles«.
Installiert wird AxsJAX entweder als Bookmarklet (einfach in die Lesezeichen-Leiste ziehen) oder über die Greasemonkey-Erweiterung in Firefox. Testen kann man auch ohne Screenreader mit der bereits erwähnten Fire Vox-Erweiterung.
Ob man allerdings einen Standard implementieren sollte, der noch in der Entwicklung ist (und sich daher noch grundlegend ändern kann), muss jeder für sich selbst entscheiden. Neben vielen anderen Baustellen kann sich die HTML-Arbeitsgruppe zurzeit ja noch nicht mal entschliessen, ob es aria:, aria- oder aria_ heissen soll. Die Chancen liegen also bei 66%, dass man sich als Entwickler für das Falsche entscheidet und dann hinterher alles wieder ändern muss.
Nachtrag: eine gute Erklärung gibt es jetzt auch bei Gez Lemon: »The AxsJAX Framework for ARIA«
Wo wir gerade beim Thema JavaScript sind:
Alejandro Vasquez hat einen Pfuschzettel für das Blueprint-CSS-Framework von Olav Bjørkøy gebaut: »Blueprint CSS v.0.6« (PDF, 37 kb).
Kein Framework, sondern eher ein leeres Grundgerüst ist HTML/CSS/JS-Kickstart 0.2 von Gerrit van Aaken. Enthalten sind Dinge, die sich bei jedem neuen Projekt immer wiederholen – man spart also eine Menge unnötige Tipperei.
Was das neue Choke Web Development Framework 1.0 von Jens Meiert ist bzw. kann konten wir noch nicht testen, denn der Download-Link ist zurzeit defekt. Wir melden uns, wenn die Störung behoben ist. Edith: der Download-Link funktioniert nun wieder, aber mehr wird nicht verraten …
Die Web Hypertext Application Technology Working Group (WHATWG) hat einen halbwegs stabilen Zwischenstand der zurzeit in der Entwicklung befindlichen HTML 5-Empfehlung veröffentlicht und bittet die interessierte Fachöffentlichkeit um Kommentare: »HTML 5 Call For Comments — 27 October 2007« (via).
Den aktuellen Stand der Diskussion um das alt-Attribut fasst ein durchaus lesenswerter Eintrag im W3C-Wiki zusammen: »HTML/IssueAltAttribute«.
Wer sich für die Weiterentwicklung von ECMAScript 4 interessiert (im Volksmund auch als JavaScript 2 bekannt), dem sei folgendes Papier empfohlen: »Proposed ECMAScript 4th Edition – Language Overview« (PDF, ca. 200 kb)
Wo wir gerade beim Thema sind: die NASA zeigt, daß Web-Standards durchaus auch in als bürokratisch verschrienen Organisationen ein Thema sein können und macht vor wie's geht:
Die allwöchentliche Linkschleuder in die Welt des modernen Scripting. Falls Sie schon immer wissen wollten, was dieses AJAX-Dings eigentlich ist – hier werden Sie geholfen: »How AJAX Works«.
Auch gut: Präsentation von Peter Paul Koch (vulgo: ppk) bei der Voices that Matter-Konferenz zum Thema »Advanced Design Techniques: JavaScript to the Rescue« (PDF, 400 kb).
