Von WAI-ARIA nach HTML5

Wer das im obigen verlinkten Artikel entwickelte Formular nicht mehr ganz parat hat, dem empfehle ich einen erneuten Blick darauf zu werfen. Die folgenden Änderungen habe ich vorgenommen, um das Formular von WAI-ARIA und HTML 4.01 auf HTML5 zu bringen:

1. Allen JavaScript-Code rausschmeißen. Die Formularvalidierung von HTML5 nimmt uns viel Arbeit ab. Da bauen wir lieber wieder was ein, wenn wir merken, dass das Formular zu wenige Features hat.
2. aria-required ändern in required. Sämtliche erforderlichen Formularfelder bekommen das WAI-ARIA-Attribut inklusive Wert gestrichen und einfach das HTML5-Formularelementattribut required verpasst.
3. Das Feld “name” bekommt ein pattern-Attribut mit einem regulären Ausdruck verpasst, der besagt, dass das Feld nur dann gültig ausgefüllt ist, wenn der eingegebene Name aus beliebigen Zeichen, einem Leerzeichen und weiteren beliebigen Zeichen besteht. Ein Name ist in unseren Breiten üblicherweise aus Vor- und Nachname zusammengesetzt, und das sollte das Formular wissen.
4. Das Feld “email” bekommt als type den Wert “email”, das Feld “website” den type “url” gesetzt. Dadurch weiß der Browser, dass er eine E-Mail- bzw. Webseiten-Adresse zu erwarten hat. Weiterhin hat dies den positiven Nebeneffekt, dass auf mobilen Geräten gleich die entsprechend verbesserten virtuellen Tastaturen eingeblendet werden. Mir ist bewusst, dass die meisten Browser zur Zeit noch nichts mit internationalen Domains anfangen können bzw. Felder mit solchem Inhalt noch nicht validieren. Wir decken der Einfachheit halber aber mal den großen Teil der allgemeinen Fälle ab.
5. Im Feld Name fügen wir noch ein Attribut x-moz-errormessage hinzu. Das Präfix besagt, dass dies kein Standard-Attribut für HTML5 ist. Mozilla-basierte Browser können aber eine bessere Fehlermeldung ausgeben. Achtung, die ist natürlich dann nicht lokalisiert, erscheint also auch in einem englischen Firefox auf deutsch!

Mit diesen Änderungen kann unser Formular jetzt folgendes:

1. Namen, E-mail-Adresse und Webseitenadresse automatisch validieren und den Status auf “ungültig” setzen, wenn ein Feld die Anforderungen nicht erfüllt.
2. Der Firefox schickt bei mindestens einem ungültig ausgefüllten Formular dieses beim Klick auf den Button nicht ab, sondern gibt eine Fehlermeldung aus und setzt den Fokus auf das Eingabeelement, in dem noch ein Problem besteht. Bei Tests im Safari in Mac OS X Lion zeigte sich, dass dieser das Formular dennoch abschickt, obwohl ungültige Eingaben vorhanden sind. Hier weichen die Implementierungen also voneinander ab

Und zurück zu WAI-ARIA

Und was kann unser Formular noch nicht wieder? Richtig: Die Ausgabe einer Fehlermeldung bei Verlassen eines Eingabefeldes. Dies unterstützen Browser bisher nicht standardmäßig, eine Validierung bei Fokusverlust, die sofort per Fehlermeldung bescheid sagt, wenn etwas nicht in Ordnung ist. Also müssen wir das JavaScript aus dem ursprünglichen Formular wieder einbauen und wie folgt abändern:

1. Den Namen der function “checkEntryValidity” in “testIfEntryIsValid” ändern, weil der ursprüngliche Name im HTML5-Kontext mit einem reservierten Bezeichner kollidiert.

Die Parameterliste verschlanken. Die Funktion braucht nur noch die ID des zu überprüfenden Elements, weil alles andere von HTML5 erledigt bzw. bereitgestellt wird.

Die Funktion so abändern, dass:
1. Keine aria-invalid-Attribute mehr gesetzt werden.
2. Keine zeichenvergleiche mehr angestellt werden, sondern lediglich das Ergebnis des Funktionsaufrufs checkValidity() ausgewertet wird. checkValidity() gibt true zurück, wenn das Feld einen gültigen Eintrag enthält, sonst false.
3. Den bisherigen Parameter aMsg ersetzen durch einen Aufruf der Eigenschaft validationMessage des jeweiligen Elements. Diese enthält die Fehlermeldung, die Firefox auch beim Absenden des Formulars generiert und die beim Drüberfahren mit der Maus als Tooltip angezeigt wird. Enthält das Element ein title-Attribut, wird dessen Wert an diese Fehlermeldung angehängt. Ist x-moz-errormessage angegeben, enthält der erste teil von validationMessage diesen Text.
1. Den Feldern “name” und “email” wieder onBlur-Handler geben, die die Funktion testIfIsEntryValid aufruft und die ID des zu prüfenden Feldes übergibt, damit bei Fokusverlust des Feldes eine Prüfung erfolgt und ggf. ein Alert generiert wird.

Mit diesen Änderungen ist unser Formular nun wieder voll funktionsfähig, besitzt jedoch verbesserte Validierungseigenschaften als vorher. Auf mobilen Geräten werden entsprechende Tastaturen eingeblendet, wenn man die E-Mail- und Webseiten-Adressen ausfüllt.

Zusammenfassung

HTML5 bietet uns also viele Funktionen frei haus, die wir früher mit eigenem JavaScript nachbauen mussten. Der Code wird schlanker. Die Lücke, die HTML5 nicht schließt, ist die Validierung bei Fokusverlust und die Ausgabe der Fehlermeldung. Diese müssen wir weiterhin durch WAI-ARIA realisieren. Wir gehen also zu einem guten Stück von WAI-ARIA-Attributen weg, und das ist auch gut so! Dort, wo es sinnvoll ist und es eine Ergänzung darstellt, nutzen wir es aber weiterhin, um unser einfaches Formular noch benutzerfreundlicher zu gestalten. Wo man kann, sollte man WAI-ARIA also durch HTML5 ersetzen, wenn man moderne Webseiten und -applikationen entwickelt. Dort, wo es Sinn macht oder HTML5 noch Lücken lässt, sollte man WAI-ARIA aber nach wie vor einsetzen!

Sämtliche drei Beispiele sind von dieser Seite verlinkt. Viel Spaß beim Spielen und Nachbauen!

Ich freue mich selbstverständlich über Feedback! Das JS hier ist jedoch absichtlich sehr einfach gehalten, weil es nur das Konzept verdeutlichen soll und keine fertige Lösung darstellt.

Neue Stimmen in vielen Sprachen

Apple bietet für Lion Stimmen in niedriger und hoher Qualität in über 40 Sprachen und Dialekten an. Diese sind in kompakter Version für viele Sprachen bereits vorinstalliert. So kommt die deutsche Variante mit der Stimme Yannick daher, die bereits aus aktuellen iOS-Veröffentlichungen vom iPhone/iPod Touch und iPad bekannt ist. Eine höherwertige Version dieser Stimme sowie die Stimmen Steffi und Anna können nachgeladen werden. All diese Stimmen, also auch die ausländischen, werden von Apple kostenlos zur Verfügung gestellt. Man wählt sie einfach im VoiceOver-Dienstprogramm unter Sprachausgabe, Standard-Stimme, Menüpunkt “Anpassen”… aus und lädt sie dann über die automatisch sich öffnende Softwareaktualisierung herunter.

Aber auch für die Freunde der bereits für Leopard und Snow Leopard verfügbaren Stimmen der á Capella Group, die über AssistiveWare heruntergeladen und käuflich erworben werden können, gibt es Entwarnung: Diese funktionieren weiterhin, bei mir nach einem Upgrade von Snow Leopard auf Lion sogar ohne neuinstallation oder erneute Aktivierung. Wem also die Nuance-Stimmen nicht gefallen, der kann weiterhin Infovox iVox nutzen. AssistiveWare sagen selbst, dass sie bis Ende des Monats ihre Produkte auf mit Lion kompatible Versionen aktualisieren wollen, meine Tests mit den Stimmen haben allerdings gezeigt, dass die reinen Stimmenpakete anscheinend weiterhin problemlos funktionieren.

Die Tatsache, dass Stimmen u. a. für Deutsch vorinstalliert sind, bedeutet, dass man jetzt in einem Apple oder Gravis Store nicht nur iPhones und iPads in seiner Muttersprache ausprobieren kann, sondern auch alle Varianten des Macs. Bei einer frischen Installation von Lion auf deutsch wird automatisch mit Yannick Compact gesprochen, so dass VoiceOver ohne Installation einer externen Sprachausgabe sofort in deutsch zu sprechen beginnt.

Einziger Wermutstropfen: Während der Installation wird diese Stimme noch nicht verwendet, hier quatscht immer noch die Decktalk-Variante “Fred” in allen Sprachen. Dies gilt aber nur für den Installationsvorgang von der Recovery-Partition, nicht für das Setup nach der allerersten Installation. Der Assistent, bei dem man u. a. nach seiner Apple-ID gefragt wird, wird bereits mit einer deutschen Stimme begleitet.

Neue Braille-Funktionen

VoiceOver liefert jetzt Brailletabellen in verschiedenen Sprachen mit, unter anderem deutsch. Auch die Kurzschriftübersetzung ist für deutsch und weitere unterstützte Sprachen verfügbar. Leider gibt es zur Zeit keine Möglichkeit, bei der Kurzschriftübersetzung die Anzeige von Großbuchstaben abzuschalten, so dass die Kurzschriftdarstellung nicht ganz der eines Standard-Buches entspricht, in der es ja keine Anzeige von Großbuchstaben gibt.

Durch Brailleausführlichkeit kann man jetzt angeben, was in verschiedenen Situationen angezeigt werden soll und somit gerade auf kleineren Displays den Platz effizienter nutzen.

Aktivitäten

VoiceOver-Aktivitäten sind Sätze von Einstellungen, auf Wunsch alle, die das VoiceOver-Dienstprogramm zur Verfügung stellt, die für bestimmte Situationen oder bestimmte Anwendungen angepasst werden können. So kann man z. B. eine Aktivität für eine Anwendung einstellen, oder man öffnet mit VO+X ein Menü aller verfügbaren Aktivitäten, weil man im Web zum Einkaufen vielleicht eine schnellere Sprechgeschwindigkeit und andere Stimme verwendet als zum Lesen von Artikeln, Blogs usw. Eine Aktivität kann hierbei durchaus auch auf mehrere Anwendungen automatisch angewendet werden.

Ziehen und Ablegen (Drag and Drop)

VoiceOver unterstützt jetzt das automatisierte Drag and Drop. Dies war bisher durch eine Kombination mehrerer Befehle bereits möglich, wurde jetzt jedoch erheblich vereinfacht.

1. Man wählt mit den VoiceOver-navigationsbefehlen oder der Tastatur das zu ziehende Objekt an und drückt VO+Komma.
2. Man navigiert mit dem VoiceOver-Cursor an die gewünschte Zielstelle am Bildschirm und drückt eine der folgenden Tasten:
   1. VO+Punkt zum Fallenlassen auf dem Objekt, auf dem sich der VoiceOver-Cursor gerade befindet. Das Resultat hängt von der Anwendung ab.
   2. VO+< (Kleiner als Das Objekt auf dem Objekt, das dem Objekt, auf dem der VoiceOver-Cursor steht, voransteht. Hierbei ist die Navigationsreihenfolge gemeint, nicht die visuelle Anordnung auf dem Bildschirm.
   3. VO+> (Größer als zum Fallenlassen auf dem Objekt, das dem Objekt unterm VoiceOver-Cursor navigationsmäßig nachfolgt.

Hierbei unterliegt der Vorgang denselben Beschränkungen wie von Windows-Screen-Readern her gewohnt: Sind nicht mehr beide Objekte visuell am Bildschirm sichtbar, weil eines in der Zwischenzeit verdeckt wurde oder weggescrollt ist, schlägt der Vorgang fehl. Auch sind nicht alle Objekte von VoiceOver zum Ziehen freigegeben: Auf den meisten Webelementen erlaubt es schon das Markieren als zu ziehendes Objekt nicht. So kann man z.B. nicht wie der Sehende in Google Plus einen Kontakt auf einen Kreis ziehen, um ihn diesem Kreis hinzuzufügen.

Schnelle Navigation mit einzelnen Buchstaben auf Webseiten

Ähnlich dem Modell von Windows-Screen-Readern kann man in VoiceOver jetzt optional einstellen, dass man durch das Tippen einzelner Buchstaben ohne Umschalttasten wie Befehlstaste zu bestimmten Elementen navigieren kann. Dies sollte Umsteigern den Umstieg noch weiter erleichtern.

Aufgeräumteres VoiceOver-Dienstprogramm

Die Benutzeroberfläche des Dienstprogrammes für VoiceOver wurde an einigen Stellen überarbeitet, um neue Funktionen elegant zu integrieren und einige Tabs übersichtlicher zu gestalten. Weiterhin gibt es jetzt eine Suchfunktion, mit der eine bestimmte Funktion leicht aufgefunden werden kann, wenn man vergessen hat, wo genau sie sich verbirgt.

Unterstützung von Anwendungen

Kalender

Die Navigation und Interaktion mit Kalenderobjekten wurde stark verbessert, auch die Überarbeitung des Kalenders selbst bringt für VoiceOver eine weitere Verbesserung der Zugänglichkeit des ohnehin schon sehr zugänglichen Kalenders.

Mail

Das neue, für meine Begriffe sehr gelungene, mail wird von VoiceOver unterstützt. Es ist also nicht nötig, außer man möchte es aus Gewohnheit tun, auf die klassische Darstellung, die man aus Snow Leopard gewohnt ist, umzuschalten. Die neue, konversationsorientierte, darstellung ist mit VoiceOver genauso nutzbar. Nach wenigen Minuten des Eingewöhnens möchte ich diese Darstellung, die auch schon vom iPad und iPhone bekannt ist, nicht mehr missen. Die Vorschau der einzelnen Mails wird automatisch vorgelesen und gibt so einen schnellen Überblick über den wichtigsten Inhalt der Mail.

Safari

Es werden jetzt Navigationspunkte (WAI-ARIA Landmarks) erkannt. Die deutsche Übersetzung ist etwas hakelig geworden, so sagt VoiceOver beim Erreichen eines Orientierungspunkts z. B. "Banner eingeben". Warum man nicht einfach die gut funktionierende Übersetzung von iOS genommen hat, erschließt sich mir nicht.

VoiceOver sagt jetzt erforderliche und ungültige Einträge an, wenn diese mit HTML5 oder WAI-ARIA ausgezeichnet sind. Auch werden WAI-ARIA Dialoge und Live Regions unterstützt.

Die Interaktion mit formatierbarem Text, z. B. beim Verfassen einer Mail in GoogleMail, wurde verbessert.

VoiceOver kommt spürbar besser und schneller mit sich dynamisch aktualisierenden Seiten wie Facebook zurecht.

LaunchPad und Mission Control

Auch die neuen Funktionen LaunchPad und Mission Control sind mit VoiceOver bedienbar. Der wirkliche Nutzen erschließt sich mir aber nur, wenn ich die Trackpad-Steuerung aktiviert habe und somit die Objekte tatsächlich berühre. Die Navigation im Gitter mit der Tastatur ist nicht effizienter als das Wählen einer Anwendung aus dem Dock oder dem Programme-Ordner im Finder, sondern eher langsamer, weil man hier keine Möglichkeit der Eingabe von Buchstaben hat, um ein Programm gezielt anzuspringen.

Die neue Rechtschreibkorrektur und Autovervollständigung

Die neue Autovervollständigung wird von VoiceOver unterstützt. Ertönt der auch vom iPhone bekannte Blubberton, kann man mit Pfeil runter die Rechtschreibvorschläge ansteuern, mit rechts und links die einzelnen Vorschläge auswählen und mit Eingabe von z. B. Leerzeichen oder einem Satzzeichen übernehmen, oder man drückt Pfeil rauf, um keinen der Vorschläge zu akzeptieren.

Kleine Detailverbesserungen

Es sind aber auch die Detailverbesserungen, die das Arbeiten unter Lion mit VoiceOver zu einem schönen Erlebnis machen. So werden bei Tabellen, denen von einem programm Zeilen hinzugefügt werden, die gewählten Zeilen nicht automatisch erneut vorgelesen, nur weil neue Inhalte dazugekommen sind. Gerade bei einem Programm wie dem Twitter-Client Syrinx ist dies eine angenehme Reduzierung der Geschwätzigkeit.

Das Vorlesen im Web geht meines Erachtens nach etwas flüssiger vonstatten als unter Snow Leopard. In manchen Situationen (ich habe noch nicht genau herausgefunden, welche) kann man sogar während des Vorlesens eines Absatzes VO+A drücken, und das Vorlesen wird nicht unterbrochen, sondern das Objekt wird zu Ende gelesen und dann mit dem nächsten weitergemacht.

Fazit

Von vielen wird bemängelt, dass Lion kein großer Fortschritt sei. In Bezug auf die Zugänglichkeit dynamischer und mit neuen Technologien wie HTML5 und WAI-ARIA zugänglich gemachter Webinhalte ist VoiceOver in Lion hingegen doch ein sehr großer Fortschritt, da die Menge an unterstützten Widgets dramatisch zugenommen hat.

Auch die neuen Oberflächen von Mail und Kalender sind, wenn man viel mit diesen Programmen arbeitet, das Upgrade definitiv wert.

Etwas weniger sinnvoll ist LaunchPad für VoiceOver-Benutzer, die die Trackpad-Steuerung nicht benutzen.

Die eingebauten und kostenlos herunterladbaren Stimmen sind ein echter Zugewinn! Man ist nicht mehr zwangsweise auf den Erwerb von Stimmen eines Drittanbieters angewiesen, sondern bekommt schön klingende und dennoch sehr reaktionsschnelle Stimmen frei haus mitgeliefert, man muss lediglich ein bisschen Zeit aufwenden, sie per Softwareaktualisierung herunterzuladen.

Für €23,99 bekommt man hier definitiv eine ganze Menge Neues fürs Geld geboten, und ich kann das Upgrade nur wärmstens empfehlen!

Unterstützung für die Spracheingabefunktion von Windows Vista und Windows 7

Windows Vista und Windows 7 haben eine eingebaute Spracheingabefunktion, mit der motorisch eingeschränkte Benutzer oder solche mit einer Lese-Rechtschreib-Schwäche Texte in verschiedene Programme diktieren können. Ab der Version 3.6 gehört auch Firefox zu diesen Programmen. Dies wird erreicht, indem das Microsoft Text Services Framework (TSF) unterstützt wird.

Da es sich hierbei um sehr neue Technologie handelt und es eventuell ungewollte Nebeneffekte geben kann, die erst in den nächsten Updates beseitigt werden können, ist die Unterstützung für TSF standardmäßig ausgeschaltet. Durch folgende Schritte kann sie eingeschaltet werden:

1. Gib in die Adresszeile von Firefox die Adresse about:config ein.
2. Bestätige den Warnhinweis mit einem Klick auf “Ich werde vorsichtig sein, versprochen!”.
3. Gib in das Textfeld für die Filterung die Buchstaben tsf ein.
4. Wähle in der Liste die Einstellung intl.enable_tsf_support.
5. Führe einen Rechtsklick auf diesem Eintrag aus und wähle “umschalten” aus dem Popup-Menü.
6. Starte Firefox neu.

Von nun an kann in Eingabefelder wie z. B. das Eingabefeld für Blogkommentare diktiert werden.

Dies erweitert die von Firefox und der Gecko-Plattform nativ unterstützten Technologien um eine weitere und schließt somit eine weitere Gruppe von Benutzern mit einer Behinderung ein.

Die neue Taskleistenvorschau in Windows 7 ist zugänglich

In Windows 7 kann die Taskleiste bei mehreren geöffneten Fenstern oder Tabs eine Vorschau der geöffneten Tabs anzeigen, und man kann direkt in dieser Vorschau wählen, mit welchem Fenster oder Tab das Programm in den Vordergrund geholt werden soll. Diese Funktion wird ab Version 3.6 auch von Firefox unterstützt und ist mit Screen Readern wie dem NVDA auch zugänglich. Bietet Firefox mehrere Tabs zur Vorschau an, sagt NVDA beim navigieren in der Taskleiste für das Symbol des Firefox “Untermenü” an. Jetzt kann mit den Pfeiltasten rauf und runter der gewünschte Tab ausgewählt und mit Eingabe oder Leertaste Firefox mit diesem Tab im Vordergrund der Fokus übergeben werden.

Bessere Behandlung des Eingabefokus

Dies betrifft Maus- und Tastaturbenutzer gleichermaßen, wird hier aber extra erwähnt, weil die Verbesserungen auch Benutzer von Bildschirmleseprogrammen betreffen. So gibt es jetzt ein verbessertes Navigieren auf Seiten, wo das Attribut tabindex für einige Elemente definiert ist und für andere nicht. Weiterhin wird beim Speichern von ausführbaren Dateien das Dialogfeld, das erscheint, jetzt automatisch angesagt.

Unterstützung für die Programmierschnittstelle IAccessibleTable2

Diese Erweiterung des Standards IAccessible2 ermöglicht es assistiven Technologien, exaktere Informationen über Tabellenstrukturen zu erhalten und dem Anwender mitzuteilen. Hierbei ist es unerheblich, ob es sich um eine Datentabelle im Web, eine mehrspaltige Strukturansicht wie die Lesezeichenverwaltung, ein ARIA tree grid oder ähnliches handelt. Die Informationen werden von Gecko gesammelt und über diese neue Schnittstelle transparent und konsistent zur Verfügung gestellt. Hersteller von assistiven Technologien können Firefox 3.6 somit zur Implementierung dieser neuen nSchnittstelle verwenden und ihren Anwender somit eine verbesserte Wiedergabe verschiedendster Tabellenstrukturen bieten.

Verbesserte Regeln zum Errechnen des accessible name

Der Name eines accessible Objekts, der häufig dem Bildschirmtext entspricht, ist der Hauptbestandteil dessen, was Anwendern von Bildschirmleseprogrammen beim Navigieren mit Tab oder im virtuellen Puffer angezeigt wird. Im Einklang mit dem User Agent Implementor’s Guide des WAI-ARIA-Standards haben wir das Errechnen dieses Namens verbessert, so dass der Programmcode jetzt besser wartbar, vorhersagbarer und somit robuster auch für zukünftige Implementierungen neuer Elemente z. B. aus dem HTML5-Standard geworden ist.

Unterstützung für sich ändernde Objektattribute

Für eine bessere Unterstützung von drag and drop in WAI-ARIA, aber auch im Hinblick auf HTML5, haben wir das Ereignis IAccessible2 Object Attribute Changed implementiert. Dieses wird immer dann ausgelöst, wenn der Wert eines Attributes eines HTML-Elements, der durch ein Objektattribut des entsprechenden accessibles veröffentlicht wurde, sich ändert. Diese Änderung passiert üblicherweise durch JavaScript. Bildschirmleseprogramme können hierauf reagieren und ihren Anwendern diese Änderung mitteilen und/oder ihren virtuellen Puffer aktualisieren.

…und wieder jede Menge Bugfixes

Und natürlich haben wir auch wieder an der Stabilität und Zuverlässigkeit des Firefox gearbeitet! Wenn bestehende Funktionen nicht so funktionierten wie gewünscht und dies uns von Anwendern und Herstellern assistiver Technologien gemeldet wurde, haben wir uns um schnelle Verbesserungen gekümmert. Weiterhin sind wir auch am Ball geblieben, was späte Änderungen in der Spezifizierung von WAI-ARIA anging und haben unsere Implementierungen entsprechend angepasst.

Das gesamte Accessibility Team bei Mozilla hofft, dass euch der Firefox 3.6 genauso gefällt und soviel Freude bereitet wie es uns Spaß gemacht hat, an ihm zu arbeiten und ihn zu testen!

Der BPSE findet jeden 1. Donnerstag und 3. Montag im Monat im Unperfekthaus statt. Das Unperfekthaus ist ein spannender Ort: Es ist ein Gebäude, das früher mal mindestens zwei waren, und eines davon war mal ein Kloster. An einigen Stellen fühlt man auch richtig altes Mauergestein. Es gibt viele Räume, die Galerien, Tanzveranstaltungen oder andere Aktivitäten beherbergen. Überall stehen Skulpturen von im Unperfekthaus aktiven Künstlern, und man darf sie, wenn man vorsichtig ist, auch anfassen. Überall sind Treppen, und das Haus ist so verwinkelt, dass das eine echte Herausforderung für jedes O&M-Training wäre, da mal durchzunavigieren. Es gibt freies WLAN und ein Buffet, das je nach Tageszeit das Angebot wechselt. Vor dem offiziellen Teil des BPSE gab es ein Grillbuffet mit leckeren Beilagen, gutem Kaffee und kalten Getränken.

Im offiziellen Teil auf der “Internetcouch” sprach Maxx Hilberer zunächst über CSS3 Transforms. Hierbei handelt es sich um visuelle Effekte, mit denen Text gedreht, verschoben und verzerrt werden kann, ohne dass er als Grafik eingebunden werden muss. Wie ein Teilnehmer feststellte und ich inzwischen per Test bestätigen konnte, liegt hier auch ein großer Vorteil für die Barrierefreiheit: Der Text steht im HTML-Code und kann aussehen wie er will, Screen Reader werden ihn trotzdem richtig lesen können. Fehler wie fehlende Alt-Texte für Bilder, die man für solche Effekte früher einbinden musste, sind so vermeidbar. Maxx zeigte sogar einen Workaround für den IE, der von Peter Kröner hier beschrieben wird, aber nicht für den IE 8 funktioniert.

Als nächstes Sprach Maik Wagner über die sinnvolle und sinnfreie Anwendung von Sprungmarken. Wir schauten uns einige Beispiele in der Praxis an und zogen auch die WebAIM-Umfrage hierzu heran.

Wir leiteten dann über zu meinem kurzen Überblick über WAI-ARIA, und ich begann sinnvollerweise mit den ARIA Landmarks. In der Diskussion stellten wir sie auch in Bezug zu HTML5-Elementen, die hiervon inspiriert worden sind. Ich sprach dann auch über Roles, States und Live Regions. Wir schauten uns Accessible Twitter an, welches ja sowohl Landmarks als auch einige weitere Roles und Attribute wie aria-required verwendet.

Der Abend ging zu Ende mit einem letzten gemütlichen Klönschnack vor der Tür des Unperfekthauses. Wir haben es natürlich geschafft, bis zur Schließung um 23 Uhr zu bleiben und verstreuten uns danach erst allmählich in alle Himmelsrichtungen.

Vielen Dank an alle, die zu so einem netten Abend beigetragen haben! Hat mir Spaß gemacht, und ich komme gern mal wieder, wenn sich die Gelegenheit bietet und es terminlich passt.

Wäre es da nicht schön, wenn man ein Formular so umgestalten könnte, dass Fehler sofort erkannt würden und man darauf hingewiesen werden würde? Mit dem Einsatz von ARIA ist dies kein Problem!

Das Formular

Als Beispiel soll folgendes einfaches Kontaktformular herhalten:

<html>
<head>
<title>Kontaktformular</title>
</head>
<body>
<form method="post" action="post.php">
<fieldset><legend>Bitte gib deine Kontaktdaten an</legend>
<label for="name">Dein Name (erforderlich):</label>
<input name="name" id="name" aria-required="true"/><br />
<label for="email">E-Mail-Adresse (erforderlich):</label>
<input name="email" id="email" aria-required="true"/><br />
<label for="website">Website (optional):</label>
<input name="website" id="website"/>
</fieldset>
<label for="message">Bitte gib deine Nachricht ein (erforderlich):</label><br />
<textarea name="message" id="message" rows="5" cols="80" aria-required="true"></textarea><br />
<input type="submit" name="submit" value="Nachricht abschicken"/>
<input type="reset" name="reset" value="Formular zurücksetzen"/>
</form>
</body>
</html>

Nichts Großes, aber wir wollen damit ja auch keinen Schönheitswettbewerb gewinnen. Einzige Besonderheit ist das Attribut aria-required, welches ich bereits früher ausführlich behandelt habe.

Der Hinweis, dass etwas fehlerhaft eingegeben wurde

Ziel ist es, sowohl beim Feld “Name” als auch beim Feld “E-Mail-Adresse” einen Hinweis zu geben, wenn eine fehlerhafte Eingabe entdeckt wurde. Hierzu testen wir, ob im namen ein Leerzeichen vorkommt (es sind also mindestens Vor- und Nachname erforderlich), und ob in der E-Mail-Adresse das “@”-Zeichen vorkommt. Ist die Eingabe fehlerhaft, so wird zum einen das Feld selbst mit dem Attribut aria-invalid versehen, dessen Wert auf “true” gesetzt wird. Dies bewirkt, dass aktuelle Screen Reader das Feld als eines mit einer ungültigen Eingabe versehenen identifizieren können. Zum anderen wird unterhalb des Formulars eine kleine Box eingeblendet, die einen entsprechenden Hinweis auf den Fehler enthält. Diese Box, die mit einem einfachen div-Element gestaltet wird, bekommt durch das role-Attribut die Rolle eines sogenannten Alerts, eines Hinweises. Dies verhält sich dann entsprechend der aus Firefox 3 bekannten Hinweismeldung “Soll Firefox dieses Passwort speichern?”. Der Fokus wird nicht zu diesem Hinweistext verschoben, es kommt auch kein Dialogfeld hoch, das man erst wegdrücken muss, sondern der Hinweis wird im Laufenden Vorgang des Ausfüllens des Formulars gegeben und man kann sofort weiterarbeiten.

Das ganze passiert in dem Moment, wo der Anwender den Fokus von dem entsprechenden Eingabefeld weg bewegt, es also den Fokus verliert. JavaScript-versierte ahnen es: Dies geschieht durch das onblur-Ereignis, welches immer dann ausgelöst wird, wenn ein Element den Tastaturfokus verliert. Im Kopf der HTML-Datei definieren wir uns jetzt also drei helfende Funktionen:

1. removeOldAlert: Diese Funktion entfernt lediglich den vom letzten Fehler aufgegangenen Hinweis. Dieser wird entfernt, wenn entweder ein neuer Hinweis erscheinen soll oder der Fehler erfolgreich korrigiert wurde.
2. addAlert: Diese Funktion fügt einen Hinweis in das Dokument ein. Sie entfernt dazu zunächst alte eventuell noch vorhandene Hinweise, erzeugt ein div-Element und gibt diesem zwei Attribute: Eine ID, mit der das Element später wiedergefunden werden kann, und das bereits erwähnte Attribut role. Schlussendlich wird der übergebene Text als Inhalt des divs eingefügt und das gesamte Element dem Dokument hinzugefügt. Alles weitere, sprich das Auslösen des Alert-Ereignisses wird automatisch durch Firefox veranlasst, wir müssen uns hier um nichts weiter kümmern.
3. checkValidity: Diese Funktion ist das eigentliche Herzstück. Sie sucht zunächst innerhalb des durch den Parameter aID angegebenen Elements nach dem als aSearchTerm übergebenen Suchbegriffs. Ist diese Suche nicht erfolgreich, wurde also eine ungültige Eingabe getätigt, werden die oben beschriebenen Schritte zur Kenntlichmachung der Ungültigkeit eingeleitet. Ist die Suche hingegen erfolgreich, der Eintrag also nicht ungültig, werden eventuelle Hinweise entfernt und das Attribut aria-invalid auf “false” gesetzt.

Der zugehörige JavaScript-Code sieht wie folgt aus:

<script type="application/javascript">
  function removeOldAlert()
  {
    var oldAlert = document.getElementById("alert");
    if (oldAlert)
      document.body.removeChild(oldAlert);
  }

  function addAlert(aMsg)
  {
    removeOldAlert();
    var newAlert = document.createElement("div");
    newAlert.setAttribute("role", "alert");
    newAlert.setAttribute("id", "alert");
    var msg = document.createTextNode(aMsg);
    newAlert.appendChild(msg);
    document.body.appendChild(newAlert);
  }

  function checkValidity(aID, aSearchTerm, aMsg)
  {
    var elem = document.getElementById(aID);
    var invalid = (elem.value.indexOf(aSearchTerm) < 0);
    if (invalid) {
      elem.setAttribute("aria-invalid", "true");
      addAlert(aMsg);
    } else {
      elem.setAttribute("aria-invalid", "false");
      removeOldAlert();
    }
  }
</script>

Einhängen des Codes in die Ereignisbehandlung

Dies ist einfach: Es wird jetzt nur noch ein Aufruf von checkValidity als Wert des onblur-Attributes für die “name” und “email”-Input-Elemente eingefügt. Die geänderten Zeilen sehen so aus:

<input name="name" id="name" aria-required="true" onblur="checkValidity('name', ' ', 'Ungültigen Namen eingegeben!');"/><br />

<input name="email" id="email" aria-required="true" onblur="checkValidity('email', '@', 'Ungültige E-Mail-Adresse');"/><br />

Testen des Beispiels

Das vollständige Beispiel habe ich zum Ausprobieren hochgeladen. Das Formular tut nichts, es ist lediglich als Anschauungsobjekt gedacht. Probiert mal folgendes:

1. Gebt ins Feld “Name” nur euren Vornamen ein und drückt Tab.
2. Gebt in das Feld “E-Mail-Adresse” eine verklausulierte E-Mail-Adresse ein, die kein “@”-Zeichen enthält, und drückt Tab.

Einige Anmerkungen

Warum hast du keine Ereignisbehandlungsroutine für das Feld “message” erstellt?

Dies überlasse ich dem geneigten Leser, sozusagen als “Hausaufgabe” zum selbst ausprobieren.

Warum setzt du das Wort “erforderlich” in die Beschriftung der Textfelder, wenn diese doch per aria-required als erforderlich gekennzeichnet sind?

Wir müssen davon ausgehen, dass auch Anwender mit Browsern und/oder Screen Readern unsere Seiten besuchen, die ARIA nicht verarbeiten können bzw. das Mitteilen eines erforderlichen Feldes nicht unterstützen. IE 7 und JAWS 8.0 sind solche Beispiele. Solange also noch eine große Anzahl Browser und/oder Screen Reader in Umlauf sind, die diese neuen Techniken noch nicht unterstützen, ist auch weiterhin eine eindeutige verbale Kennzeichnung erforderlicher Felder auf Webseiten nötig. Screen Reader, die dies jedoch schon unterstützen, können erforderliche Felder auch anders als durch Sprache, z. B. durch das Abspielen eines bestimmten Klanges, kennzeichnen, so dass die Verwendung dieses Attributes Anwendern aktueller Screen Reader auf jeden Fall weitere Vorteile ermöglicht.

Warum setzt du den Fokus nicht automatisch auf das ungültige Feld zurück?

Weil dies von mindestens der Windows-API-Dokumentation und möglicherweise anderen nicht erlaubt ist. Man darf bei einem Fokuswechsel nicht auf das Feld zurückkehren, von dem man gerade weg navigiert. Außerdem ist es nicht besonders benutzerfreundlich, den Fokus ohne Eingriff des Benutzers zuviel herumspringen zu lassen.

Weiterhin ist natürlich anzumerken, dass das obige Beispiel keinen Anspruch auf Vollständigkeit erhebt. Neben den hier gezeigten Methoden zur Kenntlichmachung von ungültigen Feldern kann man natürlich ein ungültiges Feld auch mit visuellen Stilen kenntlich machen, indem man es z. B. rot einfärbt. Der Experimentierfreudigkeit sind hier kaum Grenzen gesetzt.

Auch ist es natürlich möglich, wenn serverseitig schon Mechanismen zur Kontrolle der Eingaben vorhanden sind, diese per AJAX durchführen zu lassen anstatt innerhalb der Seiten diesen Code zu duplizieren. Der Verwendung von ARIA tut dies keinen Abbruch.

Fazit

Dieses Beispiel zeigt meiner Meinung nach eindrucksvoll, wie das immer als so wenig barrierefrei hingestellte und verschriene JavaScript genutzt werden kann, um das Ausfüllen eines Formulars wesentlich barrierefreier zu gestalten als dies heute gängige Praxis ist.

Ich würde mir wünschen, dass diese Art der frühzeitigen Warnung vor fehlerhaften Eingaben möglichst bald in großer Anzahl verwendet wird. Es ist meiner Meinung nach wesentlich benutzerfreundlicher, sofort auf Eingabefehler hinzuweisen, so dass diese dann noch während des Ausfüllens des Formulars korrigiert werden können. Ich persönlich finde es immer sehr mühselig, nach eventuell fehlerhaft gemachten Eingaben auf der nächsten Seite die Formularfelder alle nochmals durchgehen zu müssen, um das fehlerhafte zu finden, und um zu kontrollieren, dass auch ja keine der gültigen Angaben verlorengegangen sind.

Frühere Einfache ARIA Tipps

• aria-required

WordPress bringt neben den allseits bekannt gemachten Features wie der Versionierung von Artikeln auch einige Verbesserungen in Puncto Barrierefreiheit mit sich. So wurden durchgehend Labels zu den verschiedenen Eingabefeldern, Ausklapplisten und anderen Elementen hinzugefügt, so dass jetzt aucScreen Reader, die keine eigene Label-Erkennung durchführen, mit WordPress wesentlich besser klarkommen sollten. Sollte jedoch irgendwo ein Label durchgerutscht sein und ihr dies bemerken, am besten einfach hier melden! Ich gebe dies dann an die WordPress-Entwickler weiter.

Weiterhin werden WordPress-Blogs jetzt standardmäßig immer mit einer Dokumentsprache (lang-Attribut) ausgestattet. Englische Blogs, die mit WordPress 2.6 laufen, werden so auch standardmäßig von Screen Readern, die die automatische Spracherkennung unterstützen, mit einer englischen Sprachausgabenstimme vorgelesen.

Eine weitere Neuerung ist, dass das WordPress-Team sich entschieden hat, einige erste Markups des Standardvorschlages Accessible Rich Internet Applications (WAI-ARIA) zu implementieren. Die Folge ist, dass im Standard-Theme, welches auch dieses Blog verwendet, und hoffentlich auch bald in vielen anderen WordPress-Themes beim Kommentieren von Blogeinträgen benötigte Eingabefelder nicht nur in der Beschriftung wie “*” oder “erforderlich” gekennzeichnet werden, sondern mit Unterstützung z. B. des Firefox 3 und JAWS 9.0 oder NVDA 0.6p1 das Eingabefeld selbst als “erforderlich” gesprochen bzw. anderweitig angezeigt wird. Dies geschieht durch das Attribut aria-required, welches in diesen Eingabefeldern gesetzt und dessen Wert auf”true” steht.

Dies hat die beim W3C bekannte Folge, dass solche WordPress-Seiten nicht mehr gegen XHTML 1.0 validieren. Das WordPress-Team hat sich jedoch gegen eine Validierung gegen diesen inzwischen 9 Jahre alten Standard, sondern für den Fortschritt in der Barrierefreiheit entschieden.

Also, wenn ihr Firefox 3 verwendet und einen der kompatiblen Screen Reader, probiert’s doch einfach mal aus, wie das Formular zum Kommentieren jetzt mit euch spricht!

Nachdem wir Experten unsere Thesen vorgetragen und erläutert hatten, geriet der Workshop ziemlich schnell zu einer Frage- und Antwort-Stunde zwischen den anwesenden Webentwicklern im Publikum und uns. Es gab jede Menge Fragen zu ARIA (Accessible Rich Internet Applications) und deren Auswirkungen sowohl auf Browser- und Screenreader-Kombinationen, die es bereits unterstützen, als auch auf solche, die dies noch nicht tun. Sowohl Dr. Carlos Velasco als auch ich konnten deutlich machen, dass ARIA bereits heute angewandt werden kann, ja sogar sollte, um Web-2.0-Anwendungen barrierefreier zu gestalten. In Browsern, die dies noch nicht unterstützen, führt dies zu keinerlei nachteilen bei der Darstellung. Browser, die ARIA jedoch bereits unterstützen, wie der in Bälde erscheinende Firefox 3.0, können jedoch schon jetzt Vorteile daraus ziehen und entsprechend angereicherte/vervollständigte Informationen an die Screenreader weitergeben. Sobald andere Browserhersteller wie Opera und Microsoft nachziehen, werden solche Anwendungen automatisch barrierefreier, wenn diese Browser in den dann aktualisierten Versionen zum Einsatz kommen.

Es wurde weiterhin deutlich, dass es sowohl Web-2.0-Anwendungen wie gmail gibt, die von z. B. Blinden sehr aktiv genutzt werden, als auch solche, die noch echte Schwierigkeiten bereiten, wie Google Docs.

Einigkeit bestand darin, dass das Argument Barrierefreiheit nicht herangezogen werden sollte, um z. B. den Einsatz von javaScript oder Ajax zu unterlassen.

Und obwohl der Workshop zwischenzeitlich zu einer Frage- und Antwortstunde mutierte, schaffte es der Moderator Jo Bager, Redaktuer bei der C’T, am Ende doch, einige zusammenfassende Stichworte und vorausschauende Statements zu erarbeiten.

An jenem Vormittag besuchte ich einen weiteren Workshop als Publikumsteilnehmer: Zugänglichkeit und Mobilität. Dieser Workshop” wurde von Martin ladstätter, Journalist und Redakteur bei BIZEPS – Zentrum für selbstbestimmtes Leben in Wien, geleitet. Als Experte erschien lediglich Herr Jochen Hahnen, Mitarbeiter im Kompetenzzentrum Kooperationssysteme des Fraunhofer-Institut für Angewandte Informationstechnik. Der zweite angekündigte Experte, ein Herr Weber von der Fa. Microsoft, erschien nicht.

Herr Hahnen stellte eine Anwendung vor, die es mit Hilfe eines geeigneten handys ermöglicht, eine Wegstrecke in Form von GPS-Daten aufzuzeichnen und diese dann in ein dafür vorgesehenes Webportal hochzuladen. Die Zielgruppe besteht laut Herrn Hahnen aus Sportlern, die dieses Portal dazu nutzen können, sich im Vergleich zu anderen, die dieselbe Strecke laufen oder mit dem Rad abfahren, zu messen oder eine eigene Leistungskurve zu erstellen. Das Konzept der Anwendung und deren Möglichkeiten für Behinderte war für mich und viele andere Teilnehmer sofort klar ersichtlich: Auch Blinde und Rollstuhlfahrer könnten dieses System nutzen, um Mobilitätshilfen für bestimmte Streckenabschnitte zu geben. Es könnten Hinweise eingeflochten werden wie “hier befindet sich eine barrierefreie U-Bahn-Station” oder “hier befindet sich eine Wanderbaustelle”.

Könnten, denn die Anwendung ist zur Zeit nicht barrierefrei nutzbar. Auch ist momentan fraglich, ob die Handyanwendung in Bälde für Blinde nutzbar wird: Sie läuft zur Zeit nur auf Windows Mobile und soll laut Aussage von Herrn Hahnen zu Beginn des nächsten Jahres auf Java portiert werden, um dann auch auf Nokia-Handys lauffähig zu sein. Der geneigte Leser erkennt aber sofort: Java-Anwendungen und die Symbian-Screenreader Talks und MobileSpeak sind nicht gerade bekannt dafür, die dicksten Freunde zu sein.

Da Herr Hahnen von vornherein erklärte, dass die eigentliche Zielgruppe Sportler sind, ist zumindest von hierher begründbar, warum auf die Barrierefreiheit sowohl des Webportals als auch der Handyanwendung kein besonderer Wert gelegt wurde. Ein Blinder joggt ja nicht allein, also kann auch das Handy von der sehenden Begleitung bedient werden, oder?

Die Diskussion entwickelte sich zu diesem Thema sehr lebhaft und durchaus konstruktiv. So wurde deutlich gemacht, dass diese Art Anwendung eben für Behinderte ganz erheblichen Sinn machen würde. Es hängt natürlich von der Community ab, dass Daten z. B. zu Baustellen o. ä. immer aktuell sind. Aber das Web 2.0 heißt ja nicht umsonst das Mitmach-Web.

Im Rückblick erscheint mir die Wahl des Produktes zum Thema etwas unglücklich. Herr Hahnen konnte einem zwischendurch sogar schon ein bisschen leid tun, weil immer wieder auf die Tatsache hingewiesen, um nicht zu sagen, Salz in die Wunde gestreut, wurde, dass die Anwendung nicht barrierefrei ist. Mir stellt sich die Frage, ob der Workshop dazu dienen sollte, dem Fraunhofer Institut einen Anreiz zu geben, die Anwendung dahingehend zu erweitern und barrierefrei zu gestalten, dass zur Zielgruppe zukünftig auch Behinderte zählen können. Oder alternativ: Wurde sich im Vorhinein nicht hinreichend über das Produkt informiert, so dass gar nicht klar war, dass die Anwendung für den Personenkreis der Behinderten eigentlich gar nicht konzipiert ist? Diese Frage blieb der Workshop schuldig.

Den Rahmen der Veranstaltung bildeten sowohl die Vorstellung einer Studie zum Nutzerverhalten Behinderter im Web 2.0 als auch der Startschuss zum Biene-Award 2008. Was die Studie angeht, so konnte ich feststellen, dass ich voll im Trend zu liegen scheine: Ich nutze das Internet als Blinder tatsächlich viel zum Bestellen von Waren, bin kreativ im Umgehen von Barrieren, auf die ich stoße, und Captchas empfinde ich ebenfalls als lästigste Barriere, die das Web so zu bieten hat.

Weiterhin musste ich feststellen, dass die überwiegende Mehrzahl der Teilnehmerinnen und Teilnehmer sich schon kannten und das ganze fast ein bisschen wie ein großes Familientreffen wirkte. Ich selbst kannte bis dahin nur sehr wenige Teilnehmer persönlich. Als New Kid on the Block wurde ich sehr freundlich aufgenommen.

Abschließend möchte ich noch auf einen Artikel bei Heise Online hinweisen, der eine gute Zusammenfassung der Veranstaltung und ebenfalls ein paar Links zur Veranstaltung und zum Biene-Award enthält.

Ich möchte der Aktion Mensch sehr herzlich für die Einladung danken! Es war eine sehr bereichernde Erfahrung.

Hier einige der sichtbaren Änderungen, die in letzter Zeit noch so erfolgt sind:

• Bei Grafiken, die einen leeren alt-Text, also "", enthalten, jedoch auch mit einem title-Attribut versehen sind, erzeugt Firefox nun einen Namen für das Accessible der Grafik, der aus dem Inhalt des title-Attribut besteht. Bisher wäre diese Art Grafik als sogenannte dekorative Grafik gemeldet worden, weil eben der alt-Text leer ist. Während sich für JAWS und Window-Eyes-Benutzer hieraus keine Änderung ergeben dürfte, werden Anwender von NVDA und Orca die Änderung sehr wohl bemerken. JAWS und Window-Eyes haben in einem solchen Fall bisher schon selbständig nach einem title-Attribut gesucht und dieses verwendet, wenn es vorhanden war.
• Das src-Attribut von Grafiken wird jetzt über die Attribute eines Accessibles mitveröffentlicht. NVDA muss dann nicht extra für diese Informationen auf die älteren iSimple*-Interfaces zugreifen, die ursprünglich benutzt wurden, um Informationen zu veröffentlichen, die über MSAA (Microsoft Active Accessibility) hinausgingen. Unser Ziel ist es jedoch, alle Informationen, die bisher über iSimple* zu bekommen waren, auch für IAccessible2 zur Verfügung zu stellen.
• Bei ARIA gab es noch einige Verbesserungen, so dass bestimmte Arten von Listenfeldern und Menüs jetzt noch besser funktionieren.
• Unter Linux funktioniert das Dialogfeld “Bibliothek” jetzt auch in den Baumtabellen richtig.
• Durch das Auswerten eingesandter Absturzberichte konnten wir noch einige Fehler ausmerzen, die uns bis dahin nicht aufgefallen waren. Die Beta 5 von Firefox 3.0 wird anscheinend deutlich aktiver genutzt als frühere Betas, und diese Absturzberichte helfen uns wirklich, die Stabilität noch weiter zu verbessern. In diesem Zusammenhang eine Bitte: Es gibt im Dialogfeld zum Absenden eines Berichtes ein Kommentarfeld. Falls euch der Firefox abstürzen sollte, und ihr sendet einen Bericht an Mozilla, schreibt bitte einen Kommentar hinein, so dass wir einen Anhaltspunkt haben, wo euch der Absturz passiert ist. Manchmal ist es nämlich nicht ganz einfach, die Ursache für einen Absturz festzustellen, wenn man keinen Anhaltspunkt hat, auf welcher Seite sich der Berichtende befunden hat.

Es gibt in ARIA einige sogenannte universelle Attribute, also Attribute, die nicht nur ARIA-Steuerelementen vorbehalten sind, sondern die auf jedes HTML-Element angewendet werden können. Der Firefox, demnächst auch Opera, und in Zukunft hoffentlich noch mehr Browser, kann dann im Zusammenspiel mit modernen Screen-Readern dem Anwender gleich die richtigen Hinweise zur Bearbeitung eines Formulars geben, ohne dass z. B. ein Sternchen “*” für erforderliche Felder o. ä. verwendet werden muss. Browser, die dieses Attribut noch nicht unterstützen, stolpern aber nicht über das Attribut, so dass es hinzuzufügen nichts kaputtmacht.

Das erste Attribut, das ich vorstellen möchte, heißt aria-required und kann den wert “true” oder “false” annehmen. Schauen wir uns mal folgendes Beispielformular an:



Im obigen Formular sind die Felder firstName und lastName als erforderlich gekennzeichnet, indem man ihnen das Attribut aria-required=”true” zugewiesen hat.

Der NVDA, JAWS 9.0 und Window-Eyes ab Version 5.5 zeigen im Zusammenspiel mit dem Firefox an, dass diese beiden Eingabefelder erforderlich sind. JAWS 8.0 unterstützt dieses Attribut noch nicht, und auch im Orca unter Linux fehlt die Ansage bisher.

Ein Appell also an alle Webautoren: Wenn ihr keine Sternchen oder ähnlich offensichtlichen Kennzeichnungen verwenden könnt/dürft, fügt euren Elementen, die unbedingt erforderlich sind, das Attribut aria-required=”true” hinzu, um die Felder für unterstützende Browser und Screen Reader so kenntlich zu machen.

Um das Beispiel ausprobieren zu können, braucht man Firefox 3 Beta 2 und entweder JAWS 8 oder Window-Eyes 6.x. Um zum Beispiel zu gelangen:

1. Öffne aus dem oben genannten Blogeintrag den Link “New YUI example”.
2. Wähle in dem Artikel den Link “View example in new window”.
3. Navigiere mit den Pfeiltasten auf die erste Zeile, die mit “text/html” beginnt und drücke EINGABE für den Formularmodus bzw. das Äquivalent in Deinem Screen-Reader.
4. Navigiere Links und Rechts durch die Menüleiste und öffne ein Pulldown-Menü mit Pfeil Runter, wie in einer normalen Anwendung.

Ich habe es gerade selbst ausprobiert, und es hat richtig gut funktioniert. Gute Arbeit!