Artikel-Schlagworte: „Firefox“

Warum sehen Seiten im Firefox anders aus als im IE?

Freitag, 22. Januar 2010

Nein, dies ist kein weiterer Artikel, der einem Webdesigner zu erklären versucht, warum es so umständlich ist, für den Internet Explorer zu programmieren. ;) In diesem Artikel geht es vielmehr darum, warum manche Webseiten bzw. Teile davon von Bildschirmleseprogrammen für Blinde unterschiedlich dargestellt werden, abhängig davon, ob der Anwender die Seite im Internet Explorer oder dem Firefox aufruft.

Anstoß für den Artikel gab diese Bemerkung von Heiko Kunert aus Hamburg, in der er bemerkte, dass es immer noch Seiten gibt, die im Firefox mit einem Bildschirmleseprogramm anders aussehen als im IE. Auf meine Nachfrage hin führte Heiko aus, dass er versuchte, den Play-Schalter beim Anschauen des Hamburg-Journals in der NDR Mediathek zu finden und dass JAWS 8.0 diesen zwar mit dem IE, aber nicht mit dem Firefox finden würde.

Zur Erklärung dieses Phänomens kommen in diesem Fall mehrere Faktoren zusammen:

Zum einen ist da natürlich der verwendete Browser. Im Idealfall wird HTML-Code in beiden Browsern gleich interpretiert, egal ob es jetzt um die visuelle Anzeige für Sehende oder die Darstellung durch das Bildschirmleseprogramm für Blinde geht. Jeder, der schon mal mit beidden Browsern unterwegs war, dass es selbst in JAWS 10 und 11, oder auch bei Verwendung des NVDA, immer mal wieder den einen oder anderen subtilen Unterschied gibt.

Zum anderen ist da in diesem Fall der Faktor Flash. Die NDR Mediathek verwendet eine Adobe Flash-Anwendung zur Anzeige des Videomaterials und auch zur Steuerung der Wiedergabe. Der von Heiko gesuchte Play-Schalter befindet sich also nicht im eigentlichen HTML, sondern in dieser Flash-Anwendung. Hier gibt es gerade mit älteren JAWS-Versionen teils gravierende Unterschiede in der Handhabung zwischen dem Internet Explorer und dem Firefox. Der Grund ist, dass das Flash-Plugin für den Firefox erst im Jahr 2008 von Adobe zugänglich gemacht wurde, das Plugin für den IE aber schon seit 2002 Zugänglichkeit unterstützt. Da liegen also mal lockere 6 Jahre zwischen.

Und damit kommen wir zum dritten Faktor, der verwendeten Version eines Screen Readers (unabhängig vom hersteller). Die hier verwendete Version von JAWS war die Version 8.0, die in den USA zuerst Ende 2006 veröffentlicht wurde. Die Veröffentlichung der deutschen Version fand irgendwann 2007 statt. Also wurde diese Version von JAWS ein bis zwei Jahre vor einer zugänglichen Version des Flash-Plugins für den Firefox veröffentlicht und ist somit gar nicht darauf eingestellt, dass es im Firefox überhaupt ein zugängliches Flash-Plugin geben könnte. Berechtigter Kritikpunkt: man hätte auch vorausschauend in JAWS die Möglichkeit bereits vorsehen können. Jeder, der aber schon mal mit Microsoft Active Accessibility gearbeitet hat, weiß ein Lied davon zu singen, dass auch das strikte Folgen der Dokumentation nicht immer zum gewünschten Ergebnis führt, ohne noch weitere kleine Veränderungen vornehmen zu müssen, damit es tatsächlich für den Anwender rund läuft. Dasselbe Rechenspiel gilt natürlich auch für Window-Eyes, die Flash ebenfalls von Anfang an im IE unterstützten (ich glaube sie waren sogar die ersten), mit dem Flash-Plugin in Firefox aber auch erst richtig umgehen lernen mussten, als es dann endlich mal in einer zugänglichen Version erschien. Und solche Verbesserungen werden von den kommerziellen Herstellern von Bildschirmleseprogrammen nur in den seltendsten Fällen auf ältere Versionen zurückportiert.

Wer den gerade erschienenen Firefox 3.6 einsetzt, wird übrigens schnell feststellen können, ob er eine aktuelle und damit zugängliche Version des Flash-Plugins installiert hat. Firefox weist jetzt auf veraltete Versionen des Flash-Plugins hin und fordert zur Aktualisierung auf. Auch wegen bekannter Sicherheitsprobleme ist so ein Schritt unbedingt zu empfehlen!

Beim Testen habe ich das beste Ergebnis übrigens mit der neuartigen Herangehensweise des NVDA an das Interagieren mit Flash-Inhalten erzielt. NVDA sieht nicht nur sämtliche Schalter sondern liest auch von allen Schaltern die Beschriftungen vor, erkennt die bereits abgelaufene und noch verbleibende Zeit und ermöglicht ein vollständiges Bedienen des NDR-Mediathek-Players.

Es ist also leider tatsächlich so, dass ein Bildschirmleseprogramm Inhalte von Webseiten unterschiedlich darstellen kann abhängig davon, mit welchem Browser die Seite aufgerufen wird. Seiteninhalte sind in diesem Fall aber eben nicht nur HTML-Inhalte, sondern auch externe Quellen wie Flash. Und dies erhöht die Variabilität und Fehleranfälligkeit der Anzeige.

Ich hoffe, mit diesem Artikel ein wenig Licht in das Dunkel des teilweise doch verwirrenden und komplexen Zusammenspiels der verschiedenen Komponenten gebracht zu haben! Fragen und Kommentare sind natürlich immer herzlich willkommen!

Firefox 3.0.7 bring ein wichtiges Bugfix für GoogleMail-Anwender!

Donnerstag, 5. März 2009

Wie vielleicht schon gelesen wurde Firefox 3.0.7 vor einigen Stunden veröffentlicht. Dieses Sicherheits- und Stabilitätsupdate bringt ein wichtiges Bugfix für alle Anwender von Screenreadern mit sich, die den Dienst GoogleMail nutzen. Bisher war es nicht möglich, in der Nachrichtenliste einfach auf dem Link zu einer Nachricht die Eingabetaste zu drücken, um die Mail zu öffnen. GoogleMail hat sich einfach ausgeschwiegen. Man musste die Mausemulation des Screenreaders bemühen, um eine Mail zu öffnen. Dieses Problem wurde in Firefox 3.0.7 behoben, so dass Mails jetzt ganz einfach wie erwartet mit Eingabe aufgehen.

Viel Spaß!

Neuerungen der Zugänglichkeit in Firefox 3.0.5

Mittwoch, 24. Dezember 2008

In der vergangenen Woche ist Firefox 3.0.5 erschienen und bei den meisten inzwischen als automatisches Update verteilt worden. Version 3.0.5 bringt wieder drei Verbesserungen im Bereich der Barrierefreiheit, die bei entsprechender Unterstützung durch Screen Reader Vorteile für die Anwender bringen:

  1. In den Objektattributen jedes Accessibles einer Seite kann jetzt der exakte Wert für das CSS-Attribut “display” abgefragt werden. Zusätzlich zu “formatting:block”, welches weiterhin zur Verfügung steht, ist es so möglich, eine genauere Information über die Gestaltung des jeweiligen Elements zu erhalten als bisher. In Firefox 3.1 Beta ist dies schon länger verfügbar und hat jetzt auch seinen Weg in Firefox 3.0.5 gefunden.
  2. Es wurde ein Fehler behoben, durch den manche Arten von Dokumentelementen nicht ordnungsgemäß den Focus übernehmen konnten. Hiermit sollten weitere als “anklickbar” gemeldete Elemente aktivierbar werden.
  3. Für Screen Reader, die nicht IAccessible2, sondern die älteren iSimpleDom*-Interfaces verwenden, wurde ein Fehler behoben, der bei der Anforderung des sog. ComputedStyle, also des tatsächlich in Effekt befindlichen Stils eines Elements, auftrat. Hiermit sollte es Screen Readern, die diese Interfaces noch verwenden, jetzt besser möglich sein, Dokumentformatierungen zu sprechen. Auch diese Änderung ist schon länger in Firefox 3.1 und hat nun ihren Weg in Firefox 3.0.5 gefunden.

Firefox 3.0.2: Verbesserungen bei den Barrierefreiheitsfunktionen

Mittwoch, 24. September 2008

Wie in diesem englischsprachigen Eintrag des Mozilla Blogs in der vergangenen Nacht angekündigt, sind Firefox 2.0.0.17 und 3.0.2 erschienen. Neben den dort erwähnten Sicherheitsfehlerbehebungen bringt das Update auf Firefox 3.0.2 auch diverse Verbesserungen im Bereich der Zusammenarbeit mit assistiven Technologien mit, auf die ich hier hinweisen möchte.

  • Firefox 3.0.2 ist jetzt mit JAWS 7.10 kompatibel. Um möglichst allen potentiellen Anwendern den Zugang zum neuesten Firefox zu ermöglichen, wurde ein Problem identifiziert und behoben, das einen Absturz verursachte, sobald man Firefox 3.0 oder 3.0.1 mit laufendem JAWS 7.10 aufrief.
  • Wenn man Firefox 3.0.1 mit der öffentlichen Betaversion von JAWS 10 einsetzte, konnte es passieren, dass bei manchen dynamisch eingeblendeten Seitenelementen JAWS diese nicht mitbekam und auch ein Aktualisieren des virtuellen Puffers nichts half. Dieses Problem wurde behoben.
  • Ein Problem, dass manche Schalter, Grafiken oder anklickbare Elemente mit verschiedenen Screen Readern nicht aktiviert werden konnten, sondern die Mausemulation benötigt wurde, wurde behoben. Für die technisch interessierten: Die Methoden doAction und doDefaultAction haben bei manchen Elementen nicht richtig reagiert.
  • Wenn ein Map-Element etwas anderes als Grafiklinks enthielt, wurden diese bisher nicht an Screen Reader weitergegeben. Dies passiert nun, so dass das Map-Element problemlos als allgemeiner Navigationsmechanismus auf Seiten verwendet werden kann.
  • Ein selten auftretender Absturz durch bestimmte Layouttabellen wurde behoben.
  • Einige weitere Fehlerbehebungen in den Programmierschnittstellen ermöglichen assistiven Technologien unter Windows und Linux eine noch sauberere Kommunikation mit dem Firefox.

Ich empfehle, dass das Update auf Firefox 3.0.2 möglichst bald eingespielt wird, damit jede(r) Anwender(in) von den Neuerungen profitiert. Viel Spaß!

WebVisum wechselt zu einem einladungsbasierten Registrationssystem, ich kann Einladungen verschicken!

Mittwoch, 27. August 2008

Wie einige von euch vielleicht schon auf der WebVisum-Seite gelesen haben, sah sich das WebVisum-Team gezwungen, vone iner komplett uneingeschränkten auf eine einladungsbasierte Registration umzusteigen. Der Grund ist, wie schon befürchtet, ein andauernder schwerer Missbrauchsversuch durch sogenannte Spam-Bots. Die Folge ist, dass jetzt nur noch Registrierungen mit einem Einladungscode möglich sind.

Jedes legitime WebVisum-Mitglied kann diese Einladungen verschicken. Wenn ihr also bisher noch nicht bei WebVisum registriert seid, dies aber ausprobieren möchtet, um z. B. in denGenuss des Lösens von Captchas zu kommen, wendet euch doch an Freunde, von denen ihr wisst, dass sie WebVisum verwenden, und bittet sie, euch einzuladen.

Wenn ihr niemanden wisst, kann auch ich Einladungen aussprechen. Eine private Mail an marco punkt zehe at googlemail genügt.

Ein Entwicklerjob im Bereich Mozilla Accessibility zu vergeben!

Montag, 25. August 2008

Da es sich um einen Job handelt, in dem englisch fließend in Wort und Schrift Grundvoraussetzung ist, hier lediglich der Link zu meinem englischsprachigen Blogeintrag mit voller Jobbeschreibung.

Firefox 3.1 liefert Textattribute an Screen Reader

Sonntag, 20. Juli 2008

Am vergangenen Donnerstag landete wahrscheinlich das größte neue Feature für Firefox 3.1, den designierten nächsten größeren Versionssprung, im Produkt: Die Herausgabe von Textattributen an Screen Reader und andere assistive Software.

Fragte man bisher bei meinem Blog den Link unterhalb der allerobersten Überschrift nach seinen Attributen, z. B. mit dem Windows-Tool AccProbe, bekam man folgende Antwort:


getAttributes(1) = NULL

NULL ist gleichbedeutend mit “Ich hab’ nichts zu melden”.

Ganz anders mit den nächtlichen Builds von Firefox 3.1a1pre seit der Buildnummer 2008071803. Hier bekommt man nun folgende Antwort:


getAttributes(1) = org.eclipse.actf.accservice.core.win32.ia2.IA2TextSegment[text=font-style:normal;language:de-DE;text-align:start;font-size:12px;background-color:rgb(198\, 217\, 233);font-weight:400;text-indent:0px;color:rgb(34\, 68\, 102);font-family:"Lucida Grande"\,"Lucida Sans Unicode"\,Tahoma\,Verdana\,sans-serif;text-underline-style:underlinesolid;,start=0,end=14]

Man bekommt also zusätzlich zu den Informationen über die verwendete Schriftfamilie und deren Größe auch die Farben, ob eine Unterstreichung vorhanden ist, wie stark die Schrift ist (ein Wert von 400 besagt eine normale Schriftstärke), die Sprache, in der dieser Teil ausgezeichnet wurde, und auch Informationen zur Ausrichtung des Textes.

In Eingabefeldern, und wenn die automatische Rechtschreibkorrektur, die es seit Firefox 2.0 gibt, eingeschaltet ist, wird bei einem falsch geschriebenen Wort auch die Information “invalid:spelling;” zur Verfügung gestellt. Beim Tippen wird, sobald ein Satz- oder Leerzeichen gedrückt wird, ein Ereignis ausgelöst, wenn das soeben eingegebene Wort als Rechtschreibfehler erkannt wird. Screen Reader können dieses Ereignis auswerten und umgehend darauf hinweisen, dass ein Rechtschreibfehler aufgetreten ist. Die Korrektur kann dann gleich vorgenommen werden, und man bekommt sofort Feedback darüber, ob die Korrektur erfolgreich war.

Ein Hinweis: Gerade das Attribut “invalid:spelling;” kann sich noch ändern, je nachdem, ob die IAccessible2- und AT-SPI-Gruppen unseren Vorschlag, diese Werte an die möglichen Werte des Attributes aria-invalid anzulehnen, akzeptieren oder nicht.

In den nächsten Wochen wird dieses neue Feature sicher noch einige Verbesserungen in der Geschwindigkeit und eventuelle Bugfixes erfahren. Der erste Meilenstein ist jedoch geschafft, die Funktion steht prinzipiell zur Verfügung, und erstes Feedback des Orca-Teams und unsere eigenen Tests zeigen, dass es auch schon sehr gut funktioniert.

Sobald Thunderbird 3.0 die dem Firefox 3.1 zugrunde liegende Version Gecko 1.9.1 nutzen wird, was innerhalb der nächsten paar Wochen der Fall sein dürfte, steht diese Funktion auch beim Schreiben von E-Mails zur Verfügung. Bei entsprechenden Auswertungen der Infos durch die Screen-Reader dürfte also einer weiteren Angleichung der Funktionen, die Blinde und Sehende gleichermaßen nutzen können, nichts mehr im Wege stehen!

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.