accessBlog

News mit dem Tag »Motorische Behinderung«

Ein sehr spezielles Problem der Barrierefreiheit ist das Verhalten aller Plug-In-basierten Browser bei der Tastaturbedienung von Objekten wie zum Beispiel eingebetteten Flash-Inhalten. Oft können Nutzer sich zwar per Tastatur in ein solches Objekt hinein bewegen, jedoch nicht mehr hinaus aus dem Objekt zur umliegenden HTML-Seite – eine klassische Tastaturfalle für viele Nutzer, die darauf angewiesen sind. Wie Sie dies verhindern wird in den folgenden WCAG-Techniken erklärt:

Weiterlesen …

Allgemeine Techniken

Typische Fehler

Bei der Nutzung eines Angebots per Tastatur kann es sehr schnell passieren, dass Nutzer die Orientierung verlieren und nicht mehr wissen, welches Element aktuell fokussiert ist. Wie Sie Ihren Besuchern ermöglichen den Überblick zu behalten wird in den folgenden WCAG-Techniken erklärt:

Weiterlesen …

Allgemeine Techniken

CSS-Techniken

Client-seitige Scripting-Techniken

Streng genommen sind Skip Links nur eine Hilfstechnik, bis alle relevanten Zugangsformen die ARIA-Landmarks oder die strukturierenden Elemente aus HTML5 verstehen. Bis dies soweit ist sollten Sie Ihren Nutzern das direkte Anspringen von wichtigen Inhaltsblöcken auch per Tastatur ermöglichen. Möglichkeiten hierzu stellen die folgenden WCAG-Techniken vor:

Weiterlesen …

Allgemeine Techniken

Bei der Entwicklung Ihrer Seiten sollten Sie darauf achten, dass die Elemente einer Seite oder Web-basierten Anwendung in einer Reihenfolge angelegt werden, bei der der logische Aufbau im Code der optischen Reihenfolge und der Erwartung der Nutzer entspricht. Was hierbei zu beachten ist zeigen die folgenden WCAG-Techniken:

Weiterlesen …

Allgemeine Techniken

HTML-Techniken

CSS-Techniken

Client-seitige Scripting-Techniken

Typische Fehler

Gerade beim Einsatz von Client-seitigem Scripting kommt es häufig zu Barrieren für viele Nutzer, die auf eine Tastaturnutzung angewiesen sind, wenn diese Skripte zwingend eine Maus voraussetzen und alternative Eingabemethoden nicht berücksichtigen. Ein unnötiger Fehler der einfach zu vermeiden ist, wie in den folgenden WCAG-Techniken erklärt wird:

Weiterlesen …

Allgemeine Techniken

Client-seitige Scripting-Techniken

Typische Fehler

Nicht länger zur Falle werden Flash-basierte Inhalte für Tastaturnutzer, denn nun gibt es ein barrierefreies Video-Player-Framework. Die Stadt Wien hat das unter der GNU General Public License veröffentlichte Framework auf dem A-Tag 2010 in der österreichischen Hauptstadt Anfang November vorgestellt.

Bislang war der Schwachpunkt für Tastaturnutzer, dass sie in einen Film hineintabben, aber nicht mehr aus dem Video heraustabben konnten, ohne die Seite neu laden zu müssen. Die gesamte Filmsteuerung (also Abspielen/Pause, Stop, Vor- und Zurückspulen, Untertitel und Audiodeskription, Lautstärke etc.) aus dem verbreiteteten JW Player können die Anbieter nun auslagern und in HTML nachbilden. Damit ist die Steuerung unter allen denkbaren Szenarien barrierefrei nutzbar.

Darüber hinaus können Film-Beiträge mit Untertiteln versehen werden (z.B. mit dem Editor Subtitle Horse); eine weitere Audiospur kann hinterlegt werden um Inhalte im Film besser verständlich zu machen. Zudem gibt es die Möglichkeit zur Integration von Gebärdensprachvideos. Transkripte können auf- und zugeklappt werden und Videos können in einer höheren Qualität und größer betrachtet werden.

Weiterlesen …

Das unter der GNU General Public License veröffentlichte Framework basiert auf dem Open-Source JavaScript-Framework jQuery, auf jQuery-Erweiterungen wie Colorbox und auf dem teilweise offen zur Verfügung stehenden JW Player. Für User Agents ohne Flash (z.B. iPhone/iPad/iPod) wird mittels HTML5 das gleiche Video ausgeliefert wie für ›normale‹ Browser. Um die Videos auch auf diesen mobilen User Agents verfügbar zu machen, ist speziell auf das Format und auf den Codec des Videos (mp4/h264) zu achten. Der Player spielt mit einer einfachen Konfigurationsänderung auch bei YouTube gelagerte Videos.

Zu sehen ist der Player auf einer Testseite bei accessibility.at oder im Live-Einsatz bei www.wien.at/tv, Beispiele für Gebärdenvideos findet man unter www.wien.at/multimedia/oegs. Lauffähig ist der Player auf allen halbwegs modernen Browsern, er ist aber abwärts-kompatibel bis hin zu IE6 (wenn auch mit kleineren Einschränkungen).

Weitere Infos

Das Player-Framework soll in nächster Zeit weiterentwickelt werden: geplant sind zurzeit die Darstellung von mehreren Videos auf einer Seite (eine Beta dafür ist bereits in Arbeit) und die Integration in Module für Open-Source CMS-Systeme wie Drupal, Typo3, Wordpress etc. Das Projekt sucht auch noch besseren Namen – falls jemand Ideen zur Benennung hat, werden sich die Initiatoren sicher freuen.

A-Tag 2010

Weitere Berichterstattung von der Veranstaltung via Lanyrd oder via Twitter.

Zugänglichkeit für Nutzer ohne Maus zu ermöglichen ist einer der wichtigsten Schritte beim Aufbau einer barrierefreien Webseite oder Web-Applikation. Beim Testen der Zugänglichkeit per Tastatur findet man sich immer wieder nach dem Drücken der Tabtaste in der Situation: »Wo ist mein Cursor?« oder »Welches Element hat eigentlich gerade den Fokus?«. Gerade bei Elementen, die per CSS aus dem sichtbaren Bildschirm-Bereich geschoben wurden, tabt man dann gern und lang im Dunkeln.

LogFocus – hilfreiches Bookmarklet beim Testen von Keyboard-Accessibility

Beim Aufräumen unserer Lesezeichen-Sammlung haben wir ein Skript von Dirk Ginader gefunden, das Licht in diese Situationen bringt, und das er vor einiger Zeit in ein handliches Bookmarklet gekapselt hat.

LogFocus arbeitet in allen Browsern, die eine Konsole zur Verfügung stellen: Im Firefox ist hierfür Firebug notwendig; in Safari (bzw. WebKit) muss das Develop‹-Menü aktiviert sein; für Internet Explorer empfiehlt sich das PlugIn Companion.JS und in Opera wird die eingebaute Konsole im Debugger Dragonfly genutzt.

Um das Bookmarklet zu installieren zieht man einfach den folgenden Link in die eigenen Bookmarks:

LogFocus

Von dort aus kann das Skript dann einfach per Klick auf jeder beliebigen Seite ausgeführt werden und die aktuelle Position wird in die Konsole geschrieben.

In den Richtlinien zur Barriere­freiheit finden sich viele Vorgaben zur geräte­unab­hängigen Bedienung. Üblicher­weise wird darunter die Bedienung ohne Maus, also per Tastatur oder anderen Eingabe­geräten verstanden. Dabei geht es hier nicht nur um tech­nische Aspekte, sondern auch um die Gestal­tung der Inter­aktion und das visuelle Feedback für den Nutzer.

In einem neuen Artikel möchten wir einige Lösungen zeigen, mit denen Sie mit ein­fachsten Mitteln und im Ideal­fall ohne Eingriff in den HTML-Code einer Site ein ›mehr‹ an Zugäng­lich­keit für Nutzer mit motorischen Behin­derungen erreichen können:

»›Oops, wo bin ich?‹ – Ein Herz für Tastaturnutzer«.

Wir hätten da eine Idee für die Accessibility Blog Parade: John Allsopp schlägt vor, mal einen Tag lang das Web ohne Tastatur zu benutzen – wir würden gerne den umgedrehten Vorschlag machen:
Klemmen Sie die Maus ab.
Einen ganzen Tag lang. Versuchen Sie nun, alle anfallenden Arbeiten nur mit der Tastatur zu erledigen. Berichten Sie über Ihre Erfahrungen in Ihrem Blog (oder hier in den Kommentaren). Und nein, Trackpad benutzen gilt nicht und Arbeiten auf Morgen verschieben auch nicht.

Nachtrag: »Maus raus« – ernüchternde Testergebnisse von Maria Putzhuber im MAIN_web-Blog.

Pünktlich zum zehnten Geburtstag des GNOME-Projekts wurde neulich die Version 2.20 des Linux-Desktops veröffentlicht. Mit dabei sind eine ganze Reihe Dinge, die das alternative Linux-Betriebssystem gerade für Menschen mit Behinderungen interessant machen.

So gibt's (ohne Aufpreis :-) einen eingebauten Screenreader namens Orca mit eingebauter Bildschirmlupe und Braille-Unterstützung. Die neue Version arbeitet nun noch besser mit dem Office-Paket OpenOffice, dem Firefox-Browser, dem E-Mail-Client Thunderbird, Pidgin (einem IM-Programm) und Java-Applikationen zusammen.

Ebenfalls aktualisiert wurde die Bildschirm-Tastatur GOK und die alternative Eingabe-Oberfläche Dasher für Menschen mit motorischer Behinderung. Für die Nutzer der Kontrast- und Großschrift-Schemata gibt es nun bei der Einrichtung des Computers in den Voreinstellungen eine Vorschau auf das geänderte Erscheinungsbild.

Neben den in der letzten Zeit wieder in den Fokus gerückten kognitiven Behinderungen gibt es noch weitere, die in der Diskussion um ein barrierefreies Web nicht unbedingt dominieren. Dabei sind diese Barrieren so einfach zu testen, dass sie bei der BIENE sogar zu den ganz hart angewendeten Vortest-Kriterien gehören. Deswegen geht der heutige Lesebefehl zu zwei Artikeln, in denen diese Barrieren ganz eingängig beschrieben und Strategien zu ihrer Vermeidung vorgestellt werden:

Hilfsmittelwochen bei EfA: oft liegt der Fokus nur auf der Ausgabeseite und den dort eingesetzten assistiven Programmen wie Screenreader & Co. Dabei wird die Eingabeseite gerne übersehen (oder zumindest nicht gründlich genug getestet). Mel Pedley gibt bei Accessites.org einen kurzen Einblick in typische Computerhilfsmittel von Menschen mit motorischer Behinderung: »I Saw a Mouse! Where?« und erklärt, was das ganze für Auswirkungen auf das Webdesign hat.

Bei der Preisverleihung des grössten Schweizer Internet-Wettbewerbs für Jugendliche, ThinkQuest, wurde am 26. November zum ersten Mal der Access4all Award vergeben. Bei diesem Preis geht es darum, dass junge Menschen die Anforderungen von Menschen mit Behinderungen bei der Gestaltung von Websites berücksichtigen. Von insgesamt 85 Teams haben rund die Hälfte besondere Anstrengungen unternommen, um ihr Projekt auch für Menschen mit Behinderung zugänglich zu machen.

Anlässlich der Preisverleihung wurden Workshops durchgeführt, in denen sehbehinderte, blinde und motorisch behinderte Tester der Stiftung »Zugang für alle« die Nutzbarkeit der eingereichten Projekte demonstrierten. Weitere Infos und Fotos der Preisverleihung: access-for-all.ch.

IBM will mit neuen Techniken Computer vor allem für ältere und behinderte Menschen zugänglicher machen. Auf der Entwicklerseite von IBM werden neue Werkzeuge angeboten, die den Umgang erleichtern sollen. Dazu zählt ein Keyboard Optimizer, mit dem sich die Tastatureinstellungen auf den persönlichen Schreibstil anpassen lassen, je nachdem ob mit einer oder zwei Händen getippt wird und Tasten eher lange oder kurz gedrückt werden. Ein Programm namens Web Adaptation Technology soll Webseiten dynamisch an die Fähigkeiten von Seh- oder motorisch Behinderten Menschen anpassen. Die Inhalte werden dabei vergrößert, Schriften, Bilder und auch das Seiten-Layout angepasst, um Seiten leicht lesbar zu machen. Auch eine Sprachausgabe wird unterstützt. Eine spezielle Mouse Smoothing Software soll für ruhige Mausbewegungen sorgen, auch wenn der Benutzer stark zittert. Entsprechende Bewegungen filtert die Software aus, ähnlich wie ein Bildstabilisator bei Kameras (via kobinet).

Das Zentralorgan des Silicon Valley berichtet über Barrieren, denen behinderte Nutzer täglich im Web gegenüberstehen: Surfing in the dark - The web is still full of roadblocks for disabled.

Leider geht auch dieser Artikel wieder nur am Rande auf die wirklichen Probleme ein und reduziert die Barrierefreiheit auf ein technisches Problem, das mit technischen Mitteln behoben werden könnte. Die wesentlich gravierenderen inhaltlichen Hürden, mit denen unerfahrene Nutzer, Migranten und Nicht-Muttersprachler, Menschen mit Lernbehinderung oder Dyslexie oder auch gehörlose Menschen konfrontiert werden, fallen wie üblich unter den Tisch.

Erschwerend kommt hinzu, dass der Artikel die Direktorin der WAI, Judy Brewer mit den folgenden Worten zitiert: Ob jemand nun taub ist, motorisch oder kognitiv behindert, die Bedürfnisse und Lösungen ergänzen sich. Dem möchte man ein fröhliches So ein Quatsch! entgegenschmettern – verleitet die Aussage doch bei oberflächlicher Betrachtung zum vorschnellen Trugschluss, dass Barrierefreiheit nur etwas mit Alternativtexten für Screenreader zu tun hätte.

Einem Menschen, der seit seiner Kindheit in Gebärdensprache kommuniziert, ist mit diesen Alternativtexten nur bedingt geholfen. Einem ausschließlich motorisch behinderten Menschen ist es herzlich egal, wie sich die Seiten mit einem Screenreader anhören. Einem lernbehinderten Nutzer bleibt die spezielle Semantik bestimmter HTML-Tags wohl verborgen und unerfahrene User scheitern schon an simplen Konzepten, die in den Richtlinien gar nicht bedacht sind.

Barrierefreiheit als One Size fits All führt in die Sackgasse, wenn man nur einen Ausschnitt der Problematik berücksichtigt.

Via /.: dem Vernehmen nach arbeitet der norwegische Browserhersteller an einer Sprachsteuerung für Opera durch den Einbau von IBM Embedded ViaVoice. Die Pressemitteilung streicht hauptsächlich die Möglichkeiten heraus, die sich für eher exotische Einsatzzwecke wie Opera Show als PowerPoint-Ersatz ergeben. Wir könnten uns aber durchaus vorstellen, daß Opera damit auch für Menschen mit motorischer Behinderung eine interessante Alternative wird.

Die Ankündigung, daß Apple einen Screenreader in die nächste Version des Betriebssystems MacOS X einbauen wird, hatte ja gestern schon die Runde gemacht und für einiges Aufsehen gesorgt (mehr dazu bei O'Reilly: Are You Talking to Me? Speech on Mac OS X). Apple sucht nun nach Testern für die Software, insbesondere blinde oder sehbehinderte Menschen und Menschen mit motorischer oder Lernbehinderung. Falls Sie interessiert sind, das Produkt zu verbessern und vielleicht noch bestimmte Dinge berücksichtigt haben möchten, können Sie sich über dieses Formular melden (allerdings in Englisch).