Zum Inhalt springen

Archiv

Kategorie: Web Accessibilty

ZoomTextLaut aisquared’s eigenem Blog steht die Veröffentlichung von ZoomText 10 nun kurz bevor. Einzelne Features der neuen Version werden Tröpfchenweise an die LeserInnenschaft abgegeben.

Darunter finden sich z.B. ein Background Reader, mit dem Dokumente und Webseiten vorgelesen werden können, auch wenn diese nicht im aktuellen Fenster zu sehen sind. Naja, nicht wirklich eine Bahnbrechende neuerung, da ich für so etwas bereits seit langem andere Programme verwende. Auch die Funktion angeschlossene Web-Cams als eine Art Bildschirmlesegerät zu verwenden haut mich nicht wirklich vom Hocker. Dann gibt es da noch den ZoomText Recorder. Damit können Texte als Audio Datei gespeichert, und an mobile Geräte zum späteren anhören übermittelt werden.

Liebe Leute bei aisquared, diese Funktionen werden bei mir schon seit langem von anderen Programmen übernommen. Um mich davon zu überzeugen nochmals in ein aisquared Produkt zu investieren muss schon weitaus mehr geboten werden. Es ist z.B. eine Zumutung dass ZoomText 9 seit über einem Jahr nicht mehr auf den aktuellsten Stand gebracht wird. Die Software ist unbenutzbar mit aktuellen Versionen von Webbrowsern, Dokumentreadern etc. Immer öfter spreche ich mit Kolleginnen und Kollegen die mir sagen, dass sie von aisquared mehr als nur entteuscht sind, und sich um Alternativen umsehen.

Seit langem verwende ich bereits TextAloud um viele der nun als “neu” angekündigten Features von ZoomText 10 abzudecken. Schauen wir einmal, welche neuen Features es sonst noch so geben wird.

Screenshot: Einladung zur Teilnahme an einer Umfrage von MarketMindHeute flatterte mir ein nettes Mail der Firma Marketmind in die Mailbox, die im Auftrag von A1/Bob eine Umfrage zur Tarifgestaltung durchfürt. Neugierig geworden, klickte ich auf den Link zum Umfrage-Formular.

Ok, optisch sah das Formular ja ganz nett aus, nur würde es auch barrierefrei sein? Schon ein einfacher Durchlauf mit Total Validator ergab mehrere automatisch gefundene WCAG 2.0 A Probleme auf der ersten Seite des Formulars. Liebe Web-Entwicklerinnen und -entwickler, fünf Jahre nach einführung des BGstG darf man erwarten, dass zumindest jene Erfolgskriterien, die automtisch geprüft werden können, erfüllt werden.

Gleich zu Beginn wird man, wie in derartigen Umfragen üblich, nach diversen demografischen Daten wie Alter, Geschlecht, Wohnort etc. gefragt. In einem anonymen Fragebogen nichts ungewöhnliches, nur ist dieser hier wirklich anonym? Ich erhielt die Aufforderung zum Mitmachen per e-mail, persönlich mit Namen an mich addressiert. MarketMind erhielt diese Daten, laut eigenen Angaben, von A1 aus deren Kundendaten. Nun konnte ich das besagte Umfrageformular nur mit einer eideutigen ID aufrufen. Mir ist dabei schon bewusst, dass man hier sicherstellen möchte, dass die Umfrage nur von eingeladenen Personen, und hier immer nur einmal, ausgefüllt wird. Der angewendete Mechanismus erlaubt jedoch – zumindest theoretisch – die vorhandenen Kundendaten mit den in der Umfrage eingegebenen Informationen zu verknüpfen. Und tataaa – nichts mehr ist anonym.

Das lustigste kommt jedoch noch. Nach Eingabe der Daten zu meiner Person kam die Frage: “Benutzen Sie ihr Handy eher beruflich oder privat?”. Diese Aussage konnte ich so absolut nur schwer beantworten, ich entschloss mich dann doch dazu, mein Handy eher geschäftlich zu nutzen. Auf der nächsten Seite wurde ich dann mit der Meldung konfrontiert, dass ich aufgrund meiner letzten Antwort leider nicht in die Zielgruppe passe, es aber dennoch sehr nett gewesen sei, dass ich das Formular bis hier ausgefüllt hätte.

Ist das nicht lustig? Ich habe gerade vollkommen “gratis” und auch noch “umsonst” für ein Marktforschungsunternehmen gearbeitet, mich dabei diskriminieren lassen, und sogar noch persönliche Daten preis gegeben.

Die frage ist hier nur, ist der Markt oder ich out of mind?

Weblinks:

Sehr geehrte Damen und Herren,

Ich rezipiere Ihr Web-Angebot täglich und habe bis heute über diverse Accessibility-Probleme versucht hinwegzusehen. Was mir beim heutigen Besuch jedoch untergekommen ist, ließ mich sprachlos.

Bei allem Verständnis dafür, dass Sie den Betrieb der Web-Ausgabe des Standards durch Werbeeinnahmen finanzieren müssen, ist die Vorgehensweise, die Sie heute gewählt haben ein Schlag ins Gesicht für viele Personen mit Seh-Beeinträchtigungen.

Abgesehen davon, dass Sie am Kopf der Seite einen verschwommenen – vermutlich soll dies einen 3d Effekt darstellen – Werbebanner von Telering einblenden, der bei mir tatsächliche Kopfschmerzen ausgelöst hat, haben Sie auch noch das gesamte Farbschema an diese Werbe-Campagne angepasst.

Wenn Ihre Web-Verantwortlichen auch nur einen Hauch von Verständnis hinsichtlich der in Österreich nach dem BGstG anzuwendenden Web Content Accessibility Guidelines der WAI hätten, dann wäre ihnen bewusst, dass derartige verschiedenfärbige Hintergrundgrafiken vor schwarzer, oder in diesem Fall auch roter, Schrift den Text für viele Personen unleserliche macht.

Als Nutzer Ihres Angebotes erwarte ich mir, dass Sie das ursprüngliche Farbchema augenblicklich wieder aktivieren, und somit für mich zugänglich machen.

Von Ihrer Reaktion werde ich es abhängig machen, ein Schlichtungsverfahren wegen Diskriminierung aufgrund von Behinderung im Sinne des BGstG einzuleiten.

Diesen Leserbrief werde ich über die, mir im Internet zur Verfügung stehenden, kanäle auch einem breiteren Publikum zugänglich machen.

MfG. Andreas Jeitler.

Dieser Leserbrief wurde der Web-Redaktion des Standards per e-Mail an info@derStandard.at übermittelt.

Weblinks:

Den Firefox als Universaltool zur Prüfung von Web-Accessibility gibt es nun in Version 4.

Im Rahmen der eAccessibility Initiative des BMKz veröffentlichen wir bereits seit zwei Jahren eine portable Version des Webbrowsers Firefox mit zahlreichen Erweiterungen zur Prüfung der Barrierefreiheit von Webseiten – den AccessyFox. Mit der Version 4.0 des Firefox kommt nun auch eine aktuelle Version des AccessyFox.

Die Idee zu AccessyFox entstand aus dem Bedarf, in Kursen über barrierefreies Web die Teilnehmerinnen und Teilnehmer Evaluierungen eigenhändig durchführen zu lassen. Da es sehr umständlich gewesen wäre, auf allen PCs im Schulungsraum entsprechende Software zu installieren, entschieden wir uns für eine portable Lösung.

AccessyFox kann auf einem USB Stick, einer DVD, einem Netzlaufwerk oder in ein beliebiges Verzeichnis am PC kopiert, und von dort ausgeführt werden. Dabei wird nichts am PC installiert, und nach dem Programmende bleiben keine Spuren zurück. PortableApps.com bietet portable Versionen vieler bekannter OpenSource Projekte. Die portable Version des Firefox, ergänzt durch einige nützliche Erweiterungen, wird dabei zum AccessyFox.

Auf meinem Addon-Account bei Mozilla findet sich eine Sammlung der verwendeten Accessibility-Erweiterungen.

Hinweise auf neue, brauchbare Firefox Erweiterungen werden gerne unter eaccessibility@bmkz.org entgegengenommen.

 

Rein subjektiv ist Chrome der momentan flotteste Browser auf meinem Laptop. Gerade beim Einsatz der sehr langsamen Verbindung von 3 lassen sich Geschwindigkeitsunterschiede beobachten, und das nicht nur beim Seitenaufbau. Und demnächst soll Chrome auf dem N900 von Nokia laufen.

So toll Chrome als Browser auch ist, so schlecht kann man ihn momentan aber mit Hilfsmitteln wie Screen Readern nutzen. Chrom bleibt dabei stumm. Die Zeichen stehen jedoch gut, dass sich dieser Umstand bald ändern wird. Wird Chrome mit dem Aufruf chrome.exe –enable-renderer-accessibility gestartet, so sollen Screen Reader Funktionalitäten aktiviert werden. Ich konnte leider keinen Unterschied feststellen, zumindest nicht was das Lesen von Webseiten betrifft.

Auch wenn Chrome derzeit für Nutzerinnen und Nutzer von Hilfstechnologien eher zweite Wahl ist, so kann man ihn dank diverser Erweiterungen mittlerweile schon recht brauchbar zur Evaluierung der Zugänglichkeit von Webseiten nutzen. Wie Firefox bietet Chrome die Möglichkeit über einfachen Klick Erweiterungen zu installieren, die seine Funktionalität erweitern. Im Gegensatz zu Firefox ist bei der Installation neuer Erweiterungen in der Regel kein Neustart des Browsers nötig, sehr vorbildlich.

Nachfolgend habe ich ein paar dieser Erweiterungen aufgelistet, die mittlerweile fixer Bestandteil meiner Chrome Installation sind:

  • HTML Validator zeigt ähnlich dem HTML Validator von Firefox die Syntaktische Korrektheit des HTML Codes der aktuellen Seite an.
  • HTML5 Outliner zeigt ähnlich der Headings Map in Firefox die Struktur der Aktuellen Seite. Nach der Installation findet man in der URL-Eingabeleiste ein neues Symbol. Wird dieses angeklickt, so wird ein Inhaltsverzeichnis der Seite angezeigt.
  • Web Developer entspricht der Gleichnamigen Erweiterung im Firefox.
  • Pendule bietet weitere nützliche Funktionen zur Entwicklung barrierefreierer Webseiten.

Auf der Google Chrome Seite des Inclusion.cc Wiki werden wir zukünftig eine Liste der Erweiterungen für Chrome pflegen.

Wer Chrome (weil es von Google ist) nicht mag, der oder die kann auch die entgooglisierte Version Iron probieren, denn der Code von Chrome ist ja Open Source.

Update: 4.4.2011

  • ChromeLite – Zeigt den Inhalt einer Website in reinem Text.
  • Resolution Test – Wie Sieht eine Website in bestimmten Auflösungen aus?

Web-Entwicklungs Tools, die nicht direkt etwas mit Accessibility zu tun haben, aber dennoch praktisch sind:

Am 9. April wird der CSS Naked Day gefeiert. Ziel ist es auf die korrekte Nutzung von Web Standards aufmerksam zu machen. Websites deaktivieren ihre Stylesheets (CSS), wodurch nur mehr die blanke Struktur einer Seite zu sehen ist. Wurde auf die korrekte Anwendung von zum Beispiel XHTML geachtet, so sollten sich Besucherinnen und Besucher auf der Seite nach wie vor noch gut zurecht finden.

Auch nach dem CSS Naked Day kann man sich Webseiten nackt ansehen. Die meisten Browser bieten entweder von Haus aus eine Funktion zum Deaktivieren von Stylesheets oder es gibt eine Erweiterung die diese Funktionalität bereitstwellt.

Links zum CSS Naked Day:

Microformats sind eine Methode, um HTML Seiten mit zusätzlichen (semantischen) Informationen anzureichern. Dabei werden beispielsweise Tag Attribute wie “class” eingesetzt um diese Informationen darzustellen. Auf diese Weise ist es z.B. möglich, eine Visitenkarte im vcard Format in eine Website einzubinden.

Vom W3C sind Microformats nicht sehr gerne gesehen, da verschiedene Eigenschaften von HTML außerhalb des, ihnen ursprünglich zugedachten Zweckes verwendet werden.

So sinnvoll ich Microformats auch finde, so muss ich doch den Damen und Herren vom W3C in gewissem Maße zustimmen.

Die Seite über das abbr Design Pattern auf microformats.org beschreibt wie das Abbr Tag dafür verwendet werden kann, maschinen-lesbare Datums-Informationen über das Title Attribug von des abbr Tags zu kodieren. Dadurch wird der ursprüngliche sinn des abbr Tags (für Abkürzungen) außer Kraft gesetzt, und eine Nutzung durch Screen Reader erschwert.

HTML Tags sollten immer dafür verwendet werden, wofür sie laut Spezifikation geplant sind.

Das schöne an der Microformats-Gemeinde ist jedoch, dass das Problem erkannt und auf der zugehörigen Wiki-Seite diskutiert wurde. Ferner wurden alternative Lösungsansätze angesprochen.

Tag Clouds sind Begriff-Wolken die auf Delicious, Flickr und Co anzeigen wie häufig ein Begriff in Artikeln, Bildern etc. vorkommt. Je öfter ein Begriff genutzt wird (je beliebter er ist) desto größer ist die Schrift mit der er  in der Wolke dargestellt wird.

Visuell erfüllen Tag-Clouds durchaus ihren sinn. Wie sieht es aber in Hinblick auf die Barrierefreiheit aus?

Mark Norman Francis hat in seinem Blog Artikel “Marking Up a Tag Cloud” einige interessante Ideen dazu.

Sein Lösungsvorschlag sieht grundsätzlich so aus, dass er eine alphabetische Liste der Begriffe erzeugt, und jedem Eintrag die semantische Information mitgibt, wie oft das Tag genutzt wurde. Grafisch werden CSS Klassen definiert, die für die Größe des dargestellten Zeichensatzes verantwortlich sind.

Die Tag-Cloud als Designpattern gibt es auf ui-patterns.com.