Navigation

Darstellung anpassen

Service-Menü

Sprachversionen

Suche



Inhalt

Infothek

Standards
Die Zug├Ąnglichkeit von WAI-ARIA

30.11.2010

Seit einigen Jahren besch├Ąftigen sich Web-Entwickler viel mit WAI-ARIA, ein in Entwicklung befindlicher Standard des W3C. ARIA steht f├╝r Accessible Rich Internet Applications. Das Hauptziel des Standards ist es, das dynamische Verhalten von Web-Anwendungen f├╝r blinde und sehbehinderte Nutzer wahrnehmbar zu machen.

Wenn etwa durch AJAX ohne Neu-Laden der Seite ├änderungen des Seiteninhalts ausgel├Âst werden, sorgt WAI-ARIA daf├╝r, dass Screenreader-Nutzer das mitbekommen. Auch komplexere Interface-Komponenten (Widgets) wie Ausklappmen├╝s, Reiter, Schieberegler oder Hierarchieb├Ąume k├Ânnen durch WAI-ARIA brauchbar werden ┬Ś vorausgesetzt allerdings, Nutzer verf├╝gen ├╝ber aktuelle Browser und Screenreader.

Viele Nutzer haben jedoch keine aktuellen Software-Versionen, gerade am Arbeitsplatz.

Eine Messlatte zur Einsch├Ątzung der Barrierefreiheit

Deshalb werden beim Testen der Zug├Ąnglichkeit bewusst nicht die neuesten Browser und Screenreader-Versionen eingesetzt. So gilt laut BITV-Test Werkzeugliste zur Zeit immer noch der Test mit Internet Explorer 7 als verbindlich. Die dazu passendende JAWS-Version ist JAWS 8, eine Version, die WAI ARIA noch nicht unterst├╝tzt und in neueren Browserversionen bereits nicht mehr funktioniert.

Obwohl der BITV-Test keinen Praxistests mit Screenreadern einschlie├čt, wird die Hilfsmittelunterst├╝tzung von WAI-ARIA durchaus implizit mitgepr├╝ft. Angebote, die sich etwa bei Custom Widgets auf WAI-ARIA verlassen, bekommen (zur Zeit) Punktabz├╝ge, etwa in den Pr├╝fschritten "Ohne CSS nutzbar", "ohne Scripte nutzbar", und "Grafiken vor wechselndem Hintergrund erkennbar".

Dies f├╝hrt zu der grundlegenden Frage, ob es ├╝berhaupt sinnvoll ist, bei einer Pr├╝fung auf Barierefreiheit eine inzwischen veraltete Browser-Hilfsmittel Kombination, die WAI-ARIA noch nicht unterst├╝tzt, zur Messlatte zu nehmen. Werden denn damit nicht jene Web-Entwickler bestraft, die sich bem├╝hen, die vom Kunden verlangten dynamischen Web-Applikationen mittels JavaScript und WAI-ARIA auch f├╝r blinde Nutzer zug├Ąnglich zu machen?

Um diese Frage zu beantworten, muss man etwas weiter ausholen. Erstmal: Was verlangen die Web Content Accessibility Guidelines (WCAG) 2.0, an denen sich die zuk├╝nftige BITV 2.0 und damit auch der zuk├╝nftige BITV-Test orientieren? Dann, wie gut ist jetzt schon die Unterst├╝tzung von WAI-ARIA in Browsern und Hilfsmitteln? Und schlie├člich: was f├╝r praktische Hindernisse f├╝r den Einsatz von WAI-ARIA bestehen am Arbeitsplatz?

"Accessibility Support" (Zug├Ąnglichkeits-Unterst├╝tzung) in den WCAG 2.0

"Accessibility support" kann man sich als eine Br├╝cke mit zwei B├Âgen vorstellen. Nur wenn beide B├Âgen da sind, k├Ânnen Hilfsmittel-Nutzer an alle Informationen gelangen, die auch den ├╝brigen Nutzen zug├Ąnglich sind.

Der erste Bogen ist die eingesetzte Webtechnologie. Webentwickler, die sich an die WAI-ARIA-Spezifikation und die empfohlenen Authoring Practices halten, k├Ânnen sicherstellen, dass ihre Inhalte potenziell zug├Ąnglich sind.

Warum "potenziell?" Weil der zweite Bogen der Br├╝cke noch fehlt: geeignete Nutzeragenten. Browser und Screenreader m├╝ssen angepasst beziehungsweise aktualisiert werden, damit sie die neuen Webtechnologien auch unterst├╝tzen. Bei ├Ąlteren Versionen kommt h├Ąufig nichts an.

Um den "accessibility support" einer bestimmte Webtechnologie zu erkl├Ąren, reicht es also nicht aus, den Standard zu verabschieden. Man muss auch pr├╝fen, in welchem Ma├če aktuelle, Unterst├╝tzung bietende Browser und Hilfsmittel bereits weitreichende Verbreitung gefunden haben. Die Situation ist hier je nach Land, Sprache und Nutzungskontext recht unterschiedlich.

Im Abschnitt ├╝ber Understanding Accessibility Support steht deshalb:

The WCAG Working group and the W3C do not specify which or how many assistive technologies must support a Web technology in order for it to be classified as accessibility supported

Und:

...defer[s] the judgment of how much, how many, or which AT [assistive technology] must support a technology to the community and to entities closer to each situation.

In einem Intranet mit einheitlich administrierten Arbeitspl├Ątzen kann etwa eine Unterst├╝tzung gew├Ąhrleistet werden ┬Ś bei ├Âffentlichen Webangeboten mit einer Vielzahl unterschiedlicher Nutzer und technischen Ausstattungen sieht es anders aus.

Die WCAG 2.0 sagen deshalb ganz klar:

Creating content that can't be used by the general public with disabilities should be avoided.

Quelle: WCAG 2.0 Understanding Conformance: Understanding Accessibility Support

Der BITV-Test orientiert sich in der Wahl seiner Messlatte vorrangig an diesem general public, also der tats├Ąchlichen Praxis behinderter Menschen am Arbeitsplatz. Und hier zeigt sich, dass dem verbreiteten praktischen Einsatz von WAI-ARIA immer noch vieles im Wege steht.

WAI-ARIA Unterst├╝tzung in Browsern und Hilfsmitteln

Die Unterst├╝tzung einiger Teile von WAI-ARIA ist in neueren Browsern und Screenreadern inzwischen recht gut, so etwa bei den document landmarks. Es gibt aber auch noch viele Probleme.

L├╝ckenhafte Unterst├╝tzung bei Hilfsmitteln

Ein Blick auf die (inzwischen etwas veralteten) WAI-ARIA Tests auf codetalks zeigt, dass in vielen Screenreader/Browser-Kombinationen die Umsetzung bei vielen Widgets l├╝ckenhaft oder fehlerhaft ist. Und Workarounds f├╝r bekannte Screenreader-Bugs k├Ânnen die Zug├Ąnglichkeit f├╝r Nutzer standardkonformer Browser und Screenreader sogar verschlechtern.

Blinde Nutzer ohne WAI-ARIA-Unterst├╝tzung k├Ânnen ein Web Widget nicht erkennen, weil dessen WAI-ARIA-Rolle nicht ausgegeben wird. So etwa bei einer Reiternavigation (tabpanel), die gem├Ą├č der WAI-ARIA best practices umgesetzt wurde. Der Screenreader teilt den Nutzern nicht mit, dass es sich um eine Reiternavigation handelt und die Pfeiltasten benutzt werden k├Ânnen, um zwischen den Reitern zu wechseln. Nutzer werden also wahrscheinlich weitertabben und damit unwissentlich den Inhalt unter den Reitern ├╝berspringen. Und geskriptete Fokusversetzungen f├╝r die Pfeiltastennavigation zwischen den Reitern funktionieren h├Ąufig gar nicht, was bedeuten kann, das der gesamte Bereich unter den Reitern unzug├Ąnglich ist.

Wir sollten auch Nutzer mit Sehbehinderungen nicht vergessen. Die aktuellen Versionen bekannter Vergr├Â├čerungssoftware bieten noch keine WAI-ARIA-Unterst├╝tzung. ZoomText wei├č anscheinend nicht einmal, dass es WAI-ARIA ├╝berhaupt gibt. Freedom Scientific plant partiellen Support in MAGic in der n├Ąchsten Version (die aktuelle Version ist 11.0). Dolphin k├╝ndigt Unterst├╝zung in HAL und Supernova ab Version 12 an.

Korrekte und fehlerhafte Umsetzungen von WAI-ARIA

Ob etwas wie gew├╝nscht funktioniert, h├Ąngt auch davon ab, ob WAI-ARIA gem├Ą├č der WAI ARIA best practices umgesetzt wurde. Coding-Fehler k├Ânnen die Zug├Ąnglichkeit von Widgets noch verschlechtern. Das Problem hat auch damit zu tun, dass die eingebaute Semantik von nativen HTML-Elementen mit der durch WAI-ARIA hinzugef├╝gten Semantik in Konflikt kommen kann. Alexander Farkas zeigt das etwa am Beispiel von Ausklappmen├╝s in WAI-ARIA ┬ľ Epic Fail: Reste fressen.

Das Zusammenwirken dieser Probleme bedeutet, dass der korrekte Einsatz von WAI-ARIA ganz sch├Ân kompliziert werden kann. Webentwickler, denen an der Zug├Ąnglichkeit ihrer Seiten liegt, testen deshalb zunehmend mit Screenreadern, um zu ├╝berpr├╝fen, ob ihre Designs in m├Âglichst vielen Umgebungen auch wirklich funktionieren. (Ein guter Anfang ist daf├╝r der NVDA Screenreader: er ist kostenlos und leicht zu installieren).

Auswirkungen von Widgets auf sehende Tastaturnutzer

WAI-ARIA kommt besonders blinden Nutzern zugute. F├╝r sie sind desktopartige Widgets auf Webseiten jetzt nicht mehr l├Ąnger unzug├Ąnglich. Aber die sprungartige Vermehrung solcher Widgets im Web hat auch negative Auswirkungen f├╝r sehende Tastaturnutzer.

Im Gegensatz zu den Desktop-Widgets und deren Konventionen tauchen die selbstgebastelten Widgets im Web in tausenderlei Spielarten auf. Nur wenige halten sich an die WAI-ARIA best practices. Ob und wie ein Widget tastaturnutzbar ist, muss in jedem Fall ausprobiert werden.

Bei einer Reiternavigation etwa gibt es keine klaren Anhaltspunkte, um zwischen einer normalen Hauptnavigation mit Reitern und einem Widget mit Reitern irgendwo weiter unten auf der selben Seite zu unterscheiden. Und nur wenige Reiternavigationen implementieren schon die Pfeiltastennavigation. Sehende Tastaturnutzer m├╝ssen also rumprobieren, was funktioniert. (F├╝r blinde Nutzer mit WAI-ARIA-f├Ąhigen Screenreadern ist das Problem hier geringer, falls die Rollen des Widgets ├Ąhnlich wie bei Desktop-Widgets vorgelesen werden.)

Auch die Abh├Ąngigkeit von Stylesheets ist f├╝r sehbehinderte Nutzer kritisch. CSS wird bei selbstgebastelten Widgets als "accessibility-supported technique" vorausgesetzt ┬ľ denn ohne CSS zerbr├Âselt alles. Die r├Ąumliche Zuordnung (CSS-Positionierung) der div und Bilder stimmt nicht mehr, Elemente tauchen doppelt auf, oder Inhalte erscheinen weit entfernt von ihrem Kontext, z.B. am Seitenende. ├ťber CSS eingebundene Hintergrundbilder verschwinden, ebenso auch bei Nutzung eigener Farben. Eine robuste darstellungsunabh├Ąngige Semantik ist so nicht gew├Ąhrleistet.

Hindernisse f├╝r den Einsatz von WAI-ARIA am Arbeitsplatz

Andere Probleme gibt es am Arbeitsplatz, und oft aus Gr├╝nden, auf die Nutzer keinen Einfluss haben.

  • Viele Unternehmen haben Systeme, etwa ausgedehnte Intranet-Anwendungen, die nach Inbetriebnahme f├╝r einen bestimmte Browser-Hilfsmittel-Kombination angepasst wurden. Die Anpassungskosten sind dabei h├Ąufig um ein Vielfaches h├Âher als die Lizenzkosten etwa eines Screenreader-Updates. Bekannte Sicherheitsl├╝cken, etwa bei IE7, erzeugen h├Ąufig einen Upgrade-Druck ┬Ś das greift aber dann nicht, wenn Applikationen ausschlie├člich im Intranet verwendet werden.
  • Viele Unternehmen nutzen weiterhin veraltete Betriebssystem-Umgebungen wie Windows 2000, auf denen neuere Browser wie IE8 und damit auch neuere Screenreader-Versionen nicht funktionieren. Bei Anwendungen f├╝r bestimmte kaum ver├Ąnderliche Arbeitsabl├Ąufe gibt es aber kaum wirklichen Anpassungsbedarf. Erst eingreifende Umstellungen betrieblicher Prozesse bieten dann die Chance f├╝r ein Upgrade.
  • Viele blinde Computernutzer, die mit JAWS 9 oder h├Âher arbeiten, d├╝rften ├╝ber die M├Âglichkeiten von und den Umgang mit ARIA noch nicht hinreichend informiert bzw. damit geschult sein.
  • NVDA und JAWS sind derjenigen Screenreader, die mit WAI-ARIA am Besten zurecht kommen. Wir d├╝rfen dar├╝ber aber die Nutzer anderer Hilfsmittel nicht vergessen. F├╝r diese ist die Zug├Ąnglichkeit selbst unter den aktuellsten Versionen weniger gew├Ąhrleistet.

Erg├Ąnzen l├Ąsst sich, dass viele der bisher ben├Âtigten Anpassungen von Web-Anwendungen an Hilfsmittel genau solche 'selbstgebastelten' Bedienelemente betreffen, die mit WAI-ARIA Screenreader-tauglich gemacht werden k├Ânnen. Hier k├Ânnte die Unterst├╝tzung von WAI-ARIA viele M├╝hen und Kosten sparen. Nat├╝rlich m├╝ssen die Entwickler dann auch WAI-ARIA durchg├Ąngig und standardgem├Ą├č einsetzen.

Wieviele Anwender nutzen denn noch nicht-WAI-ARIA-f├Ąhige Screenreader?

Eine nicht-repr├Ąsentative Stichprobe vorweg

Wir haben bei der Recherche zu diesem Artikel eine Stichprobe bei einem gro├čen ├Âffentlichen Arbeitgeber gemacht. Von den 15 erfassten Arbeitspl├Ątzen f├╝r blinde Nutzer unterst├╝tzt zur Zeit kein einziger Screenreader WAI-ARIA.

  • 7 Arbeitspl├Ątze nutzen HAL/Lunar (zwischen Version 6 und 10)
  • 4 Arbeitspl├Ątze nutzen JAWS 6
  • 4 Arbeitspl├Ątze nutzen Blindows (zwischen Version 2 und 4)

An anderen Arbeitspl├Ątzen sieht es sicher besser aus, aber das Signal ist klar: ein gro├čer, vielleicht sehr gro├čer Anteil der blinden Nutzer am Arbeitsplatz hat bisher kein System, dass WAI-ARIA unterst├╝tzt.

Untersuchungen und Nutzerstatistiken

Es gibt leider keine Statistiken, die es erm├Âglichen w├╝rden, den Anteil der Anwender, die nicht WAI-ARIA f├Ąhige Screenreader einsetzen, einigerma├čen verl├Ąsslich zu quantifizieren. Einzig die vielbeachtete WebAim Screenreader-Nutzer Umfrage (Update vom Oktober 2009) zeigt an, dass 83,6% der Screenreader-Nutzer ein Update innerhalb eines Jahres nach Erscheinen einer neuen Version vornehmen. Wenn man einmal nur JAWS betrachtet, dann sollte, nach mehreren Releases seit dem Erscheinen des ersten WAI-ARIA f├Ąhigen Version 9 im November 2007, inzwischen der Anteil der Nutzer, die noch JAWS 8 nutzen, auf unter 5 Prozent gefallen sein. Die Umfrage reflektiert jedoch haupts├Ąchlich den amerikanischen Markt; auch ist anzunehmen, dass ein gro├čer Teil der zu Grunde liegenden Antworten aus der Gruppe der technisch affinen Screenreader-Nutzer stammen, dass also die durchschnittliche Upgrade-Rate aller Screenreader-Nutzer deutlich unter 83,6% liegt.

Unproblematische Nutzungsweisen von WAI ARIA

Viele sinnvolle Nutzungsweisen von WAI ARIA zielen darauf, HTML anzureichern, um bestimmte semantische Defizite zu beheben. Da es in HTML 4 keine expliziten Elemente f├╝r die Bereichsauszeichnung gibt, gibt es in der WAI ARIA Spezifikation die sogenannten document landmarks. Damit kann ein einfaches div mit dem Attribut role="navigation" ausgezeichnet werden, w├Ąhrend etwa der Seiteninhalt das Attribut role="main" erh├Ąlt. Dann k├Ânnen etwa Nutzer von Screenreadern, die WAI ARIA unterst├╝tzen, schneller zwischen Seitenbereichen hin- und herspringen.

Andere Attribute verbessern die Auszeichnung von Formularen: so kann etwa bei einem Texteingabefeld (input-Element) das Attribut aria-required="true" Screenreader-Nutzer dar├╝ber informieren, dass es sich um ein Pflichtfeld handelt.

Ein weiteres n├╝tzliches Konstrukt sind die ARIA live regions, mittels derer Screenreader-Nutzer ├╝ber dynamische Zustands├Ąnderungen auf Webseiten informiert werden k├Ânnen, ohne dass sie ihren augenblicklichen Tastatur- Fokus verlieren.

Den Nachteil, dass mit WAI-ARIA angereicherte Seiten nicht mehr valide sind, kann man in Kauf nehmen: die g├Ąngigen Browser st├Âren sich nicht an den zus├Ątzlichen Auszeichnungen. ├ťber kurz oder lang wird das Problem verschwinden, wenn aus dem augenblicklichen WAI-ARIA working draft eine recommendation geworden wird ist und eine neue Generation des W3C Validators WAI ARIA Attribute akzeptiert. Viele Sites umgehen auch das Validierungsproblem, indem sie die WAI-ARIA Attribute erst beim Laden der Seite per DOM Scripting hinzuf├╝gen.

Problematisch: selbstgebastelte Interface-Elemente (Widgets)

Die WAI-ARIA Spezifikation unterst├╝tzt aber auch eine ganze Reihe von interaktiven Elementen (sogenannten Widgets) mit dem Ziel, g├Ąngige Interaktionselemente prim├Ąrer Applikationen auch in Web-Applikationen zu realisieren (einen ├ťberblick bietet die WAI-ARIA Role, State, and Property Quick Reference).

Erweiterungen von Standard- Elementen

Zum einen wird versucht, die Semantik bekannter Elemente zu erweitern, etwa drei Zust├Ąnde bei Checkboxen zuzulassen oder Ausklapplisten zu schaffen, die gleichzeitig Autocomplete-Eingabefelder sind (die combobox). Dabei werden bekannte HTML Input-Elemente nachgebaut, wobei ein ziemlicher Aufwand getrieben werden muss, wenn diese neuen Elemente halbwegs zug├Ąnglich umgesetzt werden sollen.

Neue Elemente

Dann gibt es aber auch eine Reihe von Interface-Elementen, die Webdesigner schon l├Ąnger mit einigem Aufwand nachgebaut haben und die nun mittels WAI-ARIA zug├Ąnglich gemacht werden sollen: die custom widgets. Dazu geh├Âren etwa Ausklapp-Men├╝s, Reiter (Tabpanels), hierarchische Navigationsb├Ąume, Slider, Spinner, und sogar Drag-and-Drop Interfaces. Das jeweilig gew├╝nschte Tastaturverhalten dieser Widgets wird nicht wie bei normalen fokussierbaren HTML-Elementen von Browser geliefert, sondern muss mittels JavaScript definiert werden. Das ist schon das erste Problem. Hier gibt es kaum verl├Ąssliche Konventionen, das hei├čt, es ist viel schwieriger, diese Elemente erwartungskonform zu gestalten. Welche Tasten auf ein bestimmtes Widget anwendbar sind und was genau sie ausl├Âsen, muss im Zweifelsfall erst mal ausprobiert werden.

Auch ist die Fehleranf├Ąlligkeit solcher Widgets ist h├Âher. JavaScript-Tricks wie die von Alexander Farkas beschriebene TimeOut-Funktion f├╝r Fokusverschiebungen auf dem Seitenbaum hinzugef├╝gte Elemente m├╝ssen genutzt werden, damit das intendierte Verhalten auch erreicht wird.

Fallback-L├Âsungen f├╝r nicht WAI-ARIA f├Ąhige Browser/Hilfsmittel-Kombinationen?

Gibt es dann nicht die M├Âglichkeit, Widgets mit Fallback-L├Âsungen f├╝r nicht WAI-ARIA f├Ąhige Browser/Hilfsmittel Kombinationen zu versehen? Die WAI-ARIA Spezifikation erw├Ąhnt dies in der Beschreibung der Rolle presentation: "┬ůmay be used to provide for an accessible fallback in older browsers that do not support WAI-ARIA".

Tats├Ąchlich finden sich hierf├╝r bislang keine praktischen Umsetzungsbeispiele. Es f├Ąllt schwer, sich sinnvolle Anwendungen dieses Ansatzes ├╝berhaupt vorzustellen. Was w├╝rde passieren, wenn man etwa eine selbstgebastelte Checkbox mit einem Fallback ausstatten wollte, also mit einer echten Checkbox f├╝r blinde Nutzer ohne WAI-ARIA Support, die mittels CSS vor sehenden Nutzern und mittels role="presentation" vor WAI-ARIA-f├Ąhigen Screenreadern versteckt w├Ąre?

Das funktioniert nicht. Die Rolle presentation unterdr├╝ckt zwar WAI-ARIA-Attribute (au├čer globalen), nicht aber die Exponierung fokussierbarer Elemente wie Checkboxen. Der WAI-ARIA 1.0 User Agent Implementation Guide stellt klar:

...the element must still be exposed if it (...) is focusable, so that focus events can be fired (focus must never be lost).

 

F├╝r Screenreader-Nutzer ohne WAI-ARIA Support, aber mit "JavaScript an", w├╝rde nicht nur die Fallback-Checkbox, sondern auch die selbstgebastelte Checkbox den Tastaturfokus erhalten, ohne jedoch Rolle und Zustand mitzuteilen. F├╝r Screenreader-Nutzer mit WAI-ARIA Support w├╝rde die ├╝berfl├╝ssige Fallback-Checkbox zwar (dank role="presentation") nicht mitgeteilt, w├Ąrte aber dennoch Teil der Tab-Reihenfolge und weiter ausw├Ąhlbar. Sehende Nutzer schlie├člich k├Ânnten die Fallback-Checkbox auch ├╝ber die Tastatur erreichen und (ohne visuelles Feedback) ausl├Âsen. Das macht nat├╝rlich keinen Sinn.

Empfehlungen

Wenn es geeignete semantische Elemente in HTML gibt, sollten m├Âglichst diese und nicht ein nicht-semantisches, ├╝ber JavaScript und WAI-ARIA Tastatur- und Screenreader-nutzbar gemachtes Widget eingesetzt werden. Die Schwierigkeit, native Elemente mittels CSS abweichend zu gestalten, mag manchen Frontend-Designer ├Ąrgern: f├╝r den Nutzer bedeutet es h├Ąufig ein Gewinn an Erwartungskonformit├Ąt, wenn etwa Radio Buttons einfach wie die system├╝blichen Radiobuttons aussehen und sich auch so verhalten.

Designer sollten pr├╝fen, ob sie Abl├Ąufe, die mit komplexen Widgets unterst├╝tzt werden, nicht vereinfachen k├Ânnen. Braucht man wirklich eine schwer zug├Ąnglich zu machende Combobox f├╝r Autocomplete-Funktionen? Gibt es wirklich einen Bedarf f├╝r Checkboxen mit drei Zust├Ąnden, oder l├Ąsst sich das auch anders, einfacher umsetzen? Ist ein Slider nicht durch eine Gruppe von Radiobuttons mit diskreten Werten ersetzbar?

Das soll aber nicht als Aufruf zu minimalistischem Design missverstanden werden. H├╝bsche Interface-Komponenten richten kaum Schaden an, wenn sie eine gleichwertige zug├Ąngliche Alternative haben.

Ein Beispiel daf├╝r ist der Schieberegler im Spendenprozess der Site SOS-Kinderdorf, die k├╝rzlich ein Relaunch hatte. Mausnutzer k├Ânnen den Schieberegler benutzen, um die H├Âhe ihrer Spende an SOS-Kinderdorf einzustellen (siehe Abbildung 1). Abh├Ąngig von der H├Âhe des eingestellten Betrags dr├╝ckt ein kleines M├Ądchen mittels einer Sprechblase ihren Dank in verschiedenen Abstufungen der Begeisterung aus.

Der Agentur zufolge hat die Spendenbereitschaft nach Einf├╝hrung des Schiebereglers sprunghaft zugenommen ┬Ś selbst f├╝r Puristen wohl eine hinl├Ąngliche Rechtfertigung dieser spielerischen Umsetzung.

Figure 1: Zweiter Schritt im SOS-Kinderdorf Spendenprozess (Design by Aperto AG)

Statt zu versuchen, den Schieberegler hier durch den Einsatz von WAI-ARIA Screenreader-tauglich zu machen (role="slider"), haben die Designer stattdessen als Alternative ein simples Textfeld f├╝r die numerische Eingabe der Spendensumme eingesetzt. Die Tab-Reihenfolge ├╝berspringt einfach den Slider. Was wichtig ist: die Reaktion des Kindes in der Sprechblase wird von beiden Arten der Eingabe ausgel├Âst.

Fassen wir zusammen. JavaScript ist inzwischen ├╝berall pr├Ąsent; immer mehr Websites verlassen sich darauf. WAI-ARIA ist deshalb eine willkommene L├Âsung, um die Zug├Ąnglichkeitsl├╝cke zu schlie├čen, die diese Entwicklung geschaffen hat. Entwickler, die heute bereits WAI-ARIA praktisch umsetzen und auch in Hilfsmitteln testen, was tats├Ąchlich ankommt, helfen dabei, Implementationsfehler in Browsern wie Hilfsmitteln zu entdecken. Gleichzeitig schaffen sie gute Umsetzungsbeispiele, von denen andere Entwickler profitieren k├Ânnen.

Solange aber noch viele der praktisch eingesetzten Browser/Hilfsmittel-Kombinationen keine oder nur eine partielle Unterst├╝tzung von WAI-ARIA bieten, sollte man zur Sicherstellung guter Zug├Ąnglichkeit WAI ARIA nur unterst├╝tzend einsetzen und sich nicht darauf verlassen.

Gegenw├Ąrtiges Fazit f├╝r den BITV-Test

Aus den genannten Problemen ergibt sich f├╝r den BITV-Test die Konsequenz, vorerst weiterhin zu verlangen, dass sich Websites zur Sicherstellung der Barrierefreiheit nicht auf WAI-ARIA verlassen. Das kann sich dann ├Ąndern, wenn der Anteil der Nutzer, die ├Ąltere, nicht WAI-ARIA f├Ąhige Hilfsmittel benutzen, deutlich geringer geworden ist.

Danksagung

F├╝r Kommentare und Hinweise vielen Dank an Carsten Albrecht, Alexander Farkas, Michael Gro├če-Drenkpohl, Jan-Eric Hellbusch, Werner Hoog, Martin Kliehm, Werner Krau├če, Oliver Nadig, Hans-Herbert Suhling, Timo Wirth, Tiffany Wyatt und Marco Zehe.

N├╝tzliche Quellen

Zeitgleich wurde eine englische Version dieses Artikels auf "A list apart" ver├Âffentlicht.