Kategorien
ARIA Firefox Technik Zugänglichkeit

Wie ich den Bericht zu den Privatsphäre-Schutzmaßnahmen zugänglicher machte

Firefox 70, der im Oktober erschien, enthält als eine neue Funktion einen Bericht zur Aktivitätenverfolgung. Dieser eigentlich sehr grafische Bericht ist auch für die Nutzer von Screen Readern zugänglich.

Werbeanzeigen
Kategorien
ARIA Zugänglichkeit

Die Grundregeln zugänglicher Webseiten

Ich werde immer wieder gefragt, was denn die absolut grundlegenden Dinge sind, die man als Webentwicklerin und Webentwickler kennen sollte, um Webseiten so zu schreiben, dass sie möglichst zugänglich sind.

Ich hatte eigentlich angenommen, dass es hierzu schon zahlreiches Material im Web gibt und dass es nicht schwierig sein dürfte, dieses auch zu finden. Da die Frage aber immer und immer wieder aufkommt, habe ich nun beschlossen, meine eigene Sicht dieser absoluten Grundlagen aufzuschreiben. Hier ist sie also nun, meine persönliche Liste der Grundlegenden Dinge für zugängliche Webseiten.

Kategorien
ARIA Zugänglichkeit

Was ist WAI-ARIA, was tut es, und was tut es nicht?

Am 20.03.2014 veröffentlichte das W3C WAI-ARIA endlich als Version 1.0. Nach vielen jahren der Entwicklung, des Testens und Fine-Tunings ist WAI-ARIA nun ein Webstandard.

Ich werde jedoch häufig gefragt: Was ist WAI-ARIA, und wie kann es mir als Webentwickler helfen? Und was kann es nicht?

Ich habe in den letzten Jahren immer wieder festgestellt, dass von falschen Voraussetzungen ausgegangen wird, was die Fähigkeiten und beabsichtigte Benutzung von WAI-ARIA angeht. Dies führt dann häufig zu Seiten, die weniger zugänglich sind als sie es wären, wenn WAI-ARIA überhaupt nicht zum Einsatz gekommen wäre.

Zusätzlich schrieb Jared W. Smith vom WebAIM-Projekt am 26.03. einen Blogbeitrag mit dem Titel „Accessibility Lipstick on a Usability Pig“ (Zugänglichkeits-Lippenstift für ein Benutzbarkeits-Schwein), in dem auf ein weiteres verwandtes Problem eingegangen wird: Obwohl die Seite von der Benutzerfreundlichkeit her absoluter Müll ist, wird so lange WAI-ARIA-Zuckerguss draufgestreut, bis die WCAG-Kriterien irgendwie erfüllt werden.

All diese Faktoren und eine Ermutigung durch Jason Kiss auf Twitter führten dazu, dass ich diesen längst überfälligen Blogbeitrag darüber schreibe, was WAI-ARIA ist, wobei es helfen kann, wann es benutzt werden sollte und – und das ist noch wichtiger – wann es nicht benutzt werden sollte. Ich verfasste ihn zunächst auf englisch und biete ihn hier jetzt in einer deutschen Übersetzung an.

So, nach langer Vorrede nun der Einstieg!

Was ist WAI-ARIA?

WAI-ARIA steht für den englischen Ausdruck „Web Accessibility Initiative – Accessible Rich Internet Applications“, also frei übersetzt Webbarrierefreiheitsinitiative (des W3C) – Zugängliche angereicherte Internetanwendungen. Es handelt sich dabei um einen Satz von semantischen Attributen, die Hilfstechnologien für Menschen mit Behinderungen (wie z. B. Bildschirmleseprogrammen für Blinde) dabei helfen, Markupkonstrukte auf Webseiten und -applikationen zu verstehen, die es nicht nativ in HTML gibt. Die zur Verfügung gestellten Informationen können so etwas Triviales sein wie das Kommunizieren des Zustands einer Schaltfläche oder eines Links, ob das Aktivieren weiteren Inhalt ein- oder ausblendet, oder auch so komplexe Widgets wie ein Hierarchiebaum oder ganze Menüsysteme.

Dies wird dadurch erreicht, dass man dem vorhandenen HTML 4.01 oder neuer bestimmte Rollen- und Zustandssattribute hinzufügt. Diese Attribute haben keinen Einfluss auf das Layout oder die vom Browser zur Verfügung gestellte Funktionalität, erweitern aber die Informationen, die der Browser an Hilfstechnologien übermittelt.

Ein Eckpfeiler von WAI-ARIA ist das Attribut role. Es weist den Browser an, der Hilfstechnologie mitzuteilen, dass das verwendete HTML-Element nicht das ist, wonach es aussieht, sondern etwas ganz anderes. Ursprünglich nur ein div-Element, kann es durch das Rollen-Attribut zu einem Container für eine Liste von Elementen einer Autovervollständigung werden. In diesem Fall ist die richtige zu verwendende Rolle „listbox“. Genauso wird ein Kind-Element, das ebenfalls ein div ist, zu einem einzelnen Element dieser Autovervollständigung, wofür die Rolle „option“ die Richtige ist. Zwei divs, aber durch die Rollen zwei völlig unterschiedliche Bedeutungen. Die Rollen sind übrigens stark ihren Entsprechungen aus Desktop-Programmen entlehnt.

Eine Ausnahme hiervon bilden lediglich die Rollen für Dokumentmarkierungen (Landmarks). Diese teilen der Hilfstechnologie lediglich mit, dass man jetzt an einer bestimmten Stelle im Dokument angekommen ist, ohne aber die eigentliche Bedeutung des Elements zu verändern. Mehr über Landmarks erfahrt ihr im englischen ARIA-Tipp #4. Wenn ihr HTML5 verwendet, könnt ihr auch native Elemententsprechungen verwenden.

Der zweite Eckpfeiler von WAI-ARIA sind Attribute für Zustände und Eigenschaften. Sie geben Auskunft über den Zustand von nativen Elementen oder WAI-ARIA-Widgets wie z. B. ob der Inhalt zu einem Element ein- oder ausgeklappt ist, ein Formularelement erforderlich ist, einem Widget ein Popup-Menü angeheftet ist und andere. Diese Attribute sind sehr dynamischer Natur und verändern ihre Werte natürlich im Laufe des Lebens einer Webapplikation. Sie werden normalerweise durch JavaScript-Code verändert.

Was ist WAI-ARIA nicht?

WAI-ARIA wurde nicht dazu entworfen, das Verhalten des Webbrowsers zu beeinflussen. Wenn ihr z. B. einem div die Rolle „button“ gebt, weiß der Browser im Gegensatz zum echten button-Element nichts von der Fokussierbarkeit durch die Tastatur oder davon, dass er beim Druck auf Leertaste oder Eingabe einen onClick-Handler ausführen soll. Auch andere Eigenschaften, die einem Button eigen sind, sind nicht im Browserverhalten vorhanden. Der Browser weiß nicht, dass ein div mit der Rolle „button“ eine Schaltfläche ist. Lediglich der Teil, der für die Kommunikation mit Hilfstechnologie zuständig ist, weiß darüber bescheid.

In der Konsequenz heißt dies, dass es in eurer Verantwortung liegt, die Fokussierbarkeit durch die Tastatur und andere Verhalensmuster, die denen von Desktop-Applikationen ähneln, sämtlichst händisch nachbauen müsst. Ein gutes Beispiel hierfür könnt ihr in meinem englischen Artikel über ARIA-Tabs nachlesen, in dem ich schrittweise erkläre, was dazu gehört, ein Widget, das es nicht in HTML gibt, zugänglich zu machen. Dazu gehört ein bestimmtes erwartetes Verhalten bei der Benutzung durch die Tastatur.

Wann sollte ich WAI-ARIA nicht benutzen?

Ja, das ist schon richtig so, dass dieser Abschnitt zuerst kommt! Denn die allererste Regel bei der Benutzung von WAI-ARIA lautet: Verwende es nicht, wenn du es nicht unbedingt musst und dein Ziel auch durch reine HTML-Elemente erreichen kannst. Je mehr du dich auf native HTML-Elemente stützen kannst, desto besser! Es gibt noch einige weitere Regeln, denen ihr folgen solltet und die ihr in diesem informellen englischen Dokument nachlesen könnt.

Der Fall von button-Elementen versus anklickbaren div- oder span-Elementen habe ich bereits erwähnt. Dies setzt sich auch bei Attributen fort. Das HTML5-Attribut „required“ sorgt automatisch bei einem nicht ausgefüllten Wert für eine Kennzeichnung als ungültige Eingabe durch den Browser, das Attribut aria-required tut dies nicht. Genauso wird der Zustand der Gültigkeit einer Eingabe „invalid“ kommuniziert, indem entweder durch bestimmte input type-Attribute oder dem pattern-Attribut eine automatische Evaluierung der Gültigkeit der Eingabe durch den Browser durchgeführt wird (Beispiel: <input type=“email“ required />). All dies muss bei der Verwendung der Entsprechungen der WAI-ARIA-Attribute von Hand durchgeführt werden, also eine Evaluierung der Eingabe und das Setzen von aria-invalid auf „true“ oder „false“. Gerade auf Mobilgeräten haben die verschiedenen input-Typen sogar noch andere Vorteile, indem z. B. für number, email, url usw. entsprechend passende Tastaturen eingeblendet werden, und man bekommt die Validierung der Eingabe frei Haus gleich mit und braucht dafür dann kein WAI-ARIA mehr. Eine Veranschaulichung findet sich auch in diesem Blogbeitrag über HTML5- und WAI-ARIA-Formulare, den ich geschrieben habe, nachdem ich hierüber 2011 einen Vortrag beim Multimedia-Treff in Köln (Link zu Youtube-Video) gehalten habe.

Glücklicherweise kommt diese Message inzwischen sogar bei Branchenriesen an. Google Maps verwendet in der neuesten Version z. B. echte button-Elemente anstatt anklickbarer divs und spans. Dank an Christian Heilmann, dass er dies rausgefunden und bei einem Accessibility-panel auf der Edge Conf (Link zum Youtube-Video) im März 2014 hervorgehoben hat!

Hier ist eine Liste der WAI-ARIA-Rollen, für die es Entsprechungen in HTML gibt und wo diese HTML-Elemente verwendet werden sollten, wann immer dies möglich ist:

WAI-ARIA-Rolle Natives Element Bemerkungen
button button Verwendet type=“button“ wenn die Schaltfläche sich nicht wie eine submit-Schaltfläche verhalten soll
checkbox input type=“checkbox“
radiogroup und radio fieldset/legend und input type=“radio“ fieldset ist der Container, legend ist die Frage, auf die die Auswahlschalter die möglichen Antworten geben, und die input mit type „radio“ sind die eigentlichen Auswahlschalter
combobox select size=“1″ Einzige Ausnahme greift, wenn ihr ein wirklich reichhaltiges Widget baut. Aber selbst dann ist combobox ein Tretminenfeld, das seinen eigenen Blogbeitrag rechtfertigen würde.
listbox select mit size größer als 1 Einzige Ausnahme bildet das Erzeugen eines komplexen Widgets zur Autovervollständigung
option option als Kinder von select-Elementen oder solchen mit Rolle combobox oder listbox
list ul oder ol nicht zu verwechseln mit listbox! Bei list handelt es sich um eine nicht interaktive Liste wie eine unsortierte oder eine sortierte Liste. Diese sollten immer bevorzugt werden. Screen Reader bekommen auch Verschachtelungen im Normalfall prima geregelt.
spinbutton input type=“number“ Wenn der Browser diese bereits unterstützt.
link a mit href-Attribut Sollte nach meiner unmaßgeblichen Meinung niemals und unter keinen Umständen in einem HTML-Dokument verwendet werden!
form form Niemand, den ich kenne, kann mir schlüssig erklären, warum diese Rolle sich überhaupt in der Spezifikation befindet. Ich vermute, es hat mit SVG und vielleicht noch EPUB zu tun.

Der Grund für diese Duplizierung liegt darin, dass zum einen WAI-ARIA-Attribute nicht nur auf HTML, sondern auch auf SVG 2 und EPUB 3 angewendet werden können. Außerdem wurde WAI-ARIA ursprünglich zu einer Zeit entwickelt, als HTML 4.01 noch der vorherrschende Standard war und die Entwicklung von HTML5 ebenfalls erst begann. Die beiden Standards wurden dann parallel weiterentwickelt, und die HTML5-Entsprechungen bekamen, gerade bei den Attributen wie disabled, required usw. deutlich mehr vom Browser implementierte Funktionen hinzugefügt, die bei WAI-ARIA händisch nachgebildet werden müssen. Also sollten auch immer die HTML5-Attribute bevorzugt werden.

Eine Ausnahme hiervon tritt nur dann in Kraft, wenn ihr speziell noch HTML 4.01 oder gar XHTML 1.x bauen müsst. Dann müsst ihr aber eh die Validierung usw. von Hand einbauen. Bei HTML5 solltet ihr allerdings immer die Attribute disabled, required usw. verwenden anstatt der aria-disabled, aria-required, aria-invalid usw. Und ja, mir ist klar, dass ich hierin nicht mit einigen anderen Web-Zugänglichkeits-Experten übereinstimme, die empfehlen, grundsätzlich auch die WAI-ARIA-Attribute hinzuzufügen. Das Problem ist nämlich, dass dann trotzdem immer noch extra JavaScript-Code nötig ist, um die WAI-ARIA-Attribute mit den HTML5-Attributen und -Zuständen synchron zu halten.

Warum diese Verdoppelung? Warum kann der Browser nicht einfach auch auf die WAI-ARIA-Attribute so reagieren, wie er dies bei den HTML5-Attributen tut?

Diese Frage wird mir immer wieder gestellt. Die einfachste Antwort lautet: WAI-ARIA war nie dazu gedacht, das Verhalten des Browsers zu beeinflussen, sondern lediglich, um zusätzliche semantische Informationen an Hilfstechnologien weiterzugeben.Die längere antwortet lautet: WAI-ARIA-Attribute können auf HTML 4.01, XHTML 1.x und HTML5 angewendet werden. Die HTML5-Attribute können nur auf HTML5-Seiten angewendet werden und bringen eine ganze Palette von Browser-Funktionen mit, die in den Standards für diese Attribute definiert sind. Wenn die WAI-ARIA-Attribute auf einmal auch das Browserverhalten beeinflussen würden, wäre die Menge an Unstimmigkeiten enorm hoch. Um WAI-ARIA sauber zu halten, wurde irgendwann die Entscheidung getroffen, dass diese Attribute das Browserverhalten niemals und unter keinen Umständen beeinflussen mögen.

Wann sollte ich WAI-ARIA verwenden?

Wann immer ihr ein Widget baut, das nicht in der Gastgebersprache wie z. B. HTML beheimatet ist. Solche Widgets können z. B. Folgende sein:

  • tree mit treeitem Kindelementen. Dies sind Hierarchiebäume, wie man sie z. B. in der Ordnerliste des Windows-Explorer oder der Liste von Büchern und Hilfethemen in der Windows HTML-Hilfe findet.
  • menu mit Kindern menuitem, menuitemcheckbox oder menuitemradio: Dies ist ein echtes menüsystem, das man in vielen Windows- oder Mac-Desktop-Programmen findet.
  • grid oder treegrid mit Kindelementen gridrow, columnheader, rowheader und gridcell: Eine bearbeitbare Tabelle wie in einem Tabellenkalkulationsprogramm. Dies nicht verwechseln mit Datentabellen, für die native Elemente wie table, tr, th und td mit scope- und anderen Attributen verwendet werden müssen.
  • toolbar: Ein Container mit Kindelementen wie buttons oder anderen interaktiven Elementen.
  • dialog: Ein modaler Dialog, der auf die eine oder andere Weise geschlossen werden muss. Solange er geöffnet ist, ist keine Interaktion mit dem Rest der Seite möglich. Die Rolle alertdialog ist verwandt, ich empfehle ihre Benutzung jedoch nicht, da die Unterstützung hierfür sehr inkonsistent ist.
  • application: Eine Webapplikation, in der die Tastatur und sätmliche Elemente vollständig vom Webentwickler kontrolliert werden und keine Standard-Dokumentnavigation gewünscht ist. Wann und wie diese zu benutzen ist und wann nicht, habe ich in einem Blogbeitrag zur Rolle application ausführlich beschrieben.

In allen oben erwähnten Fällen liegt es in eurer Verantwortung:

  1. euch mit den erwarteten Interaktionsmuster für Maus und Tastatur vertraut zu machen.
  2. sicherzustellen, dass alle Elemente mit der Tabulator-Taste erreichbar sind und der Tastaturfokus immer sichtbar ist. Verwendet das Attribut tabindex mit dem Wert 0, um Elemente, die normalerweise mit der Tastatur nicht erreicht werden können, an ihrer natürlichen Position im Dokumentverlauf einzufügen.
  3. Ausnahmen von dieser Regel zu implementieren, um die Tastaturnavigation effizienter zu gestalten. So empfiehlt es sich z. B., auf Symbolleisten zu landen, die einzelnen Elemente innerhalb einer solchen aber nicht unbedingt mit Tab anzuspringen, sondern hierfür Pfeil rechts und links zu verwenden. Tab sollte statt dessen zum nächsten Container, z. B. der nächsten Symbol- oder Menüleiste, springen. Escape sollte die Symbolleiste verlassen und in den Hauptbereich der Anwendung zurückkehren. Analog sollten einzelne Tabs mit Pfeil links und rechts ausgewählt werden und die Tab-Taste direkt ins Tabpanel selbst springen.
  4. den Fokus immer unter Kontrolle zu haben. Wenn ihr z. B. ein Dialogfeld öffnet (Rolle „dialog“), ist es eure Aufgabe, den Fokus auf das Dialogelement selbst oder sein erstes fokussierbares Element zu stellen. Weiterhin müsst ihr dafür sorgen, dass man mit Tab nicht aus diesem Dialogfeld „entkommen“ kann, die Interaktion also definitiv modal ist. Escape sollte ein Dialogfeld in der Regel ohne Änderungen schließen, und es sollte ein OK/Speichern/Akzeptieren-Button vorhanden sein, der das Dialogfeld schließt und Änderungen übernimmt. Nachdem das Dialogfeld geschlossen wurde, müsst ihr den Fokus wieder auf ein definiertes Element außerhalb stellen, z. B. den Button, der das Dialogfeld ursprünglich öffnete, damit der Fokus nicht irgendwo im Nirvana landet.

Wenn ihr euch nicht an die Interaktionsmuster haltet, die die mit bestimmten Rollen assoziiert werden, kann euer WAI-ARIA-Zuckerguss sehr schnell zu saurer Milch werden, nämlich genau dann, wenn die vom Anwender erwarteten Interaktionen mit der Tastatur nicht funktionieren. Ich empfehle hierzu dringend das Studium der WAI-ARIA 1.0 Authoring Practices. Diese sollten auch als Referenz für später immer griffbereit liegen. Sie enthalten eine nützliche Zusammenstellung der Rollen und ihnen zugeordnete Attribute und wie die Interaktionsmuster für viele Widget-Typen aussehen. Ein weiteres Dokument, das ich auch immer für die Hinterhand empfehle, ist das schon einmal erwähnte Dokument „Using WAI-ARIA in HTML„. Dieses enthält ebenfalls eine ausführliche, aber gut verständliche Zusammenstellung von Regeln und Empfehlungen, wie WAI-ARIA am besten einzusetzen und wann von seinem Einsatz abzusehen ist.

Schlussbemerkungen

Mir ist sehr wohl bewusst, dass das Thema Barrierefreiheit im Web für jemanden, der damit gerade erst anfängt, sehr erschlagend wirken kann. Erinnert euch aber bitte daran, dass ihr auch mal mit HTML, CSS und JavaScript klein angefangen habt und euch das Thema zuerst überrumpelt hat. Die Routine kommt mit der Zeit. Genauso wie HTML, CSS und JavaScript zu einem Selbstläufer wurden, wird auch das inklusive Denken bald in Fleisch und Blut übergegangen sein und das Hinzufügen der entsprechenden Techniken wie von Selbst von der hand gehen. Und ganz wichtig: Keine falsche Scham beim Stellen von Fragen! Die Accessibility-Gemeinde ist in der Regel sehr hilfsbereit und freundlich.

Und noch ein Aspekt ist wichtig für die Motivation, der dankenswerterweise immer häufiger auch in Artikeln und Vorträgen genannt wird: Barrierefreiheit geht Hand in Hand mit Benutzbarkeit. Sobald die Benutzbarkeit für Maus, Tastatur und das Einhalten bestimmter visueller Regeln getan sind, sind schon mindestens 80% der Anforderungen für Barrierefreiheit erreicht. Ein großartiger Tipp für das Einhalten bestimmter Kontrasttiefen stammt von Eric Eggert: Stellt euch mit eurem schönen Tablet oder Handy mal in die Sonne und schaut, ob ihr eure eigene Webseite noch lesen könnt! 🙂

Und bei Benutzbarkeit und Barrierefreiheit geht es in allererster Linie um die Menschen, die eure Webseite oder Applikation benutzen können sollen. Erst dann kommt irgendwann eine WCAG-Checkliste oder eine gesetzliche Vorgabe, die es zu erfüllen gilt. Vergegenwärtigt euch immer, dass ihr dies für Menschen macht. Sobald die das benutzen können, was ihr da gebaut habt, kommt das Erfüllen von WCAG-Kriterien und gesetzlichen Vorgaben ganz automatisch.

Macht WAI-ARIA also zu einem Werkzeug in eurer Werkzeugkiste der Webentwicklung, das ihr benutzt, wenn ihr es müsst, und das ihr weg lasst, wenn andere Werkzeuge die Arbeit viel besser erledigen können. Sobald die Tastaturbedienbarkeit da ist, braucht es nur noch bestimmte semantische Erweiterungen bei bestimmten Szenarien, und der Job ist erfolgreich erledigt! Und immer daran denken: Der Mensch kommt zuerst!

Viel Spaß beim Coden!

Kategorien
Android Apple ARIA Firefox Microsoft NVDA Zugänglichkeit

Office für Blinde: Altbekanntes und neue Entwicklungen

Ausgelöst durch die am 14.01.2014 erfolgte Ankündigung von Microsoft und GW Micro, den Screen Reader Window-Eyes in Zukunft für Office-Anwender kostenlos zur Verfügung zu stellen, habe ich mich mal umgeschaut, was es im Moment so an gängigen Office-Lösungen gibt und wie zugänglich diese für Blinde sind. Zugängliche Office-Anwendungen sind gerade im beruflichen Umfeld immer noch einer der wichtigsten Faktoren, die über einen Arbeitsplatz oder die Arbeitslosigkeit entscheiden können.

Microsoft Office

Der Branchenprimus ist ganz klar weiterhin Microsoft mit seinem Office-Paket. Dabei bin ich auf eine sehr spannende Entwicklung gestoßen, nämlich Microsofts Abonnement-Modell Office 365. Als Privatanwender bekommt man hier für 10 Euro im Monat oder 99 Euro pro Jahr ein Paket, das ein vollwertiges Office Professional für Windows und Mac enthält sowie Zugang zu den Office Web Apps, die in Microsoft SkyDrive integriert sind als auch zu ihren mobilen Anwendungen für iOS und Android. Man wird stets auf dem aktuellen Stand gehalten. Selbst wenn Microsoft im Abozeitraum also eine neue große Version herausbringt, hat man sofort Zugriff drauf, ohne extra etwas bezahlen zu müssen. Und das beste: man kann es einen Monat kostenlos testen! Wenn man sich also überlegt, dass allein die Home & Student 2013 Edition, die wesentlich weniger Apps enthält, schon 139 Euro kostet und ein vollwertiges Office Pro mit fast 550 Euro zu Buche schlägt, ist das ein echt attraktives Angebot. Und der Clue: man darf das Office auf bis zu fünf Rechnern im eigenen Haushalt installieren, und diese Rechner dürfen Windows-PCs oder Mac-Computer sein. Zusätzlich kann man die Office-Apps auf bis zu fünf mobilen Geräten an einen Account anmelden. Die Web-Anwendungen sind von überall her zugänglich. Selbst ein Office-Streaming-Angebot gibt es: Man streamt es auf einen Rechner, und sobald man die App zumacht, entfernt sie sich wieder, angeblich rückstandsfrei. Das ist aber, je nach Internetverbindung, eine Option, die mitunter recht viel Geduld erfordert. Ich halte Office 365 für die mit Abstand wirtschaftlichste Möglichkeit, ein Office zu nutzen, die es für MS Office heute gibt. (Hinweis: Microsoft bezahlt mich nicht für diese Schwärmerei, und auch sonst bekomme ich von niemandem Geld dafür. 😉 )

Und eben ein solches lokal installiertes Office berechtigt in Zukunft zur Nutzung von Window-Eyes, ohne dies extra erwerben zu müssen. Voraussetzung ist der auch auf deutsch verfügbare Download der Version von der oben verlinkten Webseite. Aber Window-Eyes ist nicht die einzige Lösung, die mit diesem Office läuft. Zur Zeit ist dies Version 2013. NVDA und JAWS machen hier eine ebenso gute Figur. Wer JAWS kennt, weiß, wie gut der Office-Support ist. Und NVDA hat im letzten Jahr verdammt viel dazugelernt, was die Unterstützung von Word & Co. angeht. Da NVDA kostenlos ist, lohnt sich definitiv ein Vergleich! Ich empfand das Arbeiten mit NVDA in Office durchaus als deutlich zuverlässiger und schneller als mit Window-Eyes. Besonders bei der Benutzung einer Braillezeile hinkt WE z. B. sehr, wenn man in Word nur zeilenweise auf und ab navigiert.

Und weil ich in einem anderen Blogbeitrag speziell nach Narrator gefragt wurde: Narrator bietet keine wirklich ernstzunehmende Office-Unterstützung. Es sind keine Features wie das Lesen von Fußnoten, Rechtschreibfehlern im Dokument, Revisionen o. ä. verfügbar. Auch in Excel sieht man quasi gar nichts. Auch aus diesem Grund kommt man also mit einem RT-Tablet nicht weiter, sondern sollte für Windows 8.1 immer ein richtiges Intel-System nehmen, um einen besseren Screen Reader installieren zu können. Weitere Ausführungen finden sich im verlinkten Beitrag.

Unter OS X sieht die Situation leider nicht ganz so rosig aus. Die hier aktuelle Version Office für Mac 2011 hat zwar zugängliche Symbolleisten und Menüs, der eigentliche Dokumentbereich in Word ist mit VoiceOver aber z. B. gar nicht auslesbar. Ein Bearbeiten von Dokumenten ist hier de facto nicht möglich. Outlook geht so leidlich, aber hier muss Microsoft definitiv noch einmal nachbessern!

Die iOS und Android Apps für Office Mobile sind eher keine echten Produktivwerkzeuge für VoiceOver- bzw. TalkBack-Anwender. Unter iOS z. B. ist der Dokumentbereich nicht erfassbar, und Symbolleisten erscheinen und verschwinden quasi nach Belieben. Unter Android kommt man eventuell weiter, wenn man über die SkyDrive-App Word-Dokumente in Googles QuickOffice-App öffnet, da kann man wenigstens was lesen. Unter iOS kann Pages mit Word-Dokumenten umgehen. Mehr dazu weiter unten.

Und jetzt kommt die Überraschung schlechthin: Eigentlich hatte ich mich zuerst gar nicht mit der Webversion von Office beschäftigen wollen, nachdem sowohl Google Docs als auch iWork für iCloud eher sehr traurige Beispiele von Zugänglichkeit sind (siehe unten). Doch wie überrascht war ich, als ich dann doch ein Dokument über SkyDrive erstellte! Die Webversion von Word & Co. ist in sehr vielen Belangen als echt zugänglich zu bezeichnen! Ich testete dies mit Firefox und IE unter Windows 7 und 8.1, sowohl mit NVDA, JAWS und Window-Eyes. Man bekommt sowohl den Text auf der Braillezeile zu lesen, als auch grundlegende Formatierungsinformationen. Die Ribbon-Symbolleisten sind voll zugänglich und sprechen dank der ordentlichen Implementierung von WAI-ARIA mit NVDA zusammen vollständige Informationen, so dass man immer weiß, wo man ist. JAWS und Window-Eyes schwächeln hier etwas, da sie immer nur das im Focus befindliche Element sprechen, nicht aber eventuelle Informationen zur Zugehörigkeit eines Gruppenfeldes. So kann man mit NVDA wunderbar den Übergang von einer Schleife in die nächste mitbekommen, mit JAWS und WE hingegen nicht. JAWS war bei allen Tests mit NVDA fast gleich auf, Window-Eyes hinkte bei allem sehr hinterher. Trotz ausgeschaltetem Browse-Modus wurde vieler Text nicht gelesen oder auf der Zeile angezeigt, der Focus ging oft verloren usw. Der verwendete Browser war hierbei unerheblich. NVDA schwächelte im IE, das Navigieren in Dokumenten ist dort sehr langsam. Die beste Kombination von Screen Reader und Webbrowser für Office im Web sind Firefox und NVDA.

Unter OS X kommt VoiceOver mit Safari mit den Web-Apps von Office nicht wirklich zurecht. Man sieht die erste Zeile oder den ersten Absatz eines bestehenden Dokuments, das Betätigen der Pfeiltasten bewirkt aber nur Schweigen. Nur wenn man selbst was neues hinzufügt, kann man dies eventuell kurzzeitig lesen. Auch VoiceOver spricht in den Symbolleisten nur das aktuelle Element, die Gruppeninformationen werden auch hier nicht gesprochen.

Auf dem iPad ist die Situation sehr ähnlich. Hier habe ich es nicht einmal geschafft, in den Bearbeitungsmodus zu kommen, um eventuell einem Dokument etwas hinzuzufügen. Die Symbolleisten wurden hingegen ähnlich gelesen wie auf dem Mac.

Unter Android wird dem Firefox leider nur eine Dokumentversion zum Lesen und ein Seitenzahlenanzeiger gegeben. Will man die Desktop-Version abrufen, bekommt man die Hauptseite von office.com zu sehen.

Apropos Dokumentenanzeige: Microsoft empfiehlt in seiner Anleitung zur Benutzung der Barrierefreiheitsfunktionen von Office im Web, ein Dokument als PDF zu exportieren und dieses mit dem Adobe Reader zu lesen. Und das ist eine prima Idee, denn Microsoft erzeugt hier standardmäßig ein PDF mit Tags für die Zugänglichkeit. Und die Umsetzung ist ziemlich gut!

Man kann hier also mit Fug und Recht behaupten, dass Microsoft vorbildliche Arbeit abgeliefert haben, was die Zugänglichkeit seiner Office-Lösung für den Webbrowser angeht. Die Tatsache, dass man mit Firefox und NVDA sehr gut klarkommt, heißt, dass andere Hersteller hier noch nachzuarbeiten haben. Wäre das Geschwindigkeitsproblem nicht, würde NVDA im Internet Explorer mit Sicherheit genauso gut mit Office zusammenarbeiten.

Und dass gerade Microsoft hier so gute Arbeit abgeliefert hat, erfüllt mich, der ich seit über sechs Jahren mithelfe, WAI-ARIA zu entwickeln und dabei besonders auf die Benutzung durch Endanwender achte, mit ziemlichem Stolz! Denn nachdem ich neulich über dieses Thema auf englisch bloggte, schrieb ein Kommentator, dass er ähnlich gute Ergebnisse auch mit Firefox und Orca unter Linux erzielen konnte. Nutzt Webstandards, und ihr könnt wahre Wunder bewirken! 🙂

Google Docs

Von diesem Zustand sind Google mit seiner verbreiteten Cloudlösung Docs noch weit entfernt. Auch Google Docs implementiert zwar WAI-ARIA, und die Menüs und Symbolleisten laufen inklusive Tastaturnavigation auch echt OK, das Bearbeiten von Dokumenten ist allerdings ein echtes Problem. Google haben sich dafür entschieden, alle gesprochenen Dinge als sogenannte Live-Region einfach in den Screen Reader zu kippen. Jede Cursorbewegung, jeder Zeilenwechsel und andere Informationen werden als flüchtige Nachricht einfach an die Sprachausgabe gesendet und verpuffen danach im Nirvana. Man kann weder mit der Braillezeile kontrollieren, was man geschrieben hat, geschweige denn mit Cursorrouting im Text navigieren, noch kann man die aktuelle Zeile nochmals vorlesen lassen. Auch das Abfragen von Formatierungsinformationen geht nur, indem man hübsch von Hand in die Symbolleisten wandert und sich die Infos dort zusammensucht oder eine Taste drückt, die ausgewählte Infos einmal an die Sprachausgabe schickt. Ja, man kommt damit vielleicht irgendwie klar, wenn man nur die Sprachausgabe nutzt und sich um Braille nicht schert. Ich finde aber: Schön geht anders!

Apple iWork

Apple haben im vergangenen Oktober bei einer großen Keynote angekündigt, die Office-Anwendungen Pages, Numbers und Keynote, auch unter dem Sammelbegriff iWork bekannt, in Zukunft mit jedem neuen Mac oder iOS-Gerät kostenlos abzugeben. Die Apps waren auch vorher schon nicht mehr teuer. Aber das war schon eine ziemliche Sensation. Gleichzeitig wurden von allen Programmen, die es sowohl für Mac OS X als auch für iOS gibt, neue Versionen veröffentlicht. Die für die Software-Branche lange Wartezeit von fast fünf Jahren seit dem letzten Update der Mac-Version hat sich gelohnt! iWork ist unter OS X Mavericks (unter früheren Versionen läuft diese neue Version nicht) die mit Abstand zugänglichste Office-Lösung. Alle Kritikpunkte, die es bis dahin von VoiceOver-Anwendern gab, wurden beseitigt. So kann man jetzt auch in Pages-Dokumenten Tabellen lesen und erstellen, und seit einem Update aus dem Januar 2014 auch Präsentationen in Keynote selbstständig ablaufen lassen, nicht nur bearbeiten.

Unter iOS waren die Programme ebenfalls schon immer sehr gut, haben aber mit der neuen Version, die ab iOS 7.0 läuft, auch noch einmal richtig zugelegt. Auch hier ist das Erstellen von Tabellen und anderen weitreichenden Formatierungen auf dem iPad voll mit VoiceOver zugänglich, man bekommt in Keynote Infos über Präsentationseffekte o. ä. nicht nur angesagt, sondern kann sie auch bearbeiten, und auch mit dem iPad sind Präsentationen vollständig selbst vortragbar. Auch Numbers, die Tabellenkalkulation, ist wesentlich besser geworden. Alle Programme können mit Microsoft-Office-Dokumenten umgehen, so dass hier ein Austausch möglich ist. Dokumente werden standardmäßig in iCloud gespeichert und sind somit immer auf dem neuesten Stand. Andere Cloud-Dienste werden von der iOS-Version nicht unterstützt, die Mac-Version kann natürlich Dateien auch lokal speichern, z. B. in einem Dropbox-Ordner.

Der PDF-Export erzeugt keine getaggten PDF-Dokumente, und es gibt auch keine Option, dies einzustellen.

Die Webversion von iWork, genannt iWork für iCloud, lernt erst seit einem Update von Mitte Januar 2014 ein wenig Barrierefreiheit. Und auch hier ist das Problem, dass gesprochene Inhalte per Live Region einfach an den Screen Reader gesendet werden. Auch ist die Implementierung bisher sehr rudimentär, aber dass sich was tut, lässt hoffen, dass da noch mehr kommt. Produktiv einsetzbar ist das jedenfalls noch nicht.

OpenOffice und LibreOffice

Die Open-Source-Anwendung OpenOffice und der ebenfalls quelloffene Ableger LibreOffice bieten ein sehr uneinheitliches Bild, was die Barrierefreiheit angeht. Unter Linux mit Orca läuft es anscheinend sehr anständig. Ich hatte in der Kürze der Zeit kein aktuelles Linux zur Verfügung, höre aber eigentlich nur Gutes aus der Community.

Unter Windows ist OpenOffice und LibreOffice bis jetzt, d. h., einschließlich der Version 4.0, nur mit Hilfe der Java AccessBridge nutzbar. NVDA haben viel Zeit investiert, um es halbwegs zugänglich zu machen, andere Screen Reader laufen von Version zu Version mal schlecht, mal weniger gut. Das alles wird sich aber mit der Version 4.1, die sich in Entwicklung befindet, radikal ändern. OpenOffice, und damit vermutlich dann auch LibreOffice, erben nämlich die Implementierung der Zugänglichkeitsschnittstelle IAccessible2, welche eine Fortentwicklung von Microsoft Active Accessibility durch IBM, Mozilla, NVDA und anderen ist. IBM hatte seinerzeit als Referenzimplementierung seine auf einem älteren OpenOffice basierende Suite Lotus Symphony zugänglich gemacht und diesen Code dann später dem OpenOffice-Projekt gespendet. Lotus Symphony gibt es inzwischen nicht mehr bzw. es wird nicht weiterentwickelt, und der Code von damals ist nun endlich soweit aktualisiert und an das aktuelle OpenOffice angepasst, dass es in Version 4.1 zum Release kommt und die Java-Technologie ablöst. Ich habe einen Entwicklersnapshot mit NVDA getestet, und das Teil ging ab wie eine Rakete! Tolle Infos, sehr schnelle Reaktionszeiten, die Braillezeile läuft mit. Sobald das veröffentlicht ist, ist OpenOffice eine echte Alternative zu Microsoft Office unter Windows.

Unter OS X sieht die Situation für OpenOffice leider nicht ganz so gut aus. Die Implementierung für VoiceOver ist zwar vorhanden, aber man hat das Gefühl, dass sie in einer früheren bis mittleren Beta-Phase steckengeblieben ist und sich seit Jahren nichts mehr tut. Es ist relativ instabil, ich hatte bei meinen Versuchen mit mehreren Abstürzen bei einfachsten Aktionen zu kämpfen. Hier ist zu hoffen, dass sich da bald mal wieder ein paar Mac-Entwickler der Situation annehmen und den VoiceOver-Support zu Ende implementieren. Denn auch Pages & Co. tut eine Alternative nur gut! Es gibt unter OS X zwar noch weitere zugängliche Alternativen wie den Nisus Writer Pro. Diese sind aber reine Textverarbeitungen, keine Tabellenkalkulation oder Präsentationssoftware.

Auch OpenOffice und LibreOffice können getaggte PDFs erzeugen. Diese muss man allerdings zunächst in den Optionen zum PDF-Export aktivieren. Standardmäßig ist der PDF-Export also ohne Zugänglichkeit.

Fazit

Unter OS X und iOS kommt man zur Zeit an Apples eigenem Angebot nicht vorbei, wenn man Office-Anwendungen nutzen will oder muss. Voraussetzung ist aber der Einsatz von OS X 10.9 Mavericks und iOS 7.0 oder neuer. Ältere Betriebssystemversionen werden in beiden Fällen nicht unterstützt. Unter Windows ist am Horizont mit OpenOffice und hoffentlich LibreOffice eine echte Alternative zu Microsoft Office zu erkennen. Und im Web besticht ganz klar Microsoft mit seiner wirklich hervorragenden Implementierung von Zugänglichkeitsstandards, die es sogar unter Linux sehr zugänglich machen! Google und Apple haben hier definitiv noch ganz viel Luft nach oben!

Kategorien
ARIA Zugänglichkeit

Wenn ihr die WAI-ARIA-rolle application verwenden wollt, tut dies mit Vorsicht!

Dieser Blogeintrag richtet sich an alle LeserInnen dieses Blogs, die Webapplikationen mit fortgeschrittenen Widgets und angereicherten Inhalten in HTML, CSS und JavaScript entwickeln. Wenn ihr vorhabt, die WAI-ARIA-Rolle „application“ zu verwenden, haltet inne und überlegt zweimal, ob ihr sie wirklich braucht! Und hier kommt wieso:

Was ist das?

„application“ gehört zu den WAI-ARIA landmark roles, also Rollen, die bestimmte Navigationspunkte in Webdokumenten setzen. Sie wird dazu verwendet, Teile einer Webapplikation auszuzeichnen, die wie eine Desktopanwendung behandelt werden sollen, nicht wie ein Dokument im Web. Wenn ihr also Webapplikationen baut, die aus ungefähr über 90% Widgets bestehen und auch ansonsten keine Ähnlichkeit mit einer herkömmlichen Webseite haben, könnte die Benutzung von „application“ angemessen sein. Wenn ihr im Gegensatz dazu aber eine Benutzeroberfläche baut, die aus klassischen Eingabeelementen wie Textfeldern, Kontrollfeldern, Ausklapplisten usw. besteht und darüber hinaus weit verbreitete komplexere Widgets vorkommen, und eure Seite ansonsten aus dokumentüblichen Strukturen wie Hyperlinks besteht, lasst die Finger von role „application“! Screen Reader und andere assistive Technologien, die WAI-ARIA unterstützen, wissen in der Regel mit solchen Elementen automatisch richtig umzugehen.

Warum sollte ich sie überhaupt verwenden?

Klassischerweise wandeln assistive Technologien wie Screen Reader für Blinde Webseiten in ein Ausgabeformat um, das für diese Zielgruppe einfacher zu verstehen ist. Ein zweispaltiger Text im Zeitungsstil wird in ein einspaltig vom Beginn bis zum Ende fließendes Dokument umgewandelt. Mehrspaltige Seitenlayouts werden so verschlankt, dass sie einen logischen Fluss bilden und für jemanden, der den Bildschirm nicht sehen kann, erfassbar werden, ohne dass es ein großes Durcheinander an Informationen gibt.

Um dies zu erreichen, haben assistive Technologien, speziell unter Windows, ein zweistufiges Interaktionsmodell entwickelt:

virtueller Cursor oder Browse-Modus
Dies ist der Modus, in dem Screen Reader operieren, wenn sich der Benutzer eine Webseite anschaut. Der Begriff virtueller Cursor wird seit seiner Erfindung im jahr 1999 verwendet und bedeutet, dass der Benutzer eine Webseite mit den Pfeiltasten durchlaufen kann als würde er ein MS-Word- oder Editor-Dokument lesen. Neben dem eigentlichen Text werden semantische Informationen vorgelesen wie ob ein Element ein Link, eine Schaltfläche, Teil einer Datentabelle, ein Formularelement ist usw. Weiterhin werden auch viele Tastatureingaben abgefangen und nicht an den Browser weitergegeben. Diese werden dazu verwendet, sich innerhalb solcher virtueller Dokumente schnell zu bestimmten Elementen zu bewegen wie Überschriften, Formularelementen, Links, Listen, Tabellen usw. Dies wird üblicherweise durch den Druck auf einzelne Buchstaben erreicht. Der visuelle Fokus kann sich dem aktuellen Element, auf das der virtuelle Cursor zeigt, angleichen, wenn dieses den Fokus erhalten kann, muss dies aber nicht zwangsläufig tun; das hängt von der Implementierung und manchmal auch den Einstellungen des verwendeten Screen Readers ab.
Formular- oder Fokus-Modus
Dieser Modus ist aktiv, wenn der Anwender mit Elementen interagiert, die irgendeine Form von Dateneingabe akzeptieren. Dies kann eine Texteingabe, das Umschalten eines Kontrollfeldes, die Auswahl eines bestimmten Auswahlschalters (radio button) oder die Auswahl in einer Ausklappliste sein. Um in diesen Modus zu gelangen, steuert der Anwender den virtuellen Cursor auf ein solches Element und drückt entweder Eingabe oder der Screen Reader aktiviert bei Erreichen eines solchen Elements den Fokus-Modus automatisch. Andere Screen Reader aktivieren diesen Modus z. B. aber nur dann, wenn explizit mit tab auf so ein Element gesprungen wird. In diesem Modus werden alle tastatureingaben an den Browser durchgereicht. Es ist so als wenn ihr ohne Screen Reader vor eurem Browser sitzt und ihn mit der Tastatur bedient. Analog wird dieser Modus wieder abgeschaltet, wenn man entweder eine Taste wie escape drückt oder der Anwendungsfokus so ein Element wieder verlässt und der Screen Reader diesen Modus vorher selbstständig eingeschaltet hatte. Es wird zum virtuellen Cursor/Browse-Modus zurückgekehrt. Hinweis: Einige Elemente wie Schaltflächen und Links benötigen das Einschalten des Fokus-Modus nicht, weil sie vom Screen reader direkt aktiviert werden können und man so eine Zeitersparnis erreicht.

Die Herausforderung besteht darin, dass ihr vielleicht Widgets erstellt, die ein Erzwingen des Fokus-Modus erforderlich machen. Voraussetzung ist, dass euer Widget am besten benutzt werden kann, wenn sich der Screen Reader nicht im Browse-Modus befindet. Voraussetzung ist weiterhin, dass die Applikation so gut wie keine klassischen Dokumentinhalte enthält, und dass alle Widgets, die vorhanden sind, den nötigen Kontext bereitstellen. Als Faustregel sind hier 90 oder 95 Prozent ansetzbar. Dann, und nur dann, ist ein Einsatz der Rolle „application“ sinnvoll. Ihr habt nämlich in diesem Moment die kontrolle darüber, dass der Anwender in den Fokus-Modus gezwungen wird, und es liegt in eurem Verantwortungsbereich, ein vernünftiges Tastaturinteraktionsmodell zu entwickeln und auch die Rückkehr in den Browse-Modus zu ermöglichen. Im Gegensatz zum normalen Fokus-Modus bewirkt die Rolle „application“ nämlich, dass man nicht so einfach wieder zum Browse-Modus zurückkehren kann, um sich z. B. die umliegenden Informationen des Dokuments durchzulesen.

Wann soll ich sie denn nun verwenden, und wann nicht?

Ihr verwendet die Rolle „application“ nicht, wenn ihr eine Benutzeroberfläche baut, die nur aus in HTML eh schon vorhandenen Widgets besteht. Das gilt auch für Widget-Klone, die ihr aus WAI-ARIA-Rollen und eigenem Tastaturinteraktionsmodell zusammenbaut:

  • Textfelder inklusive Passwortfeldern, Suchfeldern, Telefonnummern, E-Mail und anderen neuen input-Typen.
  • Mehrzeilige Textfelder (textarea)
  • Kontrollfelder (checkbox)
  • Schaltflächen (button)
  • Auswahlschalter (radio button), die normalerweise in ein Konstrukt aus fieldset und legend eingefasst sind
  • Ausklapplisten (select und option)
  • Links, Absätze, Überschriften und andere Strukturen, die es nativ in klassischen Dokumenten im Web gibt.

Ihr verwendet sie ebenfalls dann nicht, wenn eure Benutzeroberfläche dynamische, fortgeschrittene Widgets der folgenden Typen enthält. Screen Reader und andere assistive Technologien, die WAI-ARIA unterstützen, unterstützen bei diesen standardmäßig ein Umschalten zwischen Browse- und Fokus-Modus analog zu nativen HTML-Widgets.

  • Strukturansicht tree view)
  • Schieberegler slider)
  • Tabellen, die fokusierbare Elemente enthalten wie eine Liste von E-Mail-Nachrichten, interaktive Gitter und Gitterbäume usw. grid, treegrid)
  • Eine Liste von Reitern tab, tablist), bei denen der Anwender mit den Pfeiltasten rechts und links einen Reiter wählt. Beachtet, dass ihr hierfür das Tastaturverhalten implementieren müsst!
  • Dialogfelder und Hinweisdialogfelder dialog, alertdialog). Diese werden von Screen Readern implizit als Anwendungsbereich behandelt, sobald sich der Fokus zu einem in ihnen enthaltenen Element bewegt. Hinweis: Diese verhalten sich am besten, wenn dem Element, das die Rolle „dialog“ oder „alertdialog“ enthält, das Attribut aria-describedby gegeben wird, dessen Wert auf die ID desjenigen Kindelements verweist, das den erklärenden Text enthält. Dadurch wird dieser Text automatisch vom Screen Reader vorgelesen, bevor das Element mit Fokus gesprochen wird.
  • Symbolleisten und deren Elemente, Menüs und deren Menüeinträge toolbar, menu, menuitem) und ähnliche

Ihr solltet die Rolle „application“ nur dann verwenden, wenn eure Benutzeroberfläche zum größten Teil aus interaktiven Widgets, und hier vornehmlich aus fortgeschrittenen, nicht nativen Widgets, besteht, sich wie eine Desktopanwendung verhält und keine klassischen Dokumentinhalte enthält. Beachtet, dass, obwohl sich heute vieles Webapplikation nennt, das meiste davon unter der Haube doch weiterhin dokumentenbasierte Daten darstellt. Facebook-Statusnachrichten und deren Kommentare, Twitter-Zeitleisten, Blogartikel,selbst viele Akkordeons, die dynamisch Inhalte ein- und ausblenden können, sind in der Regel so stark dokumentenorientiert, dass die Rolle „application“ hier völlig unangemessen wäre und das Benutzen und Lesen der Informationen nur behindern würde. Wir arbeiten im Web weiterhin primär mit Dokumentstrukturen, obwohl an der Oberfläche vieles inzwischen aussieht wie eine Desktopanwendung.

Kurz gesagt: Die Fälle, in denen die Rolle „application“ wirklich zur Benutzung angemessen ist, dürften sehr rar gesäht sein!

Wo packe ich es denn hin?

Setzt die role auf das nächstgelegene Elternelement eurer Widgets, z. B. das sie umschließende div-Element. Wenn nämlich nur die Widgets eingeschlossen werden, die dieses Applikations-Interaktionsmodell wirklich benötigen, wird so sichergestellt, dass der Browse-Modus wieder eingeschaltet wird, sobald der Fokus diesen als „application“ gekennzeichneten Bereich verlässt.

Setzt das Attribut nur dann auf das body-Element, wenn die gesamte Applikation zu ca. 95% Elemente enthält, die den Fokus-Modus benötigen. Sollte es hierin auch Teile geben, die als Dokument behandelt werden müssen, nutzt für diesen Bereich die Rolle „document“. Sie ist das Gegenstück zur Rolle „application“. Zusätzlich müsst ihr durch setzen des tabstop-Attributes sicherstellen, dass der Fokus in diesen als Dokument ausgezeichneten Bereich gelangen kann, wenn der Nutzer mit tab durch eure Webapplikation navigiert.

In einem solchen Fall, wo 90 oder 95 Prozent eurer Inhalte Widgets sind, kann das Benutzen der Rolle „application“ angemessen sein. Aber selbst dann solltet ihr jemanden finden, der eure Anwendung in zwei Versionen testen kann, einmal mit und einmal ohne die Rolle „application“, um herauszufinden, ob dieses Interaktionsmodell wirklich die beste Lösung darstellt.

Setzt das Attribut NIEMALS auf so ein Element wie body, wenn eure Seite weitgehend aus traditionellen Widgets oder Dokumentinhalten besteht. Dies führt nur zu Frustration und schlechter Benutzbarkeit eurer Seiten!

Einige Beispielseiten

Die Seite, die mich dazu veranlasste, diesen Artikel zu schreiben, ist die neueste Version des Googlemail-Layouts. Google behandelt das ganze Teil als „application“, so dass man zig dutzendmal tab drücken muss, um zur Tabelle mit den Mails des Posteingangs zu gelangen. Hätten sie die Rolle richtig eingesetzt, bräuchte der Anwender nur die Taste t in seinem Screen Reader zu drücken und stünde sofort auf der Tabelle mit den Nachrichten, anstatt 30 oder 40mal tab drücken zu müssen. Ja, Google statten uns mit den Tasten j und k aus. Abgesehen davon, dass man über diese erst einmal bescheid wissen muss, funktionieren sie aber nur in der Kombination Chrome und ChromeVox. In allen anderen Browsern und Screen Readern wird zwar der visuelle Fokus verschoben, es wird jedoch kein echter Fokus auf das Zielelement gesetzt, so dass dieser Fokuswechsel für Screen-Reader-Anwender unbemerkt bleibt. Anders als Google es uns glauben machen will, ist Googlemail unter der Haube immer noch weitestgehend eine dokumentenbasierte Anwendung, in der viele traditionelle Navigationsmodelle uneingeschränkt gültig sind und die Rolle „application“ völlig unangemessen ist.

Ein Beispiel, in dem die Rollen „application“ und „document“ tatsächlich richtig angewandt werden, ist das aktuelle Yahoo!-Mail-Interface. Die Nachrichtenliste befindet sich in einem Bereich, der als „application“ gekennzeichnet ist. Man navigiert mit den Pfeiltasten durch die Nachrichten und öffnet sie mit Eingabe. Der Nachrichtenbereich selbst ist, während alles rundherum eine „application“ ist, ein „document“, in dem die Kopfzeilen und der Nachrichtentext angezeigt werden. Hier wird auch der Fokus hingesetzt, so dass der Screen Reader automatisch in den Browse-Modus schaltet und der Anwender die Mail sofort in vertrauter Umgebung lesen kann.

Scherzhafter disclaimer: Yahoo! bezahlen mir kein Geld dafür, dass ich sie dauernd bewerbe und darauf hinweise, wie gut ihnen das Mail-Webinterface gelungen ist. Sie haben nur ein verdammt gutes Produkt abgeliefert, das ist alles! 😉

Abschließendes

Wenn ihr Fragen zu diesem Thema habt, scheut euch nicht, sie in Kommentaren zu diesem Eintrag zu stellen! Ich werde sie möglichst zeitnah zu beantworten versuchen und wichtige Punkte als Updates zu diesem Blogpost verarbeiten. Weiterhin gibt es die englischsprachige Mailingliste free-aria, in der solche Themen auch mit anderen Webentwicklern, Anwendern und Standards-Experten diskutiert werden können.

Dies ist ein wichtiges Thema, das, wenn es richtig gemacht wird, eine sehr gute und flüssige Arbeitsweise ermöglicht, wenn falsch angepackt jedoch auch zu echten Problemen führen kann.

Nutzt die Rolle „application“ also nur dann, wenn Tests zeigen, dass dies zu einem besseren Interaktionsmodell führt. Wenn ihr sie dann einsetzt, tut es mit Augenmaß, der Aufwand lohnt sich!

Kategorien
ARIA Zugänglichkeit

Von WAI-ARIA nach HTML5 und zurück, oder doch nicht?

Auf dem Multimediatreff 28 in Köln am 3. Dezember hielt ich einen Vortrag über Barrierefreiheit mit WAI-ARIA und HTML5. Als Beispiel zog ich hierfür meinen einfachen ARIA-Tip #2 heran und entwickelte diesen weiter. HTML5 bietet inzwischen viele der Fähigkeiten, die WAI-ARIA mitbringt, nativ, und viele davon sogar besser.

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.

    </li

  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.

Kategorien
Apple ARIA Zugänglichkeit

Mac OS X Lion ist da, Eindrücke von den neuen Barrierefreiheitsfunktionen

Apple hat soeben die neueste Version seines Betriebssystems Mac OS X, Lion, veröffentlicht. Eine gute Gelegenheit, einen Blick auf die neuen Barrierefreiheitsmerkmale der jüngsten Raubkatze zu werfen!

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!

Kategorien
ARIA Zugänglichkeit

Besuch beim Best Practices Stammtisch Essen am vergangenen Montag

Am vergangenen Montag war ich zu Besuch im Ruhrgebiet. Sandra, die Initiatorin des Best Practices Stammtisch Essen hatte mich schon vor längerer Zeit eingeladen, mal vorbeizukommen. Im Gepäck hatte ich einige Infos über WAI-ARIA.

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.

Kategorien
ARIA Zugänglichkeit

Impressionen der Fachtagung „Einfach für Alle – Konzepte und Zukunftsbilder für ein Barrierefreies Internet“

Am 06.05.2008 nahm ich an der Fachtagung der Aktion Mensch „Einfach für Alle – Konzepte und Zukunftsbilder für ein Barrierefreies Internet“ teil. Die Aktion Mensch hatte mich als Experten für den Workshop 8: Web-Anwendungen – die Software im Browser eingeladen.

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.

Kategorien
ARIA Firefox Qualitätssicherung

Letzter Feinschliff für Firefox 3

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.