Artikel-Schlagworte: „Barrierefreiheit“

Barrierefreiheits-Supergau beim Online-Banking der Sparda-Bank

Montag, 31. Mai 2010

Die Sparda-Bank Hamburg hat ein neues Online-Banking bekommen. Als ich mich dort heute morgen einloggen wollte, erlebte ich eine böse Überraschung.

Das erste, was ich bemerkte, war, dass der Login-Button auf der neuen Startseite des Online-Banking mir als “/portalstatic/spm/gfx/style/buttons/buttonFlach_Jetzt_einloggen.png [Schalter]” vorgelesen wurde. Sämtliche Labels waren den Eingabefeldern aber weiterhin korrekt zugeordnet, und sogar das Audio-Captcha zur Eingabe des Sicherheitscodes war weiterhin vorhanden.

Nachdem ich das Login durchgeführt hatte, erwartete mich dann aber die richtig böse Überraschung. Die ganze Seite ist gepflastert mit grafischen Links, die sich so oder ähnlich anhören: “04_SB8K8xLLM9MSSzPy8xBz9CP0os3gDU3cvAw93IwP3EFMTA08LH0NzC19jAwNfI_2CbEdFAH8_-FQ! [Grafik Link]“. Wenn mir daraus jemand ableiten kann, was dieser spezielle Link tut, ist er/sie gut! :-)

Ich schrieb daraufhin eine Mail an das Service-Team.

Nachdem ich dann auf Twitter mehrere Beobachtungen mitgeteilt hatte und auch unverholen mein Entsetzen über dieses Bremsen von 100% auf 0% Barrierefreiheit zum Ausdruck gebracht hatte, erhielt ich diesen Hinweis von der Sparda-Bank Nürnberg:

@MarcoZehe den barrierefreien Zugang zum SpardaNet-Banking gibt es bei Bedarf weiterhin. Kurze Mail an den Support dann gibt es den Link.

Es stellte sich heraus, dass die Mail an den Support nicht notwendig war. Auf der oben bereits erwähnten neuen Startseite des “modernen” Sparda Banking gibt es folgenden Absatz: “Hier melden Sie sich für kurze Zeit noch im Classic Banking an.” Es folgt ein grafisch nicht korrekt ausgezeichneter Link zum bisher gewohnten Banking.

Wer aufmerksam gelesen hat, dem ist das “für kurze Zeit” in dem obigen Zitat nicht entgangen! Wie lang wird diese Zeit sein? Ein Monat? Sechs Monate? Ein Jahr? Eine Woche?

Und nun kommen wir zum eigentlichen Grund, warum dieser Relaunch des Online-Bankings ein technischer und PR-mäßiger Super-Gau ist.

Wir schreiben das Jahr 2010. Seit über 10 Jahren predigen Organisationen wie von der Aktion Mensch und viele engagierte und technisch sehr gute Webentwickler und -agenturen die Standards der Barrierefreiheit im Webdesign und der Webprogrammierung. Seit 1999 gibt es die WCAG 1.0 des W3C, die im Dezember 2008 durch die WCAG 2.0 ersetzt wurden. Die BITV 1.0 soll noch in diesem Jahr durch die BITV 2.0 ersetzt werden. Unternehmen wie Amazon.de haben es seit Jahren nicht mehr nötig, alternative Textversionen für ihre Angebote anzubieten.

Und hier kommt ein Relaunch, der eine 100%ige Rückwärtsrolle von einem vorbildlichen(!) Online-Banking hin zu einem tut, der für Anwender assistiver Technologien überhaupt nicht mehr bedienbar ist. Und ein Verweis auf eine Alternativfersion, die der vorbildlichen Vorversion entspricht, von der aber nicht klar ist, wie lange diese tatsächlich noch weiter existieren bzw. gepflegt werden wird.

Zum einen ist es schon immer betriebswirtschaftlich und organisatorisch sehr unklug gewesen, Alternativversionen für bestimmte Personenkreise zur Verfügung zu stellen. Die Erfahrung zeigt, dass diese alternativen Angebote gern bei Aktualisierungen vergessen werden. Nun ist diese Aktualisierung bei einem Onlinebanking-Portal vielleicht nicht ganz so häufig wie z. B. auf einer Seite wie Amazon oder irgendeinem Newsportal. Aber es bleibt das Gefühl, man könnte was verpassen. Den größten Gau in diesem Bereich leistet sich GoogleMail, wo nämlich die für Blinde konzipierte HTML-Version viele(!) der Features des Standard-Interface komplett nicht zur Verfügung stellt.

Zweitens ist es betriebswirtschaftlich schlicht unvernünftig, im Jahr 2010 die Barrierefreiheit nicht gleich ins Grundkonzept mit aufzunehmen. Die Gesellschaft wird immer älter, und die Barrierefreiheit betrifft nicht nur Blinde, sondern Menschen mit allen möglichen Einschränkungen, von denen viele mit zunehmendem Alter auftreten. Weiterhin kommen immer mehr Senioren ins Netz, die darauf angewiesen sind, dass sie mit ihren Möglichkeiten der Maus- und Tastaturbedienung die Angebote bedienen können. Und auch Pensionäre machen Online-Banking! Und ich wage mal die Behauptung, dass die Damen und Herren im Management, die diese Entscheidungen die Sparda-Bank betreffend zu fällen haben, entweder schon selbst in einem Alter sind, wo diese Aussagen bald zutreffen könnten, oder Eltern haben, bei denen sie diese Notwendigkeit beobachten können. Man muss keine Menschen mit Behinderungen kennen, man braucht sich nur in der eigenen Familie oder Verwandtschaft umschauen!

Eine Agentur mit entsprechendem Know-How hätte das neue Online-Banking von vornherein barrierefrei gestalten können, und es hätte trotzdem “chic” ausgesehen. Diese Agenturen gibt es in Deutschland. Hier wurde jedoch offensichtlich eine Agentur gewählt, die dieses Know-How entweder nicht besitzt oder die Wichtigkeit einer inklusiven Vorgehensweise nicht herausgestellt hat. Initial wäre das Angebot vielleicht etwas teurer geworden. Aber das, was da jetzt betrieben werden muss, ist auf lange Sicht teurer:

Entweder lässt man den barrierefreien Zugang unbegrenzt(!) weiterlaufen und muss so immer zwei Angebote auf dem aktuellen Stand halten.

Oder man muss die Barrierefreiheit jetzt per Flickschusterei nachrüsten, also eine des Projektes einleiten, um irgendwann den barrierefreien Zugang abschalten und die Phase 2 des neuen, dann barrierefreien Zugangs, ersetzen zu können. Eine Phase 2 kostet immer mehr Geld als eine inkludierende Vorgehensweise gekostet hätte.

Bis zum Tag diesses Relaunches war die Sparda-Bank ein Vorbild an Barrierefreiheit, von dem sich so manch andere Bank in Deutschland mindestens eine dicke Scheibe hätte abschneiden können. Unter anderem deshalb habe ich die Sparda auch zu meiner hausbank erklärt.

Ich fordere die Verantwortlichen hiermit auf, zu dieser Vorbildfunktion zurückzukehren und dieses Onlinebanking-Portal barrierefrei gestalten zu lassen. Denn noch muss ich davon ausgehen, dass der von mir oben zitierte Satz von der Startseite ernstzunehmen ist und der Classic-Zugang tatsächlich nicht ewig bestehen bleibt. Und in diesem Moment wären diverse Kunden von der Teilhabe am Geschäftsleben über die Sparda-Bank ausgeschlossen!

P.S.: Während ich diesen Artikel schrieb, erhielt ich eine Antwort vom Service-Team mit dem Link zum Classic-Banking. Im Gegensatz zur oben zitierten Startseite war hier, wie auch in der zitierten Twitter-Antwort, nicht die Rede von einerzeitlichen Begrenzung.

Die neue Browserauswahlfunktion für Windows berücksichtigt keine Aspekte der Barrierefreiheit!

Dienstag, 23. Februar 2010

Nachdem Microsoft von der Europäischen Union verurteilt wurde, den Anwendern eine Auswahl an Browsern zur Verfügung zu stellen, wird diese Funktion nun in diesen Tagen allen Anwendern von Windows Vista und Windows 7 per Update zur Verfügung gestellt werden. Diese neue Browserauswahl kann sich jedoch für Anwender assistiver Technologien zu einer bösen Falle entpuppen!

Die Seite stellt nämlich keinerlei Informationen zur Verfügung, welche Browser für Blinde und andere Gruppen von Behinderten überhaupt geeignet sind. So wird aus der Auswahl Internet Explorer, Firefox, Safari, Opera und Chrome nämlich eine Wahl zwischen genau ZWEI Browsern, Internet Explorer und Firefox, wenn es unter Windows um die Belange behinderter Menschen geht. Es gibt nicht mal versteckten Text, der nur für Anwender von Bildschirmleseprogrammen hörbar wäre, der auf diesen Umstand hinweisen würde.

Wenn jetzt also ein Anwender den einzigen Browser mit Turbo-Technologie, den innovativsten Browser der Welt oder den neuen Browser für alle installiert und diesen als Standardbrowser festlegt, wird er web-technisch im Dunkeln sitzen. Screen Reader und Vergrößerungsprogramme kommen mit diesen Browsern nicht zurecht, weil diese die erforderlichen Schnittstellen nicht unterstützen. Um diese Entscheidung wieder rückgängig zu machen, muss ein Browserfenster aufgerufen werden. Ohne sehende Hilfe ist dann in der Regel nichts mehr zu machen.

Ich habe mit dem Marketing-Team bei Mozilla zusammen eine Eingabe erarbeitet, damit dieser Punkt berücksichtigt wird. Andere Hersteller und die EU waren da offensichtlich anderer Meinung und haben der Nutzerschaft, die auf Barrierefreiheit angewiesen ist, somit einen Bärendienst erwiesen. Vielen Dank dafür! :(

Und hier die Bitte an alle Leser, diese Info an alle Betroffenen im Freundes- und Bekanntenkreis weiterzugeben! Diese verlinkte Seite wird in den nächsten Tagen auf vielen Rechnern aufgerufen werden, und es ist wichtig, sich hier nicht durch fehlende Hinweise selbst ein Bein zu stellen! Vielen Dank schon im Voraus für eure Mithilfe!

Die deutsche Bank hat relauncht — oh Gott!

Freitag, 5. Februar 2010

Die Deutsche Bank hat ihre Webseite relauncht. Hier sind meine Beobachtungen von Anschauen nur der Hauptseite. Da ich kein Kunde bei diesem Kreditinstitut bin, kann ich Dinge wie das Online-Banking nicht testen. Aber allein der Eindruck der Startseite spricht Bände.

“Unsere vielen Sprungmarken gib uns heute”…Schon fast rekordverdächtig ist die Flut an Sprungmarken, die einen gleich am Anfang der Seite begrüßt. Sechs Stück sind es, und sie sind ausschließlich englischsprachig. Sie fangen alle mit “Jump to…” an, und sie haben so aussagekräftige Namen wie “Meta Navigation“.

Es folgt: “Index” link, “Index Grafik”, “Jahres-Pressekonferent am 4. Februar 2010 Grafik”. OK.

Es folgt eine Liste mit “Kontakt”, “Site Map” usw., Aha, das ist dann wohl die “Meta Navigation”.

“/de/img/tran_pxl.gif Schalter”. Aaaah ja.

“Eingabefeld Volltextsuche” OK.

Es folgen dann noch diverse Listen mit verschiedenen Möglichkeiten sich über Privatkunden, Private Banking, Geschäftskunden, Jobs o. ä. zu informieren.

Es gibt einen Impressumsbereich. Es gibt einen Link zu “Accessibility“. Es gibt jede Menge Kurztasten.

Und es gibt sogar einen Hauptteil, wie die eine Sprungmarke am Seitenanfang vermuten lässt. Hineingeklatscht zwischen zwei navigationslisten eine Abfolge von Links, nicht strukturiert, von Pressemitteilungen. OK, kann man so machen…

Ganz am Ende findet sich sogar noch die Möglichkeit einer Kontraständerung. Da ich das nicht überprüfen kann, hab ich’s mal nicht ausprobiert.

Es gibt auf dieser Startseite keinen einzigen(!) heading-Tag.

Ich habe mich dann mal getraut und den Link “Privatkunden” angeklickt.

Es gibt Überschriften! Sogar mehrere, und Unterüberschriften mit niedrigerer Ordnungsebene als die darüber liegenden Abschnitte! Und alle so: Yeah! :)

Und es gibt so etwas hier in verschiedener Form: “Link grafik pk-kredit_finanzierung-privatkredit link=pk-index-privatkredit-pbc1400b-pbcde-to-pk-kredit_finanzierung-privatkredit&WT.mc_id=1400&mc_wm=b&mc_wp=90″. Vielen Dank für das Gespräch!

Auf dieser Seite gibt es dann auch tatsächlich mehrere Formularfelder mit sogar richtig beschrifteten Schaltern.

Fazit: Dieser Relaunch ist eine ausgesprochene Peinlichkeit! Dass es im Jahr 2010 in Deutschland noch möglich ist, einen solchen Relaunch mit so offensichtlichen Fehlern in der Barrierefreiheit hinzulegen, ist unter aller Würde und durch NICHTS zu rechtfertigen! Und hier sind eventuelle Probleme für Sehbehinderte noch gar nicht berücksichtigt, und den Quellcode der Seite habe ich mir auch nur flüchtig angeschaut. Es wird zumindest nicht mit Layouttabellen gearbeitet.

Die Deutsche Bank hat im vergangenen Jahr einen Gewinn vor Steuern von 5 milliarden Euro erzielt. Einige Tausend Euro weniger Gewinn hätten dem Webseiten-Relaunch mit Sicherheit nicht geschadet, indem nämlich eine Agentur damit beauftragt worden wäre, die sich damit auskennt.

Setzen: 6!

Anwendungstipp: Geburtstagsverwaltung und Online-Banking-Anwendungen fürs iPhone

Mittwoch, 13. Januar 2010

Gestern bin ich auf zwei Anwendungen gestoßen, die ich sehr nützlich finde und die fast komplett mit VoiceOver bedienbar sind.

Die erste ist eine Geburts- und Feiertagsverwaltung namens Occasions. Die Anwendung erstellt aus den in den Kontakten hinterlegten Geburtstagen eine Liste und kann den Benutzer an die Geburtstage erinnern. Nett: Es wird das Alter gleich mit angezeigt. Das Programm kann auch Geburtstage von FaceBook abfragen und ebenfalls in die Liste aufnehmen. Eigene Ereignisse und auch Geburtstage für Kontakte können aus der Anwendung heraus nachgetragen werden.

Einziger Haken ist, man muss das Theme von “Wasser” auf “Standard” umstellen. Erst dann bekommen die meisten Schalter eine vernünftige Beschriftung und das Arbeiten mit der Anwendung läuft flüssig. Lobend erwähnen möchte ich in diesem Zusammenhang den Support des Herstellers Hand Carved Code. Ich hatte Verbesserungsvorschläge inklusive dem Link zum iPhone Accessibility Programming Guide per E-Mail an den Support geschickt. Innerhalb von 10 Minuten bekam ich eine Antwort mit dem Tipp, das Theme umzustellen und mit der Ankündigung, Verbesserungen für VoiceOver mit in die Liste von Kundenwünscen aufzunehmen. Hierfür gab’s von mir dann eine 4-Sterne-Rezension im App Store.

Die zweite Anwendung wurde von @GermanStudent empfohlen: iOutBank Pro ist eine Online-Banking-Anwendung, die diverse Banken unterstützt. Auf OutBank.de kann man anhand der Bankleitzahl überprüfen, ob die eigene Bank unterstützt wird. Die Anwendung kostet nur heute (am 13.01.2010) 0,79 € anstatt 6,99€, weil die Anwendung heute ihren ersten Geburtstag feiert.

Die Anmeldung meiner Bankdaten klappte problemlos. Das Ansehen der Kontoumsätze war ebenfalls problemlos möglich, und das Überweisungsformular sieht auch so aus, dass VoiceOver damit prima zurechtkommt. Es fehlen einige Schalterbeschriftungen, und die Anwendung hat die Eigenart, dass man sie nicht gut mit der Geste “Nach links Streichen” bzw. “Nach rechts Streichen” untersuchen kann, sondern den Bildschirm mit dem Finger systematisch absuchen muss, um die Elemente zu erreichen. Für diese zwei Proleme gab es in der ansonsten uneingeschränkt positiven Rezension 1 Stern Abzug von mir, die Bedienung ist aber trotzdem sehr gut und intuitiv gelöst.

Diese zwei Anwendungen haben mein iPhone-Leben definitiv wieder bereichert, und ich freue mich darüber, dass sie von Haus aus schon so weit barrierefrei sind! Ich hoffe natürlich, dass die Entwickler der Anwendungen die verbleibenden Probleme schnell beheben, damit es dann auch 5 Sterne von mir geben kann. ;)

Warum sind Webforen bei Blinden so unbeliebt?

Donnerstag, 9. April 2009

Ende vergangener Woche erhielten mein Kollege David Tenser, Kadir Topal (Übersetzer für die deutsche Firefox-Version) und ich eine E-Mail von Dirk, einem Moderator bei BLINDzeln. BLINDzeln ist eine Mailinglisten-Plattform, in der sich hauptsächlich deutschsprachige Blinde und Sehbehinderte über so vielfältige Themen wie das Kochen, Psychologie oder auch Themen aus dem Informatikbereich austauschen. Dirk fragte uns, ob es möglich sei, deutschsprachige Mailinglisten einzurichten, in denen die Barrierefreiheitsfunktionen der Mozilla-Plattform diskutiert werden könnten. Dies würde denjenigen, die auf den Firefox oder Thunderbird umgestellt haben, oder dies tun möchten, eine gemeinsame Anlaufstelle. Er sagte ebenfalls, dass er und andere Moderatoren überlegt hätten, eine solche Mailingliste bei BLINDzeln einzurichten, davon aber abgesehen haben, weil dies eine Insellösung darstellen würde, die den potentiellen Austausch mit anderen Mitgliedern der Mozilla-Community nicht fördern würde. Daher fragte er an, ob Mozilla solche Mailinglisten auf unseren Servern einrichten könnte.

In dem Austausch, der sich daraufhin entwickelte, wurden im wesentlichen zwei Positionen deutlich:

  • Auf der einen Seite wurde deutlich gemacht, dass blinde Anwender anscheinend Mailinglisten über alle Maßen anderen Möglichkeiten zur Kommunikation, die das Internet bietet, vorziehen, und dass dies das am leichtesten zugängliche Medium ist. Dies hat viel für sich, denn für das Eintragen in eine Mailingliste braucht man nicht einmal einen Webbrowser. Wenn man die Adresse der Mailingliste kennt, braucht man nur eine Eintragunsanforderung zu schicken und diese zu bestätigen. Hierfür muss man lediglich die Funktionen zum Verfassen einer Mail und die Antwortfunktion seines bevorzugten E-Mail-Programmes kennen. Webforen werden andererseits oft durch unzugängliche grafische Sicherheitscodes abgesichert, und die Anzeige von Themen wird von vielen als höchst ineffizient und schwer navigierbar empfunden. Internet-Newsgroups befinden sich irgendwo dazwischen. Hier ist es meistens die “Netzpolizei”, die auf dem strengen Einhalten der Netiquette pocht, die gerade Anfänger oft vergrault.
  • Auf der anderen Seite machten sich David und Kadir für support.mozilla.com (Sumo) bzw. das deutschsprachige firefox-browser.de Communityforum stark. Sie führten unter anderem an, dass die meisten beruflichen und freiwilligen Communitymitglieder, die Endanwendern helfen, sich hauptsächlich bei Sumo und den Communityforen herumtreiben, jedoch kaum auf Mailinglisten zu finden sind. Kadir und ich sprachen im IRC ebenfalls über dieses Thema, und andere, die sich an der Diskussion beteiligten, benutzten teilweise sogar Wörter wie “hassen”, wenn es um Mailinglisten ging.

Ich habe ein bisschen geforscht und festgestellt, dass es eine große Diskrepanz darin gibt, wer welches Medium gern nutzt. Mozillianer, also diejenigen, die sich hauptberuflich oder stark freiwillig engagiert mit der Entwicklung der Mozilla-Produkte beschäftigen, sind fast ausschließlich in den Mozilla-spezifischen Mailinglisten zu finden, um Entwicklungsplanung, projektspezifische Diskussionen zu führen usw. Diese Mailinglisten werden in Newsgroups und Google Groups gespiegelt. Mailinglisten auf der einen, und die fast forenartige Darstellung von Google Groups auf der anderen Seite bietet also eine sehr vielfältige Möglichkeit des Zugriffs. Es gibt hier jedoch kaum Endanwender. Es gibt zwar Support-Gruppen, aber im Vergleich zu Foren wie bei firefox-browser.de oder MozillaZine ist das Nachrichtenaufkommen fast vernachlässigbar.

In anderen Bereichen habe ich ungefähr dasselbe Bild vorgefunden: Je mehr endbenutzer-orientiert die Zielgruppe ist, desto beliebter sind Webforen. Je technischer orientiert das Zielpublikum ist, desto beliebter sind Mailinglisten. OK, die meisten Mailinglisten haben ein webbasiertes Archiv, aber diese Archive sind nicht unumstritten. In der oben erwähnten Diskussion im IRC hat ein Teilnehmer angemerkt, dass er die Foren z. B. auf Heise Online oder die typischen Mailman-Archive hasst, weil diese immer nur ein Posting zur Zeit anzeigen und er ständig klicken muss, um ein Thema durchzulesen. Und diese Person halte ich für technisch sehr versiert.

Interessanterweise wurden in den Ergebnissen der Screen-Reader-Umfrage, die Webaim kürzlich durchgeführt hat, Webforen in keiner der Listen für besonders zugängliche oder besonders unzugängliche Webseiten erwähnt.

Was ist es also, das blinde Anwender so überdurchschnittlich hoch Mailinglisten gegenüber dem bevorzugt, was sonst so Mainstream im Internet ist? Sind Webforen von Natur aus unzugänglich? Oder ist dies ein Mythos, der sich hält, wo sich das tatsächliche Bild geändert hat, die Blindengemeinde dies jedoch schlicht und einfach verschlafen hat?

Zugegeben, dies sind provokante Fragen. Eines der Dinge, die Blinde in Mailinglisten treiben könnte, und was auch lange Zeit der Grund für mich war, mich so gut wie gar nicht an Foren zu beteiligen, ist die spaghetti-artige Darstellung von Forumsthemen speziell in älteren Versionen von Forensoftware. Es ist sehr schwer, den Anfang eines neuen Posts zu finden, um z. B. das Lesen des aktuellen Posts zu unterbrechen, weil er nicht von Interesse ist. Da Blinde Forenbeiträge nicht visuell quer lesen können wie Sehende, ist dies eine sehr wichtige Funktion zur effizienten Navigation und Beteiligung in Webforen.

Folgend ein paar Beispiele von Ansichten von Forumsthemen, die darüber Aufschluss geben könnten, warum Blinde Foren nicht mögen, und auch solche, warum dies nicht mehr unbedingt ein berechtigter Vorbehalt sein muss.

  • In diesem Thema im MozillaZine-Forum (englischsprachig) beginnt jeder neue Beitrag innerhalb des Themas bei einem neuen Eintrag einer großen Definitionsliste. Da jedoch die zur Verfügung stehenden Aktionen wie “Reply…” ebenfalls innerhalb von hierin verschachtelten Listen stehen, kann man nicht einfach mit einer Schnellnavigationstaste von Listeneintrag zu Listeneintrag springen, um den Anfang des nächsten Beitrags zu finden.
  • Dieser Beitrag in der phpbb.com Community zeigt auf, wie man es richtig macht. Jede Antwort beginnt bei einer neuen Überschrift, so dass man ganz leicht zur nächsten Antwort springen kann, wenn man die aktuelle Antwort nicht zu ende lesen möchte. Da sowohl phpbb.com als auch MozillaZine auf phpBB basieren, scheint dies eine Frage des Themings zu sein.
  • Ebenfalls auf phpBB basierend, jedoch auf einer älteren Version, ist dieser Beitrag in den Foren der Delphi-Praxis. Dies ist der spaghetti-artige Aufbau, den ich vorher schon erwähnte: Es wird eine HTML-Tabelle verwendet, und jeder Beitrag bekommt seine eigene Tabellenzeile. Screen Reader verfügen zwar über Tastenkombinationen, um sich durch Datentabellen zu bewegen, diese sind jedoch nicht so komfortabel zu greifen wie die Navigation durch Überschriften o. ä. Das Interagieren mit einer Datentabelle ist immer eine bewusste Entscheidung, kein beiläufiger Handgriff, wie er beim Lesen eines Forums eher angebracht ist. Ähnlich tabellarische Darstellungen habe ich auch schon bei Foren gesehen, die auf dem System VBulletin basieren, als auch bei dem Carookee.com Forenservice. Das deutsche firefox-browser.de-Forum verwendet zur Zeit noch eine ähnliche Darstellung von Themen. Dies wird sich aber in den nächsten Wochen ändern, wenn das Forum auf phpBB Version 3 umgestellt wird.
  • Wenn man sich bbPress anschaut, das Schwesterprojekt zur WordPress Blogsoftware, so verwendet dieses ebenfalls eine Listendarstellung von Forenthemen. Hier gibt es jedoch keine eingestreuten Listen, so dass man prima von der aktuellen Position schnell zum Beginn des nächsten Beitrages springen kann, indem man einfach zum nächsten Listenelement springt.
  • Zuletzt noch ein Blick auf ein Sumo-Thema: Dieses zeigt einen ähnlich spaghetti-haften Aufbau. Die Beiträge werden lediglich durch bestimmt gestilte Div-Elemente voneinander getrennt, es gibt jedoch kein semantisch eindeutiges Element, zu dem man navigieren könnte. Der einzige Unterschied besteht also darin, dass hier Div-Elemente anstatt von Layouttabellen verwendet werden.

Hinweis: Die oben ausgewählten Themen und die Kommentare zur Güte der Anzeigestile sagt nichts über die Qualität der individuellen Foren an sich oder deren Mitglieder aus.

Wie das Beispiel der phpBB Community oder das von bbPress zeigen, gibt es gute Beispiele mit schnellen Navigationsmöglichkeiten, die Forensoftware auch für blinde Benutzer attraktiv machen. Es gibt jedoch auch immer noch viele Forumsinstallationen, deren Anzeige für Blinde zur Navigation sehr abschreckend wirken und keinen Barrierefreiheitsstandards entsprechen.

Ein Thema, das ich auch kurz ansprach, sind grafische Sicherheitscodes. Mit einer Firefox-Erweiterung wie WebVisum sind die meisten dieser Codes lösbar. Außerdem verbreiten sich Audioalternativen immer mehr, so dass dies eine Barriere ist, die mit entsprechenden Werkzeugen inzwischen zum Glück gut zu meistern ist.

Und jetzt würde ich gern eure Meinung zum Thema hören! Bevorzugt ihr Mailinglisten vor Newsgroups und Webforen? Welche Herausforderungen und Barrieren machen euch die Benutzung von Webforen schwer? Findet ihr leicht den Faden wieder, wenn neue Beiträge zu einem Thema hinzugekommen sind? Lest ihr lieber im Web, im E-Mail-Programm oder im RSS-Aggregator?

Auf der anderen Seite: Was schreckt euch als Forenbenutzer von Mailinglisten oder Newsgroups ab, oder bewegt euch sogar zu der Aussage, sie zu “hassen”?

Freue mich auf eure Kommentare!

Firefox 3.0.2: Verbesserungen bei den Barrierefreiheitsfunktionen

Mittwoch, 24. September 2008

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

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

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

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

Mittwoch, 27. August 2008

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

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

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

Ein Entwicklerjob im Bereich Mozilla Accessibility zu vergeben!

Montag, 25. August 2008

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

Firefox 3.1 liefert Textattribute an Screen Reader

Sonntag, 20. Juli 2008

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

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


getAttributes(1) = NULL

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

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


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

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

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

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

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

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

Einfaches ARIA Tip #2: aria-invalid und role “alert”

Samstag, 19. Juli 2008

Mein zweiter Tip rund um ARIA (Accessible Rich Internet Applications) beschäftigt sich mit einem Problem, das wohl jedem von uns beim Ausfüllen eines Formulars schon mal begegnet ist: Man vertippt sich bei der E-Mail-Adresse bzw. der eventuell geforderten Wiederholung davon, oder ähnliches passiert beim Kennwort. Man hat vielleicht vergessen, ein erforderliches Feld gänzlich auszufüllen. Man hat also fleißig seine 20 Felder ausgefüllt, drückt den Schalter “Abschicken”, und dann kommt der Server mit einer oder mehreren Fehlermeldungen zurück, und man muss die Formularfelder korrigieren und die übrigen nochmals durchgehen um sicherzustellen, dass keine Informationen zurückgesetzt oder entfernt wurden.

Wäre es da nicht schön, wenn man ein Formular so umgestalten könnte, dass Fehler sofort erkannt würden und man darauf hingewiesen werden würde? Mit dem Einsatz von ARIA ist dies kein Problem!

Das Formular

Als Beispiel soll folgendes einfaches Kontaktformular herhalten:

<html>
<head>
<title>Kontaktformular</title>
</head>
<body>
<form method="post" action="post.php">
<fieldset><legend>Bitte gib deine Kontaktdaten an</legend>
<label for="name">Dein Name (erforderlich):</label>
<input name="name" id="name" aria-required="true"/><br />
<label for="email">E-Mail-Adresse (erforderlich):</label>
<input name="email" id="email" aria-required="true"/><br />
<label for="website">Website (optional):</label>
<input name="website" id="website"/>
</fieldset>
<label for="message">Bitte gib deine Nachricht ein (erforderlich):</label><br />
<textarea name="message" id="message" rows="5" cols="80" aria-required="true"></textarea><br />
<input type="submit" name="submit" value="Nachricht abschicken"/>
<input type="reset" name="reset" value="Formular zurücksetzen"/>
</form>
</body>
</html>

Nichts Großes, aber wir wollen damit ja auch keinen Schönheitswettbewerb gewinnen. ;-) Einzige Besonderheit ist das Attribut aria-required, welches ich bereits früher ausführlich behandelt habe.

Der Hinweis, dass etwas fehlerhaft eingegeben wurde

Ziel ist es, sowohl beim Feld “Name” als auch beim Feld “E-Mail-Adresse” einen Hinweis zu geben, wenn eine fehlerhafte Eingabe entdeckt wurde. Hierzu testen wir, ob im namen ein Leerzeichen vorkommt (es sind also mindestens Vor- und Nachname erforderlich), und ob in der E-Mail-Adresse das “@”-Zeichen vorkommt. Ist die Eingabe fehlerhaft, so wird zum einen das Feld selbst mit dem Attribut aria-invalid versehen, dessen Wert auf “true” gesetzt wird. Dies bewirkt, dass aktuelle Screen Reader das Feld als eines mit einer ungültigen Eingabe versehenen identifizieren können. Zum anderen wird unterhalb des Formulars eine kleine Box eingeblendet, die einen entsprechenden Hinweis auf den Fehler enthält. Diese Box, die mit einem einfachen div-Element gestaltet wird, bekommt durch das role-Attribut die Rolle eines sogenannten Alerts, eines Hinweises. Dies verhält sich dann entsprechend der aus Firefox 3 bekannten Hinweismeldung “Soll Firefox dieses Passwort speichern?”. Der Fokus wird nicht zu diesem Hinweistext verschoben, es kommt auch kein Dialogfeld hoch, das man erst wegdrücken muss, sondern der Hinweis wird im Laufenden Vorgang des Ausfüllens des Formulars gegeben und man kann sofort weiterarbeiten.

Das ganze passiert in dem Moment, wo der Anwender den Fokus von dem entsprechenden Eingabefeld weg bewegt, es also den Fokus verliert. JavaScript-versierte ahnen es: Dies geschieht durch das onblur-Ereignis, welches immer dann ausgelöst wird, wenn ein Element den Tastaturfokus verliert. Im Kopf der HTML-Datei definieren wir uns jetzt also drei helfende Funktionen:

  1. removeOldAlert: Diese Funktion entfernt lediglich den vom letzten Fehler aufgegangenen Hinweis. Dieser wird entfernt, wenn entweder ein neuer Hinweis erscheinen soll oder der Fehler erfolgreich korrigiert wurde.
  2. addAlert: Diese Funktion fügt einen Hinweis in das Dokument ein. Sie entfernt dazu zunächst alte eventuell noch vorhandene Hinweise, erzeugt ein div-Element und gibt diesem zwei Attribute: Eine ID, mit der das Element später wiedergefunden werden kann, und das bereits erwähnte Attribut role. Schlussendlich wird der übergebene Text als Inhalt des divs eingefügt und das gesamte Element dem Dokument hinzugefügt. Alles weitere, sprich das Auslösen des Alert-Ereignisses wird automatisch durch Firefox veranlasst, wir müssen uns hier um nichts weiter kümmern.
  3. checkValidity: Diese Funktion ist das eigentliche Herzstück. Sie sucht zunächst innerhalb des durch den Parameter aID angegebenen Elements nach dem als aSearchTerm übergebenen Suchbegriffs. Ist diese Suche nicht erfolgreich, wurde also eine ungültige Eingabe getätigt, werden die oben beschriebenen Schritte zur Kenntlichmachung der Ungültigkeit eingeleitet. Ist die Suche hingegen erfolgreich, der Eintrag also nicht ungültig, werden eventuelle Hinweise entfernt und das Attribut aria-invalid auf “false” gesetzt.

Der zugehörige JavaScript-Code sieht wie folgt aus:


<script type="application/javascript">
  function removeOldAlert()
  {
    var oldAlert = document.getElementById("alert");
    if (oldAlert)
      document.body.removeChild(oldAlert);
  }

  function addAlert(aMsg)
  {
    removeOldAlert();
    var newAlert = document.createElement("div");
    newAlert.setAttribute("role", "alert");
    newAlert.setAttribute("id", "alert");
    var msg = document.createTextNode(aMsg);
    newAlert.appendChild(msg);
    document.body.appendChild(newAlert);
  }

  function checkValidity(aID, aSearchTerm, aMsg)
  {
    var elem = document.getElementById(aID);
    var invalid = (elem.value.indexOf(aSearchTerm) < 0);
    if (invalid) {
      elem.setAttribute("aria-invalid", "true");
      addAlert(aMsg);
    } else {
      elem.setAttribute("aria-invalid", "false");
      removeOldAlert();
    }
  }
</script>

Einhängen des Codes in die Ereignisbehandlung

Dies ist einfach: Es wird jetzt nur noch ein Aufruf von checkValidity als Wert des onblur-Attributes für die “name” und “email”-Input-Elemente eingefügt. Die geänderten Zeilen sehen so aus:

<input name="name" id="name" aria-required="true" onblur="checkValidity('name', ' ', 'Ungültigen Namen eingegeben!');"/><br />

<input name="email" id="email" aria-required="true" onblur="checkValidity('email', '@', 'Ungültige E-Mail-Adresse');"/><br />

Testen des Beispiels

Das vollständige Beispiel habe ich zum Ausprobieren hochgeladen. Das Formular tut nichts, es ist lediglich als Anschauungsobjekt gedacht. Probiert mal folgendes:

  1. Gebt ins Feld “Name” nur euren Vornamen ein und drückt Tab.
  2. Gebt in das Feld “E-Mail-Adresse” eine verklausulierte E-Mail-Adresse ein, die kein “@”-Zeichen enthält, und drückt Tab.

Einige Anmerkungen

Warum hast du keine Ereignisbehandlungsroutine für das Feld “message” erstellt?
Dies überlasse ich dem geneigten Leser, sozusagen als “Hausaufgabe” zum selbst ausprobieren. ;-)
Warum setzt du das Wort “erforderlich” in die Beschriftung der Textfelder, wenn diese doch per aria-required als erforderlich gekennzeichnet sind?
Wir müssen davon ausgehen, dass auch Anwender mit Browsern und/oder Screen Readern unsere Seiten besuchen, die ARIA nicht verarbeiten können bzw. das Mitteilen eines erforderlichen Feldes nicht unterstützen. IE 7 und JAWS 8.0 sind solche Beispiele. Solange also noch eine große Anzahl Browser und/oder Screen Reader in Umlauf sind, die diese neuen Techniken noch nicht unterstützen, ist auch weiterhin eine eindeutige verbale Kennzeichnung erforderlicher Felder auf Webseiten nötig. Screen Reader, die dies jedoch schon unterstützen, können erforderliche Felder auch anders als durch Sprache, z. B. durch das Abspielen eines bestimmten Klanges, kennzeichnen, so dass die Verwendung dieses Attributes Anwendern aktueller Screen Reader auf jeden Fall weitere Vorteile ermöglicht.
Warum setzt du den Fokus nicht automatisch auf das ungültige Feld zurück?
Weil dies von mindestens der Windows-API-Dokumentation und möglicherweise anderen nicht erlaubt ist. Man darf bei einem Fokuswechsel nicht auf das Feld zurückkehren, von dem man gerade weg navigiert. Außerdem ist es nicht besonders benutzerfreundlich, den Fokus ohne Eingriff des Benutzers zuviel herumspringen zu lassen.

Weiterhin ist natürlich anzumerken, dass das obige Beispiel keinen Anspruch auf Vollständigkeit erhebt. Neben den hier gezeigten Methoden zur Kenntlichmachung von ungültigen Feldern kann man natürlich ein ungültiges Feld auch mit visuellen Stilen kenntlich machen, indem man es z. B. rot einfärbt. Der Experimentierfreudigkeit sind hier kaum Grenzen gesetzt.

Auch ist es natürlich möglich, wenn serverseitig schon Mechanismen zur Kontrolle der Eingaben vorhanden sind, diese per AJAX durchführen zu lassen anstatt innerhalb der Seiten diesen Code zu duplizieren. Der Verwendung von ARIA tut dies keinen Abbruch.

Fazit

Dieses Beispiel zeigt meiner Meinung nach eindrucksvoll, wie das immer als so wenig barrierefrei hingestellte und verschriene JavaScript genutzt werden kann, um das Ausfüllen eines Formulars wesentlich barrierefreier zu gestalten als dies heute gängige Praxis ist.

Ich würde mir wünschen, dass diese Art der frühzeitigen Warnung vor fehlerhaften Eingaben möglichst bald in großer Anzahl verwendet wird. Es ist meiner Meinung nach wesentlich benutzerfreundlicher, sofort auf Eingabefehler hinzuweisen, so dass diese dann noch während des Ausfüllens des Formulars korrigiert werden können. Ich persönlich finde es immer sehr mühselig, nach eventuell fehlerhaft gemachten Eingaben auf der nächsten Seite die Formularfelder alle nochmals durchgehen zu müssen, um das fehlerhafte zu finden, und um zu kontrollieren, dass auch ja keine der gültigen Angaben verlorengegangen sind.

Frühere Einfache ARIA Tipps