Archiv für die Kategorie „Firefox“

Einfaches ARIA Tip #2: aria-invalid und role “alert”

Samstag, 19. Juli 2008

Mein zweiter Tip rund um ARIA (Accessible Rich Internet Applications) beschäftigt sich mit einem Problem, das wohl jedem von uns beim Ausfüllen eines Formulars schon mal begegnet ist: Man vertippt sich bei der E-Mail-Adresse bzw. der eventuell geforderten Wiederholung davon, oder ähnliches passiert beim Kennwort. Man hat vielleicht vergessen, ein erforderliches Feld gänzlich auszufüllen. Man hat also fleißig seine 20 Felder ausgefüllt, drückt den Schalter “Abschicken”, und dann kommt der Server mit einer oder mehreren Fehlermeldungen zurück, und man muss die Formularfelder korrigieren und die übrigen nochmals durchgehen um sicherzustellen, dass keine Informationen zurückgesetzt oder entfernt wurden.

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

WordPress aktualisiert

Samstag, 19. Juli 2008

Soeben habe ich dieses Blog auf WordPress 2.6 aktualisiert. Sollte es irgendwelche Probleme geben, bitte am besten hier kommentieren!

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!

JAWS 8.0 beibringen, die Firefox-Konfiguration auch für Firefox 3.0 zu laden

Donnerstag, 19. Juni 2008

Damit JAWS 8.0 die Skripts für den Firefox lädt und z. B. Features wie die virtuelle Suche auch mit Strg+F funktionieren, muss in der Datei C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Freedom Scientific\JAWS\8.0\Settings\Deu\ConfigNames.ini unterhalb von

InstallationBootstrapperLang=Freedom Scientific Installer

folgende Zeile hinzugefügt werden:

firefox3.0=firefox

Diese Änderung kann nur in der ConfigNames.ini unter All Users gemacht werden, weil zum Laden dieser Datei die Schichtung von gemeinsamen und anwenderbezogenen Konfigurationsdateien nicht funktioniert.

Achtung: Unter Vista muss diese Änderung unter C:\ProgramData\Freedom… gemacht und mit Administratorrechten ausgeführt werden. Den Editor im Startmenü auswählen, Anwendungen-Taste, “Als Administrator ausführen” wählen, die Datei laden, bearbeiten und speichern.

Erscheinungstermin für Firefox 3.0 steht fest!

Donnerstag, 12. Juni 2008

Der Erscheinungstermin der finalen Version 3.0 von Firefox steht nun fest! Wie der englischsprachigen Ankündigung zu entnehmen ist, wird Firefox 3.0 am kommenden Dienstag, den 17. Juni, veröffentlicht. Wenn Du Interesse hast, beim Aufstellen eines Weltrekords mitzuhelfen, dann besuche diese Seite. Das Ziel ist, den Firefox 3.0 zur am meisten gedownloadeten Software innerhalb von 24 Stunden zu machen.

Bei dieser Ankündigung stelle ich fest, dass ich genauso aufgeregt bin wie diejenigen im Team, die schon dabei waren, bevor die Arbeit am Firefox 3 losging. Ich bin erst seit Dezember 2007 Teil des Teams und habe einige Monate zuvor als Mitglied der Community mitgeholfen. Firefox 3 ist ein echt spannendes Release: Eine komplette Plattform (Linux) wird von der Barrierefreiheit her das erste Mal unterstützt, unter Windows wurden erhebliche Verbesserungen vorgenommen, und auch ansonsten ist das Release mit so vielen tollen neuen Funktionen bestückt, dass dies ein unbedingtes Muss für jeden Firefox-Fan sein sollte! :-)

Sobald der Firefox 3 zum Download bereitsteht, werde ich dies hier ankündigen!

Impressionen zur SightCity” 2008 in Frankfurt

Samstag, 10. Mai 2008

Vom 7. bis 9.05. fand in Frankfurt am Main die SightCity, die inzwischen wohl größte Ausstellung von Hilfsmitteln für Blinde und Sehbehinderte im deutschsprachigen Raum, statt. Die Mozilla Foundation war in diesem jahr erstmalig mit einem Stand vertreten.

Die häufigste Frage, die dem Team am Stand gestellt wurde, war “Was macht denn ein Browser-Hersteller auf einer Ausstellung für Blinde und Sehbehinderte?” Nun, überrascht hat dies nicht: Während es in den USA, z. B. auf der CSUN Gang und Gäbe ist, dass Hersteller wie Google, Microsoft oder eben auch Mozilla sich dort präsentieren, weil sie engagiert sind, ihre Produkte barrierefreier zu gestalten, ist dies bisher auf deutschsprachigen Messen nicht oder nur sehr selten vorgekommen.

Die Resonanz auf unsere Anwesenheit war sehr positiv. Besucher konnten viel über die Neuerungen im Bereich der Barrierefreiheit des Firefox 3.0 erfahren, wir gaben Tipps zu konkreten Fragen zur Benutzung von Firefox und Thunderbird, wir hatten Besuch von einigen Webdesignern, die ich teilweise auch schon auf der Tagung “Einfach für Alle” am 06.05. getroffen hatte, und einige Mitbringsel für Freunde und Familie gab es auch.

Die Premiere bei der SightCity ist also gelungen, so dass man uns in Zukunft öfter auf solchen oder ähnlichen Veranstaltungen antreffen kann, wo wir persönlich Rede und Antwort stehen werden.

Letzter Feinschliff für Firefox 3

Samstag, 26. April 2008

Entschuldigt, wenn es hier in den letzten Wochen etwas ruhig war. Ich steckte bis zum Hals in den letzten Feinschliffarbeiten für Firefox 3.0. Wir sind nun, wie man so schön sagt, aus dem Gröbsten raus, so dass ich fürs endgültige Release nur noch eventuell aufkommende Absturz-Fixes oder gravierende Mängel zu beheben erwarte.

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.

Einfaches ARIA Tip #1: Das Attribut aria-required

Freitag, 29. Februar 2008

Inspiriert durch eine Unterhaltung, die ich vor einigen Tagen mit Aaron Leventhal, dem Modulbesitzer der Barrierefreiheitsfunktionen in den Mozilla-Produkten, führte, möchte ich mit diesem Posting eine kleine Serie starten, die zeigen soll, mit wie wenig HTML-Code man ARIA in seine Webseiten einbauen kann, ohne gleich ganze ARIA-Steuerelemente programmieren zu müssen, und so die Barrierefreiheit bestimmter Webseiten zu verbessern.

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.

Einige Benutzbarkeitsverbesserungen dieser Woche

Freitag, 29. Februar 2008

Aaron leventhal, der Modulbesitzer der Barrierefrehieitsfunktionen in der Mozilla-Plattform, und ich trafen uns Anfang dieser Woche in Stuttgart, um gemeinsam an einigen Fehlern zu arbeiten, die uns die letzten Wochen, teilweise sogar Monate, begleitet haben. Als Ergebnis sind hierbei einige deutlich sichtbare Verbesserungen bei der Benutzbarkeit herausgekommen, auf die ich den geneigten Leser kurz aufmerksam machen möchte.

Ungereimtheiten beim Laden von Dokumenten

Beim Laden von Dokumenten im Firefox oder beim Laden von Nachrichten in Thunderbird gab es in den vergangenen Wochen diverse Probleme. Unter Windows kamen Nachrichten manchmal gar nicht in den virtuellen Puffer, unter Linux fehlten Ereignisse, die das vollendete Laden eines Dokumentes anzeigen, oder sie wurden nur unzuverlässig generiert, usw. Diesen ganzen Themenkomplex haben Aaron, diverse Tester und ich mit vereinten Kräften gelöst, so dass sowohl in Firefox als auch in Thunderbird jetzt unter beiden unterstützten Plattformen ein flüssigeres und zuverlässigeres Arbeiten möglich wird.

Fokus-Wechsel, der gar keiner ist

Ist euch auch schon aufgefallen, dass im Dialogfeld Add-Onss, wenn man von der Registerkarte Erweiterungen zur Registerkarte Themes wechselt, dem Screen-Reader vorgegaukelt wird, der Fokus sei gleich auf das gerade gewählte Element (also das Theme oder die Erweiterung) gewechselt, wenn man Pfeiltasten betätigt, ist man aber tatsächlich immer noch in den Registern? Dieses Problem, das ich schon seit Firefox und Thunderbird 1.5 kenne, also seit Beginn ihrer Barrierefreiheit, wurde in dieser Woche endlich behoben und kann in täglichen Builds seit dem 28.02. bewundert werden. Dies bewirkt auch, dass ein angeblicher Fokuswechsel in Thunderbird nicht mehr fälschlicherweise angesagt wird, wenn man z. B. erst im Posteingang eine Nachricht markiert, dann in den Ordner Entwürfe wechselt und später zum Posteingang zurückkehrt. Früher wurde hier gleich die markierte Nachricht vorgelesen, und der Screen-Reader glaubte, der Fokus sei tatsächlich in die Nachrichtenliste gewechselt.

Nicht aktualisierte Strukturelemente

Dies ist vor allem ein Problem in Thunderbird gewesen: Man geht auf eine Newsgroup oder einen IMAP-Ordner, er synchronisiert sich neu, der Screen-Reader kriegt davon aber gar nichts mit. Man muss erst den Fokus woanders hin und dann wieder auf die Strukturansicht zurück bewegen, um die aktualisierten Werte hören oder lesen zu können. Dies gehört seit einigen Tagen auch der Vergangenheit an: Fokusiert man jetzt einen solchen Ordner, und aktualisiert dieser die Anzahl der Nachrichten und eventuell ungelesener Nachrichten, wird dies auf der Braillezeile automatisch aktualisiert, und die Sprache sagt beim Lesen der Zeile auch die richtigen Werte an. Mit ein bisschen Skripting kriegt man sicherlich auch eine automatisierte Ansage bei Aktualisierungen hin.

Ich empfehle allen Interessierten, die eh tägliche Builds verwenden, nach diesen Neuerungen Ausschau zu halten. Die in Bälde zu erwartende Beta 4 von Firefox 3 wird diese Änderungen selbstverständlich auch enthalten.

Yahoo!’s veröffentlicht Menüsteuerelement mit wai-aria-Unterstützung

Montag, 24. Dezember 2007

Yahoo!’s Accessibility-Guru Victor Tsaran hat in diesem Blogeintrag erläutert, wie Yahoo! in seinen angereicherten Steuerelementen jetzt ARIA (Accessible Rich Internet Applications) verwendet, um so komplexe und in HTML normalerweise nicht abbildbare Strukturen wie ein komplettes Menüsystem zugänglich 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!

Firefox 3 Beta 2 ist ab sofort verfügbar!

Mittwoch, 19. Dezember 2007

Nur 31 Tage nach Erscheinen der Beta 1 von Firefox 3 steht nun die Beta 2 zum Download zur Verfügung. Auch in deutscher Sprache ist diese Beta bereits verfügbar. Zu den für Blinde wichtigen Veränderungen gehört, dass, wenn man mit JAWS auf eine Seite surft, die Ausklapplisten enthält, jetzt wieder wie gewohnt nur der gewählte Eintrag im virtuellen Dokument auftaucht und nicht alle Elemente angezeigt werden. Bei einer Ausklappliste zum Wählen eines Herkunftslandes kann das schon lästig werden…
Unter Windows und Linux wurde einiges an der Menübehandlung verbessert, so dass Screen-Reader jetzt eine wesentlich zuverlässigere Ansage tätigen dürften.

Ein bekanntes Problem ist, dass sich die Liste, die beim Vervollständigen von Adressen im Adressfeld geöffnet wird, als “Menü” zu erkennen gibt. Dies trifft auch auf das Dialogfeld “Lesezeichen hinzufügen” zu. An dem Problem wird zur Zeit gearbeitet. Während JAWS 8, NVDA unter Windows und Orca unter Linux damit keine Probleme haben, gerät Window-Eyes leider zur Zeit etwas ins Schleudern. JAWS 9.0 erkennt die Liste beim Autovervollständigen fälschlicherweise sogar als Kontextmenü, was zu einem automatischen Auswählen des ersten gefundenen Eintrags führt. Für Interessierte wird dieser Bug hier (auf englisch) behandelt.

Interessierte sind herzlich eingeladen, sich diese Betaversion anzuschauen und Feedback zu geben!