Sprung zum Inhalt

Webdesign nach Maß von webdesign weisshart

Mein Blog

RSS Feed AbonnementRSS 2.0 Feed

zum Archiv und den Kategorien

QR-Code war gestern. SpeechCode ist der neue druckbare Datencode

Mittwoch, 12. April 2017

SpeechCode ist eine neue, faszinierende Technologie, die - nicht nur - sehbehinderten oder blinden Menschen in vielen Situationen Zugang zu gedruckten Informationen ermöglichen kann.

SpeechCode
Ein Beispieltext als SpeechCode.
Der Inhalt ist in 4 Kapitel gegliedert.
Das 1. Kapitel "Seitenstruktur" beginnt mit folgendem Text: Startseite mit allen Informationen für den Kunden in einem schicken, zeitgemäßen Design; vielleicht hier schon Upload Funktion? …

Die zahllosen Einsatzmöglichkeiten sind auf der Entwicklerseite ausführlich beschrieben.
Für eigene Tests habe ich

  1. Die kostenlose iOS App installiert
  2. Ein kostenloses Konto auf www.speechcode.eu eingerichtet, um eigene Codes zu erstellen.

Das Ergebnis meines ersten Versuchs, einen eigenen Code zu generieren, ist oben zu sehen. Wichtig ist meines Erachtens, den Text entsprechend zu gliedern, wie auf der Entwicklerseite unter "How to" beschrieben. Diese Gliederung ermöglicht komfortables Navigieren innerhalb des Textes.

Meine ersten Versuche, den Code mit der iOS-App einzuscannen ließen die Befürchtung aufkommen, dass es insbesondere für blinde Nutzer sehr schwierig sein könnte, den Code zu lokalisieren. Dazu folgendes Statement von Entwicklerseite:

Beim Auffinden des Codes nützen sehbehinderte Menschen meist die Sprachführung, blinde Nutzer eher die modulierten Töne, weil das Feedback zur Bewegung exakter ist (gegenüber Verzögerung durch Sprachdauer).
Für blinde Menschen ist tatsächlich Übung nötig, unser blinder Entwickler scannte dann aber schneller als seine sehenden Kollegen.

Und nun leider ein Wermutstropfen: Das Lesen des eingescannten Codes ist für Nutzer des Screen Readers VoiceOver leider wenig komfortabel. Der Text kann nicht, wie unter VoiceOver üblich, strukturiert gelesen werden, sondern nur "am Stück".
Auch dazu ein Statement des Herstellers:

Das VoiceOver Thema ist noch ein Problem, an dessen Behebung wir arbeiten. Eine der Anforderungen an SpeechCode zur Verwendung auf z.B Packungsbeilagen war, dass die Textnavigation 100 % verlässlich und auch ohne Voice Over funktionieren muss.
Wir verwenden die gleiche TTS wie Apple, haben aber eine zusätzliche Funktion zur Korrektur/Optimierung der Aussprache entwickelt, was speziell bei Anwendung im Tourismus oder bei Produktnamen sehr wichtig ist.
Für blinde Nutzer werden wir die Möglichkeit schaffen, Voice Over zur Sprachausgabe nützen zu können und gleichzeitig auf "unsere" Navigation zuzugreifen - mit dem Nachteil, dass die Aussprache nicht mehr angepasst werden kann.
Gleichzeitig sollen auch andere Optimierungen zur Barrierefreiheit durchgeführt werden, da wir mit Unterstützung des AMAC eine US Zertifizierung als "barrierefreie App" anstreben.

(Vorläufiges) Fazit

Eine interessante Entwicklung mit viel Potenzial, - nicht nur - für sehbehinderte und blinde Menschen.


Noch mehr Komfort beim Copy & Paste

Samstag, 3. September 2016

Eine weitere Komfortsteigerung nach dem 1-Klick-Markieren hat Opera im Köcher (derzeit nur in der Developer Branch V. 41 zu bewundern Version 40+):

Screencast: Opera zeigt sofort nach dem Markieren einen Button zum Kopieren (und Suchen).

Sehr pfiffig!

(PS: Der Suchen-Button öffnet übrigens eine Suche nach dem markierten Text mit der Standardsuchmaschine.)


Code automatisch markieren zum copy & paste

Donnerstag, 1. September 2016

Die Darstellung von Codeschnipseln auf meiner Site habe ich in letzter Zeit ja in mehreren Schritten optimiert. (Hoffentlich verbessert, und nicht verschlimmbessert.)

  1. Den Container mit dem Codeschnipsel scrollbar machen
  2. Die Scrollbar permanent sichtbar machen
  3. Zeilen abwechselnd einfärben

Jetzt ein weiterer Schritt zu Verbesserung der Usability:

Den ganzen Codeschnipsel mit einem Klick markieren zum copy & paste

Folgende Anweisung im CSS bewirkt das (im Beispiel für das <code> Element:
code {
-webkit-user-select: all;
-moz-user-select: all;
user-select: all;
}

Das funktioniert in fast allen modernen Browsern. (Crome 53+, Firefox 43+, Safari 9+, Opera)
Ältere Browser, die das Feature nicht unterstützen, ignorieren die CSS Angabe einfach.


Ich will meine Scrollbar sehen

Mittwoch, 24. August 2016

Das Problem:

Fast alle aktuellen Browser verbergen Scrollbars nach kurzer Zeit, wenn nicht gescrollt wird. Für Ästheten eine feine Sache. Und auch kein Problem, wenn es um die Scrollbars für den Viewport, also für die ganze Seite geht. Der User weiß aus Erfahrung, dass er scrollen kann und muss, um Inhalte "below the fold" zu sehen.
Wenn aber einzelne Seitenelemente (z. B. divs) übergroße Inhalte besitzen, die nur durch Scrollen in Gänze sichtbar werden (CSS: overflow:auto/scroll), dann kann das ein entscheidendes Usability Problem darstellen; Weil der User nicht ohne weiteres erwartet, dass er diesen Bereich scrollen kann / muss.
IE / Edge machen, wie so oft, eine Ausnahme. Diesmal zum Besseren. Sie blenden per default die Scrollbars nicht aus.

Die Lösung:

weiterlesen…


Komfort für Tastaturnutzer

Sonntag, 24. Juli 2016

Blinde Menschen, die mit einem Screen Reader surfen, haben gegenüber sehenden Tastaturnutzern — also Surfern, die aus welchem Grund auch immer keine Maus benutzen können — seit jeher einen Vorteil: Sie können mit Hilfe ihres Screen Readers verschiedene Elemente auf der Seite direkt anspringen. Z. B. alle Überschriften auf der Seite.
Tastaturnutzern ist dieser Komfort verwehrt. Navigieren mit der Tastatur bedeutet: mit der Tabulator-Taste mühsam von Link zu Link springen. Mit viel Glück besitzt eine Website wenigstens einen oder mehrere Skiplinks, um mit der Tastatur direkt zu wichtigen Inhalten zu navigieren.

Aber Besserung ist in Reichweite. Das PayPal Accessibility Team und die University of Illinois stellen ein geniales Script zur Verfügung, das den einfachen Skiplink zu einer komfortablen Navigationshilfe erweitert: SkipTo.js

Das Skript kann praktisch ohne Konfiguration "out of the box" benutzt werden. Wobei "out of the box" heißt: Einbinden der externen JavaScript-Datei ins HTML, also eine Zeile HTML:
<script type="text/javascript" src="https://paypal.github.io/skipto/downloads/js/SkipTo.min.js"></script>

Das Skript ist hier auf meiner Site in Aktion.
Der Aufruf erfolgt entweder unmittelbar nach dem Laden der Seite mit der Tab-Taste und Enter, oder, von überall auf der Seite, mit einem Tastaturkürzel:

  • Microsoft Internet Explorer – ALT+0(Null).
  • Mozilla Firefox – ALT+SHIFT+0 (Windows) oder CONTROL+ALT+0 (Mac OS).
  • Google Chrome – CONTROL+ALT+0 (Windows) oder CONTROL+OPTION+0 (Mac OS).
  • Safari – CONTROL+0 (Windows) oder CONTROL+OPTION+0 (Mac OS).

Nachtrag 25.07.2016

Für Smartphones habe ich SkipTo deaktiviert. Da auf diesen Geräten typischerweise keine Tastatur zur Navigation genutzt wird.

Nachtrag 28.07.2016

SkipTo ist jetzt auch vor Screen Reader Nutzern versteckt. Weil das Script in Verbindung mit einem aktiven Screen Reader zu unvorhersehbarem Verhalten bis zum Absturz des Browsers führt. (Das ist übrigens keine Diskriminierung von blinden Seitenbesuchern; Screen Reader Nutzern stehen ohnehin weit umfangreichere Navigationshilfen zur Verfügung.)


Lightbox Alternativen angetestet

Donnerstag, 7. Juli 2016

Menschen in einer Bildergalerie
Foto: deviantart.com Lizenz: CC Attribution-Share Alike 3.0.

Eine Bildergalerie braucht man immer wieder. Seit jeher benutze ich Fancybox als Galerie-Script, als Lightbox-Alternative.
Weil es:

  • valides HTML erzeugt,
  • relativ schlank und
  • einigermaßen barrierefrei ist.

Im Laufe der Jahre sind aber doch immer mehr Schwächen aufgetaucht:

  • Fancybox 1 (letzte Version 1.3.4) wird seit 2011 nicht mehr weiter entwickelt. Vermutlich (und verständlich), weil der Entwickler wohl die (kostenpflichtige) Version 2 bevorzugt behandelt.
  • Fancybox 1.3.4 arbeitet mit aktuellen Versionen von jQuery nur noch, wenn zusätzlich das Migrationstool jquery-migrate.js geladen wird.
  • Barrierefreiheit: Der (unvermeidbare, aber für blinde Menschen nutzlose) Link zum Vergrößern der Bilder irritiert Screen Reader Nutzer.

Ich habe mich daher nach Alternativen umgeschaut. Klar, Lightbox-Alternativen gibt es wie Sand am Meer. Ich bin einfach mal einer Empfehlung von Matthias Mees gefolgt:

  1. Magnific Popup von Dmitry Semenov, und
  2. PhotoSwipe vom gleichen Entwickler

Für die beiden Scripte, sowie für Fancybox habe ich jeweils eine Demo-Seite erstellt. Ich habe die Einstellungen jeweils so gewählt, dass der optische Eindruck in allen drei Demos möglichst identisch ist. Vor allem habe ich die Scripte in mein übliches Layout eingebaut, um eventuelle Unverträglichkeiten mit anderen Scripten zu testen.

Die Demos:

Fazit

PhotoSwipe hat das Zeug zum “Testsieger”. Unabhängig von jQuery, perfektes Look & Feel auf Touchscreens und kleinen Smartphone-Monitoren. Zudem: Bildunterschriften / Bildbeschreibungen perfekt umsetzbar. Sowohl für sehende, als auch blinde Nutzer.

PS: Es gibt natürlich auch “handgemachte” Lösungen, die wirklich alle Wünsche bezüglich Barrierefreiheit erfüllen. Die blinde Bloggerin Eva Papst präsentiert auf Ihrer Website Bilder mit Bildbeschreibungen.


Und jetzt das Zwangs-EU-Cookie

Sonntag, 19. Juni 2016

Screenshot
Ein - scheinbar - ganz üblicher Cookie Hinweis
"Dieser Blog benutzt Cookies. Wenn Sie die Website weiter nutzen, stimmen Sie der Verwendung von Cookies zu."

tl;dr Wer vom Thema EU-Cookie-Hinweis ausreichend genervt ist, braucht ab hier nicht mehr weiter zu lesen. weiterlesen…


Accessibility Club 2016 im Rahmen der Nürnberg Web Week

Mittwoch, 13. April 2016

Die doch relativ weite Anfahrt hat sich gelohnt.
Der Accessibility Club am 12. April 2016 bei tollwerk in Nürnberg war klein, aber fein. Danke an Joschi Kuphal für die Orga, an die Sessiongeber für die Vorträge, und an die Teilnehmer für anregende Gespräche am Rande.

Zwei besondere Dinge habe ich für mich mitgenommen:

  1. ally.js von Rodney Rehm, und
  2. Was ist das IndieWeb?

weiterlesen…


Mein erstes BarCamp

Samstag, 30. Januar 2016

Ein BarCamp zum Thema Inklusion, veranstaltet von OpenTransfer, der Aktion Mensch, und Social Entrepreneurship Akademie

Erste — und spätere — Eindrücke:

Perfekte Organisation, ein nettes und immer hilfsbereites Orga-Team, Kaffee und Butterbrezen zum Empfang, hilfreich für einen lockeren Start.
Zu Mittag gab's u. a. veganes Karottengemüse, und fast jeder an meinem Tisch hatte eine Intoleranz, gegen Laktose oder irgend etwas anderes.
50% der Teilnehmer am abendlichen Cool Down bestellten ihre Pizza vegetarisch.
Also viele Leute, die sich üblicherweise nicht in meiner Filterbubble befinden. Kann interessant werden.

Weil es, wie gesagt, mein erstes BarCamp war, zuerst die Regeln:

Flipchart mit den BarCamp-Regeln
  1. Keine Zuschauer
  2. Geplant ungeplant
  3. Mehrwert
  4. Law of 2 Feet
  5. Nur Mut!
  6. Spread the word #otc16

Gemäß Regel 1 hab' ich mir Sessions ausgesucht, bei denen ich glaubte, aktiv etwas beitragen zu können.
Die zwangsläufige Folge: Ich hab' dort wenig Neues erfahren. Vielleicht hätte ich besser Regel 5: "Nur Mut!" befolgt, und mir die Session über Mode für Rollstuhlfahrer - "Warum ist Mode noch nicht inklusiv?" - angetan. Das wäre wohl absolutes Neuland für mich gewesen.

Ansonsten: Zwei Sessions im Vortragsstil mit Folien und vielen Zuhörern — also genau das Gegenteil dessen, was ich mir erwartet hatte. Eine weitere Session über ein spannendes Projekt wurde zum "Zwiegespräch": außer dem Session leader und mir schaute nach der Hälfte der Session nur noch ein einziger weiterer Teilnehmer herein. Erstaunlich, wie souverän der Session leader die Situation meisterte.

Am interessantesten fand ich eine Diskussions-Session mit dem Titel: Barrierefreiheit für alle — (un)möglich? Klar, dass man unter dieser Überschrift keine Lösungen für alle Probleme der Welt erwarten darf.
Beispielhaft ein Diskussionsbeitrag aus dieser Session: Rollstuhlfahrerin empfindet Blindenleitlinien z. B. in Bahnhöfen als Barriere, weil sie ständig mit den Rädern ihres Rollstuhls in den Rillen der Leitlinien hängen bleibt.

Mein persönliches Fazit am Abend:

Jeder Teilnehmer entscheidet durch seine persönliche Auswahl der Sessions, wie viel er für sich aus dem BarCamp mitnimmt.
Ich hatte den Eindruck, dass die Mehrzahl der Teilnehmer durchwegs zufrieden waren. Ich hatte einen netten Tag, und bin um eine neue Erfahrung reicher.

Noch ein paar Fotos

Follow up:

www.opentransfer.de/event/otc16-inklusion/


Sitemap - Sinnvoll oder nutzlos?

Montag, 11. Januar 2016

Darstellung der Verlinkung von Seiten untereinander
Symbolische Darstellung der Verlinkung von Seiten untereinander.
Grafik: Wikipedia OgreBot CC BY-SA 3.0

Jede Website muss eine Sitemap besitzen. Bereits 1996 hat der Usability-Papst Jakob Nielsen diese Forderung aufgestellt. Folglich hatte auch meine Site eine. Damit sie auch die Strukur meiner Site wiedergab, hatte ich sie manuell erstellt — und fast nie gepflegt . (Asche auf mein Haupt!)
Ob jemals ein Besucher sie genutzt hat, bezweifle ich.

Unabhängig von dieser, eigentlich für Besucher gedachten, Sitemap, gibt es natürlich auch eine sitemap.xml für Google. Diese Sitemap wird täglich per cronjob automatisch erstellt mit dem Tool von xml-sitemaps.com und automatisch an Google übergeben.

Warum nicht die aktuelle, vollständige sitemap.xml (derzeit 848 Seiten gelistet) dazu verwenden, auch die auf der Site veröffentlichte Sitemap stets aktuell zu halten?
Gesagt — getan: Ein Script von #! code musste ich nur wenig anpassen, um eine ansehnliche HTML-Sitemap zu erzeugen. Natürlich ebenfalls per cronjob täglich aktualisiert.

Gut. Eine richtige Sitemap ist das jetzt zwar nicht. Weil sie keinerlei hierarchische Struktur widerspiegelt. Vielmehr handelt es sich einfach um eine Auflistung aller Seiten mit kurzer Inhaltsangabe (aus dem description-Tag übernommen).

Wozu das Ganze also? Auch diese "Sitemap" wird Besuchern genau so wenig helfen wie die alte. Aber mir hilft sie! Als Hilfsmittel zur Fehlersuche. Allerhand Unsauberkeiten, Dateileichen u. ä. konnte ich beim Überfliegen "meiner" Sitemap bereits erkennen und korrigieren.


Die iPhone Freisprecheinrichtung automatisch aktivieren

Montag, 14. Dezember 2015

Das iPhone hat, wie seit Urzeiten jedes Handy, eine Freisprecheinrichtung. Erreichbar (nur) während eines Gesprächs über den Button "Lautsprecher".

Screenshot
Die während eines Telefonats auf dem iPhone verfügbaren Buttons

Wenn ich also erst im Laufe eines Telefonats auf Freisprechen umschalten will, beispielsweise um etwas Nachzuschlagen, dann muss ich dazu das Smartphone vom Ohr nehmen, und den entsprechenden Button betätigen. Was mein Gesprächspartner in dem Moment sagt, geht mir dadurch verloren.

Das geht natürlich auch intelligenter. Ob das Telefon am Ohr ist, erkennt das iPhone ja bereits jetzt — falls ja, schaltet es nämlich das Display ab und spart so Energie. Die gleiche Technik könnte man natürlich auch einsetzen, um automatisch auf Freisprechen umzuschalten, wenn das Telefon vom Ohr genommen wird. Und genau das macht das iPhone sogar. Aber nur, wenn der integrierte Screen Reader VoiceOver aktiv ist.

Warum nur blinde iPhone User diesen Komfort genießen, ist Apples Geheimnis.


RWD ist gar nicht schwer

Montag, 16. November 2015

… und sogar nachträglich machbar. Wenn das Desktop-Layout sauber strukturiert ist.
Ein Beispiel gefällig:

Das Navigationsmenü auf www.backis-welt.de befindet sich im Quellcode nach dem Inhalt, also am Ende der Seite. Per CSS float wird es rechtsbündig dargestellt:

Screenshot Desktop Seite
Die "normale" Darstellung der Seite auf Desktop-PC und Notebook. Das Navigationsmenü wird in der rechten Spalte dargestellt.

Für die Darstellung auf Smartphones ist dieses Layout natürlich nicht geeignet.
Einige wenige Zeilen CSS verhindern das floating. Die Naviation wird, wie im Quellcode vorgegeben, am Ende der Seite dargestellt.
Der Sprunglink "Zum Wegweiser" (zur Navigation) — der auf PC und Notebook versteckt ist, und dort nur sichtbar wird, wenn er mit der Tab-Taste angesprungen wird (CSS: focus) — wird für die mobile Ansicht permanent dargestellt. Das ist notwendig, weil es auf Smartphones keine Tab-Taste gibt.
Anstelle des (Hamburger-)Menü-Buttons, der ein Menü einblendet, erfüllt hier also ein seiteninterner Sprunglink zur Navigation den Zweck.

Screenshot 1 iPhone
Die Darstellung auf dem Smartphone. Der Sprunglink zur Navigation "Zum Wegweiser" oben.
Screenshot 2 iPhone
Die Navigation wird für das Smartphone per CSS auf Seitenbreite vergrößert.

Der CSS-Code, der all dies ermöglicht, umfasst im Prinzip nur wenig Zeilen:

@media only screen and (max-width: 680px) {
 
/* Angaben zurücksetzen, Elemente auf 100% Breite einstellen: */
body,#main,#kopf,#inhalt, #navi, #kopf {border:0;margin:0;padding:0;box-sizing:border-box;width:100%;max-width:100%;}
 
/* Querformat-Darstellung auf Smartphones */
body { -webkit-text-size-adjust:none;font-size:100%;}
 
img {max-width:97%; height:auto;}
#navi ul {margin-left:0 !important}
#navi li {margin:5px 0 !important}
 
/* Skiplink positionieren */
.skip a {left:1em;top: 7em}
 
}


WWW - das World Wide Web ist 25 Jahre alt

Freitag, 13. November 2015

Happy 25th Birthday WWW.
Der britische Physiker Tim Berners-Lee veröffentlichte am 13. November 1990 unter der Domain info.cern.ch die erste Website der Welt.
Einfach mal reinschauen. Funktioniert mit jedem Browser, und ist responsive und 100% barrierefrei.


Gebärdensprache - Barrierefreiheit auch für gehörlose Menschen

Freitag, 6. November 2015

Barrierefreie Webseiten — bei diesem Begriff denken die meisten wohl zuerst an Webseiten für blinde Menschen. Aber gehörlose Menschen? Die können doch sehen, und lesen. Für diesen Personenkreis braucht es doch keine speziell barrierefreien Seiten.
Falsch!
Die Muttersprache gehörloser Menschen ist die Gebärdensprache.
Gebärdensprache weist eine eigene Grammatik auf, die sich oft wesentlich von der Grammatik der jeweiligen Schriftsprache unterscheidet.
Schriftsprachen sind für gehörlose Menschen wie Fremdsprachen, die sie erst mühsam erlernen müssen.
Vielen gehörlosen Nutzern fällt es schwer, Schrifttexte im Internet zu verstehen oder zu nutzen, wenn deren Inhalte nicht in Gebärdensprachvideos übersetzt sind.

Leider ist die Übersetzung in Gebärdensprache, sowie die Erstellung eines Gebärdensprachevideos recht aufwendig, und folglich teuer. 1.000,- € für eine Seite mit 300 Wörtern entsprechend ca. 4 Minuten Video sind durchaus üblich.

Das ServiceCenter ÖGS.barrierefrei, ein gemeinnütziger Verein, erstellt Gebärdensprachvideos zu einem Bruchteil der üblichen Kosten. Die Umsetzung ist technisch perfekt.

Ein Demovideo zeigt die Umsetzung mit einem Klick auf das folgende Logo. Das Video beinhaltet ein Kurzportrait von webdesign weisshart. Logo Gebärdensprache

Das Video wird bei ServiceCenter ÖGS.barrierefrei gehostet, die Einbindung in die eigene Website erfolgt ganz einfach durch einen Link.
Alternativ kann das Video aber auch selbst gehostet werden. Das sieht dann so aus.

Die finanzielle und technische Hürde, die ein barrierefreies Angebot auch für gehörlose Menschen häufig verhindert, wurde von ServiceCenter ÖGS.barrierefrei deutlich niedriger gelegt.


HTML-E-Mails mit dem Mac erstellen

Mittwoch, 7. Oktober 2015

E-Mails verschicke ich (fast) ausnahmslos als text-only. Weil ich so sicher stelle, dass der Empfänger sie auf jeden Fall lesen kann.
Ausnahmsweise kann es aber auch einmal Sinn machen, eine E-Mail HTML-formatiert zu versenden. Weil man eine solche E-Mail semantisch korrekt gliedern kann: Mit Überschriften, Listen usw.

Auf dem Mac funktioniert das relativ einfach mit Bordmitteln:

  1. Das HTML-Dokument erstellen. Gerne nutze ich dazu Markdown.
  2. Das HTML-Dokument im Browser öffnen.
  3. Alles markieren (cmd + a) und kopieren (cmd + c).
  4. Mail (das E-Mail Programm von OS X) zum Erstellen von formatierten Mails einstellen: Einstellungen - Verfassen - E-Mail-Format: Formatierter Text
  5. Inhalt der Zwischenablage in Mail einfügen (cmd + v).

Warnung:

Prinzipiell kann man jede Webseite auf diese Weise per E-Mail verschicken. Komplexe Formatierungen gehen jedoch möglicherweise auf dem Mail-Client des Empfängers verloren. Empfehlen kann ich, wie eingangs gesagt, HTML-formatierte E-Mails nur für Textdokumente, die ordentlich strukturiert werden sollen.

Und noch ein Hinweis:

Die Formatierungsmöglichkeiten von Mail: Schriftgröße, Fettschrift, Farben usw. ersetzen keine semantisch korrekte Gliederung. Fett geschriebener Text ist keine Überschrift! Korrekt mit Überschriften gegliederte E-Mails können auch mit assistiven Technologien wie Screen Reader leichter erfasst werden.

Nachtrag:

Fast noch eleganter geht das Erstellen und Versenden von HTML-formatierten E-Mails mit dem iPhone/iPad. Mit Hilfe der iOS App NoteBox. Dazu in Kürze ein eigener Beitrag.


user-scalable=yes

Sonntag, 28. Juni 2015

Responsive Web Design RWD und Barrierefreiheit: Das sollte nun wirklich kein Widerspruch sein; ganz im Gegenteil. Leider gibt es immer noch und immer wieder "Designer", denen ihr — "gephotoshoptes?" — Design so wichtig erscheint, dass sie den dummen User hindern, es durch Zoomen zu verunstalten.
Wie das geht? Ganz einfach:

<meta name="viewport" content="width=device-width, maximum-scale=1.0, minimum-scale=1.0, initial-scale=1.0" >

in den Header.
Der Meta-Tag "viewport" ist schon richtig und wichtig, um mobile Geräte anzuweisen, den Inhalt entsprechend der Bildschirmgröße richtig zu skalieren.
Aber

maximum-scale=1.0, minimum-scale=1.0

Was soll das? Auch Laien leuchtet anhand der sprechenden Syntax sofort ein, dass damit jeglicher Versuch des Users, den Seiteninhalt zu zoomen, vereitelt werden soll.

Warum macht so etwas eine Agentur, die für sich in Anspruch nimmt:

Darüber hinaus spielen auch Aspekte wie die barrierefreie Nutzbarkeit Ihres Webangebots, die responsive und adaptive Darstellung Ihres Designs auf Endgeräten mit unterschiedlicher Bildschirmauflösung (Smartphone, Tablet) … eine zentrale Rolle im Gestaltungsprozess.

Unwissenheit? Gedankenlosigkeit? Schlamperei?

Dabei wäre es so einfach:

Screenshot
Mit "Pinch" (zwei Finger auseinanderziehen) kann der User jedes Detail einer Webseite nach Bedarf zoomen — wenn der "Webdesigner" das nicht mutwillig unterbindet.

<meta name="viewport" content="width=device-width, user-scalable=yes, initial-scale=1" />

Also

user-scalable=yes

Und alles ist gut.


Neues vom TBL-Kommunikator

Donnerstag, 4. Juni 2015

TBL-Kommunikator Hilfe

Beta 1.11 01.06.15

Der TBL-Kommunikator ermöglicht die asynchrone elektronische Kommunikation mit taubblinden oder hörsehbehinderten Menschen. Asynchron bedeutet, dass Schreib- und Lesegeschwindigkeit entkoppelt sind. Der/die taubblinde oder hörsehbehinderte Leser(in) bestimmt selbst seine/ihre Lesegeschwindigkeit.

Diese Anwendung ist auf den Schreiber (TBA, Schriftdolmetscher) registriert. Der Schreiber kann beliebig viele Leser einladen.

Voraussetzungen beim Schreiber:

  • ein internetfähiges Gerät (PC, Notebook o. Ä)
  • Internetzugang mittels WLAN oder Mobilfunknetz (mindestens UMTS/3G).
  • Kürzel / Textbausteine, die systemweit auf dem Gerät des Schreibers verfügbar sind, können bei der Eingabe benutzt werden.
    Darüber hinaus können Kürzel innerhalb des Systems individuell konfiguriert werden.
  • Spracheingabesysteme, die in ein Textfeld schreiben (in vielen Betriebssystemen, z. B. iOS, Mac OS X, Win 7 enthalten), werden unterstützt.

Voraussetzungen beim Leser:

  • ein internetfähiges Gerät (PC, Notebook, Tablet oder Smartphone, Organizer wie z. B. Pronto!)
  • Nach Bedarf: Ein installierter Screen Reader und angeschlossene Braillezeile
  • Internetzugang mittels WLAN oder Mobilfunknetz (mindestens UMTS/3G).

Bedienung

  1. Der Schreiber öffnet http://w7t.de/t2b (passwortgeschützt) und erstellt eine neue Sitzung.
  2. Der Name der Sitzung hat die Funktion eines Passworts. Er sollte nicht leicht zu erraten sein.
  3. Dort findet sich eine Angabe wie: "Die folgende Adresse muss der/dem Leser(in) mitgeteilt werden: http://w7t.de/t2b/xyz"
  4. Diese (neu erstellte) Adresse muss dem Leser mitgeteilt werden.
  5. Von der Sitzungsseite führt ein Link zur Eingabeseite.
  6. Die Sitzung startet automatisch, sobald der Schreiber eine erste Nachricht eingibt.
  7. Der Schreiber kann Rückmeldungen zulassen.
  8. Neue Meldungen (auch Rückmeldungen) werden durch einen Ton angekündigt. (Nicht iOS und Adroid)
  9. Der Schreiber kann die aktuelle Sitzung bei Bedarf jederzeit leeren, oder eine neue Sitzung starten.
  10. Sobald der Schreiber die erste Nachricht erstellt hat, kann der Leser asynchron lesen. D. h., der Leser bestimmt seine Lesegeschwindigkeit selbst, unabhängig von der Eingabegeschwindigkeit.
    Am Ende jeder Nachricht findet sich ein Link "weiter", der zur nächsten Nachricht führt. Falls es (noch) keine weitere Nachricht gibt (falls also der Leser den Schreiber "einholt"), muss die Seite vom Leser manuell neu geladen werden (eventuell wiederholt).
  11. Das Protokoll der aktuellen Sitzung kann jederzeit vom Leser eingesehen werden. Der Link zum Protokoll befindet sich auf der Seite mit der letzten Nachricht. Dieses Protokoll kann mit der entsprechenden Browserfunktion ausgedruckt, oder als .html (formatiert, barrierefrei) oder .txt (unformatiert) gespeichert werden.

Der TBL-Kommunikator

Samstag, 23. Mai 2015

Ein spannendes neues Projekt:

Der TBL-Kommunikator ermöglicht die asynchrone elektronische Kommunikation mit taubblinden oder hörsehbehinderten Menschen. Asynchron bedeutet, dass Schreib- und Lesegeschwindigkeit entkoppelt sind. Der/die taubblinde oder hörsehbehinderte Leser(in) bestimmt selbst seine/ihre Lesegeschwindigkeit.

Die ersten Reaktionen von Testpersonen: Begeistert!

Eine Beta steht für Interessierte zur Verfügung. Bei Interesse bitte Kontaktaufnahme per E-Mail.

Infoseiten: w7t.de/t2b/help.php und w7t.de/b2t/help.php


alt-Text Robot für Twitter

Sonntag, 19. April 2015

Kaum gibt es das neue Twitter Feature "Retweet mit Kommentar", hat sich das jemand für einen ganz tollen Service zunutze gemacht:
Ein Alt-Text Robot.

Das Problem ist alt: Um blinden Lesern einen kurzen Hinweis zu geben, was auf einem Online-Bild dargestellt ist, gibt es in HTML das alt-Attribut.
Nicht so bei Twitter.
Ich hab' deshalb vor längerer Zeit ein Tool gebastelt, um Bilder nachträglich mit einer Beschreibung für blinde Twitteristi zu versehen: twitpicdescription.de. Entstanden ist das Tool eigentlich nur, um zu beweisen, dass so etwas grundsätzlich machbar ist. In der Praxis ist der Aufwand, eine Bildbeschreibung auf Twitter einzustellen, doch recht erheblich. Das Tool wird daher kaum genutzt (was ich auch nicht erwartet habe).

Aber jetzt hat es jemand geschafft: @alt_text_bot.
Wie das funktioniert?
Einfach ein Bild twittern, und im Text des Tweets "@alt_text_bot" erwähnen.

Das Ergebnis ist verblüffend:

Screenshot eines Retweets mit alt-Text
alt=gray-scale landscape of rainbow over large body of water

Hinter dem Dienst steht natürlich eine leistungsfähige Bilderkennungs-Software.

Ach ja, ich sollte noch das ursprünglich getwitterte Bild nachreichen:

Schwarzweißbild Regenbogen
Das Schwarzweißbild zeigt einen Regenbogen über einer dramatisch wirkenden Gebirgslandschaft (Monument Valley in Kalifornien).

Twitter und die Barrierefreiheit

Mittwoch, 15. April 2015

Twitter war (und ist?) bei Screen Reader Nutzern ja nicht gerade als Muster an Bedienbarkeit bekannt. Blinde und sehbehinderte Twitterist sind daher zumeist auf alternative Twitter-Clients ausgewichen.
Kann es sein, dass die Entwickler bei Twitter sich des Themas Barrierefreiheit verstärkt annehmen?
Ein neues Feature "Retweet mit Kommentar" weckte meine Neugier, und ich habe mal die Nutzbarkeit dieses Features mit Screen Reader kurz angetestet.
Dieses Feature steht meines Wissens nur auf der Website https://twitter.com, sowie auf der offiziellen Twitter-App für Smartphones und Tablets zur Verfügung.

Die erste Überraschung:

Screenshot vom iPhone
Wenn VoiceOver auf dem iPhone aktiviert wird*), erscheint folgende Meldung:

Du hast VoiceOver eingeschaltet.

Für ein optimales Erlebnis bei VoiceOver mit Twitter empfehlen wir, die App zu schließen und wieder zu öffnen, während VoiceOver eingeschaltet ist.

*) Aktivieren von VoiceOver

Dieser Hinweis, den blinde Twitteristi vermutlich nie zu Gesicht bekommen — weil sie VoiceOver eben immer laufen haben, und nicht erst nach dem Aufruf der Twitter App zuschalten — hat mich elektrisiert. Hier scheinen Entwickler am Werk zu sein, für die Barrierefreiheit mehr ist, als eine Rampe am Eingang zum Büro.

Dann also einen der neuen Retweets aufrufen:

Screenshot eines Retweets (Desktop)
Der Retweet zeigt zuerst den Kommentar, darunter, eingerückt, den zititerten Tweet einschließlich Bild.

Auf dem iPhone hört sich so ein Retweet folgendermaßen an (Audio von VoiceOver):

Bemerkenswert an dieser Ausgabe ist die Aufbereitung speziell für Screen Reader. Es wird nicht einfach linear vorgelesen, was auf dem Bildschirm sichtbar ist, sondern eine logisch sinnvolle Reihenfolge für das Zitat erstellt:

Transkription:

Fritz Weisshart zitierte achimhepp.de:
"Einer meiner Hashtag Twitter Tipps: Nichts automatisieren …"
Fritz Weisshart fügte hinzu:
"Ok, dann eben ein Test mit einem fremden Tweet."

Das ist wirklich erstaunlich, und so etwas entsteht nicht zufällig, sondern wurde von Entwicklern geschaffen, die das Thema Barrierefreiheit ernst nehmen und verstehen.

Ich muss natürlich auch noch kurz eingehen auf die Erstellung eines "neuen Retweets" mit Screen Reader.
Auf iOS klappt das prima. Den zu kommentierenden Tweet anklicken. Er öffnet sich auf einer neuen Seite, die Buttons zum Antworten, Retweeten usw. sind erreichbar. Bei Retweet öffnet sich ein Auswahldialog "Retweeten oder Tweet zitieren". Perfekt.

Weniger glücklich ist das auf dem Desktop (Firefox mit NVDA) gelöst. Twitter kann zwar fast vollständig mittels Tastaturkürzeln bedient werden. Siehe www.bitpage.de/2014/internet/twitter-per-tastaturkuerzel-bedienen
Leider muss im NVDA jedes einzelne der zahlreichen Tastaturkürzel erst mal durchgereicht werden, was die Bedienung zu einer fingerverknotenden Aktion macht.

PS: Dieser Kurztest eines einzelnen Features sagt natürlich nichts aus über die Barrierefreiheit von Twitter insgesamt.


Deppenlink 2.0

Samstag, 7. Februar 2015

Der "Deppenlink" (bei Google, und meine Erklärung dazu) ist auch nach mehr als 25 Jahren Webdesign noch nicht ausgestorben. Immer noch gibt es Content Management Systeme (CMS), die ganz selbstverständlich Deppenlinks erzeugen. Wordpress sei hier stellvertretend genannt.
Etwas neuer ist der "Deppenlink 2.0". Der "nach oben"-Button macht auf langen Seiten eventuell Sinn. Aber nicht, wenn es gar nichts nach oben zu scrollen gibt:

Screenshot
Eine Seite, die so klein ist, dass sie auch auf kleinen Monitoren vollständig ohne Scrollen dargestellt wird.

Ich gebe zu: Es erfordert etwas Aufwand, den "Deppenlink 2.0" zu vermeiden. Aber wenn, wie im oben gezeigten Beispiel, 522 kB nur für JavaScript (darunter auch jQuery) eingesetzt werden, dann liegt es wohl nicht an Unfähigkeit der Entwickler, sondern eher an Gedankenlosigkeit.

Anmerkung: Der zweite auf dem Screenshot gezeigte Deppenlink — ein Button zum Sortieren, wo es nichts zu sortieren gibt — unterstreicht nur meine obige Aussage.


Facebook ohne Flash

Mittwoch, 4. Februar 2015

Ich habe mich ja vor einiger Zeit von Flash verabschiedet. Aus Gründen.
"Ordentliche" Websites werden auch ohne Flash ordentlich dargestellt. Auch, wenn sie praktisch nur aus Videos bestehen.
YouTube — kein Problem.
Twitter — kein Problem.
Nur Facebook ist anscheinend mit Adobe "verbandelt". In Facebook gepostete Videos werden auf meinem Macbook nicht angezeigt.

Fehlermeldung bei Facebook
Beim Aufruf eines Videos zeigt Facebook diese Fehlermeldung:
"Du musst die neueste Version von Adobe Flashplayer herunterladen und installieren.

Du musst … Nein! Muss ich nicht. Und werde ich auch nicht.
Facebook will mich nur vera***en. Auf den Servern von Facebook liegt nämlich das Video nicht nur in einem Flash-kompatiblen Format, sondern sehr wohl auch in einem Format (mp4 H.264), das vom nativen HTML5-Player verstanden wird. Klar: nur so schafft es Facebook, Videos auch auf iOS (iPhone, iPad) und Androiden (Smartphones, Tablets) darzustellen.

Was also tun, um Facebook-Videos auch ohne Flash auf dem Desktop / Notebook zu spielen?
Nichts einfacher als das.
Im Adressfeld des Browsers die angezeigte Adresse ändern von https://www.facebook.com/… in https://m.facebook.com/…

Das Adressfeld des Browsers.
Das Adressfeld des Browsers nach dem Aufruf eines Videos auf dem Desktop / Notebook
Das Adressfeld des Browsers
Das Adressfeld des Browsers nach dem ändern auf http://m.facebook.com/…

(Achtung! Nach dem ändern der Adresse die Seite nicht reloaden (mit F5 o. ä.), sondern die geänderte Adresse mit Enter aufrufen!)

Et voila - Das Video rennt. Das "m" gaukelt Facebook vor, dass ich die Seite mit einem mobilen Gerät besuche.
(Dass Facebook zu doof ist, direkt die Verfügbarkeit von Flash abzufragen, möchte ich lieber nicht unterstellen.)

Das Video
An der Adresse https://fbcdn-video-b-a.akamaihd.net/… erkennt man, dass das (H.264) Video auf dem Facebook-Server liegt.

Accesskeys - eine Technik, die sich überholt hat

Sonntag, 11. Januar 2015

Accesskeys, die den Zugriff per Tastatur auf bestimmte Seiten und Inhalte einer Website erleichtern sollten, waren lange Zeit ein fester Bestandteil von barrierefreien Webseiten.
Auch auf meinen Seiten wurde diese Technik eingesetzt.
Ich habe mich entschieden, die Accesskeys nach vielen Jahren von meinen Seiten zu entfernen.

Begründung:

  • Es gab nie einen Standard. Das hatte zur Folge, dass jede Site ihre eigenen Accesskeys definierte. Seitenbesucher mussten also erst einmal herausfinden, welche Accesskeys auf einer bestimmten Site gelten, und sich diese — für jede Site unterschiedlichen — Keys merken.
  • Accesskeys können zu Konflikten mit Tastaturkombis führen, die im Betriebsystem oder im Browser des Benutzers wirksam sind. Dies können sogar vom Benutzer individuell konfigurierte Tastaturkombis sein. Es gibt also keine Tastenkombination, die sicher konfliktfrei arbeitet.
  • Nutzer von Screen Readern wurden gerne als Zielgruppe genannt. Gerade diese Personengruppe hat bessere, universell verwendbare Techniken, um auf Webseiten zu schnell navigieren.

Das HTML5 audio Element - wo Apple falsch denkt

Samstag, 3. Januar 2015

Die HTML5 Elemente audio und video kennen unter anderem die Attribute autoplay und preload. Beide Attribute werden von iOS (und auch Android ab Version 4.2.2) nicht erkannt. Unter iOS muss ein Audio bzw. Video durch eine Nutzereingabe gestartet werden. Das — scheinbar logische — Argument: Benutzer, die im Mobilfunknetz surfen, sollen vor unerwartetem Datenverbrauch geschützt werden.

Ich halte dies für eine unsinnige Bevormundung des Users, und einen Usabilty-Fail.

Beispiele:

  1. Gerade Tablets werden häufig im WLAN genutzt, und nicht automatisch im Mobilfunknetz.
  2. audio autoplay ist nützlich, um bei bestimmten Events Sounds auszugeben. Nicht nur Games nutzen Sounds, auch z. B. mein Chat.
  3. Eine Liste, aus der verschiedene Videos ausgewählt werden können. Nachdem der User ein Video gewählt hat (also bereits einmal eine Nutzereingabe getätigt hat) muss mit einem weiteren Tipp das Video selbst gestartet werden. Eine Zumutung.

Wozu braucht der Mensch Flash - Statusupdate

Montag, 29. Dezember 2014

Vor knapp 2 Monaten hab' ich Flash im Firefox deaktiviert, um zu sehen, ob das Leben ohne Flash — und ohne hochdrehenden Lüfter — lebenswert ist.
Damals habe ich auch 3 Baustellen benannt, die ich selbst "flashfrei" machen müsste, um glaubhaft zu sein:

  1. Videos auf Kundenseiten
  2. Der Yahoo! - Player, den ich u. a. in meinem Blog als Audio-Player verwende(te).
  3. Das in meinem Chat eingebundene Radio

Diese veröffentlichte Aufstellung hat wohl meinen Ehrgeiz geweckt.

Alles erledigt:

Screenshot
Der HTML5 audio-Player mit einigen Stationen, im Chat eingebettet.
  1. Kundenvideos werden in HTML5 mit dem video-Element erstellt. Mit einigen Buttons aufgepeppt, um die Steuerung des Videos auch mit der Tastatur zu ermöglichen.
  2. Im Blog und auf anderen eigenen Seiten wird das HTML5 audio-Element verwendet.
  3. Im Chat gibt es anstelle des eingebundenen Flash-Players von radio.de jetzt alternativ meine eigene Entwicklung. Erstaunlicherweise lassen sich mit dem HTML5 audio-Element nämlich auch Streams abspielen.

Erreicht habe ich nicht nur die Befriedigung meines Ehrgeizes, sondern auch ein ganz klein wenig mehr Barrierefreiheit im Web. Ich muss gestehen, dass ich "nicht unstolz" bin.

Nachtrag 31.01.2015

Es gab noch 2 Baustellen, die es galt, "flashfrei" zu machen:

  1. Der mp3-Player. Der Player ist zwar nach wie vor verfügbar. Aber ich gebe dem HTML5 Audio- und Radio-Player die Präferenz.
  2. Ein Uralt-Tool: Hintergrundmusik wird jetzt ebenfalls "flashfrei" angeboten.

Das HTML5 audio Element - wieder einmal

Samstag, 27. Dezember 2014

Die Unterstützung von HTML5 im Allgemeinen, und des audio-Elements im Besonderen, durch Browser ist ständig im Fluss — zum Besseren!
Inzwischen unterstützt auch der aktuelle Opera-Browser im audio-Element das .mp3-Format. Das erleichtert den Einsatz des audio-Elements erheblich. Die Bereitstellung der Audiodateien im alternativen .ogg-Format, die bisher erforderlich war, um auch Opera-Browser zu bedienen, kann damit endgültig unterbleiben.

Eine nette Anwendung, die davon profitiert: Mein Audioplayer. Barrierefrei, funktioniert in allen aktuellen Browsern (auch iOS), und leicht individuell konfigurierbar.

Diesen Player stelle ich kostenlos zur Verfügung. Download auf dieser Seite: audio_tag.php.


Entspannt Lesen

Donnerstag, 18. Dezember 2014

Eva Papst führt, mit viel Liebe zum Detail, seit Jahren ihre Website aus-meiner-feder.at. Heute würden viele diese Website wohl als Blog bezeichnen; was die Sache nur zum Teil trifft.

Eva Papst, selbst blind, legt großen Wert darauf, dass ihre Leserschaft, keineswegs ausschließlich blinde oder sehbehinderte Menschen, auch optisch ansprechende und vor allem leicht zu lesende Seiten vorgesetzt bekommen. Seit einiger Zeit hat sie mir die Verantwortung für das Design ihrer Site übertragen, eine Aufgabe, die sie selbst aus nachvollziehbaren Gründen nicht erledigen kann.
Absolute Priorität hat dabei, dem Leser entspanntes Lesen zu ermöglichen, damit er sich auf die Inhalte konzentrieren kann. Im Zuge dieser Prioritätensetzung kam vor einiger Zeit neben dem Stil "dunkel", mit dem die Website ursprünglich online gegangen war, ein zweiter Seitenstil "hell" hinzu. Der dunkle Stil setzte helle Schrift auf dunklen Hintergrund, eine Darstellung, die zwar von manchen (auch sehbehinderten) Menschen als leichter lesbar empfunden wird, von anderen aber, vor allem bei längerem Lesen, als ermüdend.

Screenshot 1
Der Styleswitcher, das Auswahlmenü für den Seitenstil, auf der Desktop-Ansicht von "Aus meiner Feder"

Die zunehmende Nutzung mobiler Geräte macht natürlich auch vor Eva Papsts "Blog" nicht halt. Prinzipiell waren die Seiten zwar immer schon auch mit Smartphones zugänglich. Korrekte Technik — valides HTML und CSS — sorgten dafür. Aber eben nur prinzipiell. Das für Desktop-Monitore gestaltete Layout führte dazu, dass die Texte auf Smartphones nur mit Zoomen und ständigem Links-/Rechts-Scrollen lesbar waren.
Ein interessanter Aspekt in diesem Zusammenhang: Für Eva Papst selbst und ihre blinden Leser, die ein iPhone und den Screen Reader Voice Over benutzen, waren die Seiten auch auf dem iPhone ohne Einschränkungen lesbar und bedienbar. Dem Screen Reader ist es nämlich egal, wie winzig die Schrift auf dem Monitor dargestellt wird.

Nach dieser Vorrede: Ein mobiles Design musste her. Und es ist gut geworden, darf ich nicht ohne einen gewissen Stolz sagen.

Nachtrag: Eva Papst bloggt über die "Nachrüst-Aktion".

Screenshot 2
Die Startseite von Aus meiner Feder auf dem iPhone. Links oben der "Hamburger Button" zum Auf- und Zuklappen des Navigationsmenüs

Das Konzept des mobilen Layouts von "Aus meiner Feder" — für Interessierte

weiterlesen…


Chance verpasst?

Freitag, 28. November 2014

Ein spannendes Experiment: Krautreporter

Zitat:

Krautreporter ist eine Community, die Journalismus im Netz ermöglichen möchte. Dafür nehmen wir uns Zeit — zum Recherchieren, Experimentieren, Diskutieren und natürlich zum Lesen.

Krautreporter hat per Crowdfunding über 1 Mio € Startkapital gesammelt. 90.000 € davon wurden für die Website (Software und Design) aufgewendet. Ein stolzes Budget.

Ja, die Website macht tatsächlich etwas her. Wenn, ja wenn man nicht

  • mobil bei geringer verfügbarer Bandbreite lesen will, oder
  • wegen einer Sehbehinderung auf einen Screen Reader angewiesen ist.

Was ist da schief gelaufen?

  • RWD (Responsive Web Design) ist heutzutage ein Muss für jede Agentur, die ein Projekt als zeitgemäß verkaufen will.
    Leider haben die Macher zwar berücksichtigt, dass Smartphones und Tablets über kleine Monitore verfügen. Aber auch an Smartphones Seiten mit bis zu 6 MB Gewicht auszuliefern, wovon lediglich 15 kB auf Text, also auf den Inhalt, entfallen? Smartphones werden nicht ausschließlich im WLAN oder mit LTE eingesetzt!
    Dabei wäre es mit etwas gutem Willen durchaus möglich, die Inhalte mobil-friendy anzubieten. Ich habe erst kürzlich einen Artikel zu diesem Thema verfasst.
  • Ganz schlechte Karten haben blinde und sehbehinderte Menschen, die Krautreporter mit Hilfe eines Screen Readers lesen wollen. Ohne auf Details einzugehen, darf ich hier stellvertretend 2 Fehler erwähnen, die es Screen Readern schwer machen, die Seiten korrekt wiederzugeben, und blinden und sehbehinderten Lesern, sich auf den Seiten zu orientieren:
    1. Die Seiten sind mit technischen Fehlern gespickt, und
    2. semantisch nicht bzw. sehr mangelhaft strukturiert (z. B. h2 für das Artikeldatum, aber keinerlei Gliederung der Artikel selbst durch Zwischenüberschriften).

Die Probleme lassen sich natürlich beheben. Leichter, und vor allem kostengünsiger wäre es allerdings gewesen, bereits in der Konzeptions- und Umsetzungsphase sowohl die Barrierefreiheit, als auch die mobile Nutzung entsprechend zu berücksichtigen.


HTML5 veröffentlicht

Montag, 3. November 2014

HTML5 hat jetzt den Status "Recommendation", und ist damit De-facto-Norm. Am 28.10.2014 hat das World Wide Web Consortium nach mehr als 6 Jahren Entwicklungszeit die Spezifikation der Hypertext Markup Language 5 veröffentlicht.

Das HTML5 Logo
Bild: Wikipedia

HTML, das ist die Sprache des Web, die (Auszeichnungs-)Sprache, in der Webseiten geschrieben (nein, nicht programmiert) werden.
HTML5 erweitert den Vorgänger HTML 4.01 um viele neue Elemente, und ermöglicht eine bessere, sinnfälligere Strukturierung von Webseiten.

HTML5 ist eine Obermenge von HTML 4.01; anders ausgedrückt: Praktisch alle Elemente von HTML 4.01 sind auch in HTML5 enthalten.
Diese scheinbar akademische Feststellung hat ganz praktische Konsequenzen: Der Umstieg auf HTML5 kann "sanft" erfolgen. Es genügt im ersten Schritt, ein vorhandenes HTML 4.01 Dokument mit der Dokumenttypangabe <!DOCTYPE html> zu versehen, und schon hat man ein gültiges HTML5 Dokument.

Anschließend kann man all die schönen und nützlichen neuen Möglichkeiten von HTML5 nutzen, z. B.:

  • Natives audio und video. Auf Sicht werden damit Erweiterungen wie Flash, Silverlight usw. entbehrlich.
    Ein praktisches Beispiel mit dem audio-Tag.
  • Strukturierende Elemente: section, nav, article, aside, header und footer, anstelle "nichtssagender" div-Elemente. Assistive Techniken, z. B. Screen Reader, nutzen diese Elemente heute bereits um die Seitenstruktur zu verdeutlichen, und die Navigation zu erleichtern.
  • Beim input-Element können Entwickler genauere Vorgaben machen, welche Eingabewerte zulässig sind. So sind etwa Datumstypen oder Schieberegler für Zahlen vorgesehen.

Nicht alle Browser unterstützen bereits alle Möglichkeiten von HTML5. Im Einzelfall kann man auf caniuse.com nachschlagen und entscheiden, ob und welche Elemente man nutzen kann / will. So wird z. B. der Input-Typ date von den Schwergewichten IE und Firefox gar nicht unterstützt, das audio-Element hingegen von allen modernen Browsern.

Mein Fazit:

HTML5 ist eine feine Sache, ohne Nachteile. Viele neue Möglichkeiten, Verbesserung der Barrierefreiheit, z. B. Entfall von Flash, Verbesserung der Orientierung auf einer Seite, usw.


Telefonieren - Direktwahl aus der Webseite

Mittwoch, 22. Oktober 2014

Telefonnummern finden sich wohl auf jeder Website. Zumindest auf impressumpflichtigen Websites die Telefonnummer des Seitenbetreibers. Dort hoffentlich nicht als Bild, sondern in Textform. Weil ersteres nicht nur sehbehinderte Nutzer ausschließt, sondern auch die formalen Anforderung an ein rechtssicheres Impressum nicht erfüllt, und im schlimmsten Fall zu einer Abmahnung führen kann.

So weit, so gut.

Seit dem Siegeszug von Smartphones und Tablets ist die Nutzung von Telefonnummern auf Webseiten sehr komfortabel. Viele Geräte erkennen selbständig, dass eine Ziffernfoge eine Telefonnummer sein könnte, und machen aus dieser Ziffernfolge automatisch einen Link, der die auf dem Gerät installierte Telefonapp aufruft. Sehr komfortabel.
Man kann es den Geräten auch leichter machen, und gleichzeitig die Darstellung der Telefonnummer frei gestalten, wenn man das URL-Schema "tel" verwendet.

Tel.: +49 171 - 8319084

Die Spezifikation zum URL-Schema "tel": RFC 3966

Solchermaßen eingebundene Telefonnummern ermöglichen unter Umständen auch das komfortable Telefonieren vom Desktop-Computern aus. Sie rufen, falls vorhanden, eine installierte VOIP-Software auf, oder nutzen auf Macs mit dem aktuellen Betriebssystem Yosemite die Telefonfunktion des iPhone.


Suchen

Donnerstag, 16. Oktober 2014

Was wäre "Neuland" ohne komfortable Suchfunktionen? Voran natürlich die allseits geliebte Tante Google.

Heute möchte ich aber nicht über Google & Co schreiben, sondern über

Seiteninterne Suchfunktionen auf Webseiten und in Apps.

Jeder aktuelle Browser kann komfortabel innerhalb von Webseiten suchen. Mit Strg + F, und dann mit Enter zum jeweils nächsten Treffer springen.
Die neuesten Browserversionen zeigen zusätzlich noch einen Hinweis wie "1 von 5 Übereinstimmungen" (Firefox), "1 von 5" (Chrome, Opera) oder "5 Treffer" (Safari).

In meinem Suchscript

habe ich versucht, die Sache ähnlich komfortabel zu gestalten. Die Treffer werden auf den Zielseiten farbig unterlegt, und zusätzlich wird die Zielseite bis zum ersten Treffer gescrollt.

Screenshot Firefox
Die Seite mit dem Suchtreffer (in diesem Fall die Startseite von webdesign weisshart) wird bis zum ersten Treffer (Internet) gescrollt.

Interessant wird es mit mobilen Geräten

iOS/Safari hat die seiteninterne Suche etwas versteckt. Eigentlich Schade um diese coole Funktion.

Screenshot iPhone 1
Ins Adressfeld, also dort, wo man normalerweise die Adresse der zu öffnenden Seite eingibt, den Suchbegriff eintippen. Es werden mehrere Vorschläge angeboten, je nach Konfiguration des iOS-Geräts, z. B. die Suche nach dem eingegebenen Begriff bei Google fortzusetzen.
Screenshot iPhone 2
Wenn man ganz nach unten scrollt, kommt als letzter Vorschlag "Auf dieser Seite [Suchbegriff] suchen"
Screenshot iPhone 3
Diesen Vorschlag antippen, und auf der aktuellen Seite werden die Suchtreffer gelb hinterlegt. Mit den Pfeiltasten in der Fußleiste kann man dann bequem von Treffer zu Treffer springen.

ähnliche Features bieten fast alle für iOS verfügbaren Browser.

iOS-Apps

Meine neue Lieblingsapp auf dem iPhone, NoteBox, versucht, die geschilderte Funktionalität von Safari nachzuahmen. Bei NoteBox gibt es eine sowohl eine seitenübergreifende als auch eine seiteninterne Suche. Die Umsetzung ist noch etwas holprig. Aber die App ist relativ neu, und wird vom Entwickler intensiv gepflegt. Da ist noch Verbesserung zu erwarten.

Sonderfall Screen Reader

Gerade für blinde IT-Nutzer, die ein längeres Dokument nicht mit einem Blick scannen können, ist eine auch mit Screen Reader funktionierende seiteninterne Suche wichtig. Funktionierend heißt: Treffer anspringen (fokussieren), und den Kontext (die Umgebung) automatisch vorlesen.
Die verschiedenen Screen Reader haben diese Funktion implementiert.

Für Interessierte hier beispielsweise die Befehle für den kostenlosen Screen Reader NVDA:

  • NVDA-Taste+STRG+F öffnet ein weiteres Fenster, in dem Sie einen Text eingeben können, der im aktuellen Dokument gesucht werden soll.
  • NVDA-Taste+F3 aucht die nächste Zeichenkette des gesuchten Textes im aktuellen Dokument, welche zuvor eingegeben wurde.
  • NVDA-Taste+Umschalt+F3 sucht die vorherige Zeichenkette des gesuchten Textes im aktuellen Dokument, die zuvor eingegeben wurde.

iOS VoiceOver

Safari unterstützte seit iOS 6 die oben beschriebene seiteninterne Suche mit dem betriebssystemeigenen Screen Reader VoiceOver. Genauer: Wenn VoiceOver aktiv war, wurde der Fokus automatisch in den ersten Treffer gesetzt, und der Kontext vorgelesen. Weitere Treffer konnten auf die gleiche Art angesprungen und vorgelesen werden. In iOS 8 (bis einschließlich Version 8.0.2) ist diese Funktionalität, das automatische Vorlesen, leider kaputt. Aber das ist ja nicht das einzige Problem mit iOS 8.


Bin ich ein DAU?

Freitag, 12. September 2014

… diese Frage musste ich mir soeben ernsthaft stellen.

Ich will Konzertkarten kaufen. Das Angebot auf der Website hat mich angemacht. Vor allem das eingebundene YouTube-Video. Also flugs das Online-Buchungsformular aufgerufen:

Screenshot
Ausschnitt aus einem Navigationsmenü:

KARTEN

  • Pauschalangebot Saitensprünge
  • Abo
  • Verkaufsstellen

Ich probiere "Pauschalangebot Saitensprünge" — das ist es natürlich nicht.
Als nächstes "Abo" — nein, ich will ja nur Karten für ein Konzert.
Letzter Versuch: "Verkaufsstellen". Dort finde ich ein Kartentelefon. Na gut, dann eben old style.

Die Dame am Telefon war wirklich nett. Was die alles von mir wissen wollte: Welches Konzert, meine Adresse und E-Mail, Bankverbindung — eine IBAN telefonisch durchzugeben hat was. Da konnte ich mir die Frage nicht mehr verkneifen, warum denn keine Online-Buchung möglich sei.
Antwort: "Haben wir. Gehen Sie auf die Seite bla bla bla …"
Ich: "Aber dort gibt es nur Pauschalangebote und Abo. Das will ich aber nicht. Ich will nur 2 Karten bestellen."
Antwort: "Klicken Sie auf KARTEN".

Boing! Das war für mich eine Überschrift, eine Kategorie, und kein aktiver Menüpunkt. Die Großschreibung des Begriffs KARTEN hat mich zu der Annahme geführt. Und diese Überschrift wurde beim Überfahren mit der Maus auch nicht so schön rot unterlegt wie die Unterpunkte.

Usability? Oder bin ich ein DAU?


Adaptive Web Design vs. Responsive Web Design - die Zweite

Montag, 8. September 2014

Im vorhergehenden Artikel hab' ich mich selbst gelobt, wie gut ich doch Websites für mobile Geräte optimieren kann.
Aber um welche Website es sich handelt, sollte ich doch noch verraten: Ein 5 Jahre altes Projekt relaunched.

Und vor allem sollte ich kurz erwähnen, wie es gelungen ist, eine 1,3 MB schwere Webseite auf 100 kB zu schrumpfen.
www.webpagetest.org

Mit Media Queries, dem Schweizer Messer des RWD (Responsive Web Design) geht das nämlich nicht. Vielmehr musste ich auf eine alte, etwas in Verruf geratene Technik zurück greifen: User Agent Sniffing.
Warum?
Media Queries können zwar für eine auf das jeweilige Gerät optimierte Darstellung sorgen. Aber sie können nicht verhindern, dass Daten vom Server geladen werden, die für eine mobile Ansicht gar nicht nötig sind. In unserem Beispiel sind das vor allem jQuery & Co.
Mit User Agent Sniffing stelle ich schon auf dem Server fest, ob ein mobiles Gerät auf die Site zugreift, und PHP sorgt dafür, dass bestimmte Inhalte gar nicht erst zu mobilen Geräten geschickt werden.

Auf html5-mobile.de gibt es eine schöne Sammlung der wichtigsten mobilen User Agents.
Diese User Agents werden in ein Array namens $agents gepackt, und etwa folgendermaßen abgefragt (PHP):

for ($i=0; $i<count($agents); $i++) {
if (isset($_SERVER["HTTP_USER_AGENT"])
&& strpos($_SERVER["HTTP_USER_AGENT"], $agents[$i]) !== false) {
$sitestyle = "mobile";
}
}

Die relevanten Daten, z. B. jquery.js, werden dann nur zum Client geschickt, wenn es sich NICHT um ein mobiles Gerät handelt.

if ($sitestyle != "mobile" ) {
echo'
<script src="jquery.min.js"></script>

Natürlich muss Sorge getragen werden, dass die Seiten konsistent bleiben. D. h. beispielsweise eben nicht auf jQuery zugegriffen wird, wenn es nicht verfügbar ist. Wie schon mehrfach erwähnt, bedeutet das Handarbeit. Und vor allem immer wieder testen. Mit verschiedenen Tools, aber natürlich auch mit echten Geräten.


Adaptive Web Design vs. Responsive Web Design

So. ich bin mir selbst untreu geworden. Ich habe meine erste Website mit mehr als 1 MB für die Startseite online gestellt. Exakt 1.35 MB. Der Wunsch des Kunden war mir Befehl. Es mussten einfach wechselnde Hintergrundbilder sein.

Screenshot
Der Screenshot zeigt die Webseite. Links die Bereichsnavigation mit der Box für Aktelles
Screenshot
Der Screenshot zeigt die Webseite, nachdem der Inhalt ausgeblendet wurde, um nur das Hintergrundbild anzuzeigen. Ein Feature der Website.

Schön und gut. Mit einem schnellen Internet.

Aber was ist mit den ca. 20 % Besuchern (gemessen), die das Angebot mobil nutzen?
Gut. Sie bekommen eine mobile Version mit 100 kB, also gerade mal 8 % des Gewichts der Standardseite angeboten. Dafür gibt es für mobile Nutzer zusätzliche Features, die mobil, und nur mobil Sinn machen. Z. B. Direktlinks zu Navigationsapps, die ggf. auf dem Smartphone installiert sind.

Screenshot iPhone
Auf dem mobilen Bildschirm wird zuerst einmal das Wichtigste gezeigt, nämlich die Last Minute Angebote, die auf der Standardansicht in der seitlichen Navigationsleiste eingebunden sind.

Nein. Das ist keine Seite, die speziell für mobile Nutzung erstellt wurde. Sondern RWD (Responsive Web Design) weiter gedacht. Also AWD (Adaptive Web Design). Was nicht benötigt wird, wird für die mobile Nutzung auch nicht vom Server geladen. Das geht weit über RWD, Responsive Images und ähnliches hinaus. Ein wenig Handarbeit ist dazu allerdings erforderlich. Ich kenne zumindest kein CMS, das ähnliches leistet.


Firefox 32 - das neue Kontextmenü

Mittwoch, 3. September 2014

Firefox 32.0 hat ein nettes Feature: Das Kontextmenü beinhaltet jetzt Buttons für Vorwärts / Rückwärts / Seite neu laden / Favoriten

Screenshot
Das neue Kontextmenü des Firefox 32.0 mit den Navigationsbuttons

Schön. Und schneller, als mit der Maus die entsprechenden Buttons im Browser anzusteuern.
Aber dass Firefox jetzt den Deppenlink adelt, finde ich gar nicht nett. Wieso zeigt der Pfeil nach links ein Tooltip "Eine Seite zurück", wenn es keine vorherige Seite gibt, und Pfeil nach rechts ein Tooltip "Eine Seite vor", wenn es keine Seite vor gibt?
Beim genaueren Hinschauen stelle ich fest, dass die inaktiven Pfeile grau, und nicht schwarz sind. Zu spät, ich habe mich bereits geärgert. Mozilla bitte nachbessern, wirklich hellgrau machen, und den Tooltip entfernen.

NB: Screen Reader Nutzer sind hier im Vorteil. Sie erhalten einen Hinweis wie "nicht verfügbar".


Wie lange darf die Beantwortung einer E-Mail dauern?

Freitag, 29. August 2014

Drei Tage? Eine Woche? Kann man nach 2 Wochen noch mit einer Antwort rechen?
Ja. Wenn der Adressat Lufthansa heißt. Auch wenn die Antwort dann als Telefonat kommt.

Neuland eben.

PS:
E-Mail ist in diesem Fall nur Synonym. Es gibt keine E-Mail Adresse der Lufthansa! Sondern nur ein Online-Formular. Und wenn man dort seine Haarfarbe und ähnliche Details nicht eingibt, wird das Formular einfach nicht abgeschickt. Dafür kann man Anlagen mitschicken. Bis zu 500 kB. Aber dass es diese Begrenzung gibt, und wo sie liegt, kann man nur vermuten, nachdem man das entsprechende Dokument eigens für die Lufthansa gescannt und ans Formular angehängt hat. Mehrere erfolglose Versuche mit Dateien unterschiedlicher Größe führten mich zur Annahme, dass es die Begrenzung auf 500 kB gibt.
Nun gut, dann also zippen. Denkste. zip-Dateien mag die Lufthansa gleich gar nicht. Auch das erfährt man, nachdem man die Datei gezippt und hochgeladen hat.

Neuland eben. Dass der Verfasser des Online-Kontaktformulars den Begriff Usability kennt, will ich mal nicht unterstellen. Denn sonst müsste ich Böswilligkeit unterstellen.

Was übrigens gut funktioniert bei der Lufthansa: Der Autoresponder. Die Lufthansa hat also meine Nachricht erhalten. Welche Nachricht? Das verrät man mir wohlweislich nicht. Ich hab' mir ja vor dem Abschicken des Formulars sicher einen Screenshot angefertigt. Eine andere Möglichkeit, das Formular vor dem Abschicken zu speichern, gibt es nämlich auch nicht.
Womit wir wieder beim Stichwort Usability wären …


GPS Navigation

Sonntag, 10. August 2014

Aus Scobbler wurde Navi 2 wurde GPS Navigation by Scout
Navi 2 hatte ich vor längerer Zeit auf Barrierefreiheit, d. h. Benutzbarkeit mit VoiceOver, getestet. Und dem Entwickler mit zahlreichen Hinweisen geholfen, die schlimmsten Barrieren auszumerzen.

Seit einiger Zeit wird Navi 2 zusammen mit Scout und Telenav weiter entwickelt und vertrieben.
Die Neugier trieb mich, den Stand der Barrierefreiheit erneut anzutesten. Mit dem schon fast erwarteten Ergebnis: Die App wurde "aufgehübscht", und bei dieser Gelegenheit mal schnell für VoiceOver Nutzer unbrauchbar gemacht. Details erspare ich mir. Es hat keinen Sinn.

Immer mehr Apps, die nicht speziell für die Zielgruppe "VoiceOver-Nutzer" entwickelt werden, werden mit optischen Gimmicks aufgepeppt, und dabei leider für blinde Nutzer unbedienbar. Kein schöner Trend.


top: - 9000 ist böse

Samstag, 2. August 2014

Elemente nur für Screen Reader sichtbar machen. Ein Standardverfahren auf barrierefreien Seiten.
Tl;dr - if you're not interested in accessibility
weiterlesen…


Audio- und Videoplayer barrierefrei

Das Thema barrierefreie Audio- und Videoplayer beschäftigt mich seit langer Zeit. Ich habe zu diesem Thema im Laufe von Jahren eine Vielzahl von Artikeln und Demos verfasst.

Es sieht fast so aus, als ob die Suche ein Ende hätte. HTML5 und Terrill Thomsons Able Player sei Dank.
Auf obiger Übersichtsseite werden eine Reihe von Demos verlinkt, mit allen denkbaren Optionen. Ich möchte folgende zwei Beispiele hervorheben:

Terrill Thomsons Able Player stellt alles in den Schatten, was ich gerne als „der beste bisher“ bezeichnet habe. Der Player ist Open Source und steht unter der freien MIT-Lizenz.
Able Player bei GitHub

Kollegen: Verwenden! Nicht nur blinde, seh- oder hörbehinderte Menschen werden es euch danken.

Nachtrag 01.09.2016:

Nachdem zwischenzeitlich alle relevanten Browser natives HTML5 unterstützen, halte ich persönlich den Einsatz des Able Players in den weitaus meisten Fällen für überflüssig, weil der Einbau zu aufwendig ist. HTML5 audio oder HTML5 video sollten fast immer genügen.


Neue App Dechiffr löst automatisch komplizierte Captchas

Donnerstag, 31. Juli 2014

Die Empörung über den CAPTCHA-Unfug hat die breite Öffentlichkeit erreicht. Nicht nur sehbehinderte Menschen ärgern sich über CAPTCHAs, die den Zugang zu vielen Seiten, Online-Shops, Kommentarfunktionen usw. für sie erschweren. Auch Der Postillon findet, dass das Thema wohl eine Satire wert ist, und meldet die Verfügbarkeit eines Programms, das CAPTCHAs automatisch knackt. Das Programm lautet angeblich auf den Namen Dechiffr.

Der Postillion weiß vermutlich nicht, dass es ein solches Programm tatsächlich längst gibt: Rumola
Und vermutlich ist sich Der Postillion nicht einmal der Tatsache bewusst, dass für viele Menschen ein solches Programm keineswegs ins Reich der Satire gehört, sondern bittere Notwendigkeit ist.

Ich benutze übrigens das Programm, obwohl ich nicht sehbehindert bin. Aus reiner Bequemlichkeit. Und auch, weil ich die Entwickler damit finanziell unterstütze. Der Dienst kostet nämlich ein paar Cents. Z. B. 0,79 € pro 50 gelöste CAPTCHAs.
Hier noch ein Blogpost zu Rumola.


Suchformular - Browser setzen De-Facto-Standard

Donnerstag, 3. April 2014

Das Suchformular in Browsern hat keinen Submit-Button. Suchanfragen werden mit Enter abgeschickt.

Die Browserhersteller haben damit einen De-Facto-Standard gesetzt, dem ich mich gerne anschließe.

Mein Suchfeld sieht zukünftig so aus:
Das Suchfeld ohne Submit-Button
Im Einzelnen:

  1. Ein Lupensymbol sowie die Vorbelegung mit "Suchbegriff" o. ä. kennzeichnet das Feld als Suchfeld.
  2. Das Label wird unsichtbar gemacht durch Verschieben aus dem Viewport, d. h. für Screen Reader bleibt es weiterhin sichtbar.
  3. Es gibt keinen Submit-Button. Seit 10 Jahren oder länger senden Browser das Formular auch ohne Submit-Button ab, wenn Enter gedrückt wird.

Ich bitte um Kommentare zu

  1. Kann ich das Label ebenfalls weglassen? Sind Screen Reader Nutzer mit einer sinnvollen Vorbelegung des Suchfelds zufrieden?
  2. Gibt es möglicherweise doch noch einen Client, der ohne Submit-Button das Formular nicht abschicken kann?

Barrierefreiheit - nicht nur für blinde Surfer

Montag, 31. März 2014

Nur allzu oft wird Barrierefreiheit im Web mit "von blinden Menschen lesbar" oder "Screen Reader tauglich" verwechselt.
Dabei sind es nicht nur blinde Surfer, die von barrierefreien Seiten profitieren.

Oder: "Meine Site bietet ohnehin keine sinnvollen Inhalte für blinde Menschen, blinde Menschen gehören nicht zu meiner Zielgruppe. Also macht der Mehraufwand für Barrierefreiheit keinen Sinn."

Falsch.

  1. Beispiel: "Wozu brauchen blinde Menschen ein Fernsehprogramm?" Fragen sie einfach mal einen blinden Menschen, dann wissen Sie es.
  2. Haben Sie schon einmal versucht, in einem fahrenden Zug mit dem Notebook auf dem Schoß mit der Maus zu navigieren?

Beispiel 2 führt zum Thema des heutigen Artikels:

Tastaturbedienbarkeit

Die Bedienbarkeit einer Website auch ohne Maus ist ein wichtiger Aspekt der Barrierefreiheit. Man muss ja nicht immer an Menschen mit Bewegungseinschränkungen denken. Vielleicht lässt die Situation gerade keine sinnvolle Bedienung der Maus zu. Im schwankenden Zug mit dem Notebook auf dem Schoß ist es viel bequemer, mit der Tastatur von Link zu Link zu navigieren. Auch innerhalb des Navigationsmenüs.

Nötig ist dazu zweierlei:

  1. Die Menüpunkte müssen mit Tastatureingaben erreichbar sein.
  2. Der jeweils aktive Menüpunkt (Fokus) muss erkennbar, d. h. deutlich sichtbar sein.

Als Beispiel für Tastaturbedienbarkeit soll das Navigationsmenü in dieser Demo dienen.
Eine Besonderheit gibt es hier: Untermenüs werden nicht mit der Tab-Taste erreicht, sondern mit den Pfeiltasten (wenn ein Screen Reader läuft: mit der Enter-Taste, und nach Öffnen des Untermenüs weiter mit der Tab-Taste). Einen Hinweis auf die Existenz eines Untermenüs bietet für sehende Surfer das bekannte "Hamburger Icon", für blinde User eine entsprechende Ansage.

Für alle Zielgruppen gilt:
Keine "Deppenlinks"!
Deppenlinks sind Links, die zur aktuell geöffneten Seite führen, beim Aktivieren also lediglich die aktuelle Seite neu aufrufen. Das kann irritierend sein. Also bitte die aktuelle Seite in der Navigation kennzeichnen (optisch, und für Screen Reader erkennbar), und nicht verlinken!


Schöner lesen auf dem iPhone - die Dritte

Samstag, 22. Februar 2014

Webseiten lesen auf dem iPhone - immer noch Glücks- und/oder Geduldssache, weil viele Seiten eben noch nicht responsive sind, also nicht für den kleinen Monitor optimiert. Klar, man kann die Bildschirmanzeige mit verschiedenen Techniken vergrößern, und dann so lange Hin- und Herzoomen, bis einem das zu blöd wird.
Ich greife in solchen Fällen gerne auf Readability zurück (Readability fürs iPhone). Leider führt Readability ein Neuladen der Seite durch. Und das erfordert gerade bei großen, überladenen Seiten einige Geduld, und eine schnelle Anbindung ans Web.

Eine Alternative bietet der iCab Browser (iTunes Link 1,79 Euro). Dort ist Readability „eingebaut“, und wesentlich schneller, und auch stabiler.

Screenshot 1
spiegel.de nach dem Aufruf im iPhone Browser. Ein „Mäusekino“.

Anm.: Klar, Spiegel bietet auch eine App, die speziell für Smartphones optimiert ist. Die Seite dient hier nur als Beispiel, um die Leistungsfähigkeit von Readability zu demonstrieren.

Screenshot 2
Nach dem Tipp auf das Brillensymbol rechts oben öffnet sich ein Auswahlmenü mit den Optionen „Später lesen“, „Jetzt lesen“ und „Leseliste“
Screenshot 3
Nach der Auswahl „Jetzt lesen“ zeigt sich die Seite aufgeräumt, und bereit zum komfortablen Lesen.

Barrierefreiheit:

iCab ist mit VoiceOver bedienbar. Auch die Readability-Funktionalität. Das genannte Brillensymbol wird von VoiceOver als „Leseliste“ gelesen.


Ein barrierefreier Audio-Player - Version 3.0

Dienstag, 18. Februar 2014

Am 01. Dezember 2010 habe ich den AAP-Player vorgestellt, den (damals) besten barrierefreien Audio-Player.
Inzwischen ist einiges passiert: Der Yahoo! Media Player, der als Fallback erforderlich war für Browser, die das HTML5 audio-Tag nicht unterstützen, wurde eingestellt. Damit wäre der AAP-Player „eigentlich“ unbrauchbar. Wenn, ja wenn nicht inzwischen die Unterstützung des HTML5 audio-Tags fast allgemein als gegeben zu bezeichnen wäre. Wenn man bereit ist, den IE 8 und älter, und den Opera nicht (mehr) zu unterstützen, dann kann man inzwischen auf das Fallback verzichten. Und dafür Smartphones und Tablets bedienen.

Da der Entwickler des AAP-Players Terill Thomson diesen Schritt (noch) nicht gegangen ist, habe ich mal ein wenig mit der letzten veröffentlichten Version 3.0 gespielt.

Im Einzelnen:

  • Ich habe die - nicht mehr funktionierende - Fallback Lösung Yahoo! Mediaplayer entfernt
  • Dafür teste ich mittels Modernizr, ob das audio-Tag und .mp3 Dateien unterstützt werden. Falls nein, gebe ich lediglich einen entsprechenden Hinweis aus.
  • Um die kleinen Smartphone-Monitore zu unterstützen, habe ich ein wenig am CSS geschraubt. Und vor allem das entsprechende, für ordentliche Darstellung auf Smartphones unentbehrliche Metatag ins HTML eingefügt:
    <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />

Das Ergebnis ist in dieser Demo zu sehen bzw. zu hören.
Und das Hören bezieht sich auch auf Screen Reader und auf Tastaturnutzer ohne Maus. Der Player ist nämlich nach wie vor ein Vorbild an Barrierefreiheit.


Freundlich Drucken

Mittwoch, 8. Januar 2014

Ein pfiffiger Dienst, um Webseiten

  • ballastfrei zu drucken
  • in durchsuchbare PDFs umzuwandeln, oder
  • als E-Mail zu verschicken

www.printfriendly.com

Der Dienst kann online ohne jegliche Installation verwendet werden, für sporadische Einsätze, oder mittels Bookmarklet, wenn man das Tool immer wieder nutzen will. Das Bookmarklet funktioniert sogar auf dem iPhone/iPad.
Pfiffig: In der Druckvorschau können beliebige Elemente gelöscht werden, und damit wird die Druckausgabe oder das PDF auf das wirklich Benötigte reduziert.

Webmaster oder Blogger können sogar einen PrintFriendly-Button in ihre Seiten einfügen, und den Komfort des ballastfreien Druckens ihren Besuchern bieten:

Print Friendly Version of this page"Freundliches" Drucken

Damit dieser Button funktioniert, muss allerdings auf der eigenen Seite JavaScript-Code eingefügt werden, den man auf o. g. Seite erstellen und downloaden kann (hier nicht integriert).

Ob man der Privacy Policy des Anbieters vertraut, mag jeder für sich entscheiden. Ebenso, ob und wofür man das Tool nutzen kann und will.

Schade ist allerdings, dass die erzeugten PDFs nicht barrierefrei sind. Die Struktur der Website (Überschriften usw.) ist im PDF nur optisch umgesetzt. Dieser Beitrag zeigt, wie es richtig wäre.


Bandbreite

Montag, 30. Dezember 2013

Ein t3n-Artikel über die Internet-Infrastruktur „wieso Deutschland beim Thema Internet-Infrastruktur weit hinter anderen Ländern herhinkt?“ hat mich wieder einmal an eines meiner Lieblingsthemen erinnert:

Wie groß dürfen/müssen Webseiten sein?

Jakob Nielsen hat in den Anfangsjahren des Web 5 kB als Maß aller Dinge propagiert. Die ursprüngliche Website useit.com hat sich lange Zeit tatsächlich an diese Grenze gehalten. Leider gibt es die Site, an die sich mancher alte Hase vielleicht noch erinnert, nur noch unter archive.com zu bewundern. Z. B. useit.com vom 25.01.2002

Mich selbst hat die Idee „so wenig Ballast wie möglich“ seit den Anfängen meiner eigenen „Webwerklerei“ fasziniert. Und so kommt es, dass die Startseite meines Webauftritts auch heute noch mit 50 kB auskommt:

Größe Nichtkomprimierte Größe
1 Dokument 7 KB 20 KB
16 Bilder 24 KB 24 KB
0 Objekte
2 Skripte 6 KB 22 KB
5 Stilvorlagen 12 KB 44 KB
24 Dateien 50 KB 110 KB

Dass ich damit ziemlich allein stehe, ist mir natürlich bewusst. Und mit neueren Seiten bin ich auch schon „großzügiger“. So etwa mein aktuelles „Werk“ http://bauer-bernau.de
Immerhin 427 kB spendierte ich der Startseite, vor allem für Fotos.

Damit bin ich aber immer noch vergleichsweise extrem sparsam. Die Website eines Kollegen aus Berlin, als trendiger One-Pager ausgeführt, bringt es auf 5 MB, um ganze 11 kB Text zu transportieren.

Dass http://www.webpagetest.org/ eine Ladezeit von 10 Sekunden ausweist, ist kein Wunder.

Selbst beim Aufruf der Seite auf dem Smartphone werden immer noch ca. 3,5 MB geladen, obwohl das Design responsive ist.
Wie viele potentielle Kunden in den von t3n zitierten ländlichen Gegenden er damit wohl ausschließt? Na ja, ist nicht mein Problem.

Im Vergleich dazu sind die durchschnittlich 1 bis 2 MB, die heute bei Nachrichtenportalen üblich sind, geradezu schlank.


Die Gebärdensprache als Muttersprache

Mittwoch, 21. August 2013

Mein Chat ist, auch wenn das äußerlich nicht ohne weiteres erkennbar ist - weitgehend barrierefrei. Die Barrierefreiheit geht so weit, dass selbst taubblinde Menschen damit zurecht kommen. Mehrere Installationen des Scripts speziell für taubblinde Nutzergruppen belegen dies.

Zur Klärung einiger spezieller Einstellungen hatte ich neulich einen gehörlosen und einen taubblinden Benutzer in meinem Demo-Chat. Die beiden sind von Geburt gehörlos, ihre Muttersprache ist also die Gebärdensprache. Sie hatten beide gewisse Probleme, sich in deutscher Schriftsprache - für sie ja eine Fremdsprache - auszudrücken. Wir haben es dennoch mit Geduld geschafft, die anstehenden Fragen zu klären.
So weit, so gut.

Im Anschluss an den "technischen Teil" haben die Beiden ihr Treffen im Chat noch zu einem persönlichen Schwätzchen genutzt. Ich war dabei nur passiver Zuhörer. Dennoch hat mich das Gespräch mehr und mehr gefesselt. Nicht wegen des - eher belanglosen - Inhalts. Auffallend war zuerst, dass die Frequenz des Gesprächs jetzt deutlich höher war als vorher, als wir im Dreier-Gespräch waren. Auffallend war aber vor allem, dass sie untereinander einen für mich schwer verständlichen Satzbau verwendeten. Langsam wurde mir klar: Das waren Wörter der deutschen Schriftsprache, in den Satzbau der Gebärdensprache gekleidet. Ich war fasziniert und gefesselt: Näher an der Muttersprache ging das Gespräch den beiden gehörlosen Chattern deutlich flotter "über die Lippen".


Amazon goes barrierefrei

Mittwoch, 31. Juli 2013

Nachdem Amazon lange Zeit blinde und sehbehinderte Menschen anscheinend nicht als potentielle Kunden registriert hatte, wurde jetzt wohl die Kehrtwende eingeläutet.
E-Books können schon seit einiger Zeit mit der iPhone App Kindle auch mit VoiceOver gelesen werden. Und jetzt (Version 3.9) gibt es eine ausführliche Anleitung aller vorhandenen Gesten für VoiceOver-Nutzer:

Screenshot
Die Anleitung ist innerhalb der Kindle-App zu erreichen unter:
Einstellungen (rechts unten) > Häufig gestellte Fragen (FAQ) > Welche barrierefreien Gesten/Aktionsmuster werden unterstützt?

Buttons zum Einstellen der Schriftgröße - die Zweite

Montag, 15. Juli 2013

Erst gestern habe ich gebloggt über Buttons zum Ändern der Schriftgröße auf Webseiten.
Der eigentliche Anlass für den Artikel war eine Anpassung in meinem Barrierefreien Chat. Dieser Chat wird gerne auch von sehbehinderten Nutzern installiert. Eine taubblinde / hörsehbehinderte Chatmoderatorin hat mich darauf aufmerksam gemacht, dass der Chat für sie sehr gut auf dem iPad nutzbar ist. Mit starker Vergrößerung, und mit aktivierter Sprachausgabe VoiceOver zur Unterstützung. Flüssiges Chatten ist aber unmöglich, wenn bei starker Vergrößerung zum Lesen jeder einzelnen Nachricht gescrollt werden muss, weil die Zeile länger als der Viewport ist.
Die integrierte Schriftvergrößerung ermöglicht jetzt sehr große Schrift ohne dass die Zeilen über den Viewport hinaus fließen.

Screenshot iPad
Die Schriftgröße kann in 3 Stufen eingestellt werden. Das Bild zeigt die drei Buttons in Form von 3 As unterschiedlicher Größe.

Schriftgröße auf Webseiten verändern

Sonntag, 14. Juli 2013

Seit Jahren vertrete ich die Meinung, ein Button o. Ä. zur individuellen Einstellung der Schriftgröße auf Webseiten sei obsolet. Alle Browser haben inzwischen diese Möglichkeit eingebaut. (Strg + bzw. Strg -).
Alle? Nein. Das iPad bzw. allgemein iOS macht das scheinbar viel eleganter mit verschiedenen Gesten, z. B. Pinch - zwei Finger auseinander ziehen.
Elegant ja. Zufriedenstellend? Da die ganze Seite vergrößert wird, und nicht nur die Schrift, wird die Seite auch breiter; Um die Übersicht zu behalten, muss also ständig horizontal "gescrollt" werden (auf dem iPad/iPhone natürlich nicht gescrollt, sondern "geschoben", aber das Ergebnis bleibt das gleiche).
Besser geht es mit einer von der Website angebotenen Schriftvergrößerung, die natürlich per Cookie gespeichert wird, damit sie über alle Seiten beibehalten wird. (Die Möglichkeit zu Pinchen gibt es natürlich weiterhin.)
Auf zimmer-chiemsee.de ist so etwas eingebaut, und feiert auf dem iPad fröhliche Urständ.

Screenshot 1
Screenshot der Seite auf dem iPad ohne Schriftvergrößerung
Screenshot 2
Screenshot der selben Seite mit Schriftvergrößerung

CAPTCHAs automatisch lösen - ein neuer Dienst

Mittwoch, 10. Juli 2013

CAPTCHA ['kæptʃə] ist ein Akronym für Completely Automated Public Turing test to tell Computers and Humans Apart. Das bedeutet wörtlich: “Vollautomatischer öffentlicher Turing-Test zur Unterscheidung von Computern und Menschen".
Quelle: Wikipedia

Leider ist das System inzwischen komplett pervers: Maschinen sind zumeist besser im Lösen von CAPTCHAs als Menschen. Von blinden und sehbehinderten Menschen ganz zu schweigen. Letztere sind sogar darauf angewiesen, CAPTCHAs von Maschinen lösen zu lassen.

Es gibt einen (zumindest für mich) neuen Dienst: Rumola von skipinput.com
Hier eine Seite mit Anleitungen für blinde und sehbehinderte Menschen (englisch).
Rumola wird als Addon für Firefox, Chrome und Safari angeboten.
Rumola light (mobil) gibt es derzeit für Android. Für iOS ist es angekündigt.

Nach der Installation des Addons muss man sich mit einer E-Mail Adresse registrieren. Nach der Registrierung hat man 10 Credits kostenlos. Die kostenlosen Credits gelten nur am Tag der Registrierung. Also jedenfalls noch am gleichen Tag testen! Weitere Credits kosten 0,79 € für 50 Credits / 1 Jahr bzw. 1.55 € für 150 Credits / 6 Monate.
Bezahlung mit PayPal.

Ein Kurztest zeigt, dass das Addon tadellos und schnell funktioniert. Wenn ein CAPTCHA auf einer Seite gefunden wird, gibt Rumola eine entsprechende Meldung aus. Ein Doppelklick im Eingabefeld füllt dieses automatisch aus mit der Lösung des CAPTCHAs.

Screenshot 1
Ein ReCAPTCHA Eingabefeld vor dem Lösen des CAPTCHA
Screenshot 2
Das ReCAPTCHA Eingabefeld ist von Rumola mit der Lösung ausgefüllt worden.

Nachtrag

Rumola füllt das Ergebnisfeld mit dem gelösten CAPTCHA nicht nur auf Doppelklick, sondern bereits dann, wenn man ein beliebiges anderes Formularfeld auszufüllen beginnt. Sehr komfortabel.

Nachtrag 2

Rumola lässt sich via Kontextmenü auf einzelnen Seiten deaktivieren. Nützlich z. B. auf eigenen Seiten, um den Alert zu unterdrücken.


PDF-Reader für Sehbehinderte

Dienstag, 25. Juni 2013

PDF-Dokumente sind heute ein häufig verwendetes Format in der digitalen Kommunikation. Tausendfach werden sie per Mail versendet und auf Websites zum Download angeboten. Für sehbehinderte Menschen jedoch, die am Bildschirm Texte vergrössern sowie Schriften und Hintergrund kontrastieren müssen, stellen PDF-Dokumente oft eine unüberwindbare Hürde dar.

Der Schweizerische Zentralverein für das Blindenwesen (SZB) hat jetzt für diese Zielgruppe ein fantastisches Tool entwickelt, und stellt es kostenlos zur Verfügung. Download hier

Zahlreiche Einstellungen ermöglichen es sehbehinderten Menschen, die Ansicht nach ihren individuellen Bedürfnissen zu konfigurieren.

Screenshot des VIP PDF-Readers
Der Screenshot zeigt ein PDF in der Darstellung Gelb auf Blau.

Das Tool lässt kaum Wünsche offen. Das Handbuch [PDF] mag für Interessierte vorab als Informationsquelle dienen.

Eine wichtige Einschränkung:
Optimal erkennt der "VIP-Reader" nur barrierefreie PDF-Dokumente. Diese weisen unsichtbare Zusatzinformationen - sogenannte Tags - auf. Überschriften, normale Absätze, Listen, Tabellen, Links und Bilder mit Legenden oder Alternativtexten zählen zu den wichtigsten Inhalten der Tags.

Aber selbst barrierebehaftete PDFs versucht der VIP-Reader zu optimieren. Er erzeugt dann einen unstrukturierten Textwurm ohne Inhaltsverzeichnis und ohne Bilder. Logisch. Wo nichts ist (keine Struktur), kann auch das beste Tool nichts erkennen. Aber Zoom, Zeilenumbruch, Farben funktionieren, ebenso die Suche im PDF. Und das kann für die Zielgruppe eine große Hilfe sein.

Und jetzt mein Wunschzettel

  • Bedienbarkeit des VIP PDF-Readers und Lesbarkeit der vom VIP PDF-Reader optimierten Dokumente auch mit Screen Readern.
    Begründung: Viele stark sehbehinderte Menschen verwenden die Sprachausgabe von Screen Readern zur Unterstützung. Ideal wäre also nicht ein Entweder (VIP-Reader) - Oder (Screen Reader), sondern die gleichzeitige Nutzbarkeit von Screen Reader und VIP-Reader.
  • Eine App für Smartphones
    Begründung: Der VIP-Reader erzeugt Text, der je nach verfügbarer Breite des Fensters umbrochen wird. Kein "normaler" PDF Viewer macht das. Auf Smartphones können PDFs zwar gelesen werden, aber häufig ist die Schrift dann so klein, dass gezoomt werden muss. Und ohne Zeilenumbruch zwingt ein gezoomtes PDF zu wahren Scroll-Orgien auf dem kleinen Monitor.
    Ich wäre gerne bereit, für eine VIP PDF App zu bezahlen - Wink-mit-dem-Zaunpfahl an die Entwickler.

Nachtrag 05.07.2013

Die Version 1.1 ist veröffentlicht. Download auf der oben erwähnten Seite, einfach drüber installieren. Gefixt ist die Vergrößerungsfunktion mit Tastatur - einfach + und - Taste, und das Öffnen eines Dokuments mit dem VIP-Reader via Kontextmenü (nicht mit OS X).

Nachtrag 06.08.2013

Neue Version 1.2 veröffentlicht. Ein Changelog kann ich leider nicht finden. Und selbst konnte ich keine Änderung feststellen, weder unter Windows noch auf OS X.


Animierte GIFs stoppen

Samstag, 8. Juni 2013

Animierte GIFs - fast so nervig wie manche Politiker.
Animiertes Gif: Angler wird von Hai gefressen

Wie man sie ruhig stellt, habe ich schon vor Jahren beschrieben. Einfach mit der Escape Taste. Nur leider funktioniert das in modernen Browsern nicht mehr.
Zumindest für den Firefox habe ich jetzt die Lösung in Form eines kleinen Add-ons gefunden: SuperStop verwendet die selten benutzte Tastenkombi Shift + Esc, um diese Funktionalität wieder herzustellen. Wer will, kann sogar mit etwas Fummelei die Funktion wieder auf die Esc-Taste alleine legen. Auf der Add-on Seite ist beschrieben, wie das geht.
Ach ja, wer nach dem Shift + Esc etwas vermisst: Wieder einschalten kann man die Zappelei durch Neuladen der Seite.


GEMA versus YouTube - und Unblocker

Freitag, 7. Juni 2013

YouTube scheint (jetzt) auch gegen Barrierefreiheit zu kämpfen.
YouTubes Kampf mit der GEMA - oder sollte ich sagen: GEMA gegen YouTube geht in die nächste Runde.
Anscheinend hat YouTube es jetzt geschafft, einen (von vielen) Unblocker(n) zu blocken:

Screenshot eines Youtube Unblockers
YouTube Unblocker: There are corrently some problems due YouTube changes. We are working on an update. Please be patient.

Nun? Gut gemacht YouTube?
Mitnichten.
YouTube hat mit dieser Änderung auch Unschuldige getroffen. So z. B. Chris Heilmanns Easy YouTube Player. Ein Player, der YouTube Videos so weit wie nur möglich barrierefrei zugänglich macht. Das Video, das in obigem Beispiel eingebunden ist, hat nichts mit der GEMA zu tun, und wird von YouTube nicht geblockt. Aber Chris Heilmanns Player ist kaputt. Kollateralschaden?
Danke GEMA.


Mobil Fernsehen mit Zattoo

Donnerstag, 6. Juni 2013

Zattoo ist legales Fernsehen für unterwegs.
Zattoo im iOS Appstore

Screenshot iPhone
Auf dem iPhone läuft nach der Auswahl eines Senders in der oberen Bildschirmhälfte das gewählte Programm, in der unteren Bildschirmhälfte gibt es die Senderliste (zum schnellen Zappen)

Bis gestern galt diese Aussage nur bedingt. Weil aus lizenzrechtlichen Gründen die Sendungen der Empfang nur in einem WLAN möglich war.
Seit heute sendet Zattoo auch in Mobilfunknetzen. Und das klappt sogar recht ordentlich, mindestens 3G vorausgesetzt. Darüber hinaus sollte man schon über einen Tarif mit üppigem Inklusive-Traffic-Volumen verfügen. Ein paar hundert MB kommen beim Fernsehen schnell zusammen. Und auch über die werbefreie HQ-Version (45,- Euro p.a.) sollte man nachdenken. Traffic für Werbung zu verbrennen ist nicht sehr cool.

Wie geht es wohl mit Zattoo weiter? Eine Vereinbarung mit RTL ist bereits abgeschlossen. Und die Verfügbarkeit in weiteren Ländern ist auch angekündigt. Es sollte mich sehr wundern, wenn Österreich nicht dabei wäre.

Ach ja, beinahe hätte ich vergessen zu erwähnen, dass die App mit VoiceOver bedienbar ist.


dailymeTV mit automatischer Aktualisierung

Dienstag, 28. Mai 2013

dailymeTV habe ich erstmals am 1. April 2012 beschrieben.
Ein wirklich pfiffiges Tool. Irgendwo unterwegs, ohne WLAN, und 10 Minuten nichts zu tun, außer warten? Einfach offline vorher definierte TV-Sendungen sehen. Wenn man sie vorher, zuhause mit WLAN, gespeichert hat. Nur: Immer wenn es so weit ist, stelle ich fest, dass ich eben zuletzt vor 3 Wochen neue Sendungen gespeichert habe. Und 3 Wochen alte Nachrichten … na ja.

Seit einiger Zeit gibt es bei dailyme eine (Beta-)Option: Download-Orte.
Die Funktionsweise:
Du bist zuhause (auf Arbeit etc.), rufst die Option im Menü auf, und speicherst den Download-Ort als "zu Hause" (oder eben "Arbeit" etc.)
Die App erkennt, dass du dich ein einem gespeicherten WLAN befindest, und aktualisiert automatisch, ohne dass die App geöffnet sein muss. (Das iPhone muss natürlich an sein.)

Screenshot des Menüs Download-Orte
Beschreibung der Option Download-Orte
Du möchtest Sendungen im Hintergrund über WLAN aktualisieren, ohne extra die App zu öffnen?
Lege hier Orte fest, an denen automatisch neueste Folgen runtergeladen werden, sobald Deine definierten WLAN-Verbindungen (z.B. zu Hause, Schule, Arbeit) gefunden wurden.
Wichtiger Hinweis:
Bei Aktivierung wird dauerhaft ein kleiner Pfeil neben der Akkuanzeige angezeigt.
Von uns werden dabei keinerlei Daten aufgezeichnet, und die Akkulaufzeit wird durch diese Funktion kaum gemindert.
Neuen Download-Ort hinzufügen…
zu Hause (Löschbutton)

Eine Anmerkung:
Ich habe dailymeTV sowohl auf dem iPhone, als auch auf dem iPad. Also beide Geräte automatisch aktualisieren lassen, ist doch klar. NEIN! Dann funktioniert es auf keinem der beiden Geräte. Warum das so ist, mag der Entwickler wissen. Also nur auf einem Gerät diese Funktion aktivieren, und es klappt. Ich hab' natürlich das iPhone gewählt, weil das ja unterwegs ständig am Mann ist.

Nachtrag

Dass diese Option die Akkulaufzeit nicht merklich beeinflusst, kann ich bestätigen.

Nachtrag 2

02.07.2013
Aktualisierung im Hintergrund scheint jetzt zu funktionieren, nachdem ich ein Konto bei dailyme.tv registriert habe. Zufall?

Nachtrag 3

15.07.2013
Seit dem heutigen Update auf Version 2.5.9 ist die App von blinden und sehbehinderten Usern nicht mehr benutzbar. Mit aktiviertem VoiceOver lässt sich keine Sendung zur Wiedergabe auswählen.
Am 01.04.2012 hab ich noch geschrieben:
"Durchgängig saubere Bedienbarkeit auch mit VoiceOver. Da können sich viele Entwickler etwas abschauen."

Nachtrag 4

17.07.2013
Wunder dauern gewöhnlich etwas länger. Dann war es wohl kein Wunder, sondern die richtige Einstellung der Anbieter und Entwickler zu Accessibility: Vorgestern reklamiert, heute ist die Version 2.5.10 im App-Store verfügbar, und damit ist die Bedienung mit VoiceOver wieder möglich.
Ein schöner Beweis, dass es geht, wenn der Wille da ist.

Nachtrag 5

09.10.2013
Irgendwie hat das mit der automatischen Aktualisierung nie richtig geklappt.
Auf Nachfrage erhielt ich heute folgende Aussage seitens dailyme:

ab dem nächsten Update (das ca. in einer Woche kommen sollte) wir die automatische Aktualisierung auch auf iOS funktionieren.


Es steht doch im Internet

Sonntag, 12. Mai 2013

"Doch, das stimmt; Ich hab's doch im Internet gelesen."
Nicht immer sollte man sich darauf verlassen. Böswillige Verfasser von Falschmeldungen bedienen sich gerne des Tricks, Falschmeldungen mit einem Bild plus Untertitel zu belegen.
Beispiel:
Portrait Abraham Lincoln mit Zitat als Bildunterschrift
Die meisten Leser werden wohl zwei Mal hinschauen müssen, bevor sie die Selbstbezüglichkeit dieses Bildes verstehen: Wie konnte Abraham Lincoln vom Internet sprechen?

Mir ist bei der Betrachtung des Bildes etwas anderes aufgefallen:
Sowohl SEO als auch Barrierefreiheit verlangen zwingend, dass die Bildunterschrift vom Foto getrennt, und als (maschinenlesbarer) Text angeboten werden. Das Beispiel sieht dann so aus:

Portrait Abraham Lincoln
"Don't believe everything you read on the Internet just because there's a picture with a quote next to it."
- Abraham Lincoln

Was ist damit gewonnen?
Auch blinde und sehbehinderte Leser verstehen jetzt Bild und Artikel. Und ganz nebenbei auch Suchmaschinen - die sind nämlich auch blind.


Barrierefreiheit eingebaut - ein Loblied auf VoiceOver, den Screen Reader von iOS

Mittwoch, 24. April 2013

Barrierefreiheit - wie oft schon wurde in Webworker-Kreisen darauf hingewiesen, dass man Barrierefreiheit von Anfang an berücksichtigen sollte muss, und nicht erst "in einem zukünftigen Projektschritt".

Apple hat mit seinem genialen Screen Reader VoiceOver genau dies getan: Barrierefreiheit von Anfang an. Selbst Apps, deren Entwickler sich anscheinend nicht einmal der Tatsache bewusst sind, dass blinde und sehbehinderte Menschen ein iPhone / iPad benutzen (können), zeigen ein hohes Maß an Barrierefreiheit.

Ein Beispiel:
Documents by Readdle, ein geniales Tool zur Dokumentenverwaltung auf iPhone oder iPad.

Ja, die App hat Mängel bei der Benutzung mit VoiceOver. Eva Papst hat einen Artikel gebloggt, der einen typischen Mangel vieler Apps beschreibt, ohne sich in ihrem Beitrag explizit auf diese App zu berufen.

Ich hatte Eva Papst diese App empfohlen, war mir aber nicht sicher, ob die App wirklich mit VoiceOver sinnvoll nutzbar ist. Bereits im Vorfeld hatte ich nämlich einen anderen Mangel an die Entwickler gemeldet, und die Antwort war eindeutig:

the Documents app does not work in VoiceOver regime…

So deutlich hatte ich das noch nie von einem Entwickler gehört.

Von Eva Papst weiß ich aber, dass die App hervorragend auch mit VoiceOver bedienbar ist. Blinde iPhone Nutzer haben wohl gelernt, auch mi typischen Mängeln wie fehlende Beschriftung von Buttons zurecht zu kommen. Und den Rest erledigt Apple, auch ohne Zutun der App-Entwickler.
Genial.


Files App - ein iPhone App Test - auch mit VoiceOver

Samstag, 2. März 2013

Beliebige Dateien vom PC/Mac auch auf dem iPhone oder iPad, auch offline. Früher oder später kommt wohl bei jedem dieser Wunsch auf.
Eine neue App namens Files App erfüllt diesen Wunsch. Ohne Schnickschnack. Aber mit allem, was nötig ist. iTunes Link
Dateien können vom PC/Mac via http übertragen werden, aber auch z. B. aus der Dropbox, und ganz einfach in Ordnern organisiert werden. Die App kann wirklich fast jedes Dateiformat anzeigen.

Screenshot 1
Der Startbildschirm von Files App mit einigen angelegten Ordnern

Eine Suchen Funktion ist verfügbar. Dazu auf dem Monitor nach unten streichen.

Screenshot 2
Der Startbildschirm von Files App mit eingeblendetem Suchfeld

Neben dem Suchfeld gibt es eine Taste zum Umschalten zwischen der voreingestellten Ansicht in Form von Thumbnails und Ordnersymbolen, oder einer Listenansicht.

Screenshot 3
Der Startbildschirm von Files App als Liste

Die App ist mit VoiceOver gut bedienbar. Kleine Unsauberkeiten sind verzeihbar, zumal es sich um eine Version 1.0 handelt. So ist die Taste zum Umschalten auf Listenansicht abenteuerlich beschriftet: "s m searchbar table switch grid acti" oder so ähnlich, der Zurück-Button in manchen Situtationen nur mit "Taste".
Wichtig für VoiceOver Nutzer: immer die Listenansicht benutzen. Das Suchfeld mit dem Umschalter auf die Listenansicht erreicht man ganz schnell durch mehrfaches Wischen nach rechts.


App Update = Barrierefreiheit verschlimmbösert?

Mittwoch, 27. Februar 2013

Apps für iOS werden regelmäßig mit Updates versorgt. Kennt jeder iPhone oder iPad Nutzer. Mit der Ankündigung des Updates gibt es in der Regel eine mehr oder weniger aussagekräftige Beschreibung von neuen Funktionen.
Wenn dann dort etwas zu lesen ist wie: "Tolles neues UI" oder "Fantastische neue Grafiken", dann ist die Chance groß, dass die App für blinde und sehbehinderte User, die auf VoiceOver angewiesen sind, kaputt gemacht wurde.

Das es auch anders geht, zeigt Spotify, der tolle Musik-Streaming Dienst. In der Ankündigung zur Version 0.6.0 steht "Neu: Das tolle neue Gesicht von Spotify." Ein kurzer Test mit VoiceOver zeigt, dass das tolle neue Gesicht nicht mit Einbußen bei der Barrierefreiheit erkauft wurde. Die App ist weiterhin mit VoiceOver perfekt bedienbar. Es geht also doch. Hallo, App Entwickler, nehmt euch ein Beispiel!

(Ja, Spotify mobil setzt einen kostenpflichtigen Premium Account voraus.)


FiRe Recorder 2.6.0 wieder mit VoiceOver bedienbar

Dienstag, 8. Januar 2013

FiRe - eine Recorder App fürs iPhone - und für besondere Ansprüche. Eine der wenigen Apps, die mit einem passenden Mikrofon (z.B. das TASCAM iM2) Stereoaufnahmen ermöglichen.
Download-Link FiRe (5,99 €)
Heute gab's ein Update.

Screenshot
Beschreibung zum Update u. A.:
new preference to toggle between slide-to-record and classic control buttons

Warum mich diese Bemerkung elektrisiert hat?
Vor über einem Jahr wurde FiRe "verschlimmbösert" und damit für VoiceOver Nutzer vollkommen unbrauchbar. Ich habe damals die Entwickler auf den Fehler hingewiesen. Ob meine Reklamation der Anlass war, die App wieder zugänglich zu machen? Egal. Ein schneller Test zeigte, dass FiRe jetzt wieder vollständig mit VO bedienbar ist.
Die dazu erforderliche Einstellung:
Settings (nur im Aufnahmemodus erreichbar - Transport - Button Controls ein - zurück - Save As Default Settings

Eine Warnung sei angebracht: FiRe ist sehr mächtig, und daher nicht intuitiv bedienbar. Ein Studium der In-App-Hilfe oder z. B. dieser Anleitung ist unumgänglich.

Fragen zur App beantworte ich gerne.


Dropbox 2.0 mit VoiceOver auf dem iPhone

Samstag, 15. Dezember 2012

Die Cloud-App Dropbox ist auf allen meinen Geräten - MacBook, iPhone, iPad, PCs - installiert. Beliebige Dateien immer und überall verfügbar haben, oder einfach und schnell mit Anderen teilen, das hat schon was.
Heute wurde die iOS App auf Version 2.0 "aufgeschönt". Und immer, wenn ich "neues Design" lese, dann denke ich an meine blinden Freunde, die auf VoiceOver Unterstützung angewiesen sind; und ich werfe dann VoiceOver an, um zu testen, ob eine App auch nach dem Update weiterhin für blinde iPhone-/iPad-Nutzer bedienbar ist.

Für Dropbox 2.0 lautet das Ergebnis meines Kurztests: Ja, aber …

Zum "Aber" im Detail:
Dropbox kann Dateien jeglicher Art beherbergen. Textdateien, Sound-, Bilddateien usw. Das aktuelle Update hat speziell die Verwendung und Verwaltung von Bilddateien zum Inhalt. Und genau hier kann sich für VoiceOver Nutzer unter Umständen eine böse Falle auftun. Ja, auch blinde Menschen arbeiten zuweilen mit Bilddateien. Und dann heißt es aufpassen:

Nach dem Anklicken einer in der Dropbox gespeicherten Bilddatei öffnet sich ein neues Fenster zur Anzeige des Bilds. Um den kleinen Monitor eines iPhones optimal zur Betrachtung des Bildes zu nutzen, werden die Bedienelemente in diesem Fenster beim Aufruf ausgeblendet, und erst nach einem einfachen Tipp auf den Bildschirm angezeigt. Bedienelemente: das sind Buttons zum Sharen, Speichern usw, sowie der Zurück-Button, um die Bildansicht zu verlassen. Und genau diese Ansicht der Bedienelemente kann auf keine Weise aktiviert werden, wenn und so lange VoiceOver aktiv ist. Ein blinder User landet also auf einer Seite ohne jeglichen Inhalt - es gibt ja keine sichtbaren Elemente, die vorgelesen werden könnten - und ohne Möglichkeit, diese Seite wieder zu verlassen. Auch Löschen der Dropbox aus dem Speicher mit dem App-Umschalter und Neustart hilft nicht. Beim erneuten Aufruf landet man wieder auf der Seite mit dem Bild ohne Bedienelemente.

VoiceOver Nutzer ohne Bilder in der Dropbox sind also von diesem Fehler nicht betroffen, und können ohne weiteres updaten.
Und VoiceOver Nutzer, die das eine oder andere Bild in der Dropbox vorfinden, und sei es in einem Ordner, den sie mit anderen teilen?
Hier der Workaround:
Auf der Seite mit dem Bild VoiceOver ausschalten (3fach Home Button) und dann ohne VoiceOver Unterstützung einen kurzen, trockene Tipp irgendwo auf dem Bildschirm; das schaltet die Anzeige der Buttons ein. Anschließend VoiceOver wieder einschalten, und die Buttons bleiben, auch für VoiceOver, sichtbar. Hinweis: der einfache Tipp auf den Bildschirm toggelt, schaltet also bei wiederholtem Tipp die Anzeige wechselweise an und aus.
Mit diesem Workaround kann man leben. Aber schön ist das nicht. Vor allem ist es eine böse Falle für jemanden, der den oben genannten Trick nicht kennt. Ohne dieses Wissen erscheint die App schlicht kaputt, und kann anscheinend nur durch Neuinstallation repariert werden.

PS: Auf dem iPad gibt es dieses Problem nicht. Dort bleiben die Bedienelemente eingeblendet.


Styleswitcher

Mittwoch, 7. November 2012

Styleswitcher, die Möglichkeit, alternative Seitenstile auf einer Website zu wählen, sind etwas aus der Mode gekommen.
Zu Recht?
Eva Papst setzt auf Ihrer Website aus-meiner-feder.at seit vielen Jahren auf helle Schrift und dunklen Seitenhintergrund - "ein Zugeständnis an blendempfindliche Leser".
In einem ausführlichen Gedankenaustausch anlässlich des A-TAG 2012 haben wir die Grundzüge eines zweiten, hellen Seitenstils für Evas Site festgelegt:

  • Wiedererkennbarkeit: Der Stammgast muss sofort erkennen, dass er sich nach wie vor auf Evas Site befindet.
  • Lesbarkeit hat oberste Priorität. WCAG 2 - Wahrnehmbarkeit
  • Der zusätzliche Stil soll nicht nur einfach die Farben des bisherigen Stils invertieren, sondern insgesamt freundlich und einladend wirken, zum Verbleiben auf der Site animieren. Dabei darf er ruhig auch etwas moderner daherkommen.

Ich glaube, dass ich diese Prinzipien gut umgesetzt habe.

Screenshot
Der zusätzliche, helle Seitenstil auf aus-meiner-feder.at. Unterhalb der Navigation der Styleswitcher, überschrieben mit "Seitenstil"

Der 10 Sekunden Check auf Barrierefreiheit

Montag, 8. Oktober 2012

Terrill Thomson beschreibt in seinem Blog, wie er sich in 10 Sekunden einen ersten Eindruck verschafft, ob eine Webseite "einigermaßen" barrierefrei ist.
Seine Vorgehensweise umfasst 4 Schritte, die ich im folgenden kurz erläutere.

Vorab:

  • In 10 Sekunden lässt sich natürlich kein kompletter Webauftritt beurteilen. Terrill beschränkt sich daher auf die Startseite.
  • Er hat nur Websites untersucht, die ARIA landmarks, und zwar konkret role="main" verwenden. Dieses Kriterium mag sinnvoll sein, um aus einer großen Anzahl von Sites diejenigen heraus zu filtern, die den Anspruch erheben, barrierefrei zu sein. Ich persönlich würde aber nicht so weit gehen, die Verwendung von ARIA Landmarks als KO-Kriterium für Barrierefreiheit zu werten.

Nun zu den Testschritten:

  1. Hat die Seite eine halbwegs vernünftige, durch Überschriften gegliederte Struktur? Terrill verwendet für diesen Schritt die WAVE Toolbar
    Gut geeignet ist für diesen Schritt auch das HeadingsMap Firefox Addon
  2. Im nächsten Schritt checkt Terrill mittels WAVE auf Errors, Features and Alerts.
    Hier zeigt WAVE seine ganze Stärke. Einen einfachen, gleichwertigen Ersatz für diesen Test kenne ich nicht.
  3. Mittels der Tab-Taste, also ohne Maus, durch alle Links und Formularelemente der Seite tabben. Ist der Fokus, das jeweils aktive Element, erkennbar?
  4. Falls die Seite Video enthält: Ist das Video untertitelt?

Apple Maps - ein Loblied

Donnerstag, 4. Oktober 2012

Apple Maps mit dem neuen Betriebssystem iOS 6 erntet fast nur Kritik. Nur teilweise zu Recht, finde ich. Die Optik der 3D Darstellung - bisher nur in einigen wenige Großstadtzentren verfügbar - ist für mich einfach ein Hingucker. Ich bin mir sicher, dass dieses Feature im Lauf der Jahre noch ausgebaut wird. Großes Plus: Die Vektorgrafiken kommen mit deutlich weniger Daten im Vergleich zu Google Street View aus, und damit wird Apple Maps 3 D in Bälde auch mobil sinnvoll einsetzbar sein.
Ein Screenshot kann nur begrenzt eine Vorstellung davon geben, wie man mit dem Finger auf dem Touchscreen des iPhone quasi als Hubschrauberpilot über die Innenstadt fliegen kann.

Screenshot Apple Maps 3 D
Die Innenstadt von München mit Marienplatz und Rathaus in Vordergrund, und den Türmen der Frauenkirche im Hintergrund. Links im Vordergrund ist auch noch der Alte Peter zu erkennen.

Doch jetzt zum eigentlichen Thema dieses Artikels:
Apple Maps kommt mit einer integrierten Navigation. Modi: Fahrzeug - Fußgänger - öffentliche Verkehrsmittel (letzteres ist in Deutschland anscheinend noch nicht verfügbar.)
Ich werde den Fußgängermodus genauer untersuchen, und zwar speziell für die Zielgruppe blinde und sehbehinderte iPhone User, die auf Sprachausgabe angewiesen sind. Hier kommt gleich ein Plus der Apple Map zum Zug: Die Sprachausgabe VoiceOver ist ja ins Betriebssystem integriert, so dass wesentlich sparsamerer Umgang mit den Ressourcen quasi eingebaut ist.

Fußgängermodus ist für alle Navigationssysteme ein ganz eigenes Thema. Die Darstellung auf dem Bildschirm zeigt daher in der Regel neben dem momentanen Standort die Richtung zum Ziel, unabhängig von Wegen oder Straßen. Der Fußgänger kann also auch vom vorgezeichneten Weg mal abweichen, ohne die Richtung aus dem Auge zu verlieren.

Screenshot Apple Maps Navigation Fußgängermodus
Nur das Wesentliche wird angezeigt, aber das gut sichtbar. Oben Navigationsanweisungen für den aktuellen Standort, unten dier Route mit Standort und Blick-/Gehrichtung.

Diese optische Führung ist Apple Maps hervorragend gelungen.

Nun zur Nutzung durch blinde und sehbehinderte Menschen. Hier bietet sich ein Audio zur Beschreibung an:

Audio eines Spaziergangs mit Apple Maps Navi und VoiceOver

Entscheidendes Detail für VoiceOver Nutzer: Links unten gibt es einen Schalter "Ortung" mit drei Zuständen. Diesen Schalter durch zweimaliges Aktivieren auf "Weiter Richtung" einstellen, damit die aktuelle Position und Richtung angesagt wird. Die jeweils nächste Routenanweisung steht im oberen Bildschirmbereich. Mit Auf- und Abstreichen kann man durch alle Anweisungen scrollen.

Nicht verschwiegen sei ein weiteres Manko: Nach dem Verlassen der Route, zum Beispiel, weil eine Abzweigung überlaufen wurde, gab es keinerlei Ansagen von VoiceOver mehr. Bei Sicht auf den Monitor kein Problem …

Fazit: Apple muss sich mit dieser Lösung vor großen, teuren Navigationslösungen nicht verstecken, die App hat aber noch viel Potenzial nach oben.


Der defekte Homebutton des iPhone - Apple hilft

Freitag, 28. September 2012

Der Home-Button am iPhone geht schnell mal kaputt. Apple weiß dass, und hat lange über eine Softwarelösung als Ersatz für den Home-Button nachgedacht. Ein iPhone ohne Home-Button also. Diese Pläne hat Apple offensichtlich in die Schublade gelegt. Nicht aber den Software-Home-Button. Den gibt es seit langem. Etwas versteckt unter Einstellungen > Allgemein > Bedienungshilfen > Assistive Touch (also doch: Bedienungshilfen).
Aktivieren von Assistive Touch zaubert einen Software-Home-Button auf den Bildschirm. Der Button wird nach wenigen Augenblicken transparent, so dass man die von ihm möglicherweise verdeckten Seiteninhalte erkennen kann. Und vor allem: Er ist verschiebbar: einfach antippen und dort hin schieben, wo er nicht stört.

Screenshot
Nach dem Antippen des Software-Home-Buttons öffnet sich ein Menü mit 4 Elementen: Siri - Favoriten - Gerät - Home

Diese Hilfe kann man natürlich auch prophylaktisch in Anspruch nehmen. Mein Home-Button geht ganz bestimmt nicht kaputt, weil ich ihn nie mehr betätige. Der Home-Button im Assistive Touch Menü funktioniert exakt wie der Hardware-Home-Button.

  • Einmal Tippen: App schließen bzw. zum Start-Bildschirm
  • Zweimal Tippen: App-Umschalter öffnen
  • Dreimal Tippen: Die in Einstellungen - Allgemein - Bedienungshilfen - Dreifachklick eingestellte Aktion (z. B. VoiceOver ein)
Screenshot
Der Punkt "Gerät" im Assistive Touch Menü öffnet ein Untermenü: Mit "Bildschirm sperren" schalte ich mein iPhone aus.

Ach ja, dieser Trick funktioniert seit iOS 6 auch mit VoiceOver. Weil VoiceOver jetzt den Software-Home-Button erkennt. Die Bedienung ist etwas tricky, aber erlernbar: Um beispielsweise den App-Umschalter zu öffnen, muss man den Home-Button im Assistive Touch Menü dreifach tippen.


Ein barrierefreies PDF

Montag, 13. August 2012

PDFs, das sind doch die Dinger, die man aus Prospekten durch Scannen erzeugt, dann ins Internet stellt, und von dort wieder ausdruckt. Also häufig nur Bilder. Und damit für blinde und sehbehinderte Surfer unbenutzbar.
Doch es geht auch anders. PDFs können so erstellt werden, dass auch blinde und sehbehinderte Menschen sie mit Screen Reader benutzen, d. h. lesen und navigieren können. Das ist zwar mit etwas Mühe verbunden, jedoch prinzipiell für jeden ohne Investition in teure Spezialsoftware machbar, guter Wille vorausgesetzt.
Das folgende PDF-Dokument soll als Beleg für diese Aussage dienen, und zeigt gleichzeitig die wichtigsten Schritte bei der Erstellung barrierefreier PDFs.

Demo-PDF

Hinweis, wenn Sie selbst testen wollen:

  1. Download der Demo mit Rechtsklick (Kontextmenü) und Speichern unter …
  2. Lesen: Die Kombination Acrobat Reader 10.1 und NVDA ist getestet und funktioniert. Andere PDF-Reader und Screen Reader …?

Wenn Sie nicht testen, sondern einfach nur wissen wollen, wie man barrierefreie PDFs erstellt: Z. B. mit dem kostenlosen Textverarbeitungsprogramm OpenOffice.
Download (bitte hierzu den Kommentar Nr. 2 lesen!):
nur für Windows:
OpenOffice nur Windows.
für Mac:
OpenOffice universell.

Weiterer Lesestoff zur Vertiefung

Über Kommentare würde ich mich diesmal ganz besonders freuen.


Ein Unterthan erdreystet sich

Samstag, 28. Juli 2012

Jawohl. Ich habe es getan. Ich einfacher EU-Bürger habe mich erdreistet, die EU darauf hinweisen zu wollen, dass es eine Verbesserungsmöglichkeit in einem ihrer Angebote an mich gibt. Leider ist es beim Wollen geblieben, weil die EU alle meine Versuche, einen geeigneten Ansprechpartner für mein Anliegen zu finden, einfach ignoriert. Wohl nach dem Motto: "Wo kämen wir denn hin …".

Doch der Reihe nach:
Eva Papst, eine blinde EU-Bürgerin und Accessibility-Expertin, sollte eine von der EU Kommission veröffentlichte Smartphone-App auf Barrierefreiheit testen. Sie bat mich, ihr bei diesem Test zu assistieren. Das Ergebnis meines Kurztests habe ich hier gebloggt: Passagierrechte für Personen mit Behinderungen. Ein EU (Schildbürger-) Streich.

Nun ist es mein Ding nicht, nur zu meckern. Vielmehr hatte ich die feste Absicht, die Entwickler der App konkret auf Accessibility-Mängel der App hinzuweisen. Also habe ich mich auf die Suche nach einem Ansprechpartner gemacht. Gar nicht so einfach. Auf Webseiten der EU gibt es kein Impressum. Aber mit einiger Mühe wurde ich dennoch fündig, und habe an folgende Adressen geschrieben:

  • address-information@ec.europa.eu
    Wie aus der Adresse zu entnehmen ist, eine Stelle (Behörde?), die über Adressen innerhalb der EU Kommission Auskunft geben sollte.
  • digit-europa@ec.europa.eu
    Ein Schuss ins Blaue, in der Hoffnung, dass sich hinter dieser Adresse Menschen mit Verständnis für IT verstecken.
  • cab-kallas-web-feedback@ec.europa.eu
    Siim Kallas, Vizepräsident der Kommission, verantwortlich für Verkehr (Webseite)
    An dieser Stelle habe ich vermutlich den Bogen überspannt. Direkt an den Vizepräsidenten zu schreiben! Vielleicht würde sich irgend jemand in seinem Büro des Anliegens eines einfachen EU Bürgers annehmen?
  • Schließlich griff ich zum Telefon, und rief ganz dreist im Büro der EU in München an. Ein freundlicher Herr dort reagierte prompt, und nannte mir folgende Kontaktmöglichkeit zum Web Team:
    http://europa.eu/geninfo/mailbox/form_de.htm

    Klasse. Endlich. Flugs mein "Anliegen" (so nennt man wohl die Frage eines Untertans an die Obrigkeit) dort ins Kontaktformular gestellt.

Hier der Inhalt meiner Mails:

Sehr geehrte Damen und Herren,

im Auftrag einer blinden Bekannten versuche ich, Kontakt mit den Entwicklern der App http://itunes.apple.com/de/app/your-passenger-rights-for/id535428814 aufzunehmen. Die App weist erhebliche Mängel bezüglich Barrierefreiheit auf. Ich würde gerne Details weitergeben

Bisheriges Fazit meiner Bemühungen:
Nach nunmehr 3 (i. W. drei) Wochen nicht eine einzige Antwort. Nicht einmal eine Eingangsbestätigung.
Ob die angeschriebenen Herrschaften sich wohl bei der Annahme ihres monatlichen Gehaltsschecks, der immerhin von meinen Steuern finanziert wird, auch so zieren?

Wenn mir so ein Fall von obrigkeitlicher Borniertheit in Deutschland passieren würde, dann wüsste ich, was zu tun ist. "Mein" Abgeordneter würde mir bestimmt ganz schnell eine Adresse benennen, wo ich Untätigkeitsbeschwerde einlegen kann.

Nachtrag 02.08.2012

Recht spät doch noch eine Reaktion:


In Antwort auf Ihre Anfrage möchten wir Ihnen mitteilen, dass die Europäische Kommission sich der Situation bewusst ist und an der Verbesserung der Barrierefreiheit der Smartphone-Applikation arbeitet.

Sollten Sie jedoch weitere Details weitergeben möchten, können Sie sich gerne unter folgender E-Mail-Adresse direkt an den zuständigen Dienst (Generaldirektion Mobilität und Transport) der Kommission wenden.
MOVE-APRIGHTS@ec.europa.eu

Eva Papst hat übrigens eine ähnlich lautende Antwort erhalten. Mit der zusätzlichen Aussage, dass in 2013 (in Worten: zweitausenddreizehn) mit einer neuen Version zu rechnen ist.

Meine Lesart:

Danke, wir sind an Ihren Informationen nicht interessiert. Wir wissen selbst, was zu tun wäre, aber wir haben es nicht nötig (sonst hätten wir die App ja gleich richtig geschrieben). Sollten Sie dennoch ihr Anliegen weiter verfolgen wollen: So schnell wird das nicht umgesetzt.

Gut, ich habe verstanden. Ein einfacher Bürger möge die Kreise der Europäischen Kommission nicht stören.


CAPTCHAs - der nicht enden wollende Unfug - und ein Gegenmittel

Montag, 23. Juli 2012

CAPTCHAS. Ich hab' mir schon die Finger wund getippt über dieses Thema. Nicht, weil ich persönlich mehr als nur die "normalen" Probleme mit dem Lösen dieser unsinnigen Aufgaben hätte. Ich habe keine, außer einer altersbedingten Sehbeeinträchtigung. Aber ich muss mich jedesmal wieder darüber ärgern, wenn ich mit zusammengekniffenen Augen versuche, so ein Ding zu entziffern. Und ich muss mich über die Gedankenlosigkeit ärgern, mit der Millionen von blinden und sehbehinderten Menschen von der Nutzung vieler Online-Dienste ausgeschlossen werden.

Als kürzlich eine mehrtägiger Ausfall von WebVisum zu berechtigter Aufregung unter betroffenen Surfern führte, habe ich mich aus purer Neugierde auf die Suche nach Alternativen gemacht. Und ich wurde fündig: bei Captcha Monster, einem Firefox-Addon.

Captcha Monster bietet eine kostenlose 30tägige Testphase an. Danach kostet Captcha Monster US$ 2,99 (2,63 €) zuzügl. MWSt. pro Monat. Mein 30-Tage-Testzeitraum läuft demnächst ab. Aber ich habe mich so daran gewöhnt, Captchas mit einem Rechtsklick und wenigen Sekunden Wartezeit lösen zu lassen, anstelle von "Augenverrenkungen", dass ich den Dienst vermutlich abonnieren werde. Obwohl … (siehe oben).

Ein Hinweis an blinde Leser:
Captcha Monster kann problemlos neben WebVisum installiert, und alternativ verwendet werden.


Passagierrechte für Personen mit Behinderungen. Ein EU (Schildbürger-) Streich.

Freitag, 6. Juli 2012

Screenshot Webseite
Reisen ist ein Recht für alle
In Europa sind Reisen für jeden fünften Bürger aufgrund von Alter, Behinderung oder eingeschränkter Mobilität schwierig. Deshalb hat die Europäische Union eine Reihe von Rechten festgelegt, damit dieser Personenkrels genauso problemlos mit dem Flugzeug oder der Bahn reisen kann wie jeder andere.

So weit so gut. Ob die Europäische Kommission diese ihre eigene Aussage verinnerlicht hat, darf bezweifelt werden.
Auf der Website werden Apps für verschiedene Smartphones angeboten. Ich hab' mir die iPhone App mal angeschaut; oder besser angehört, mit VoiceOver. VoiceOver, das ist das Hilfsmittel, mit dem blinde User das iPhone bedienen. Also exakt die Zielgruppe. Wenn also für die Zielgruppe der blinden iPhone User eine App angeboten wird, dann sollte diese Zielgruppe die App auch bedienen können.

Schauen wir uns einmal die Startseite "Bahn" an:

Screenshot iPhone App - Bahn
Die Startseite "Bahn" bietet ein Menü mit Themen und verlinkt zu den Antwortseiten.
Beispiel:
  • Kauf einer Fahrkarte
  • Verfügbarkeit von Informationen
  • Sicherheit im Zug und auf den Bahnhöfen
  • usw.

Antippen der ersten Option öffnet die Seite "Kauf einer Fahrkarte":

Screenshot iPhone App - Bahn
Kauf einer Fahrkarte
Welche Rechte habe ich?
Sie können Ihre Karte an einem Fahrkartenschalter oder an einem Fahrkartenautomaten, per Telefon oder über das Internet kaufen. Wenn keine dieser Möglichkeiten verfügbar ist, können Sie Ihre Fahrkarte auch im Zug kaufen
Wie kann man sich beschweren?
Wenn Sie glauben, dass Ihre Rechte … usw.

Sieht doch alles gut aus. Nicht so für blinde User. Die kriegen auf der Seite etwas ganz anderes als sehende User vorgesetzt:

Audio der Seite "Kauf einer Fahrkarte" von VoiceOver gelesen.

Ab ca. Sekunde 13 läuft die Bildschirmanzeige und die Sprachausgabe auseinander. Da wird an Stelle des angezeigten Inhalts die nicht sichtbare Menüseite erneut vorgelesen!
Nein! Das ist keineswegs ein einzelnes Mißgeschick. Die Accessibility-Probleme ziehen sich durch die ganze App. Es wäre ermüdend, und vermutlich wenig zielführend, jedes einzelne Detail hier zu dokumentieren

Was soll man davon halten? An Stelle eines (vernichtenden) Urteils über die Entwickler (können Sie es nicht, oder wollen sie nicht?) hier einige Links, die sich die Entwickler einmal zu Gemüte führen sollten:

Testen Sie selbst (Eva Papst).

See for yourself (english).

So baut man VoiceOver-Support in iOS-Anwendungen ein (Marco Zehe)

Nachtrag 17.07.2012

Eva Papst, eine unmittelbar Betroffene, hat einen grundsätzlichen Artikel zu der Thematik geschrieben:
http://aus-meiner-feder.at/alltag/kompensation.php


onlinetvrecorder.com

Montag, 2. Juli 2012

onlinetvrecorder.com ist der Online TV Recorder meiner Wahl. Kostengünstig - nur wenige Cent pro Aufzeichnung - , große Programmauswahl.
Ein Highlight: Viele Sendungen werden automatisch aufgezeichnet. Ich kann also auch Sendungen downloaden, die ich nicht selbst programmiert habe. (Stichwort: GetItAll-Wishlist)

Wenn nur die furchtbar unübersichtliche Programmoberfläche nicht wäre:

Screenshot Desktop
Der Startbildschirm der Online TV Recorder Website

Mit der Web-Oberfläche V2 wurde die Ansicht zwar etwas aufgeräumter. Aber die Bedienung ist für meinen Geschmack immer noch etwas mühsam. Ich will ja in der Regel nur eine Sendung programmieren, die ich im Programm gefunden habe.

Mehr oder weniger zufällig habe ich entdeckt, dass Online TV Recorder auch eine mobile Version bietet:
http://www.onlinetvrecorder.com/webapp/

Screenshots:

Screenshot 1 iPhone
Der Startbildschirm von Online TV Recorder auf dem iPhone, mit den 5 Optionen:
  • Sendungen
  • Aufzeichnungen
  • Profil
  • Hilfe
  • Erweiterte Funktionen
Screenshot 2 iPhone
Die Suchfunktion von Online TV Recorder auf dem iPhone

Voraussetzung für die Benutzung der mobilen Version ist ein Premium-Status mit App-Zugang. Preis hierfür: 99 Cent pro Monat. (Die Anmeldung leitet leider auf die Weboberfläche weiter, muss aber nur einmalig durchgeführt werden. Verlängern des Abos - Einzahlungen - können von der mobilen Oberfläche aus durchgeführt werden.)

Die mobile Version lässt sich auf dem iPhone mit VoiceOver tadellos bedienen.

Mein persönlicher Trick: Ich rufe die mobile Seite auch auf dem PC auf. Eine Wohltat nicht nur für die Augen.

Screenshot:

Screenshot der Web App auf dem Desktop
Der Startbildschirm der Online TV Recorder Web App auf dem Desktop

Wenn ich es richtig beurteile, dann ist diese Seite mit ScreenReader nicht bedienbar? Vielleicht ja mit Mac/Safari und VoiceOver?

Nachtrag

Auf Twitter wurde mir noch eine PDA-Version genannt:
http://www.onlinetvrecorder.com/pda/
Mit dieser Version geht auch das Registrieren ganz einfach. Ob auf dem iPhone, oder im Browser.


FTP auf dem iPhone - auch mit VoiceOver

Dienstag, 26. Juni 2012

… oder:

Blinde Webworker, die unterwegs mit dem iPhone Ihre Seiten pflegen wollen

Webworker, die auch unterwegs ihre Seiten pflegen. Das kann schon mal notwendig sein. Ohne "richtigen" Rechner, also ohne Tastatur, d. h. mit dem iPhone, Dateien auf dem Server bearbeiten: Auch das geht. mit einer wirklich genialen App: FTP On The Go. Der Preis: 4,99 €.
QR Code iTunes Link
So weit, so gut.
Dass FTP On The Go seit dem letzten Update mit VoiceOver perfekt bedienbar ist, ist alles andere als selbstverständlich. Also genau das richtige für blinde Webworker, die unterwegs mit dem iPhone Ihre Seiten pflegen wollen.


Voice Book VO für Facebook - eine iPhone App der anderen Art mit VoiceOver getestet

Samstag, 26. Mai 2012

Neu im App Store: Voice Book VO
Eine App, die es blinden und sehbehinderten iPhone Nutzern erleichtern soll, Facebook auf dem iPhone zu nutzen.

In der Beschreibung werden sehende Benutzer vor dem abgespeckten Design gewarnt.

Screenshot des Nachrichtenbildschirms
Die Standardansicht der App zeigt eine Nachricht in reiner Textform. Darüber die Überschrift "Newsfeed Item 7 of 94". In der Fußzeile ein Bedienungshinweis.
Screenshot des Aktionsbildschirms
  • Follow Link
  • Like This
  • Who Likes This?
  • Read Comments
  • Add Comment
  • Post Status
  • Go To Top
  • Go To Bottom
  • Refresh Newsfeed
  • Done
  • Voicebook Settings

Nett gemacht, und möglicherweise wirklich eine Option für blinde und sehbehinderte Facebooker.

Nachtrag 27.05.2012

Meine Kritik an der vermeintlich kaputten VoiceOver-Rotorsteuerung, die hier ursprünglich stand, muss ich zurücknehmen. Danke an Stan Lüder, Marco Zehe, und Sandra für die Hinweise.


Na also, geht doch! Remember the Milk zeigt, wie es geht

Montag, 14. Mai 2012

Ja, ich weiß. Die Überschrift ist irreführend. Wenigstens teilweise. Ich will nämlich heute einmal an einem Beispiel zeigen, dass Accessibility aka Barrierefreiheit und pfiffig gestylte Elemente sich nicht ausschließen. An Hand einer iPhone App. Remember the Milk, ein Get things done Tool, hat heute ein Upgrade seiner iOS App bereitgestellt. Mit der Ankündigung: "redesigned with a completely new interface". Die Erfahrung zeigt leider, dass sich hinter solchen Versprechungen in vielen Fällen eine Verschlechterung der Zugänglichkeit für VoiceOver Nutzer verbirgt.
Nicht so bei Remember the Milk. Der folgende Screenshot zeigt in Handschrift beschriftete Elemente, die entgegen einer ersten Befürchtung auch mit VoiceOver korrekt gelesen werden.

Screenshot 1
Screenshot iPhone: Die Seite mit den Aufgaben für morgen. Die Überschrift "Morgen" und die Auswahlschalter "erledigt" und "unerledigt" sind in Handschrift gestylt. Die Auswahl "unerledigt" ist handschriftlich eingerahmt, um die aktuell gewählte Ansicht zu symbolisieren.

VoiceOver liest korrekt und entsprechend der Konvention: "Unerledigt - Taste, Erledigt - grau dargestellt - Taste."

Ich kann nur sagen: Na also, geht doch.

Kurz noch zur App selbst: Remember the Milk synchronisiert perfekt sowohl mit der Desktop-Webapplikation, als auch mit iCal.

Screenshot 2
Screenshot des iPhone Kalenders mit der soeben in Remember the Milk eingegebenen Aufgabe: "Test mit VO"

Eine Schlussbemerkung: Ich kann leider nicht sagen, welche Funktionalität die kostenlose Version mitbringt, da ich seit einem Jahr die kostenpflichtige pro-Version nutze. Aber die Kernaussage dieses Artikels ist davon nicht betroffen.


Wie man Kommentatoren erfolgreich vergrault

Donnerstag, 26. April 2012

Kommentarspam - die unendliche Geschichte. Über kaum ein Thema habe ich so oft gebloggt.
Man kann Kommentatoren aber auch vergraulen. Bei Menschen zumindest funktioniert das. Ob's auch geben Spambots hilft?
Wie man Kommentatoren erfolgreich vergrault, zeigt das ZDF: Man blockiert Kommentare mit dem Hinweis "Ihr Kommentar wird moderiert. Bitte haben Sie etwas Geduld.". Meine Geduld wird nunmehr seit 24 Stunden (erfolglos) auf die Probe gestellt. Ich glaube inzwischen, die Ursache erraten zu haben: Kommentare mit einem Hyperlink werden automatisch blockiert, und mit diesem Kommentar versehen.
Liebes ZDF. Ich verstehe ja, dass ihr mit dem Moderieren nicht nachkommt (Eigentlich verstehe ich es nicht, aber das ist eine andere Geschichte). Dann aber bitte einen Hinweis, dass Hyperlinks in Kommentaren nicht erwünscht zulässig sind. Und diesen Hinweis bitte bevor ich mir die Mühe mache, einen Kommentar zu schreiben.
Warum schreibe ich mir meinen Frust in meinem Blog von der Seele, und nicht eine E-Mail an das ZDF? Weil das ZDF meinen Rat nicht will. Siehe dieser Artikel. (Meine GEZ Gebühren nimmt es gerne. Aber das ist schon wieder eine andere Geschichte .)

Nachtrag:
Ich hab' mir mal den Spaß gemacht, einen Kommentar an den (anscheinend überlasteten) Moderatoren des ZDF vorbei zu schleusen. Trotz Hyperlink. Womit bewiesen wäre: Manuelle Moderation ist kein Spamschutz.


Warum ist das so schwer?

Dienstag, 27. März 2012

Die meisten Entwickler von Apps für iOS reagieren mit einem Textbaustein a la "werden wir an die Entwicklungsabteilung weitergeben", wenn sie auf Barrieren in ihren Apps angesprochen werden.
Das war's dann leider auch schon, in der Mehrzahl der Fälle.
Positive Ausnahmen sind selten. Philipp Kandal von Skobbler mit der iOS App Navi 2 ist so eine Ausnahme. Dort gibt es echtes Bemühen um Barrierefreiheit. Leider ist auch dieses Bemühen nur teilweise von Erfolg gekrönt.
Philipp Kandal reagierte so, als die App bei einem Update mal wieder "verschlimmbösert" wurde:

Mir ist nicht so klar, warum uns das so schwer fällt …

Hier mein Versuch, darauf eine Antwort zu geben:

Ich vermute einfach, dass es Entwicklern schwer fällt, pragmatisch an das Thema heranzugehen.
Der oder die Entwickler wissen doch, welche Funktion in einem Programm enthalten ist, oder bei einer neuen Version neu eingebaut / verändert wurd.
Neue oder geänderte Funktionen werden selbstverständlich im Entwicklungprozess getestet. Natürlich mit dem Client, für den das Programm geschaffen wurde. In unserem Falle also mit einem iPhone und/oder iPad. Ich unterstelle, dass jeder Entwickler Zugang zu einem iPHone/iPad hat. Und damit hat er auch Zugang zum vorinstallierten VoiceOver.
Warum also nicht jede Funktion auch einmal mit VoiceOver testen. Ein Dreifachklick auf den Homebutton genügt. Und das Wissen um ganz wenige Gesten, die erforderlich sind, um eine App mit VoiceOver zu bedienen, und zumindest offensichtliche Barrieren zu entdecken.

Wie die Sache mit dem Dreifachklick funktioniert, hat Eva Papst allgemein verständlich beschrieben:
Testen Sie selbst!
Und damit fehlendes Verständnis der deutschen Sprache nicht als Ausrede her halten kann, das Gleiche auch noch auf englisch.


Podcasts mit Inhaltsverzeichnis - eine Demo

Samstag, 4. Februar 2012

Logo webdesign weisshart

RSS Feed LogoRSS Podcast Feed abonnieren

Download:

podcast_1.mp3
podcast_1.m4a

Es wird eine Methode demonstriert, wie man meinen Wunsch erfüllen kann, im Podcaster aus einem Inhaltsverzeichnis heraus die Zeitangabe anzuklicken, um direkt zur entsprechenden Stelle im Podcast zu springen.
Einfach die Zeitangabe(n) in folgender Liste anklicken.
Dies funktioniert derzeit meines Wissens leider nur im Instacast Podcatcher für iPhone bzw. für das iPad (und erst, wenn man den Podcast abonniert hat!)
Instacast ist übrigens mit VoiceOver perfekt bedienbar.

Aus Bequemlichkeit habe ich für diese Demo einfach diverse Musikstücke gewählt.

Inhalt Folge 1

[00:00:13] Diese Musik ist gemafrei
Hier könnten noch weitere Erklärungen zum verlinkten Abschnitt stehen.
[00:00:35] Victimae paschali laudes
Klar, man kann auch einen Hyperlink setzen im Inhaltsverzeichnis.
[00:02:23] Osterglocken

Dieses Inhaltsverzeichnis wird einfach als Liste im feed.xml im Abschnitt <description> eingefügt. Um HTML Tags in einer .xml Datei zu verwenden, muss der entsprechende Abschnitt als CDATA deklariert werden. Ein angenehmer Nebeneffekt: Die description kann einfach aus einem HTML Dokument kopiert werden. Der Aufwand hierfür ist damit wirklich nicht groß - vorausgesetzt, der Podcast kann in einzelne Abschnitte strukturiert werden.
Download der .xml-Datei zum Nachmachen.


Clearly - Schöner Lesen mit einem Add-on für Firefox

Freitag, 23. Dezember 2011

Die Idee ist nicht ganz neu: Lesen im Web verschönern, durch Ausblenden aller unnötigen, ablenkenden Komponenten wie Werbung, Navigation usw. Bereits Adblock Plus hilft bereits etwas dabei. Bekannt dürfte auch Readability sein, das meines Wissens erstmals aus "verstyltem" Seitendesign schön lesbare Seiten gemacht hat. Der bisher gelungenste Ansatz ist allerdings Cleary von Evernote. Clearly auf der Seite des Herstellers. Screenshot ohne Clearly Screenshot mit Clearly
Das Schönste: "Entrümpeln" mittels Clearly mittels frei konfigurierbarem Tastaturkürzel. Und zurück mit Esc. Das müsste doch auch was sein für Screen Reader Nutzer.


Die Büchse der Pandora

Sonntag, 4. Dezember 2011

… sollte man tunlichst nicht öffnen.

Der Webseiten-Bastler, der für den Internetauftritt des Pandora Store Wien www.pandora-store.at/) verantwortlich zeichnet, hat diese Erkenntnis wohl zu wörtlich genommen. Besucher der Site werden von folgender Startseite begrüßt:

Screenshot

Nein, nicht alle Besucher sehen eine leere Seite. Nur Besucher, deren Browser keine Grafiken anzeigt. Weil sie Grafiken deaktiviert haben (im mobilen Browser zum Beispiel, um unterwegs Traffic zu sparen), oder Benutzer eines Screen Readers. Diese Besucher werden auch nie erfahren, dass es auf der Seite weiterführende Links gibt, z. B. zu einer Seite mit Adressen und Öffnungszeiten. Aber genau diese Besuchergruppe muss auch nicht wissen, dass es noch weitere Seiten gibt. Die bestehen nämlich auch wieder nur aus Grafiken, und unsere Besuchergruppe würde wieder nur eine leere Seite sehen. (Screenshot siehe oben; einen weiteren Screenshot konnte ich mir ersparen.)

Der Pandora Store kann vermutlich leicht auf diese 10 oder 20 Prozent potenzieller Kunden verzichten. Falls nicht, sollte man dem verantwortlichen Webseiten-Bastler mal erklären, dass man die gleiche Optik auch mit "ordentlicher" Technik erreichen kann, dass man schöne Webseiten erstellen kann, ohne von vornherein einen erheblichen Prozentsatz potenzieller Kunden auszuschließen.

Bevor ich's vergesse: so sieht die Webseite mit aktivierten Grafiken aus:

Screenshot


iOS5 macht pinch to zoom kaputt. Eine Katastrophe für sehbehinderte Menschen?

Montag, 17. Oktober 2011

In einschlägigen Foren liest man über das neueste mobile Apple-Betriebssystem iOS5, dass pinch to zoom nicht mehr funktioniert. Ich hab' erst mal mit Unverständnis reagiert. Wenn ich meine eigenen mobilen Seiten auf dem iPhone aufrufe, dann funktioniert das sehr wohl. Beispiel: webdesign.weisshart.de und zimmer-chiemsee.de
Aber auf google.de funktioniert das tatsächlich nicht (mehr).
Ein kurzer Blick in den Quelltext genügt: Nicht Apple und iOS5 sind daran schuld, sondern Google & Co. Um das zu verstehen, muss man nicht einmal HTML können. Etwas Englisch genügt:

<meta content="width=device-width,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no" />

Was soll wohl das user-scalable=no bedeuten? Und was hat Google sich dabei gedacht?

Warum nicht einfach richtig:

<meta name="viewport" content="width=device-width, user-scalable=yes" />

Safari HTML Reference


Accessible Google Routenplaner

Sonntag, 25. September 2011

Unter blinden Reisenden ist/war der Trick bekannt, wie man an eine barrierefreie Version des Google Routenplaners kommt: http://maps.google.de/m/, die mobile Version von Google Maps war nicht nur für Smartphones optimiert, sondern auch optimal mit Screen Readern auf dem PC bedienbar. Die Verbreitung von mobilen Webdiensten kam also, wohl unabsichtlicherweise, auch blinden Menschen zugute.

War? Kam? Ja, leider. Der Aufruf des obigen Links wird neuerdings umgeleitet auf Google Places. Trendy; und nett, wenn man in der Nähe des Aufenthaltsorts nach einer Pizzeria oder Ähnlichem sucht. Aber es führt kein Weg mehr zum mobilen (=barrierefreien) Routenplaner, mit freier Eingabe von Start und Ziel.

Doch es gibt ihn noch, den mobilen Routenplaner:

http://maps.google.de/m/directions sowohl auf dem Smartphone, als auch auf dem PC.

Screenshot


Der Einsatz auf dem PC kann auch im Zeitalter von iPhone & Co. durchaus sinnvoll sein. Ein Fußweg durch die Straßen einer Großstadt mit dem Smartphone_Navi vor der Nase kann durch schlechten GPS-Empfang gestört oder gar unmöglich sein. Für blinde Navigatoren kommt erschwerend der Lärm der Großstadt hinzu, der ein Lauschen auf die Sprachausgabe des Navi unmöglich oder gar lebensgefährlich machen kann. Die Lösung: Route vorab am PC planen, und ausdrucken (ggf. auf "blindengerechte" Weise).

Screenshot Routenbeschreibung


Diese Routenbeschreibung ausgedruckt, oder als Text gespeichert, liest sich dann wie folgt:

Marienplatz 900 m - Info zu 11 Minuten

  1. Von Landschaftstraße nach Westen Richtung Weinstraße starten - 63 m
  2. Weiter auf Filserbräugasse - 69 m
  3. Links abbiegen auf Frauenplatz - 190 m
  4. Links abbiegen auf Augustinerstraße - 76 m
  5. Rechts abbiegen auf Neuhauser Str. - 400 m
  6. Rechts abbiegen auf Karlsplatz - 45 m
  7. Links halten, um auf Karlsplatz zu bleiben - 17 m
  8. Nach links abbiegen, um auf Karlsplatz zu bleiben - 42 m

Ende: Karlsplatz, München

Wie lange wohl Google diese undokumentierte Adresse offen hält?

Nachtrag 26.09.2011

Die mobile Version von Google Maps ist jetzt zu erreichen unter http://maps.google.com/m/maps. Nachdem man dort eine Adresse eingegeben hat, findet sich unter der Karte ein Link namens "Wegbeschreibung abrufen". Dieser Link führt ebenfalls zum mobilen (=barrierefreien) Routenplaner.

Nachtrag 2 - 04.07.2012

Lange Zeit dachte ich, Google hätte nur einen temporären Schluckauf. Leider scheint das Problem permanent zu sein.
Google Maps mobil gibt es noch. Auch den Link zum Routenplaner, mit dem Linktext "Wegbeschreibung abrufen".
Nur: Das ist kein Link. Sondern funktionsloser Text. Auch wenn Google ihn mittels CSS so aussehen lässt, als ob es ein Link wäre.
Was soll man davon nur halten?


VisionSim: iPhone App simuliert Augenkrankheiten

Donnerstag, 8. September 2011

Unter dem Namen VisionSim gibt es eine kleine kostenlose App fürs iPhone, die einen Einblick ermöglicht, wie Menschen mit verschiedenen Augenerkrankungen ihre Umwelt wahrnehmen. Die App verwendet die Kamera des iPhone und stellt das Ergebnis als Virtual Reality dar.

Nimm dein iPhone, und schau dir die Speisekarte mal so an, wie ein an Macula-Degeneration erkrankter Mensch versucht, eine Auswahl zu treffen.

Screenshot:

Screenshot


Test ZDFmediathek iPhone App mit VoiceOver

Montag, 5. September 2011

Das ZDF hat heute die kostenlose iPhone App ZDFmediathek veröffentlicht. Die App tut im Prinzip, was sie verspricht: Zugriff auf archivierte ZDF-Sendungen auch auf dem iPhone. Das User Interface ist hässlich,

Screenshot 1


aber wenn man "seine" Sendung gefunden hat - dazu gibt es auch eine Suchfunktion - funktioniert das Abspielen der Sendungen im iPhone eigenen Player zufriedenstellend.

Screenshot 2


Leider zeigt auch diese App wieder einmal die altbekannten Barrieren: Wichtige Schaltflächen sind für VoiceOver nicht beschriftet. VoiceOver spricht nur "Hyperlink". Dies gilt beispielsweise für den wichtigen Button zur Suche (rechts oben neben dem Button Menü).

Hinweis für VoiceOver Nutzer, die es dennoch versuchen wollen: Der Button zum Start des Videos ist auf der Seite, die nach Auswahl einer Sendung geöffnet wird, und belegt etwa das obere Drittel des Bildschirms. Beschriftet ist der Button (un)sinnigerweise mit "Leerzeichen". Darunter die Beschreibung des Films. Die Position des Buttons ist also relativ leicht zu "erraten".

Screenshot 3


Liebes ZDF: Die fehlende Beschriftung nachzurüsten ist technisch eine Kleinigkeit, und muss nur einmal gemacht werden, um Ihr Angebot für alle Zeiten auch für blinde Benutzer zugänglich zu machen. Nur Wollen müssen Sie schon mögen.

Ein Hinweis an die Entwickler

Ich empfehle folgende Lektüre:

iOS Accessibility sowie Making Your iPhone App Accessible

Nachtrag 07.05.2012

Weil das ZDF sich um Barrierefreiheit anscheinend nicht bemüht, hier noch ein paar Hinweise für blinde User nachgereicht, um die Suchfunktion mit VoiceOver zu nutzen:

  • App killen und neu starten, weil der Home-Link nicht immer zuverlässig auf die Startseite führt.
  • Der Suchen Button (beschriftet mit Hyperlink) ist rechts oben neben dem Button "Menü".
  • Das Suchfeld kann man nicht antabben, sondern nur erraten. Es befindet sich mittig unter der Überschrift "ZDFmediathek", und unter einer ebenfalls nicht fokussierbaren Überschrift "Suche". Also ca 2 cm nach unten fummeln, Ansage: "Suche - Suchbegriff - Textfeld". Die Tastatur schließt sich nicht nach dem Abschicken des Suchbegriffs per Suchen-Taste auf der Tastatur, sondern nur, wenn man von Suchfeld aus mit rechts wischen zum Absendebutton geht. (Beschriftung: "Suche 30.png")

10 Schritte auf dem Weg zur barrierefreien Website

Mittwoch, 24. August 2011

Wer barrierefreie Websites erstellen muss (oder will), kommt in letzter Instanz nicht umhin, sich mit der WCAG 2.0 zu beschäftigen. Leider sind diese Richtlinien ein Monster, und alleine der schiere Umfang der Dokumentation kann abschreckend wirken, insbesondere auf Neulinge auf dem Gebiet Barrierefreiheit.
Yahoo! hat jetzt einen Katalog mit nur 10 Punkten aufgestellt, der bei der Beurteilung der Frage helfen soll, ob eine Site barrierefrei ist. Der 10-Punkte Katalog
Natürlich kann man die WCAG 2.0 nicht verlustlos auf lediglich 10 Fragen komprimieren. Aber mir gefällt der Ansatz von Yahoo! - besser ein Einstieg mit niedrigen Hürden, als überhaupt kein Einstieg wegen scheinbar zu hoher Einstiegshürden.
Ich darf Punkt 1 des Yahoo-Katalogs zitieren:

1. Did the people who built your site consider individuals with disabilities when they designed it?
A "yes" answer means that you are already halfway to making your site accessible.

Volltreffer! Das Problembewusstsein, die Absicht, ist schon die halbe Miete. Das Gros der Barrieren im Web ist darauf zurückzuführen, dass die Entwickler sich gar nicht der Tatsache bewusst sind, dass man Webseiten mit relativ einfachen Mitteln für Menschen mit Behinderungen zugänglich machen kann.

Eine Kritik an der Yahoo-Liste sei mir allerdings gestattet: Es fehlt der Hinweis, dass eine saubere Semantik, eine logische Strukturierung der Seiten mit Überschriften und Absätzen, Listen usw. in jedem Fall für eine Verbesserung der Zugänglichkeit für alle Besucher sorgt. Eine Validierung des HTML-Codes kann dabei helfen.


Hyphenation - automatische Silbentrennung

Donnerstag, 18. August 2011

Pretty much the only forms of Western literature that don't use hyphenation are children's books and websites.

schreibt das FONTDECK Blog.
Warum Websites keine Silbentrennung einsetzen, ist schnell erklärt: Weil die Laufweite der Zeilen, anders als im Print, nicht bekannt ist. Sie hängt nämlich von den Benutzereinstellungen ab.
HTML bietet in diesem Fall eine Art Automatik - den bedingten Trennstrich "soft hyphens" - an: ­ - inzwischen unterstützen alle modernen Browser das.
Das manuelle Setzen von soft hyphens rechtferigt den Aufwand aber nur in wenigen, speziellen Fällen. Deshalb gibt es Techniken, das Setzen von soft hyphens automatisch von JavaScript erledigen zu lassen. Am bekanntesten dürfte Hyphenator.js sein.

Wann macht automatische Silbentrennung Sinn?

  1. Wenn Blocksatz eingesetzt wird.
  2. Bei extrem kurzen Zeilenweite, z. B. wenn Text Bilder umfließt.

Die Ergebnisse mit Hyphenator.js sind ordentlich. Mit einer gravierenden Einschränkung: Screen Reader (nicht alle, aber die meisten) "verschlucken sich" an den soft hyphens. Das Ergebnis ist unverständlich bis unzumutbar. Wer Wert darauf legt, dass seine Seiten für Screen Reader zugänglich sind, muss auf automatische Silbentrennung mittels Hyphenator.js verzichten.

Ein erster Schritt in die richtige Richtung

Puristen hätten längst eingewendet:
Silbentrennung hat nichts im Markup zu suchen (Markup ist Inhalt), und auch nichts im JavaScript (JavaScript ist zuständig für das Verhalten einer Webseite). Silbentrennung ist Darstellung, und gehört ins CSS! Und dort hat es jetzt, mit der CSS3-Deklaration "hyphens:auto" auch Einzug gefunden. Bisher unterstützen diese Deklaration der brandneue Firefox 6, und Safari 5.1 bzw. Safari / iOS. Und beide Browser auch nur mit Vendor-Prefix. Der CSS Code muss also lauten:

.hyphen {
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    hyphens: auto;
}

Damit ist der Safari bedient.
Für den Firefox ist zusätzlich lang="en" für das entsprechende Element (oder ein Elternelement) nötig. Jawohl: "en", auch wenn die Sprache des Dokument eine andere ist. Also

<div class="hyphen" lang="en" >

Das funktioniert. Zumindest auf dem Monitor. Aber es ist natürlich ein absolutes No-Go - nicht nur wegen des Kauderwelsch', das Screen Reader dann ausgeben.

Was bleibt? - Fazit

Also alles noch Spielerei, nicht in der Praxis einsetzbar?
DOCH!
Es gibt einen Anwendungsfall, der geradezu nach "hyphens:auto" schreit: Das iPhone! Dort sind die Zeilen kurz, und das iPhone versteht die Deklaration.
Also ran ans CSS:

body {
    -webkit-hyphens: auto;
}

Das versteht nur der Safari, und es erfordert kein Verbiegen der Dokumentensprache. Und, weil die Silbentrennung jetzt dort ist, wo sie hingehört, nämlich im CSS, "verschluckt" sich auch der Screeen Reader (VoiceOver) nicht. Wer das Ergebnis sehen will, hier ein Testcase.
Hinweis: Die Testseite ist mit <body lang="en"> ausgezeichnet. Die Anzeige funktioniert also auch im Firefox 6. Wer sich die Seite mit VoiceOver im Safari anhört, weiß, warum das ein No-Go ist.

Nachtrag 08.11.2011

Firefox in der Version 8 versteht jetzt -moz-hyphens:auto, auch ohne die Vergewaltigung mittels lang="en". Und ältere Versione ignorieren diese Auszeichnung einfach. Weil das niemandem schadet, habe ich es sofort in meine Seiten eingebaut.

Nachtrag 19.11.2011

Und auch Safari/Mac in der aktuellen Version 5.1.1 kann jetzt Hyphenation. Ohne Die oben genannten VoiceOver-Probleme.

Kuriositäten im Firefox

Nobody is perfect. "Merkwürdige" Trennungen im Firefox, die mir so untergekommen sind.

  • iPho-ne
  • VoiceO-ver
  • vi-elleicht
  • App-le
  • Seitende-sign
  • JavaS-cript

Mit den Händen sehen

Montag, 27. Juni 2011

Das Kunsthistorische Museum Wien KHM bietet seit kurzem blinden und sehbehinderten Menschen ein einzigartiges Erlebnis. Ausgewählte Gemälde aus der Sammlung wurden in ertastbare Reproduktionen umgesetzt. In Verbindung mit einer ausführlichen Bildbeschreibung in Braille-Schrift wurde wohl das Optimum erreicht beim Versuch, Kunst, die ausschließlich für das Auge geschaffen wurde, auch Menschen zugänglich zu machen, die Kunstwerke nicht oder nicht mehr über den Sehsinn erfassen können.

"Madonna im Grünen" Raffael 1505 oder 1506

Das Original
Das Original: Raffael - Madonna im Grünen
Foto: © Kunsthistorisches Museum
Das Relief
Das Foto zeigt eine Vorstufe des Reliefs ohne Glättung. Die Gesichter sind noch relativ grob gefräst.
Foto: © Kunsthistorisches Museum
Das fertige Exponat in der Ausstellung
Foto: © Kunsthistorisches Museum

Am Beispiel dieses Exponats möchte ich versuchen, meinen Eindruck von der begeisternden Technik zu beschreiben. Wobei ich mit Technik nicht das Fräsen und Gießen des Reliefs meine.

Nein, mich fasziniert der künstlerische Prozess, die Umsetzung von rein optischen in tastbare Informationen. Unter einem rein technischen Aspekt transportiert ein Gemälde Informationen mittels Farben und Konturen. In Farben und Konturen verschlüsselt sind fallweise auch die dritte Dimension, die Tiefe des Raumes, und plastische Formen. Darüber hinaus werden Stimmungen durch Lichter und Schatten, also letztlich wieder durch Farben ausgedrückt. Kein Programm wird in absehbarer Zeit in der Lage sein, all diese virtuellen Informationen automatisch "richtig" in andere Dimensionen zu übersetzen. Nur das Einfühlungsvermögen eines Künstlers kann letztlich entscheiden, ob und wie Farbübergänge, Lichter, Konturen usw. durch tastbare Details wie Oberflächenstruktur, erhabene Bereiche, Kanten, Rundungen usw. repräsentiert werden können. Letztlich entsteht so aus dem Original-Kunstwerk ein Sekundärkunstwerk mit einer eigenen Qualität, aber mit dem Anspruch, das Original bestmöglich zu repräsentieren.

Für das Projekt wurde ganz offensichtlich dieser Künstler mit technischem Background (oder Techniker mit Kunstverstand?) gefunden. Dipl.-Ing.(FH) Andreas Reichinger, Computer Vision - VRVis Forschungs-GmbH, www.VRVis.at.

Herr Reichinger hat mir freundlicherweise den Prozess geschildert. Wie nicht anders erwartet, bedient er sich verschiedener Programme - Photoshop, aber auch speziell für diesen Zweck erstellter Software. In einem ersten Schritt werden mit Unterstützung von Photoshop die Konturen nachgezeichnet. Ja, nicht vom Programm ermittelt, sondern manuell nachgezeichnet. Ein Mensch muss in diesem Schritt zwischen relevanter Information und "Rauschen" unterscheiden. Bei der Hinzufügung der Information über die räumliche Tiefe, dem nächsten Schritt, hilft wiederum Software. Allerdings gibt es Fälle, welche die Software zum "Stolpern" bringen. Beispiel: Der Figur der Madonna ist eine bestimmte Tiefeninformation zugeordnet. Das Jesuskind steht unzweifelhaft eine Ebene davor. Nun umschlingt Marias Arm das Jesuskind, durchdringt also quasi die Ebene des Jesuskinds, und mündet in der Hand, also noch eine Ebene davor. Diese "Krümmung" in der Tiefeninformation des Elements Arm muss manuell hinzugefügt werden.

Interessant am Rande: Der Großteil des Prozesses wird auf Basis eines Graustufenbilds durchgeführt. Der Grund hierfür: Die Menge an Informationen muss für eine ertastbare Reproduktion reduziert werden. Für wichtiger als Farben wurde erachtet, Texturen und Oberflächenbeschaffenheit zu transportieren. Farbinformationen müssen, und können ohne Qualitätseinbuße, aus der Bildbeschreibung entnommen werden.

Der nächste, wichtige Schritt war die Abbildung von plastischen Elementen, hier insbesondere von Gesichtern. Ein Filterprogamm auf Bildausschnitte angewandt konnte hier einen guten Teil der Arbeit übernehmen.

Das Projektteam erachtete als wichtig, Gesichter auch für sehende Betrachter ansprechend zu gestalten, und damit das ganze Relief. Ich kann nur bestätigen, dass dies hervorragend gelungen ist. Für die am Projekt beteiligten blinden Testpersonen war natürlich die Haptik wichtig. Ein Gesicht oder Körperteil muss weiche Rundungen zeigen, und keineswegs Schichtungen wie Höhenlinien, die von der eigentlichen Form ablenken würden.

Das Relief
Das fertige, ausgestellte Relief

Von der Vorlage, dem in hoher Qualität eingescannten Original, bis zur Vorlage für die computergesteuerte Fräsmaschine, wurden mehrere verschiedene, auch speziell für diesen Zweck geschriebene Programme koordiniert eingesetzt. Der Wunsch, zukünftig diese verschiedenen Programme zu einem einzigen zu konsolidieren, und auf diese Weise die Technik portabler und auch kostengünstiger zu machen, ist verständlich.

Ergänzend, und für das Verständnis des Kunstwerks unverzichtbar, gibt es eine Bildbeschreibung, die der Qualität des zu beschreibenden Kunstwerks adäquat ist. Diese Beschreibung geht weit über Form und Inhalt einer typischen Bildbeschreibung, wie sie z. B. im Web eingesetzt wird hinaus, und beinhaltet auch weiterführende Informationen über das jeweilige Werk.

Im folgenden ein kurzer Auszug:

… Raffael verstand es meisterhaft, dank Farbgebung, Figurentypik und Symbolik den tiefen religiösen Charakter dieses Andachtsbildes herauszuarbeiten. Marias Gewänder sind in den ihr theologisch zugeordneten Farben gehalten. Sie trägt ein rotes, langärmeliges Kleid mit einem halbrunden Halsausschnitt. Der Saum des Dekolletees ist mit goldenen Buchstaben bestickt, in denen die Jahreszahl 1506 zu lesen ist. Ihr strahlend blauer Mantel, ebenfalls mit einer kostbaren Goldborte verbrämt, ist stoffreich um ihre Hüften und Beine drapiert. Sie strahlt Würde und Ruhe aus, ganz auf die Kinder zu ihren Füßen konzentriert. Johannes ist im Verhältnis zu Maria als Kleinkind geschildert, ein Bub von vielleicht drei oder vier Jahren, Christus etwas jünger. Nach theologischer Auffassung sind die Cousins altersmäßig kaum voneinander entfernt. Raffael gibt den beiden jedoch unterschiedlich reife Gesichtszüge, vermutlich um die theologische Botschaft zu unterstreichen. Johannes als letzter Prophet verheißt die Ankunft des Erlösers, er ist ja auch der Täufer Christi.

Quelle: Kunsthistorisches Museum

Man kann dem KHM zu diesem Projekt nur gratulieren, und viel Erfolg wünschen. Schön wäre es, wenn Kopien der Exponate auf Reisen gehen könnten, um blinden Menschen auch außerhalb Wiens diesen Kunstgenuss zu ermöglichen. Noch schöner wäre es, die Technik portabel zu gestalten, um auch andere Museen weltweit zu animieren, eigene Exponate auf diese Weise blinden Menschen zugänglich zu machen.

Mein Dank geht an die Projektleiterin Frau Dr. Krall, KHM, für viele interessante Hintergrundinfos, sowie an Eva Papst, die auch maßgeblich am Projekt beteiligt war, für die "Museumsführung". Eva Papst wird hoffentlich in Ihrem Blog http://aus-meiner-feder.at auch noch einen eigenen Beitrag aus ihrem Blickwinkel schreiben.

Weiterführende Links:

vr vis - Tactile Paintings (english)


Der barrierefreie Apfel

Montag, 11. April 2011

Apple ist ein geschlossenes Universum. Das hat natürlich Nachteile im Vergleich zum Beispiel mit der offenen Unix-Welt. Aber auch Vorteile. Apps für iPhone & Co. müssen eine rigide Qualitätssicherung in Cupertino durchlaufen, bevor sie via App Store auf die tragbaren Äpfel installiert werden. An dieser Qualitätssicherung führt kein Weg vorbei. Es gibt also, wie bei kaum einem anderen System, eine zentrale Stellle, welche die Qualitätskriterien festlegt und kontrolliert.

Das hat mich auf eine verwegene Idee gebracht. Diese zentrale Stelle könnte doch auch für mehr Barrierefreiheit sorgen. Apple ist ja dem Thema Barrierefreiheit gegenüber grundsätzlich extrem aufgeschlossen. Wie sonst käme es, dass Apple mit jedem System einen Screen Reader (VoiceOver) kostenlos mitliefert.

Meine Idee: Anlässlich der Qualitätskontrolle wird jede App auch auf Barrierefreiheit, also auf die Verwendbarkeit mit VoiceOver getestet.

Ich höre lauten Widerspruch: Wieso muss denn jede App auch von blinden Nutzern bedienbar sein? Es gibt doch auch …

Klar. Und kein Problem. Mit VoiceOver nicht bedienbare Apps müssen ja nicht endgültig abgewiesen werden. Aber eine Rückmeldung an den Entwickler, dass eine eingereichte App an dieser oder jener Stelle mit VoiceOver nicht bedienbar ist, verbunden mit der Frage, ob die App dennoch bewusst barrierebehaftet veröffentlicht werden soll, hätte sicher einen erzieherischen Effekt.

Man könnte sogar noch einen Schritt weiter gehen: So wie bestimmte Apps vor der Installation einen Hinweis auf ein Mindestalter zeigen, könnte man einen Hinweis auf mangelhafte Benutzbarkeit mit VoiceOver anzeigen.

All dies würde nicht die (Apfel-) Welt kosten, und könnte einen großen Schritt vorwärts für viele Apfel-Fans bewirken, die auf VoiceOver-Unterstützung angewiesen sind, also die vielen blinden iPhone User.


Versteckte Inhalte sichtbar machen

Mittwoch, 2. März 2011

Vorbemerkung

Bei der Erstellung barrierefreier Webseiten ist ein fester Bestandteil das Einfügen von Elementen, die ausschließlich für Screen Reader sichtbar sind. Ein Beispiel: Die Kennzeichnung der aktuellen Seite im Navigationsmenü erfolgt in der Regel in Form von optischen Merkmalen - Farbe, Hintergrundfarbe oder ähnliches.
Da diese Merkmale für Screen Reader nicht erkennbar sind, kann man man der aktuellen Seite im Menü ein "Standort:" voranstellen, und diesen Zusatz unsichtbar machen.
Dieses unsichtbar machen erfolgt per CSS. Aber natürlich nicht, wie immer noch häufig anzutreffen, per display:none!
Die richtige Technik ist vielmehr, diese Elemente aus dem Viewport zu schieben. Zu diesem Zweck werden die betreffenden Elemente mit einer bestimmten Klasse ausgezeichnet, z. b. class="hide", und ins CSS kommt etwas wie
.hide {
position:absolute;
left:-9000px;
overflow:hidden;
display:inline;
}

Versteckte Inhalte sichtbar machen

Nun kann durchaus der Wunsch aufkommen, die solchermaßen versteckten Elemente wieder sichtbar zu machen. Insbesondere Webworker, die sich um Barrierefreiheit bemühen, könnten sich ein entsprechendes Werkzeug wünschen.
Ich glaube allerdings nicht, dass sich die Anzeige von aus dem Viewport geschobenen Elementen automatisieren lässt. Zu vielfältig sind die möglichen Umsetzungen via CSS. Ich habe mir daher eine Technik erarbeitet, die mit wenig Handarbeit auskommt, und einem Firefox Add-on, das vermutlich jeder ernsthafte Webworker ohnehin installiert hat: Das Web Developer Add-on

Die Vorgehensweise

Im Web Developer "CSS bearbeiten" aufrufen.
Im CSS suche ich nun die Deklaration für das aus dem Viewport schieben. Häufig hilft eine Suche nach dem String "000" - weil eben häufig nach - 1000px oder einem Vielfachen davon verschoben wird.
So sieht das dann aus:
Screenshot Web Developer CSS bearbeiten


Nun hänge ich an die gefundene Deklaration einfach ein paar Zeilen an, und überschreibe damit das Verschieben:
position:relative;
left:0;
top:0;
color: #222;
background: yellow;
font-weight:normal;

Das sollte für die meisten Fälle genügen. Eventuell ist hier noch ein wenig Nacharbeit erforderlich.
Screenshot 2 Web Developer CSS bearbeiten


Das Ergebnis erscheint jedenfalls sofort im Browser. Alle aus dem Viewport geschobenen Elemente sind sichtbar, und markiert.
Screenshot Webseite mit Markierungen


Test TVSpielfilm iPhone App mit VoiceOver

Mittwoch, 2. Februar 2011

Dass auch blinde Menschen fernsehen, sollte sich inzwischen herum gesprochen haben. Und auch blinde Menschen entscheiden gerne vorab, was sie sich "anschauen" wollen. Dazu dient in der Regel eine Programmzeitschrift. Im iPhone Zeitalter natürlich in Form einer iPhone App. Die ist für blinde Menschen ohnehin besser lesbar als die gedruckte Ausgabe. Falls sie, die App, mit VoiceOver bedienbar ist. Und dies trifft auf die App von TVSpielfilm zu. Zumindest weitgehend. Von einigen Nachlässigkeiten der Programmierer abgesehen, die ich im folgenden aufzeige.

Screenshot Startseite TVSpielfilm
Der Startbildschirm zeigt eine Liste mit den aktuell laufenden Sendungen, darüber die 4 Buttons: Jetzt - 20.15 - 22.00 - andere Zeit. Jetzt ist als aktiv gekennzeichnet.

Die Funktion dieser Buttons ist selbsterklärend. Nicht jedoch für VoiceOver Nutzer. Die bekommen etwas wie "Auswahl Segment tcr xx passive" vorgelesen. So hört sich das an:

Audio

Falls ein VoiceOver Nutzer doch herausgefunden hat, wozu die 4 Buttons dienen, und mittels Auswahlbutton 4 eine andere Zeit auswählen will, wird es wieder spannend. Es öffnet sich ein Auswahlmenü - bei VoiceOver heißt das Einblendmenü - mit drei Spalten: Tag - Uhrzeit - Sender. Screenshot:

Screenshot Auswahlmenü TVSpielfilm
Das Auswahlmenü mit den drei Spalten: Tag - Uhrzeit - Sender.

Die einzelnen Spalten sind zwar nicht beschriftet, aber VoiceOver liest den jeweils ausgewählten Wert vor. Damit kann man sich gut orientieren. Erst in der letzten Spalte, der Senderauswahl, wird es für VoiceOver Nutzer wieder abenteuerlich. Die grafischen Sendersymbole sind hübsch anzusehen, aber so anzuhören:

Audio2

Irgendwann hört man sogar "ARD" und "ZDF". Na ja, Benutzer von Screen Readern sind an so etwas ja gewöhnt. Hübsch wäre allerdings, wenn die Entwickler diesen Schönheitsfehler ausbessern würden. Das kann nicht schwer sein. Bitte, liebe Entwickler, einmal VoiceOver anwerfen, und dann hier nachlesen: fur-iphone-app-entwickler-learn-how-to-make und hier: Wiki sowie hier: http://mattgemmell.com

Nachtrag:

Ich habe die Entwickler angeschrieben. Leider, wie so häufig, ohne Reaktion. Daher der Versuch, hinter den Entwicklern "aufzuräumen":

Die 4 Buttons am Seitenanfang verbergen, von links nach rechts, folgende Funktionen:

Jetzt - 20:15 Uhr - 22:00 Uhr - Andere Zeit
Hinweis: Voice Over Nutzer können Buttons selbst beschriften. Das soll allerdings keine Ausrede für die Schlamperei von Entwicklern sein.

Das Auswahlmenü versteckt (hinter schlecht beschrifteten Grafiken) in der rechten (dritten) Spalte in der Voreinstellung der Reihe nach folgende Sender:

Alle
ARD
ZDF
RTL
Sat 1
Sieben
RTL 2
VOX
3sat
arte

Nachtrag 2:

Eine Antwort von TV Spielfilm:

Sehr geehrter Herr Weisshart,

Vielen Dank für Ihren Hinweis auf die Voiceover-Erweiterungsmöglicheiten von iPhone-Apps.

Ich gehe davon aus, dass unsere App-Entwickler die Voiceover-Eigenschaften gar nicht berücksichtigt haben, sondern einfach die Werte der Parameter bzw. Funktionselemente automatisch ins jeweilige Voiceover-Label einfließen und oft entspricht dies einem menschlich interpretierbaren Wert, manchmal eben auch nicht.

Ich werde Ihren Vorschlag den Projektverantwortlichen weitergeben und die Kollegen werden dann einschätzen, ob Sie diese Funktionalität demnächst einbinden können.

Schöne Grüße,

Jürgen Stein

Sitemanager TV SPIELFILM Verlag GmbH Christoph-Probst-Weg 1 20251 Hamburg

Jetzt hoffen, dass dies nicht wieder nur, wie so oft, ein Beschwichtigungsschreiben bleibt.

Nachtrag 02.08.2011:

Auf erneute Nachfrage, nachdem zwischenzeitlich ein Update der App erschienen ist - ohne Verbesserung der angesprochenen Barrierer, heute folgende Antwort:

Sehr geehrter Herr Weisshart,
Nach meinen Informationen ist Barrierefreiheit kein Bestandteil des Konzepts für die nächsten Entwicklungsschritte der App.
Schöne Grüße, Jürgen Stein
Sitemanager TV Spielfilm Online, TV Today Online

Ohne Worte.


Relaunch der Bahnhofsmission

Donnerstag, 13. Januar 2011

Vor knapp einem Jahr startete ich intensive Bemühungen, die Bahnhofsmission zu einer Verbesserung der - damals katastrophalen - Zugänglichkeit ihres Webauftritts zu ermuntern. An meiner Seite kämpfte in diesem konkreten Fall Eva Papst um eine Barriere weniger im Web.
Ob es unseren Bemühungen zuzuschreiben ist, dass der neue Webauftritt der Bahnhofsmission besser geworden ist?
Wie dem auch sei - hier eine kurze Beurteilung über den neuen Stand:

Positiv

  • Die Seiten validieren
  • Suche nach Bahnhofsmissionen: Als Suchformular und Karte, gut bedienbar (Diese Suchfunktion war einer der Schwerpunkte unserer Aktion vor Jahresfrist.)
  • Die Seiten sind mit der Tastatur (ohne Maus) navigierbar. Der Tastaturfokus ist deutlich sichtbar.
  • Skalierbares Layout: auch bei höchsten Zoomfaktoren zerfällt das Layout nicht
  • Layout auch auf Smartphones brauchbar

Negativ

  • Die Verwendung von display:none für Skiplinks und Überschriften über Navigations-Listen macht diese Links und Überschriften für alle unsichtbar. Auch für die Benutzer von Screen Readern und Tastaturbenutzer, für die Skiplinks und Listenüberschriften wohl gedacht sind. - Stirbt denn dieser Anfängerfehler nie aus?
    Anmerkung: Die fälschliche Verwendung von display:none wurde auch im offenen Brief an die Bahnhofsmission vor einem Jahr erwähnt.
  • Auf den meisten Seiten keine vernünftige Struktur durch hierarchische Überschriften. Überschriften werden anscheinend zur Gestaltung des Seitendesigns eingesetzt, nicht aber zur Gliederung des Inhalts.
  • "Deppenlinks": Ein Link zur aktuellen Seite, der nichts bewirkt, außer Verwirrung
  • Standort nicht gekennzeichnet
  • Eine sogenannte Bereichsnavigation gibt es auf jeder Seite 4! mal. Semantik? Sollen das Sprunglinks sein? Dann sind sie nutzlos. Weil alle 4 mit display:none ausgezeichnet, also für jeden unsichtbar sind.
  • Kein Label fürs Suchfeld
  • Bereich Neues:
    Viele Links, die nur mit "mehr…" beschriftet sind.
    keine alt-Attribute für Bilder
  • 277 kB für die Startseite sind für den mobilen Einsatz zu viel. Eine mobile Version ohne Bilder wäre kein Luxus - und kein großer Aufwand.

Fazit

Es ist unglaublich, dass auch im Jahr 2010 anlässlich eines Relaunches noch solche Anfängerfehler bezüglich Barrierefreiheit gemacht werden. Zwei Stunden Schmökern in einem der zahlreichen Bücher zum Thema, und ein Großteil der Fehler wäre vermieden worden.
Aber vielleicht nimmt die zuständige Agentur jetzt ein solches Buch in die Hand, oder arbeitet einfach obige Liste ab. Auch für Letzteres wäre der Aufwand gering, der Gewinn an Barrierefreiheit aber sicher beträchtlich.


Test qando iPhone App mit VoiceOver

Montag, 8. November 2010

Wiener Linien / Verkehrsverbund Ost-Region VOR bieten eine ganz pfiffige App für das iPhone namens qando. Wer, wie ich, nach kurzer Zeit von der Qualität des öffentlichen Nahverkehrs in Wien überzeugt ist, findet die qando-App auch schnell nützlich.

Die Kernfunktion der App ist die Suche nach Verbindungen. Startpunkt und Endpunkt sowie Abfahrtszeit eingeben oder auswählen, "Formular" abschicken, und eine übersichtliche Liste mit Verbindungen steht bereit. Alles auch mit VoiceOver bedienbar - und VoiceOver Nutzern käme diese App sicher manchmal gelegen.

Screenshot 1
Der Eingabebildschirm mit dem Absendebutton
Screenshot 2
Verbindungsanzeige nach dem Absenden (Fahrplan anfordern) (1)
Screenshot 3
Verbindungsanzeige nach dem Absenden (Fahrplan anfordern) (2)

Alles bedienbar? Fast! Nur ein kleines Dorf im Norden Galliens … nein; das war eine andere Geschichte. Hier handelt es sich "nur" um den Absendebutton. Der sieht zwar gut aus, und ist sogar sinnfällig mit "Fahrplan anfordern" beschriftet. Aber für VoiceOver gänzlich unsichtbar. Und damit ist alles, was sich nach der Fahrplananforderung auftut, unerreichbar.

Audio (Der Button Fahrplan anfordern steht nach dem Feld "Abfahrt"):

Audio des Eingabebildschirms

Was nur haben sich die Entwickler dabei gedacht?

Sollten sie sich tatsächlich nichts dabei gedacht haben, dann empfehle ich dringend folgende Lektüre:

iOS Accessibility sowie Making Your iPhone App Accessible

Nachtrag 12.11.2010

Hinweis an Wiener Linien geschickt:

Feedback:

qando ist für blinde und sehbehinderte iPhone User nicht nutzbar. Wegen eines einzigen Details.
Siehe: dieser Artikel

Verbesserungsvorschläge:
Den Button "Fahrplan anfordern" für VoiceOver "sichtbar machen".
Wie man das macht steht hier: http://is.gd/gQxBq und hier: http://is.gd/gQxyS

DANKE

Nachtrag 14.11.2010

Die Antwort von qando ist da:

Lieber Herr Weisshart,

vielen Dank für Ihr Feedback! Wir haben den Punkt zur Nutzung für blinde und sehbehinderte Personen an unsere Entwickler weitergeleitet. Uns ist es ein großes Anliegen mit qando ein hilfreiches und praktisches Service zur Verfügung zu stellen und danken Ihnen für Ihren Vorschlag zur Optimierung!

Liebe Grüsse,
Ihr qando Team

3 Monate später

Heute, 11.02.2011 gab es ein Update der App. Gleich mal schau'n, ob die Leute von quando es ernst meinen mit der Aussage "ist es ein großes Anliegen…"

Wie fast zu erwarten war: Leider nur heiße Luft. Ob es Sinn macht, per E-Mail nachzuhaken?

Nachtrag:

Ich hab's getan. Ich hab' qando noch einmal angeschrieben:

Sehr geehrte Damen und Herren,

heute gab es ja ein Update der qando App für's iPhone.

Zu meinem Bedauern musste ich feststellen, dass Sie meine 3 Monate alte Anregung, die App auch für blinde Menschen zugänglich zu machen, leider nicht aufgegriffen haben. Dabei wäre das wirklich nur eine Kleinigkeit.

Kann ich mit weiteren Informationen behilflich sein?

mit freundlichen Grüßen

Fritz Weisshart

Ob jetzt wieder nur so eine Textbaustein-Bla-Bla-Antwort kommt? Oder gar keine?

Nachtrag 15.02.2011

Die Antwort von qando:

Lieber Herr Weisshart,

Danke für Ihre neuerliche Email und das Angebot, behilflich zu sein.
Wir haben die Angelegenheit nicht aus den Augen verloren, doch müssen neue Ideen und Anregungen vor Ihrer Umsetzung überprüft und besprochen werden. Dadurch entsteht eine gewisse Vorlaufzeit.

Wir werden Sie aber informieren, sobald wir Ihnen genaueres zur Nutzung von qando für blinde und sehbehinderte Menschen sagen können.

Liebe Grüsse,
Ihr qando Team

Der Leser möge sich ein eigenes Urteil über den Wert dieser Antwort machen.

Nachtrag 01.04.2011

Auch das gestrige Update ändert leider nichts an dem beanstandeten Fehler. Mir drängt sich immer mehr der Eindruck auf, dass qando nicht wirklich an Feedback interessiert ist. Und auch nicht an Barrierefreiheit.
Nachtrag 28.04.2011

Gute Nachricht: qando hat geantwortet:

Sehr geehrter Herr Weisshart, Für das nächste Update von qando wird die durchgehende Sprachausgabe explizit überprüft.

Nachtrag 05.06.2011

Versprechen gehalten. In der aktuellen Version 3.0 ist die unüberwindbare Barriere der Vorgängerversionen behoben, der mit VoiceOver nicht bedienbare Button zum Anfordern des Fahrplans.

Die Version stellt ein umfassendes Redesign der App dar, mit vielen nützlichen Features. Leider ist beim Design der neuen Features die Barrierefreiheit wieder zu kurz gekommen.

Die Suche nach Start und Ziel ist - vorsichtig ausgedrück - gewöhnungsbedürftig. So findet z. B. die Eingabe von "schö" nicht wie erhofft Schloß Schönbrunn, sondern nur Schwedenplatz.

Menschen mit etwas Ortskenntnis können aber ganz elegant auch den Streckenplan aufrufen, und dort die gewünschte Station durch Antippen als Start oder Ziel übernehmen.

Diese Methode ist von blinden Menschen naturgemäß nicht nutzbar. Sehr gut nutzbar hingegen ist die Alternative Linienliste. Dort werden für jede Linie die einzelnen Stationen aufgelistet, und wieder durch Antippen als Start oder Ziel übernommen. Für ortskundige Benutzer eine sehr effektive Methode.

Leider ist diese Option für VoiceOver Nutzer ebenso unzugänglich, wie ehedem der Button zum Abrufen des Fahrplans. Der halbtransparente Layer zur Auswahl zwischen Streckenplan und Linienliste wird von VoiceOver nicht gelesen, ja, er kann gar nicht aufgerufen werden.

Screenshot 4
Der transparente Layer zur Auswahl zwischen Linien und Netzplan. VoiceOver "sieht" diesen Layer, und die Buttons zur Auswahl nicht.

Schade.

Die Agentur hat zugesagt, diesen Mangel mit dem nächsten Update zu beheben. Effektiver wäre es sicherlich, die Barrierefreiheit neuer Features bereits früher im Entwicklungsprozess zu berücksichtigen und zu testen.

Es gibt eine Reihe weiterer Schwachstellen, die hauptsächlich im Bereich Usability, und nicht Barrierefreiheit/Accessibility angesiedelt sind. Also Schwachstellen, die alle Benutzer betreffen. Die Details im einzelnen aufzuführen, würde den Rahmen dieser Artikelserie sprengen. Eine ausführlichere Auflistung wurde jedoch von meiner "Mitstreiterin" Eva Papst an die Entwickler der App überreicht.

An dieser Stelle habe ich beschlossen, die weitere Entwicklung nicht mehr zu beobachten/dokumentieren. (Es wurde mir einfach zu dumm.)


JavaScript und der Platzmangel auf kleinen Smartphone-Displays

Montag, 4. Oktober 2010

Mit dem iPhone kann man sehr gut im Web surfen. (Welch banale Aussage!) Was liegt also näher, als meine eigene Site auch ein wenig ans iPhone (und natürlich andere Smartphones) anzupassen. Mit CSS und einer Abfrage des User Agent ist das ja schließlich kein Problem. Bleibt das Problem der Bildschirmgröße. Im Falle von webdesign.weisshart.de ist auf jeder Seite erst einmal nur das relativ umfangreiche Navigationsmenü zu sehen, und erst Scrollen (oder Antippen des Skiplinks) zeigt den Inhalt der Seite. Nicht sehr elegant.
Screenshot mit Menü

Aber Abhilfe ist nicht fern.
Vor einem Jahr habe ich eine Technik vorgestellt, Bereiche auf Webseiten per JavaScript ein- und auszublenden. Nichts spricht dagegen, zu dieser Technik zu greifen; auch und vor allem, weil das Script die Technik der "Graceful Degradation" einsetzt. Falls JavaScript nicht verfügbar ist, werden die ausgeblendeten Bereiche immer angezeigt. Es geht also keine Information verloren. Im Falle einer Seitennavigation ist dies natürlich absolut unverzichtbar.
Die Technik funktioniert ohne jegliche Anpassung sofort auf einem Touchscreen. Eine Lösung mit CSS-hover könnte dies nicht ohne weiteres. Auf Touchscreens gibt es keine Maus, und ohne Maus gibt es kein hover.
Screenshot mit zugeklapptem Menü

Das sieht doch gleich viel aufgeräumter aus.

Keine Überraschung war, dass VoiceOver (der Screen Reader des iPhone) mit der Technik anstandslos klar kommt. Ebenso wie auch Screen Reader unter Windows.

Soundbeispiel 1: VoiceOver liest die Startseite mit "zugeklappter Navigation", also im default-Zustand nach Aufruf der Seite. Bitte das "Plus" bei ca. 0:10 Min. beachten.


Audio Download des Hörbeispiels (mp3 - 237 kB)

Mit dem iPhone kann man sehr gut im Web surfen. (Welch banale Aussage!) Was liegt also näher, als meine eigene Site auch ein wenig ans iPhone (und natürlich andere Smartphones) anzupassen. Mit CSS und einer Abfrage des User Agent ist das ja schließlich kein Problem. Bleibt das Problem der Bildschirmgröße. Im Falle von webdesign.weisshart.de ist auf jeder Seite erst einmal nur das relativ umfangreiche Navigationsmenü zu sehen, und erst Scrollen (oder Antippen des Skiplinks) zeigt den Inhalt der Seite. Nicht sehr elegant.
Screenshot mit Menü

Aber Abhilfe ist nicht fern.
Vor einem Jahr habe ich eine Technik vorgestellt, Bereiche auf Webseiten per JavaScript ein- und auszublenden. Nichts spricht dagegen, zu dieser Technik zu greifen; auch und vor allem, weil das Script die Technik der "Graceful Degradation" einsetzt. Falls JavaScript nicht verfügbar ist, werden die ausgeblendeten Bereiche immer angezeigt. Es geht also keine Information verloren. Im Falle einer Seitennavigation ist dies natürlich absolut unverzichtbar.
Die Technik funktioniert ohne jegliche Anpassung sofort auf einem Touchscreen. Eine Lösung mit CSS-hover könnte dies nicht ohne weiteres. Auf Touchscreens gibt es keine Maus, und ohne Maus gibt es kein hover.
Screenshot mit zugeklapptem Menü

Das sieht doch gleich viel aufgeräumter aus.

Keine Überraschung war, dass VoiceOver (der Screen Reader des iPhone) mit der Technik anstandslos klar kommt. Ebenso wie auch Screen Reader unter Windows.

Soundbeispiel 1: VoiceOver liest die Startseite mit "zugeklappter Navigation", also im default-Zustand nach Aufruf der Seite. Bitte das "Plus" bei ca. 0:10 Min. beachten.

Audio Download des Hörbeispiels (mp3 - 237 kB)

Nun wird das Pluszeichen angetippt. VoiceOver liest weiter, und "sieht" jetzt auch das Navigationsmenü. (Das Minus zu Beginn der Aufnahme würde beim Antippen das Navigationsmenü natürlich wieder schließen.)

Audio Download des Hörbeispiels (mp3 - 171 kB)

Schön, wenn barrierefreie Seiten ohne großen Aufwand auch auf Geräten funktionieren, die es zur Zeit der Entstehung der Site noch gar nicht gab.


(M)ein barrierefreier Webchat - eine spezielle Konfiguration für hörsehbehinderte Menschen

Donnerstag, 9. September 2010

Mein Chat ist speziell auf Barrierefreiheit optimiert (obwohl 95% der Benutzer davon wohl nichts bemerken).
Die Konfigurationsmöglichkeiten sind fast unendlich. Und für manch einen wohl fast zu viel. Ich habe daher mal eine beispielhafte Konfiguration für hörsehbehinderte Menschen online gestellt.
Viele hörsehbehinderte Menschen nutzen ihre Hör- und Sehreste so weit es irgendwie geht. Einmal durch maximale Vergrößerung der Bildschirmanzeige (z. B. mittels Strg und Plus-Taste), zum anderen durch parallel laufende Sprachausgabe mittels eines Screen Readers. Für diesen "multimedialen" Ansatz ist die Konfiguration optimiert. Dennoch können auch nichtbehinderte Menschen den Chat "normal" nutzen, etwa durch Umschalten auf einen der vielen mitgelieferten Skins.
Die Konfigurationsdatei ist im Download-Paket enthalten. Einfach die Datei tbl_config_inc.php umbenennen in personal_config_inc.php.


Sprachwechsel auszeichnen auch für denglische Begriffe?

Freitag, 27. August 2010

Damit Benutzern von Screen Readern der Inhalt von Webseiten verständlich vorgelesen wird, kann / soll man fremdsprachige Wörter / Passagen mit dem lang-Attribut auszeichnen. Darüber habe ich mehrfach gebloggt. Zuletzt hier: Sprachwechsel oder nicht - die Dritte

Ein Sonderfall sind "denglische" Ausdrücke, also Wörter, die einem deutschsprachigen Leser wie englisch erscheinen, aber nicht wirklich englisch sind. Beispiel: "Webdesign" gibt es im Englischen nicht. Korrektes Englisch ist vielmehr "web design".

Hier 4 Varianten:

  • webdesign ohne Auszeichnung
  • webdesign mit Auszeichnung
  • web design ohne Auszeichnung
  • web design mit Auszeichnung

Wie der verbreitete Screen Reader Jaws (Version 11.0) mit dieser Situation umgeht, zeigt folgendes Hörbeispiel.


Audio Download des Hörbeispiels (mp3 - 82 kB)

Der kostenlose Screen Reader NVDA wiederum zeigt sich von jeglicher Sprachauszeichnung unbeeindruckt. Die von mir verwendete Spache "Steffi" hat aber dafür ein integriertes Aussprachewörterbuch, um den gebräuchlichen Ausdruck "Webdesign" korrekt auszusprechen:


Audio Download des Hörbeispiels (mp3 - 77 kB)

Es gibt übrigens noch viele solcher Beispiele. Um nur eins zu nennen: Screen Reader ist englisch. Nicht aber Screenreader, oder (von) Screen Readern.

Der geneigte Web Worker (nicht: Webworker!) möge sein eigenes Urteil fällen.


Sprachwechsel oder nicht? die Dritte

Sonntag, 4. Juli 2010

Sprachwechsel innerhalb eines HTML-Dokuments sollen/müssen entsprechend ausgezeichnet werden. Unter anderem, damit die jeweiligen Passagen von Screen Readern richtig vorgelesen werden.
Zu diesem Thema habe ich mich hier im Blog bereits mehrmals geäussert:
/blog/2009/09/26/sprachwechsel-fur-screen-reader-auszeichnen/
und
/blog/2010/04/10/sprachauszeichnung-oder-nicht-sprachauszeichnung/
Mein Fazit: Zurückhaltung beim Auszeichnen von Sprachwechseln ist angesagt. Auch der Blind-Text Blog vertritt im Wesentlichen meine Haltung.

Eine zufällige Erfahrung bestärkt mich in meiner Haltung: Ich hatte den Screen Reader NVDA mit der deutschen Stimme von Steffi aktiviert, und besuchte die englischsprachige Seite angularjs.org. Das hört sich dann folgendermaßen an:

Audio Download des Hörbeispiels (mp3 - 306 kB)

Erstaunlicherweise ist der Text relativ gut verständlich, obwohl, wie gesagt, der Screen Reader auf Deutsch eingestellt war. Zu verdanken ist dies dem Hersteller des Screen Readers bzw. dem Hersteller der synthetischen Sprache, der viele gebräuchliche englische Begriffe in ein entsprechendes Wörterbuch aufgenommen hat.

Was will ich damit zeigen? Nein, ich plädiere nicht für falsche/fehlende Sprachauszeichnung für das ganze Dokument. Ich will nur zeigen, dass auch längere Passagen in Englisch ohne eine "richtige" Sprachauszeichnung relativ gut verständlich sind. Möglicherweise, abhängig vom verwendeten System aus Screen Reader und Sprachdatei, sogar besser als mit ausgezeichnetem Sprachwechsel.


Der gepunktete Rahmen des Submit-Buttons

Samstag, 19. Juni 2010

Der Firefox macht um den Absende-Button von Formularen einen gepunkteten Rahmen, wenn man den Button per Tabulator-Taste ansteuert.
Das kann im Falle eines sorgfältig gestaltetes Designs arg stören. Ein Beispiel ist der per CSS "rund gemachte" Absende-Button meines Suchformulars. (siehe diesen Beitrag.)
Screenshot

Ein eckiger Rahmen um einen runden Button, das sieht wirklich nicht gut aus.
Aber dieser Rahmen widersetzt sich sich allen Versuchen, ihn per CSS zu entfernen, recht störrisch.

Und es geht doch

Screenshot

Dirk Ginader hat es ganz kurz und trocken getwittert.

Die CSS Anweisung dazu lautet:

input[type=submit]::-moz-focus-inner {border: 1px dotted transparent;}

Ja, genau so. Auch wenn die Syntax fremd erscheint.

Wer nicht generell alle Submit-Buttons stylen will, sondern nur bestimmte mit id oder class ausgezeichnete Buttons, kann die CSS Anweisung natürlich entsprechend abändern. Für einen Button mit der Klasse senden :

.senden::-moz-focus-inner {border: 1px dotted transparent;}
bzw. für einen Button mit der id senden:
#senden::-moz-focus-inner {border: 1px dotted transparent;}

Wichtig: Bitte unbedingt sicherstellen, dass der Fokus, wenn nicht mittels des gepunkteten Rahmens, dann auf andere Art klar kenntlich gemacht wird! Dies ist unentbehrlich für Tastatur-Nutzer, damit sie den Fokus sehen, d. h. wissen, welches Seitenelement gerade aktiv ist.

PS: Kennt jemand eine Methode, den Rahmen auch für Webkit (Chrome, Safari) und Opera zu entfernen. Nach dem IE frag' ich erst gar nicht. Dort fällt es übrigens gar nicht so sehr ins Gewicht, weil der IE ohnehin den per CSS rund gestalteten Submit-Button nicht darstellen kann.


Besuchte Links auf Webseiten kennzeichnen.

Mittwoch, 9. Juni 2010

Eine alte Usability- und Accessibility-Forderung: Besuchte Links kennzeichnen. Und zwar nicht nur farblich.
Auf webdesign weisshart wurde das bisher ganz deutlich in Form eines Häkchens hinter besuchten Links gemacht.
Screenshot aus der Navigation

hacks.mozilla.org hat vor einiger Zeit angekündigt, dass der CSS Selector :visited aus Sicherheitsgründen zukünftig nicht mehr unterstützt wird:

For many years the CSS :visited selector has been a vector for querying a user's history. It's not particularly dangerous by itself, but when it's combined with getComputedStyle() in JavaScript it means that someone can walk through your history and figure out where you've been. And quickly - some tests show the ability to test 210,000 URLs per minute. At that rate, it's possible to brute force a lot of your history or at least establish your identity through fingerprinting. Given that browsers often keep history for a long time it can reveal quite a bit about where you've been on the web.

At Mozilla we're serious about protecting people's privacy, so we're going to fix this problem for our users. To do so we're making changes to how :visited works in Firefox. We're not sure what release this will be part of yet and the fixes are still making their way through code review, but we wanted to give a heads up to people as soon as we understood how we wanted to approach fixing this.

Seit gestern setzt als erster Browser der Safari 5 diese "Drohung" um. Es ist also wohl nur eine Frage der Zeit, bis Firefox nachzieht. Das Häkchen ist damit Geschichte. Es bleibt die farbliche Kennzeichnung. Eine spannende Frage kann ich derzeit nicht testen: Wie sind besuchte Links zukünftig in Screen Readern erkennbar?

Nachtrag: VoiceOver, der Screen Reader von Apple, erkennt besuchte Links, hat mir eben ein Bekannter bestätigt.


Eine Seite soll nicht auf sich selbst verlinken.

Sonntag, 6. Juni 2010

Eine berechtigte Forderung, wenn es um Usability im Allgemeinen, oder um Barrierefreiheit im Besonderen geht:

Eine Seite soll nicht auf sich selbst verweisen.

Es leuchtet ohne nähere Erklärung ein, dass das folgende Beispiel irritieren kann:

Du bist hier: Startseite - zur Startseite wechseln

Screenshot der Startseite mit Link zur StartseiteDieses Beispiel findet sich auf einer ansonsten technisch absolut sauber umgesetzten Seite. Der Seitenbetreiber mag mir nachsehen, dass ich ausgerechnet sein Projekt als negatives Beispiel zitiere. Im günstigsten Fall ist er mir für den Hinweis dankbar. Übrigens: Toscho nannte das Problem beim Namen: Deppenlink



Mehr als irritierend kann so etwas für Menschen sein, die nicht den Überblick über den ganzen Bildschirm haben. Zum Beispiel Benutzer von Screen Readern. Idealerweise sollte man die jeweils aktuelle Seite in einer Navigation nicht nur nicht verlinken, sondern auch mit einem Hinweis ausstatten, z. B.: "Standort:". Wie dies gedacht ist, zeigt folgender Screenshot aus der Navigation auf meiner Startseite, mit abgeschaltetem CSS (wie auch Screen Reader die Seite vorlesen):
Screenshot der Seitennavigation


Aber jetzt mein Rezept gegen den "Deppenlink"

Das Problem: Die Navigation wird per PHP in alle Seiten eingebunden. Immer die gleiche Navigation. Nun muss natürlich PHP entscheiden, welches die jeweils aktuelle Datei ist, und den Link auf sich selbst durch einen unverlinkten Text ersetzen.

Zuerst den Dateinamen der aktuellen Seite in eine Variable:
<?php $a = $_SERVER['PHP_SELF']; ?>

Und dann eine if-else Abfrage, hier am Beispiel eines Links, der zur Seite /index.php führt:

<?php
if ($a!="/index.php") {
echo '<a href="/">MStartseite</a>';
} else {
echo '<span class="cur"><dfn>Standort: </dfn>Startseite</span>';
}
?>

Anmerkung:
In der Praxis schreibe ich diese if-else Abfrage in Kurzform. Hier jedoch zugunsten der einfacheren Lesbarkeit die ausgeschriebene Form.

Wozu nun der span class="cur"? Nun, dieser Span kann jetzt individuell per CSS so gestylt werden, dass er zum Design der Seite passt.

Und was hat es mit /lt;dfn>Standort: </dfn> auf sich?
Der Hinweis "Standort:" soll nur von Screen Readern vorgelesen werden.
Eine einfache CSS-Regel erledigt dies:

dfn {
position:absolute;
left:-9000px;
width:0;
height:0;
overflow:hidden;
display:inline;
}


Formulareingaben vor dem Absenden prüfen

Samstag, 8. Mai 2010

Formular-Eingaben, z. B. Kommentare hier im Blog, müssen selbstverständlich überprüft werden, bevor die Eingaben in die Datenbank auf dem Server geschrieben werden.
Heute geht es aber um die Überprüfung der Eingaben vor dem Absenden. Genauer: die Prüfung, ob alle Pflichtfelder ausgefüllt wurden. Noch genauer: Um die Behandlung von Fehleingaben.
Dies muss auf dem Server erfolgen. Weil eine clientseitige Überprüfung, z. b. mittels JavaScript, nicht greift, wenn der Besucher JavaScript deaktiviert hat.

Aber um die Usability zu verbessern, kann man eine Prüfung per JavaScript vorschalten.
Der Benutzer erhält so beim Drücken des Absende-Buttons sofort eine - möglichst aussagefähige - JavaScript-Meldung, wenn ein Pflichtfeld nicht ausgefüllt wurde, und nach Quittieren dieser Meldung wird er unmittelbar auf das fehlerhafte Eingabefeld geschickt.
Hier eine gute Anleitung.

Danke an Eva Papst für das Einfordern dieses Usability-Features.


Farbfehlsichtigkeit

Freitag, 7. Mai 2010

Farbfehlsichtigkeit ist weit verbreitet. 8 bis 10% der Männer leiden unter irgend einer Form von Farbfehlsichtigkeit. Farbfehlsichtigkeit ist häufig auch mit anderen Sehbehinderungen verbunden.
Dennoch kommt dieses Thema im Zusammenhang mit Barrierefreiheit wenig bis kaum zur Sprache.
Dabei gibt es viele gute Tools zum Testen.
Ich benutze und empfehle Wickline
Wickline simuliert online verschiedene Arten von Farbfehlsichtigkeit. Wickline kann, wie viele andere Tools, nicht automatisch Barrierefreiheit testen. Aber Wickline kann für das Thema Farbfehlsichtigkeit sensibilisieren, und ist in der Hand eines verantwortungbewussten Webdesigners ein wertvolles Werkzeug.
Wickline online auf webdesign.weisshart.de
Ich habe Wickline in meine Werkzeugsammlung aufgenommen.


Text vor Screen Readern verstecken

Donnerstag, 6. Mai 2010

Lange gesucht - und endlich gefunden: eine Möglichkeit, Text vor Screen Readern zu verstecken.
(Nein, das ist nicht ernst gemeint. Alle erbosten Kommentare bitte vorläufig zurückstellen.)
Danke an www.textdreher.de/ für die Idee.
Den folgenden Satz können Screen Reader nicht lesen (oder, besser gesagt, nicht verstehen):

:nednufeg hcildne dnu - thcuseg egnaL
.nekcetsrev uz nredaeR neercS rov txeT ,tiekhcilgöM enie

Nachtrag 7. Mai 2010
Der Kommentar von Eva veranlasst mich jetzt doch zu einigen Ergänzungen.

  1. So hört sich der Text mit dem Screen Reader NVDA an:


    Download mp3 AudioDownload des Hörbeispiels (mp3 - 345 kB)
  2. Eva schlägt eine Retourkutsche vor: Text so verschlüsseln, dass nur Braille-Kundige ihn verstehen. Das sieht dann so aus:

    lge &su4t'- u cd_ &f/dc:
    6e m_k, te'xt ? s'crec read7n z -}e$c.

    Und hier noch auszugsweise Evas Erläuterungen dazu:

    In der [Braille-]Kurzschrift gibt es so genannte Zweilautkürzungen, z.B. lg = lang.
    Diese können Endungen annehmen; lge = lange.

    Einlautkürzungen: z.B. u = und. Hier darf nichts angehängt werden.

    Silbenkürzungen:
    - 6 = ein
    - & = ge
    - 4 = ch
    usw.

Danke, Eva. Die beste Kurz-Erklärung zu Braille-Kurzschrift, die ich bisher sah.


WAI ARIA landmark roles

Mittwoch, 5. Mai 2010

WAI ARIA ist eine Technologie, die es Entwicklern ermöglicht, ihre Seiten besser für Nutzer von Screen Readern zugänglich zu machen.
Eine Einführung in WAI ARIA in deutscher Sprache
Eine Teilmenge von WAI ARIA, die landmark roles, hilft bei der Orientierung, indem typische Bereiche von Webseiten mit standardisierten Namen bezeichnet werden.
Ich habe landmark roles auf meinen Seiten eingesetzt. Für die Bereiche

  • Kopf
  • Suchformular
  • Navigation, und
  • Inhalt

Screen Reader können jetzt mit einem Tastenkürzel (NVDA: d, Jaws: ö) diese Bereiche anspringen. Die angesprungenen Bereiche werden mit standardisierten Namen angesagt. Diese Namen lauten im Falle meiner vier Bereiche

  • Logo
  • Suche
  • Navigation, und
  • Haupt

Das Anspringen der landmarks mit dem Screen Reader NVDA:


Download mp3AudioDownload des Hörbeispiels (mp3 - 349 kB)

Das Einfügen von ARIA landmarks

Der HTML-Code hierfür lautet beispielsweise:
<div role="navigation">
Wollte man diesen Code manuell in alle Seiten einpflegen, dann könnte das in Arbeit ausarten. Wir machen uns einfach den Umstand zunutze, dass die betroffenen Bereiche ohnehin mit id-Attributen ausgezeichnet sind. Mit wenigen Zeilen JavaScript lässt sich ganz einfach zusätzlich zur id das jeweilige role-Attribut setzen.
function addARIARole(strID, strRole)
{
// Find the element to add a role property to
var objElement = document.getElementById(strID);
if (objElement)
{
// Add the role property to the element
objElement.setAttribute('role', strRole);
}
}
function setupARIA()
{
// Add ARIA roles to the document
addARIARole('inhalt', 'main');
addARIARole('menu', 'navigation');
addARIARole('suchform', 'search');
addARIARole('headimg', 'banner');
}

Nun noch dafür sorgen, dass die Funktion setupARIA onload aufgerufen wird, und ohne viel Arbeit ist ein weiterer Schritt zur Barrierefreiheit getan.


Sprachauszeichnung oder nicht Sprachauszeichnung, das ist hier die Frage.

Samstag, 10. April 2010

Sprachauszeichnung - die zweite Lektion für jeden, der sich mit Barrierefreiheit beschäftigt. Damit Screen Reader das Web-Dokument in der richtigen Sprache vorlesen.

Klar, die (Haupt-)Sprache des Dokuments muss im <head> ausgezeichnet werden. Artikel zu Sprachauszeichnung bei www.456bereastreet.com

Ganze Sätze, z.B. Zitate, in abweichender Sprache, sollte man auf jeden Fall auszeichnen.

Aber wie verhält es sich mit einzelnen Wörtern oder Phrasen? In diesen Fällen gilt es, unter Anderem auch Folgendes zu bedenken:

  • Nicht jeder Screen Reader unterstützt automatisch jede Sprache. Im Grundpaket sind wohl etliche fremdsprachliche Stimmen enthalten, andere müssen hingegen separat gekauft und installiert werden.
  • Eine Besonderheit stellt der kostenlose Screen Reader NVDA dar, der ständig mehr Anhänger findet: Er unterstützt keine Sprachwechsel innerhalb eines Dokuments.
  • Einen abweichenden Ansatz verfolgt der Screen Reader VoiceOver, der in iPhone, iPod und iPad ab Werk verfügbar ist: dort sind zig (20?) Sprachen standardmäßig enthalten.
  • Jeder Sprachwechsel innerhalb eines Dokuments unterbricht den Lesefluss. Es dauert, bis die Software "den Schalter umlegt". Und jede Sprache hat einen abweichenden Klang; auch das kann den Lesefluss stören.
  • Viele gebräuchliche Fremdwörter, z.B. aus der Informationstechnologie, sind in Screen Readern bereits mit der korrekten Aussprache hinterlegt, und werden auch ohne Sprachauszeichnung korrekt ausgesprochen.
    Hier ein Beispiel mit solchen Ausdrücken ("Open Source Flash Video Player") gelesen vom NVDA:


    Download mp3
    Audio Download des Hörbeispiels (mp3 - 294 kB)
  • "Eingedeutschte" Deklination von Fremdwörtern (z. B. "in Screen Readern") darf nicht in der Fremdsprache ausgezeichnet werden, weil es diese deklinierte Form in der jeweiligen Fremdsprache höchstwahrscheinlich gar nicht gibt. Gleiches gilt für zusammengesetzte Fremdwörter, die laut neuer deutscher Rechtschreibung zusammen geschrieben werden. Beispiel: Longdrink.
  • Zuletzt noch ein Fall, der zwingend die Auszeichnung einzelner Wörter verlangt: Eigennamen. In diesem Fall dürfte kein Screen Reader die korrekte Aussprache "erraten". Beispiel mit korrekter Auszeichnung: Giscard d'Destaing oder ohne Auszeichnung: Giscard d'Destaing

Ein schönes Beispiel mit Sprachauszeichnungen gibt es bei 456bereastreer. Wer einen oder gar mehrere Screen Reader verfügbar hat, findet hier interessantes Material für eigene Tests.

Mein Fazit: Ich bin mit Sprachauszeichnung von einzelnen Wörtern inzwischen äußerst zurückhaltend. Im Zweifel verzichte ich darauf. Wenn ich es ganz genau machen will, und mir viel Zeit nehme, dann teste ich ausgewählte Texte mit NVDA und Jaws.


Videos im Web - Stand 2010

Dienstag, 6. April 2010

Gerrit van Aaken hat in seinem Blog einen guten Artikel über den aktuellen Stand von Videos im Web geschrieben.
Das Ergebnis unter Einsatz von HTML5 und einem Fallback unter Verwendung des Open Source Flash Video Players Flowplayer überzeugt erst einmal durch wunderschön schlanken Code.
Um die vorgestellte Technik selbst zu erproben, habe ich hier eine eigene Demo erstellt.
Und ich muss leider feststellen, dass der aktuelle Stand zwar technisch hochinteressant, aber eben doch noch nicht ganz reif ist für die freie Wildbahn.
Meine Beobachtungen:

  • Unter Windows kann nur der Google Chrome Browser das HTML5 <video> im H.264 Format abspielen.
  • Alle anderen Browser verwenden das - zugegebenermaßen elegante - JavaScript, das auf das Flowplayer-Fallback umschaltet.
  • Opera/Win in der aktuellen Version 10.51 kann das Video im Flowplayer gar nicht abspielen
  • Safari/Win in der aktuellen Version 4.0.5 spielt das Video erst, nachdem es komplett heruntergeladen ist. Je nach Größe des Videos und Qualität der Internetverbindung kann das unakzeptabel lange dauern.
  • Und das gewichtigste "Aber": Für Nutzer eines Screen Readers oder für Besucher ohne Maus ist sowohl der vom HTML5 <video> Tag erzeugte Player, als auch der Flowplayer vollkommen unbenutzbar. In beiden Fällen wäre eine zusätzliche Steuerung per JavaScript nachzurüsten, wie ich es z. B. in diesem Artikelvorstelle. Und damit ist der Charme des schlanken Codes wieder hinfällig.
    Accessibility-Features wie Untertitel oder Audio-Descriptions: Leider auch Fehlanzeige.

Es heißt also weiter warten auf den "heiligen Gral", den Gerrit van Aaken etwas vollmundig versprochen hat.


Der CAPTCHA-Unfug stirbt nicht aus

Freitag, 2. April 2010

CAPTCHAs sind unwirksam, und schließen Menschen aus. Wie oft wurde darüber schon geschrieben. CAPTCHAs wollen sicherstellen, dass ein Mensch, und nicht eine Maschine, ein Formular ausfüllt. Wobei man Maschine gleichsetzt mit Spambot. Wer täglich gegen Spam jeglicher Art kämpft, hat mein volles Verständnis. Und ich kann auch verstehen, dass man jede Maßnahme bereitwillig übernimmt, die Abhilfe gegen die lästigen Spambots verspricht. Aber CAPTCHAs sind einfach der falsche Weg.
CAPTCHAs können von Maschinen leichter gelöst werden als von Menschen!
Lassen Sie mich das an einem Beispiel erläutern:
Das homepage-forum.de verwendet die Forensoftware vBulletin.
Dort versucht man, Spambots mit CAPTCHAs auszuschließen. Diese CAPTCHAs sehen z. B. so aus:

Ich schaffe es nicht, auch nur eines der gezeigten CAPTCHAs zu lösen. Und weil es vermutlich nicht nur mir so geht, hat vBulletin eine pfiffige Funktion eingebaut: Ein Link unter dem CAPTCHA "Grafik neu laden" ermöglicht es, ein neues CAPTCHA aufzurufen. Beliebig oft! Und nach einigen Versuchen sind auch lesbare CAPTCHAs dabei:

Klasse.
Denkste!
Genau diese leicht lesbaren CAPTCHAs sind ein Kinderspiel für Maschinen, die mit OCR arbeiten. Und Maschinen, anders als Menschen, haben keine schlechten Nerven. Sie geben nicht nach einigen erfolglosen Versuchen entnervt auf. Vielmehr haben sie schier endlose Geduld. Wie gesagt: ein neues CAPTCHA kann beliebig oft angefordert werden. Und anders als bei Menschen, genügen den Spambots Trefferquoten von 10%, 1% und sogar weniger. Im Klartext: Wenn ein Mensch ein CAPTCHA nach dem 10 Versuch noch nicht gelöst hat, dann dürfte auch der Geduldigste entnervt aufgeben. Anders ein Spambot: wenn der nur bei jedem 100sten Versuch erfolgreich ist, dann genügt das immer noch, um die Welt mit Spam zu beglücken.
Nach dieser langatmigen Einleitung komme ich auf den Punkt:
Offensichtlich wurde auch das homepage-forum.de von Spambots beglückt. Und der vermeintliche Spamschutz mit CAPTCHAs war offensichtlich unwirksam. Deshalb hat homepage-forum.de zusätzlich! zur CAPTCHA-Abfrage jetzt noch eine Rechenaufgabe eingeführt. Rührend! Warum man sich von den CAPTCHAs nicht trennen konnte oder wollte, kann ich nicht nachvollziehen. Eine intelligente Kombination alternativer Möglichkeiten, wie hier beschrieben, würde Menschen nicht ausschließen/nerven, und Spambots sicher in die Schranken weisen.


Reiseplanung für blinde Weltenbummler

Sonntag, 28. März 2010

Wenn einer eine Reise tut … dann sollte er sich tunlichst vorbereiten. Im Falle einer Urlaubsreise, auch wenn sie mit einer Reisegruppe erfolgt, gehört dazu unter anderem das Studium der Reiseroute. Google bietet hierfür mit Google Maps ein Werkzeug, um eine Route mit beliebig vielen Stationen auf einer Karte einzuzeichnen.

Ausdruck einer Reiseroute aus Google Maps
Die Google Karte zeigt Schottland und einen Teil von Nordirland. Die einzelnen, in Google Routenplanung manuell eingegebenen Stationen, sind mit Buchstaben von A bis J gekennzeichnet, die Route selbst, also der Straßenverlauf, ist als blaue Linie eingezeichnet.

Bis hierher ist das nichts Besonderes, und kaum der Rede wert.
Wenn aber blinde Menschen verreisen - oh ja, sie tun das, wie man hier nachlesen kann - dann erfordert die Reise Vorbereitungen besonderer Art. Nicht zu sehen bedeutet ja keineswegs, kein Interesse an der Geographie des Urlaubsziels zu haben.
Mir war also die Aufgabe gestellt, die von Google Maps ausgegebene Reiseroute "erfühlbar" zu machen. Moderne Technik macht's möglich. Ein spezieller Drucker kann neben normaler Grafik zusätzlich ein erhabenes, tastbares Relief der Grafik "drucken". Zusätzlich heißt, die sichtbare und die tastbare Grafik überlagern sich; sehende und tastende Betrachter können ein und denselben Ausdruck benutzen, und sich z. B. über Details austauschen.
Das klingt großartig, und ist es auch. Wie anders als mittels einer Grafik sollte man den zerklüfteten Umriss von Schottland erklären, und die Lage einer Reiseroute und der einzelnen Stationen beschreiben.
Gut, bei sehr detailreichen und/oder kontrastschwachen Grafiken - beides trifft auf Google Maps zu - ist einiges an manueller Vorbereitung nötig. Die Fingerkuppen von geschulten blinden Menschen sind zwar unvorstellbar sensibel, aber an die Auflösung des Gesichtssinns kann der Tastsinn nicht heranreichen. Weniger wichtige Details müssen also manuell entfernt, wesentliche Konturen, wie die Küstenlinie oder die Reiseroute hervorgehoben werden.
Das folgende Bild zeigt die für den Reliefdruck bearbeitete Grafik, und vermittelt einen Eindruck, wie die Prägung "aussehen" wird.

Bildschirmkopie der für die Reliefprägung vorbereiteten Seite
Die gleiche Karte. Diesmal sind alle Farben, die im Original die Topografie repräsentieren, durch ein feines Raster in Grautönen ersetzt. Die Umrisse der Kontinente sind in einem dunkleren Blau gerastert, die Reiseroute in dunklerem Grau, und deutlich breiter als im Original. Die Buchstaben der einzelnen Reisestationen sind in Braille-Schrift konvertiert.

Bei der Vorbereitung für den Prägedruck hilft natürlich eine spezielle Software.

Nochmals zur Klarstellung: die beiden Versionen der Grafik, farbiges Bild und tastbare Prägung, werden auf einem Blatt deckungsgleich übereinander gedruckt.

Als letzter Schritt noch die wichtigsten Stationen der Reise mit Braille-Schrift markieren. Anders als auf normalen Landkarten kann die Braille-Beschriftung jedoch nicht einfach "über" das Bild gelegt werden, weil die tastenden Finger einen "ruhigen" Hintergrund brauchen. Um Platz zu sparen, werden für die Beschriftung daher möglichst nur einzelne Buchstaben oder Ziffern verwendet, und eine separate Legende bereitgestellt:

A: Hull
B: York
C: Carlisle
D: Glasgow
E: Loch Lomond
F: Oban
G: Isle of Mull
H: Aviemore
I: Edinburgh
J: Newcastle upon Tyne

Gute Reise!

Nachtrag 3. Mai 2010 - ein Belegexemplar

Eva, die sich in einem Kommentar als "Nutznießerin" outete, hat mir netterweise ein "Belegexemplar" zukommen lassen; mit dem genannten Spezialdrucker erzeugt, also sichtbare und tastbare Grafik überlagert.Und mit etwas Phantasie kann man auch Evas Begeisterung nachempfinden.

der Original-Ausdruck
Ein Ausdruck der fertigen, tastbaren Grafik. Im Gegenlicht aufgenommen, kann man auf dem Foto die Prägung in Form von einzelnen Punkten gut erkennen. Die Original-Karte in Original-Farben ist deckungsgleich zur Prägung zu sehen.

Der virtuelle Pranger

Donnerstag, 25. Februar 2010

Der Internetauftritt der Bahnhofsmission hat mich einige Tage beschäftigt. Anlass war die Klage meiner taubblinden Bekannten Marina Pompe, die wegen gravierender Mängel der Website der Bahnhofsmission nicht an dringend benötigte Informationen kam. Die Leitung der Bahnhofsmission stellte sich leider taub für die begründeten Anliegen ihrer eigenen Klientel. Eine ganze Reihe von E-Mails blieb unbeantwortet und unbearbeitet. Sogar eine Mängelanzeige des AbI-Projekts wurde schlicht ignoriert.
Mit so viel Ignoranz konnte und wollte ich mich nicht zufrieden geben. Ich wollte meiner taubblinden Bekannten bei Ihrem Bemühen helfen, sich ein klein wenig Selbständigkeit zurück zu erobern.

Offener Brief

Ich griff zu einer Maßnahme, die mir nicht leicht fiel: Ein offener Brief an die Leitung der Bahnhofsmission (den ich in Kopie natürlich auch per E-Mail an die Adressaten schickte).
Und siehe da: plötzlich klappte es mit der Kommunikation. Herr B., einer der Angeschriebenen, antwortete. Und beklagte sich zuerst einmal über die Tatsache, dass

… Organisationen, die nicht oder (wie in unserem Fall) nicht umgehend reagieren, in Foren, Blogs etc. sehr schnell an den virtuellen Pranger gestellt [werden]

"Nicht umgehend"? Die nicht beantwortete Mängelanzeige des AbI-Projekts datiert vor dem November 2009. Auf M. Pompes und meine Mails kam über zwei Wochen keinerlei Reaktion, nicht einmal eine Eingangsbestätigung.
Nein, Herr B. Sie haben keinen Grund, sich zu beklagen. Mit Ihrer Methode, auf Anfragen und wohlmeinende Hinweise per E-Mail schlichtweg nicht zu reagieren, rechtfertigen Sie nachträglich das, was Sie selbst virtuellen Pranger nennen. Es scheint leider die einzige Möglichkeit zu sein, Bitten oder Vorschläge an Sie heranzutragen.

Flurschaden

Herr B. schrieb weiter:

… führt aber u.U. zu einem dauerhaften Flurschaden, wenn einschlägige Beiträge nicht wieder entfernt werden.

Nein, Herr B., Sie verwechseln da etwas. Der Flurschaden besteht bereits. Auf Ihrem Internetauftritt. Und die "einschlägigen Beiträge" wurden in der Absicht erstellt, diesen Flurschaden zu begrenzen.

Ein Lichtblick

Zwei von drei der konkret angesprochenen Mängel wurden inzwischen behoben. Der Aufwand für diese Nachbesserung betrug mit Sicherheit nur einen Bruchteil des Aufwands, den ich in meine Bemühungen investiert habe, mit der Bahnhofsmission in Dialog zu treten.
Bei dieser Gelegenheit gilt mein besonderer Dank Eva Papst, die mein Vorhaben mit einem eigenen Blogbeitrag und mehreren E-Mails an die Bahnhofsmission unterstützt hat.


An die Bahnhofsmission - offener Brief

Montag, 15. Februar 2010

Konferenz für Kirchliche Bahnhofsmission in Deutschland
Bundesarbeitsgemeinschaft der Katholischen Bahnhofsmissionen in Deutschland
Verband der Deutschen Evangelischen Bahnhofsmission e.V.

Herrn Christian Baron
Frau Dr. Gisela Sauter-Ackermann
Herrn Christian Bakemeier

Kopie geht per E-Mail an:
bundesgeschaeftsstelle @bahnhofsmission.de
gisela.sauter-ackermann@bahnhofsmission.de
bakemeier@diakonie.de

Sehr geehrte Damen und Herren,

vor einiger Zeit wurde ich von einer taubblinden Bekannten darauf aufmerksam gemacht, dass Ihr Internetauftritt www.bahnhofsmission.de für blinde und sehbehinderte Menschen nicht bedienbar ist. Um an die benötigten Informationen zu gelangen, hat meine Bekannte eine E-Mail an Ihre Geschäftsstelle geschickt, mit der Bitte, ihr die Adressdaten der einzelnen Bahnhofsmissionen mitzuteilen. Da die E-Mail meiner Bekannten unbeantwortet blieb, versuchte auch ich, per E-Mail an die auf Ihrer Webseite genannte Adresse Ihrer Geschäftsstelle Kontakt mit Ihnen aufzunehmen.
Auch diese E-Mail blieb ohne Antwort.

Aus diesem Grund wähle ich nun den Weg über einen offenen Brief.

Auf www.bahnhofsmission.de ist zu lesen:

Wir geben Auskünfte und unterstützen Sie bei Verständigungsschwierigkeiten.
Zum Beispiel wenn Sie gehörlos sind, schwerhörig, blind, seh- oder sprachbehindert. …

Ihr Webauftritt missachtet diesen Anspruch leider auf geradezu eklatante Weise. Insbesondere blinde oder sehbehinderte Menschen, die Webseiten mit Zusatzprogrammen lesen, können die auf Ihren Webseiten angebotenen Informationen wegen handwerklicher Fehler bei der Erstellung der Seiten nicht nutzen.

Solche Fehler können aus Unwissenheit und Unkenntnis der erforderlichen Techniken entstehen, und wären dann korrigierbar und entschuldbar. Oder sollte es sich im vorliegenden Fall nicht um Unwissenheit handeln, sondern um Desinteresse? Desinteresse für die Bedürfnisse der eigenen Klientel?
Wie anders sonst wäre folgendes zu erklären:
Das AbI-Projekt hat eine Meldestelle für erkannte Webbarrieren eingerichtet, informiert Seitenbetreiber über erkannte Barrieren, und bietet Hilfestellung zur Behebung dieser Barrieren. AbI-Projekt hat Sie auf die Barrieren aufmerksam gemacht - ohne Erfolg. Nachzulesen auf www.webbarrieren.wob11.de/annahmeverweigert.html

Gerne wäre auch ich bereit, detaillierte Hinweise auf die schlimmsten Mängel des Webauftritts zu geben, und Wege aufzuzeigen, wie die gravierendsten Schwachstellen möglichst schnell beseitigt werden könnten. Vielleicht kann meine taubblinde Bekannte dann vor Ihrer nächsten Bahnfahrt selbst die Bahnhofsmission kontaktieren, um die Assistenz der vielen freundlichen Helfer vor Ort in Anspruch nehmen zu können.

mit freundlichen Grüßen

Fritz Weisshart
webdesign weisshart
Dipl.-Ing.(FH) Fritz Weisshart & Co. GbR

Anhang:
Unter anderem auf folgenden Internetseiten wurde kürzlich über die Mängel auf Ihrer Webseite berichtet:

Nachtrag 16.02.
Es ist sicher nicht schön, wenn man quasi an den virtuellen Pranger gestellt wird. So empfand es auch einer der Adressaten dieses offenen Briefes. Und sanktioniert gleichzeitig mit seiner Antwort, die heute eingegangen ist, sowie einer ersten Notmaßnahme, diese von mir gewählte Methode. Zwei Wochen nach dem Versand mehrerer E-Mails nicht einmal eine Empfangsbestätigung zu schicken, rechtfertigt Versuche, auf andere Art in Kontakt zu kommen. Es widerspricht jeglicher Erfahrung, nach zwei Wochen noch Antwort auf eine E-Mail zu erwarten.
Positiv: Die falschen Verlinkungen zu den Adressen der einzelnen Missionen in der Textversion (siehe Eva Papsts Blog) wurden korrigiert. Damit kann zumindest jemand, der die nichtöffentliche Adresse der Textversion kennt, nach Adressen recherchieren.
Hier noch einmal die Adresse: http://www.bahnhofsmission.de/bahn/html/home/index_text.php
Warum "nichtöffentlich"? Weil diese Adresse per CSS display:none vor ALLEN Seitenbesuchern versteckt ist. Also sowohl vor sehenden Besuchern, als auch vor blinden und sehbehinderten Usern, die auf Screen Reader angewiesen sind.


Barrierebehaftet und beratungsresistent

Donnerstag, 4. Februar 2010

Die Bahnhofsmission hätte wirklich Grund, ihren Webauftritt barrierefrei zu gestalten. Der eigene Anspruch (Zitat):

Wir geben Auskünfte und unterstützen Sie bei Verständigungsschwierigkeiten. Zum Beispiel wenn Sie gehörlos sind, schwerhörig, blind, seh- oder sprachbehindert.

Leider ist der Internetauftritt der Bahnhofsmission ein Muster an Unzugänglichkeit. Praktisch alle Fehler, die man nur machen kann, wurden auf der Site auch umgesetzt.
Siehe dazu Eva Papsts Blog und mein eigener Beitrag

Nun muss ich feststellen, dass die Bahnhofsmission wohl auch beratungsresistent ist:
Das Aktionsbündnis für barrierefreie Informationstechnik, ein Zusammenschluss von Behindertenverbänden und Experten für barrierefreie Informationstechnik, hat eine Meldestelle für Webbarrieren eingerichtet. Und nun finde ich, dass die Bahnhofsmission von dieser Meldestelle bereits auf die Mängel hingewiesen wurde, sich aber leider beratungsresistent zeigt.
Hier die Liste beratungsresistenter Seitenbetreiber
Dass die Bahnhofsmission sich damit auf eine Stufe mit Burgerking, musicload.de, Lidl & Co. stellt, macht einfach nur traurig.


Barrierefreiheit ist kein Spiel

Montag, 1. Februar 2010

Es gibt Seiten im Web, die sollten sich nun wirklich mit dem Thema Barrierefreiheit auseinandersetzen.
Die Bahnhofsmission gehört dazu.
Zitat auf der Seite:

Wir geben Auskünfte und unterstützen Sie bei Verständigungsschwierigkeiten. Zum Beispiel wenn Sie gehörlos sind, schwerhörig, blind, seh- oder sprachbehindert.

Hier sollten also unter anderem blinde oder sehbehinderte Benutzer Hilfe finden. Zum Beispiel Kontaktadressen.

Ich habe einer blinden Bekannten die Aufgabe gestellt, auf diesen Seiten die Telefonnummer der Bahnhofsmission München zu finden. Und ich hätte gewettet, dass sie das nicht schafft. Warum ich mir da so sicher war? Nun, ich verwende zum Testen einen Screen Reader. Und ich hab' mir die Seiten der Bahnhofsmission mit einem Screen Reader angehört. Speziell die Seite Zu Ihrer nächsten Bahnhofsmission.
Hören Sie selbst:

Audio Download des Hörbeispiels (mp3 - 843 kB)

Hier wurde geradezu beispielhaft alles falsch gemacht, was man nur falsch machen kann: Das Navigationsmenü aus Grafiken aufgebaut. Alle Grafiken unbeschriftet (der Screen Reader liest bei jedem Navigationspunkt "index", weil er versucht, aus dem Linkziel etwas Brauchbares herauszulesen), Dann eine Image-Map, die auch nur für sehende Mausbenutzer bedienbar ist. Und so geht es weiter.

Soll ich berichten, wie die Wette mit meiner blinden Bekannten ausgegangen ist? Nein, wir haben nicht gewettet. Ich hätte das als nicht fair empfunden. Sie hatte meines Erachtens keine Chance. Aber sie hat es geschafft! Wie? Ich habe einen bösen Verdacht: Durch erzwungene Übung. Es gibt wohl so viele schlechte Seiten, dass Screen Reader Benutzer Strategien entwickeln mussten, auch damit zurecht zu kommen.

PS: Die Geschäftsstelle der Bahnhofsmission habe ich angeschrieben. Sollte ich eine Antwort erhalten, werde ich das selbstverständlich hier posten.


List of accesskeys on twitter.com

Freitag, 15. Januar 2010

I hope this list of accesskeys to be somewhat helpful.
Some of these accesskeys may not work while using a particular screen reader, or even not work at all.
Some accesskeys need Enter to be pressed even in Firefox e.g. "h". (The reason is duplicate definition of these accesskeys on the page. Would be nice if Twitter corrected this.)

  • 0 Skip past navigation
  • 1 Home
  • 2 Skip to footer
  • 3 Jump to the sidebar
  • d Direct messages sent only to you
  • f Favorites
  • h Home
  • i Send a direct message
  • l Sign out
  • m Tweets mentioning you
  • n Results update
  • o Direct messages you've sent
  • p Profile
  • r Retweets by others
  • s Settings

The following group will not work on Firefox, since Firefox requires Alt+Shift to activate accesskeys.

  • > Send a direct message
  • = (equal sign) Find People
  • ? (question mark) Help
  • / (forward slash) Search

Wenn Flash Text versteckt

Freitag, 4. Dezember 2009

Sie haben Printerzeugnisse, die Sie hübsch im Internet präsentieren wollen?
dialogperfect®viewer produziert daraus ein schickes E-Paper. Auf dem Bildschirm kann man das Ergebnis anschauen, blättern, und suchen.
So richtig funktioniert das alles aber nur, wenn man die Seite mit der Maus bedienen kann, und nicht auf die Tastatur angewiesen ist. Nach dieser Vorbemerkung ist auch Folgendes verständlich:

"Ich kann auf der Seite nichts lesen. Wo eine Textsuche ist, müsste doch auch auch Text sein." Diese Logik einer befreundeten Screen Reader Nutzerin ist zwingend. Also mache ich mich auf die Suche nach dem Text.

Ein Blick in den Quelltext der Beispielseite liefert schnell den nötigen Hinweis. JavaScript deaktivieren! dann läuft der Flash-Player nicht, und schwupps, der komplette Text ist sichtbar. Sogar mit richtigen Links zum Blättern durch das Dokument.
Eigentlich schade um die Arbeit, die mit der Konvertierung des Textes verbunden ist. Und vor allem schade um das schöne Geld. Unter 480,- € läuft das nämlich nicht. www.dialogperfect-viewer.de/358-Preise.html

Dabei könnte der Anbieter mit wenigen Zeilen Code Abhilfe schaffen. Wenn er für Accessibility sensibilisiert wäre, und sich die notwendigen Kenntnisse aneignen würde.

Nachtrag:
Weil vermutlich nicht jeder sofort sofort weiß, wie man JavaScript deaktiviert und wieder aktiviert, hier die Kurzfassung:

Firefox:
Menü - Extras - Einstellungen.
Hier deaktivieren Sie unter Inhalt bzw. Web-Features den Punkt "JavaScript aktivieren" und klicken Sie OK.

Internet Explorer:
Menü - Extras - Internetoptionen.
Hier klicken Sie unter Sicherheit auf Stufe anpassen und aktivieren dann unter Scripting - Active Scripting den Punkt "Deaktivieren". Bestätigen Sie zwei mal mit OK.

Richtig elegant, weil Domain bezogen, geht das Aktivieren und Deaktivieren von JavaScript natürlich mit der Firefox-Extension NoScript


Von Google und Screen Reader Benutzern lernen

Montag, 23. November 2009

Von einem Screen Reader Nutzer hörte ich neulich beiläufig folgende Bemerkung:

Die Google-Ergebnisse kann man jetzt endlich ordentlich lesen, seit Google die Seite mit Überschriften strukturiert hat.

Tatsächlich: Jeder einzelne Treffer ist als h3 ausgezeichnet, und damit komfortabel per Screen Reader anzuspringen.
Aber die Ergebnisseiten waren doch immer schon als nummerierte Listen aufgebaut? Und allein dadurch schon mit Screen Readern optimal zu scannen und zu navigieren?

Des Rätsels Lösung: Innerhalb jedes Listenelements ist der Link zur gefundenen Seite als h3 Überschrift ausgezeichnet. Das ist in HTML erlaubt, und macht auch semantisch Sinn. Wenn denn nach der Überschrift tatsächlich ein Kapitel folgt. Die Treffer in den Google Ergebnissen könnte man tatsächlich als einzelne Kapitel bezeichnen.

<ul>
   <li>
      <h3>Überschrift des 1. Listenpunkts</h3>
      Text des 1. Listenpunkts.
   </li>
   <li>
      <h3>Überschrift des 2. Listenpunkts</h3>
      Text des 2. Listenpunkts.
   </li>
</ul>

Ich hab' die Technik übernommen: Für Kommentare. Z. B. in diesem Artikel. Die Kommentare sind als nummerierte Liste ausgezeichnet, und jeder Kommentar hat eine h3 Überschrift.
Semantisch korrekt, und optimal lesbar.


Dynamische Textersetzung vs. Screen Reader

Dienstag, 10. November 2009

Das Design von Schriften bereitet bei der Gestaltung von Webseiten immer wieder Kopfschmerzen. Nur eine Handvoll Fonts sind auf allen Systemen verfügbar, und aufwendige grafische Effekte sind nahezu unmöglich, wenn man sich an CSS und HTML Standards halten will.

So die Einleitung eines Artikels, der eine inzwischen mehrere Jahre alte Technik beschreibt. Eine Technik, die hier immer noch eingesetzt wird, um die Überschriften im Style Leonardo zu generieren.

Nun mag ja in einigen Jahren @font-face embedding allgemein verfügbar sein. Bis es so weit ist halte ich die Dynatext Technik noch immer für eine der besten:
Das fallback, d. h. die Funktion ohne Javascript, ist perfekt.
Und die Barrierefreiheit ebenso.
Wirklich?
Mal in einem Screen Reader testen:


Download des Hörbeispiels (mp3 | 76 kB)

Was sagt der Screen Reader? (im Hörbeispiel ist es der NVDA)

Webdesign nach Maß - Grafik - von - Grafik - webdesign weisshart

Zugegeben. Das zweimalige Ansagen einer Grafik ist nicht schön. Aber akzeptabel. Und die Technik damit barrierefrei: Es geht keine Information verloren; und die Navigation mit dem Screen Reader funktioniert weiterhin (in diesem Fall das Anspringen von Überschriften).
Die Belästigung für Screen Reader Nutzer durch das unschöne Ansagen der Grafiken hält sich in Grenzen, da diese Technik der dynamischenTextersetzung aus Performance Gründen ohnehin nur für kürzere Textpassagen, z. B. Überschriften, einsetzbar ist.


Webseiten vorlesen für Alle

Montag, 12. Oktober 2009

Seit einiger Zeit schon gibt es auf manchen Seiten im Web die Möglichkeit, sich die Seite vorlesen zu lassen.
Zum Beispiel bei heise online

Dazu muss lediglich ein Grafiklink angeklickt werden.vorlesen / MP3 download

Dass dieser Service nicht für blinde Surfer gedacht sein kann, ist offensichtlich. Wie sollte ein Blinder den Link zum Anklicken finden? Dazu braucht er erst einmal einen Screen Reader, der ihm die Seite vorliest – und wenn der Screen Reader liest, dann braucht er den Vorleseservice nicht mehr.

Wozu also der Aufwand?
Nun gut, ich habe gelernt, dass angeblich Menschen mit Leseschwäche für diese Erleichterung dankbar wären.
Ich kann das leider nicht überprüfen, aber meine persönliche Meinung ist: Man schmückt sich mit einem mehr oder weniger nutzlosen Feature, um zu demonstrieren, wie fortschrittlich man ist, wie sehr man um Barrierefreiheit bemüht ist.

Was ist aber mit der scheinbaren Zielgruppe, den blinden und sehbehinderten Surfern, die einen Screen Reader benutzen? Wehe, wenn sie versehentlich diesen Link betätigen. Dann fängt die Vorleserei an, während gleichzeitig der Screen Reader den Inhalt eines Popups vorliest, das sich beim Klick öffnet. Und das klingt dann so:

Audio Download des Hörbeispiels (mp3 - 428 kB)

Warum schildere ich das so detailliert?
Ich suche immer noch nach einer Möglichkeit, Seiteninhalte vor Screen Readern zu verstecken. Hier wäre ein klassischer Anwendungsfall. Und ein Fall für praktizierte Gleichberechtigung. Warum soll ich Screen Reader Nutzern Inhalte präsentieren, die im besten Fall überflüssig für sie sind.

Leider kann man zwar Seiteninhalte zuverlässig vor sehenden Besuchern verstecken, aber der umgekehrte Weg scheint nicht möglich zu sein.
Oder doch? Kennt jemand eine Technik?


Sprachwechsel für Screen Reader auszeichnen

Samstag, 26. September 2009

Kaum wusste ich, dass es Screen Reader gibt, schon sah ich mich mit der Aufgabe konfrontiert, Sprachwechsel im Markup auszuzeichnen.
Doch gemach und der Reihe nach:

Screen Reader, das sind die Programme, die blinden und stark sehbehinderten Computerbenutzern den Bildschirminhalt vorlesen. Hut ab vor der Leistung dieser Programme. Sie schaffen es, verständlich vorzulesen, wenn auch der Tonfall der synthetischen Stimmen gewöhnungsbedürftig ist.
Nun ist leicht nachzuvollziehen, dass diese Programme wissen müssen, in welcher Sprache der geneigte Hörer den Text gerne vorgelesen hätte. Geben Sie einem deutschen Erstklässler einen englischen Text zum Vorlesen, und Sie wissen, was ich meine.
Für Webseiten gilt:
Damit Screen Reader wissen, in welcher Sprache Sie vorlesen sollen, suchen sie nach dem lang-Attribut im <html> Tag.
Beispiel:
<html xmlns="http://www.w3.org/1999/xhtml" lang="de" xml:lang="de">
Screen Reader wissen nun: Die Sprache der Seite ist deutsch. So weit so gut.

Was nun, wenn auf einer Webseite anderssprachige Passagen vorkommen?
Nun, die Schulbuchweisheit sagt: Diese Passagen müssen entsprechend ausgezeichnet werden. Das sieht an einem Beispiel folgendermaßen aus:
<span lang="en" xml:lang="en">Best Practice</span>
und das Ergebnis klingt sogar, von einem Screen Reader wie z. B. Jaws vorgelesen, zumeist relativ vernünftig nach Englisch.

Leider wird Sprachauszeichnung wohl nur auf einem verschwindend geringen Anteil der Webseiten realisiert. Das haben anscheinend auch die Hersteller von Screen Readern festgestellt. Und haben ihren Programmen beigebracht, die am häufigsten auch in deutschen Texten vorkommenden englischen Ausdrücke auch ohne Sprachauszeichnung richtig auszusprechen. Was dann wohl wiederum zur Folge hat, dass genau diese Ausdrücke, mit einer an sich korrekten Sprachauszeichnung versehen, vollkommen entstellt vorgelesen werden.

Dazu kommt noch ein weiteres Problem: Der Screen Reader braucht eine merkbare Zeit, um den ausgezeichneten Sprachwechsel zu realisieren. Er legt eine hörbare, und den Lesefluss störende, Pause ein.

Mein Fazit: Ich bin inzwischen mit der Auszeichnung von Sprachwechseln sehr zurückhaltend geworden. Lieber einmal zu wenig, als einmal zu oft.


Links zu fremden Seiten in neuem Fenster öffnen?

Samstag, 19. September 2009

Fenster mit Geranien Die Geister scheiden sich daran, wie denn nun ein Link am besten geöffnet werden soll. Die einen schätzen ein neues Fenster, um die alte Ansicht nicht zu verlieren. Andere hassen das Fenstergewirr.

Eine Lösung für dieses Dilemma habe ich bereits 2006 hier beschrieben.

Nun habe ich mich entschieden, dieses Feature durchgängig auf allen Seiten anzubieten. Auf Kommentare hierzu freue ich mich.


Tastaturkürzel - Accesskeys

Freitag, 18. September 2009

Accesskeys sind ein — umstrittenes — Mittel, um Seiten zugänglicher zu machen für Benutzer, die keine Maus bedienen können — aus welchen Gründen auch immer.
Umstritten, weil damit Webseiten Tastenkombinationen belegen, die eventuell vom System des Besuchers vorbelegt sind. Paradebeispiel ist die Tastenkombination Alt + D. Damit wird in vielen Browsern das Dateimenü aufgerufen. Sollte nun ein Webworker genau diese Tastenkombination für einen Accesskey verwenden, dann können Tastaturnutzer das Dateimenü ihres Browsers nicht mehr erreichen. Accessibility pervertiert.
Eine gute Abhandlung zu diesem Thema gibt es bei Jens Meiert über Accesskeys
Auf meinen Seiten gibt es seit langem Accesskeys — Tastaturkürzel bei webdesign weisshart — obwohl ich immer wieder darüber nachdenke, sie ganz zu entfernen. Aus den oben zitierten Gründen.
Wie dem auch sei: Ich habe die Keys geändert, und an den britischen Accesskey-Standard angepasst. Wichtigstes Detail: Der Sprung zum Inhalt, der Skiplink, hat jetzt den Accesskey [S]. "S" für Skiplink oder Sprunglink.


Anzeigen und verbergen von Bereichen mit JavaScript

Freitag, 11. September 2009

Manchmal möchte man Bereiche auf einer Webseite erst bei Bedarf anzeigen, die Seite soll erst einmal übersichtlich und aufgeräumt sein. Erst nach einem Klick sollen Details gezeigt werden.
Eine barrierefreie Lösung auf Basis von JavaScript beschreibe ich in diesem Artikel
Ich freue mich auf Kommentare - direkt im Artikel! (die Kommentarfunktion hier ist gesperrt).


Skiplinks - Vergebliche Liebesmüh

Donnerstag, 27. August 2009

Skiplinks (englisch: to skip, deutsch: überspringen) sind Links, die es ermöglichen, größere Bereiche einer Webseite zu überspringen, zum Beispiel die Navigation. Skiplinks unterstützen Nutzer, die nur mit der Tastatur arbeiten, zum Beispiel blinde Menschen.
Immer öfter sieht man Skiplinks, auch auf "großen" Portalen. Gut. Leider "sieht" man diese Skiplinks aber häufig nur im Quellcode. Und dann werden Sie per CSS display:none; unsichtbar gemacht. Und leider nicht nur unsichtbar, sondern sogar total unwirksam. Sie funktionieren einfach nicht. Auch nicht mit Screen Readern, für die sie doch wohl gedacht sind.
Zwei Beispiele:
www.zdf.de und www.deutsche-rentenversicherung-bund.de
Ist die Sache mit den Skiplinks denn wirklich so schwierig?

PS: Beide Firmen wurden angeschrieben. Auf eine Antwort warte ich.


Creating Accessible Sites in Flash

Freitag, 7. August 2009

Flash Barrierefrei? Im Prinzip geht das. Nur Benutzer des Firefox Browsers bleiben außen vor.

Wieso?
Barrierefreies Flash bedeutet vor allem, dass Flashfilme mit der Tastatur bedient werden können.
Ein schönes Beispiel für einen mit der Tastatur bedienbaren Flash Film bietet Adobe selbst auf dieser Seite. Wunderbar. Alle Schaltflächen mit der Tab Taste erreichbar, und alle sauber für Screen Reader beschriftet.
Nur mit dem Firefox: Fehlanzeige. Man kommt mit der Tab Taste überall hin, nur nicht in den Flash Film.
Warum?
Weil vermutlich auch Adobe weiß, dass der Firefox den "Tab-Fokus kapert". Wenn man im Firefox mit Tab in einen Flash Film hineintabbt, dann kommt man mit der Tastatur nicht mehr aus diesem Film heraus, man bleibt quasi im Flash gefangen. Damit ist die Seite nicht mehr benutzbar.

Der übliche Ausweg ist bekannt:
In den Aufruf des Flash Objekts kommt diese Anweisung: style="-moz-user-focus:ignore;"
Damit erreicht man, dass der Firefox mit der Tastatur nicht in das Flash Objekt hineintabbt, und folglich auch der Tastaturfokus auch nicht "eingefangen" wird.
Aber natürlich ist das Flash dann mit der Tastatur auch nicht zugänglich.

Fazit:
Flash und Firefox passen nicht zusammen. Auch nicht in der jeweils neuesten Version.
Wann werden die Firefox Entwickler sich dieses Themas annehmen? Barrierefreiheit hat doch ansonsten bei Mozilla einen hohen Stellenwert.
Oder bin ich nicht auf dem aktuellen Stand?

Nachtrag:

Der Bug ist seit 2001 bei Mozilla als Bug 78414 und Bug 93149 bekannt, um nicht zu sagen berühmt.


Valide oder Barrierearm, und die Bauchschmerzen der Webworker

Dienstag, 4. August 2009

Mein Chat ist neuerdings nicht mehr XHTML valide.
Grund: Ich setze WAI ARIA ein. Konkret: aria-live.

Was ist ARIA? Hier eine gute Einführung in ARIA

Mit aria-live erreiche ich, dass im Chat die jeweils neueste Nachricht von Screen Readern automatisch vorgelesen wird. Für blinde Chatter ein nicht zu unterschätzender Komfort. Und ein großer Schritt in Richtung weniger Barrieren für eine bestimmte Personengruppe.

Leider wird dadurch die Seite für den W3C Validator invalide. Und Validität wird allgemein als eine der Grundfesten, als "sine qua non", jeglicher Barrierefreiheit bezeichnet.

Was nun?
Auf ARIA verzichten, bis das W3C mit dem Validator nachzieht?
Mit invaliden Seiten leben?

Mal sehen, wie Andere mit dem Dilemma umgehen.

Standfest: Die Vorteile von ARIA rechtfertigen ein "nicht valide" Urteil des Validators:

www.einfach-fuer-alle.de

Wankelmütig: WordPress:

Mit der WordPress Version 2.6.3 wurde erstmals ARIA eingesetzt:
www.gefangenimnetz.de
sowie www.webdesign-in.de

aber WordPress 2.8 machte dann wieder einen Rückzieher:

Hier finde ich zwar im Template die Angaben für aria-required, aber sie werden nicht im Quelltext ausgegeben, - entweder habe ich technisch was übersehen oder es ist ein Bug - kann ich derzeit einfach nicht sagen:

Quelle:
www.texto.de

Die Ja - Aber Fraktion

ARIA ja, aber dennoch validieren. Das versuchen

www.456bereastreet.com und www.paciellogroup.com

Mein Fazit

Ich kann mich für diese, zweifellos technisch reizvollen Versuche, ARIA zu validieren, nicht erwärmen.
Ich versuche, mich der Fraktion der Standfesten anzuschließen. ARIA bringt wertvollen Zusatznutzen, und schadet niemandem. Also bleibt es. Auch wenn ARIA bisher bei W3C erst den Status working draft hat. Und auch wenn das W3C noch länger braucht, um den Validator auf den Stand der Zeit zu bringen.
Nennt man diese Haltung Pragmatismus?

Nachtrag 08.08.2009

Auch www.bik-online.info/ wird von Bauchschmerzen geplagt, und eiert rum:

Wenn Fehler bei der Validierung ausschliesslich durch den Einsatz von WAI-ARIA (Rollen, Zuständen, Eigenschaften etc.) enstehen gilt der Prüfschritt als erfüllt.

Der Einsatz von WAI-ARIA Techniken verbessert die Zugänglichkeit. Der BITV-Test bewertet die praktische Zugänglichkeit. Es wäre nicht nachvollziehbar, wenn der Einsatz von Techniken zur Verbesserung der
Zugänglichkeit im BITV-Test zu Punktabzügen führen würde.

Neuentwurf Prüfschritt 3.2.1 "Valides HTML":
testen.bitv-test.de/index.php?a=di&iid=1140

Wir sind nicht sehr glücklich mit dieser Ausnahmeregelung und hoffen, dass sich das Thema bald von selbst erledigt.

Nachtrag 10.08.2009

Ich gehöre anscheinend auch zur Fraktion der "Ja - Aber".
Ich konnte mir nicht verkneifen, das aria Attribut per Javascript ins DOM zu schreiben, damit der Validator wieder "Grün" zeigt. Asche auf mein Haupt.


Testwerkzeuge und Validatoren

Mittwoch, 29. Juli 2009

Der AChecker (Accessibility Checker) nach WCAG 2.0 der Universität Toronto, den ich schon länger in die Liste meiner Testwerkzeuge aufgenommen hatte, wurde rundum erneuert. Und bei der Gelegenheit änderte sich auch die Adresse in http://achecker.ca/checker/
Schade nur, dass er anscheinend nicht mehr mit einem URL Parameter aufgerufen werden kann. Das war bisher so praktisch in Verbindung mit den Web Developer Extras.


Auswahllisten mit der Tastatur bedienen

Montag, 27. Juli 2009

Auswahllisten (Ausklapplisten / <select>) dienen dazu, dem Anwender eine Liste mit festen Einträgen anzubieten, aus der er einen Eintrag auswählen kann. Der Text des ausgewählten Eintrags wird übertragen, wenn der Anwender das Formular abschickt.
Zum Abschicken gibt es einen eigenen Button, z. B. <input type="submit" … >
Wenn nun das Formular als einziges Element eine Auswahlliste enthält (typisches Beispiel: ein Style Switcher), dann ist es lästig, den Submit Button anzusteuern und zu betätigen.
Pfiffiger wäre es, die Auswahl mit Enter bestätigen zu können.
Hier kommt Javascript mit dem Event Handler onchange zu Hilfe.
Beispiel:

<select name="titel" size="1" onchange="this.form.submit()" >

Wunderbar.
Aber:
Versuchen Sie mal, eine solchermaßen aufgepeppte Auswahlliste im Internet Explorer ohne Maus, also nur mit der Tastatur, zu bedienen. Ich habe für Ihre Versuche ein Muster zum Testen erstellt. Dieses Muster beinhaltet konsequenterweise keinen Submit Button. (In der Praxis würde ich den jedoch sicherheitshalber belassen.)
Und was passiert da? Es gelingt bei ausschließlicher Tastaturnutzung nicht, einen der angebotenen Einträge auszuwählen, weil das Formular sofort beim Versuch, innerhalb der Auswahlliste mit den Pfeiltasten nach unten zu gehen, abgeschickt wird. Dabei wird dann immer der zweite Eintrag in der Liste "Michael Jackson" gewählt.
Es sei denn, Sie wissen, wie man das mit dem Internet Explorer macht:

  1. Mit der Tab Taste den Fokus auf die Auswahlliste setzen.
  2. Die Auswahlliste mit "Alt+Pfeil nach unten" öffnen.
  3. Mit den Pfeiltasten (nach unten / nach oben) innerhalb der ausgeklappten Liste navigieren.
  4. Enter

Und jetzt die Preisfrage: Wer wusste das?

Mir jedenfalls ist das zu riskant. Ich befürchte, zu viele Besucher mit dieser Technik auszuschließen.
Ich werde also in der praktischen Anwendung dem Internet Explorer ein Formular ausliefern ohne den onchange event handler. (Das geht ja recht zuverlässig mit conditional comments.)


Barrierefreiheit auch für gehörlose Menschen?

Dienstag, 7. Juli 2009

Behindern gehörlose Übersetzer die Schaffung barrierefreier Webseiten?

oder

Übersetzer für DGS (deutsche Gebärdensprache) gesucht

Beim Thema Barrierefreiheit denken die meisten Webworker erst einmal an blinde Menschen. Wenn sie sich überhaupt zu diesem Thema Gedanken machen.
Dieser Ansatz ist auch gut. Wenn Webseiten so gestaltet werden, dass sie für blinde Menschen mit den entsprechenden Hilfsmitteln (Screen Reader) zugänglich sind, dann ist ein wichtiger Schritt zur Barrierefreiheit getan.

Es gibt aber noch weitere Behinderungen, die bei der Erstellung barrierefreier Webseiten berücksichtigt werden müssen. Neben Menschen mit motorischen Behinderungen ist insbesondere die Gruppe der gehörlosen Menschen zu nennen. Auf letzteren Fall möchte ich in diesem Beitrag speziell eingehen.

"Wieso sollte Gehörlosigkeit bei der Benutzung des Internet ein Problem darstellen?" werden Sie sich jetzt vielleicht fragen. "Gehörlose Menschen können doch lesen."
Leider trifft diese Aussage nur bedingt zu. Für von Geburt gehörlose Menschen ist Deutsch eine Fremdsprache. Sie sind mit Gebärdensprache aufgewachsen. Ihr Sprachverständnis für die deutsche Schriftsprache ist in manchen Fällen auf dem Niveau der 4. Klasse.

Als Lösung bietet sich die Bereitstellung von Gebärdensprachfilmen an. Dabei werden die Inhalte der Internetseiten in Deutsche Gebärdensprache übersetzt und auf Video verfilmt. (…) So sind wichtige Informationen auch für Gehörlose barrierefrei erreichbar und nur noch einen Mausklick entfernt.

Quelle: www.dgs-filme.de/GWHomepage/barrierefreiheit.htm

Leider ist nun diese empfohlene "Bereitstellung von Gebärdensprachfilmen" ihrerseits mit einer in vielen Fällen unüberwindlichen Barriere behaftet: Die Kosten für die Erstellung entsprechender Übersetzungen sind exorbitant. Für einen mittelschweren Text mit 600 Wörtern (entsprechend ca. 1 ½ Seiten oder dem 1 ½ fachen Umfang dieses Beitrags) wurde mir von zwei Anbietern jeweils ein Preis von 1000 (tausend) Euro genannt.
Ich kann nachvollziehen, dass der Aufwand für die Erstellung von Gebärdensprachfilmen höher ist als beispielsweise die Übersetzung in eine andere Schriftsprache. Ein Schmunzeln hat mir jedoch folgender Passus in einer mit dem Angebot gelieferten Leistungsbeschreibung entlockt:

… die genaue Einstellung der Kamera, die Auswahl und Positionierung der Scheinwerfer sowie die Vorbereitung des Hintergrundes. Auch muss die Kleidung des Darstellers festgelegt werden.

Ich will nicht von Abzocke sprechen. Ich glaube auch nicht, dass hier eine gewisse Monopolstellung missbraucht wird.
Beide Angebote stammen von "Muttersprachlern", also von gehörlosen Menschen, deren Muttersprache die deutsche Gebärdensprache ist. Eine wichtige Voraussetzung für eine qualitiativ hochwertige Übersetzung.

Aber:
Mit diesen Preisen verhindern die Anbieter, also die Betroffenen selbst!, dass mehr Webseiten barrierefrei nach ihrer eigenen Definition gestaltet werden.

Ich suche weiter nach einer Möglichkeit, Gebärdensprachfilme zu Kosten anzubieten, die es auch nichtkommerziellen und nichtöffentlichen Webseitenbetreibern ermöglicht, gehörlose Seitenbesucher in ihrer Muttersprache anzureden.


Ein (neuer und besserer) barrierefreier Video Player

Samstag, 9. Mai 2009

Einen neuen Video Player ein, der hinsichtlich Barrierefreiheit alles in den Schatten stellt, was ich bisher im Web gesehen habe, stelle ich in diesem Artikel vor, einschließlich Demo, Beschreibung und Codeschnipseln.


Hintergrundmusik auf Webseiten

Montag, 9. Februar 2009

Hintergrundmusik auf Webseiten ist - vorsichtig ausgedrückt - einer der beliebtesten Anfängerfehler. Im Web wird, zu Recht, nachdrücklich davor gewarnt. Diese Warnungen kann man im Wesentlichen wie folgt zusammenfassen:
Hintergrundmusik, vor allem, wenn sie ungefragt losdudelt, führt dazu, dass die meisten Besucher die Seite sofort wieder verlassen.
Eine Suche nach "Hintergrundmusik auf Webseiten" listet daher - zu Recht - hauptsächlich Seiten auf, die vor dem Einsatz von Hintergrundmusik auf Webseiten warnen.

Was aber, wenn ein Webmaster partout der Meinung ist, dass sein Fall ganz anders liegt, und dass auf seiner Seite Hintergrundmusik gerechtfertigt ist? Nun gut, dann wenigstens richtig.

Wie es richtig gemacht wird, zeige ich auf einer Demoseite
Und um die Sache zu erleichtern, gibt es dort auch gleich das komplette Script mit einer detaillierten Anleitung zum Download.


Skiplinks - springe direkt zum Inhalt

Freitag, 16. Januar 2009

Skiplinks (englisch: to skip, deutsch: überspringen) sind Links, die es ermöglichen, größere Bereiche einer Webseite zu überspringen, zum Beispiel die Navigation. Skiplinks unterstützen Nutzer, die nur mit der Tastatur arbeiten, zum Beispiel blinde Surfer.

Ich habe einen Artikel verfasst, wie man Skiplinks richtig einbaut.
Ein besonderes Zuckerl ist eine Technik, die auch WebKIT basierten Browsern wie Safari das Springen beibringt.


Barrierefreiheit testen mit einem Screen Reader

Montag, 22. Dezember 2008

Eine der besten Methoden, Webseiten auf Barrierefreiheit zu testen, ist die Verwendung eines Screen Readers.
Ich habe einen Artikel zu diesem Thema von WebAIM übersetzt.

Einige persönliche Anmerkungen zu diesem Artikel:

  • Die dort beschriebenen Verfahren zur Benutzung von Jaws werden wohl nur sehr erfahrene Benutzer allesamt kennen und verwenden. Ein Webworker, der nur seine eigenen Seiten testen will, wird mit einem Bruchteil der beschriebenen Tastaturkürzel auskommen.
  • Im Zweifelsfall sollte man immer den Rat eines Experten suchen. Im vorliegenden Fall ist jeder blinde Screen Reader Nutzer ein Experte.
  • Last but not least: Barrierefreiheit ist nicht nur Webdesign für blinde Menschen. Es gibt viele Aspekte der Barrierefreiheit, die mit einem Screen Reader nicht getestet werden können.

Tastatur statt Maus

Montag, 10. November 2008

Logo der Tabparade
Bei Robert Lender bin ich drauf gestoßen: Eine Blog-Parade zum Thema "Webseiten ohne Maus, nur mit der Tastatur bedienen - und viele Menschen sind sogar darauf angewiesen, dass Webseiten ohne Maus navigierbar und bedienbar sind."
Dabei ist mir aufgefallen, dass ich selbst dazu schon einiges veröffentlicht habe, verstreut über viele Seiten und Blogeinträge. Eine Zusammenfassung kann daher nicht schaden:

Mehr zum Thema in der aktuellen Tab-Parade von MAIN_blog.


Animated GIFs stoppen

Samstag, 8. November 2008

La OlaAnimated GIFs, das sind die hüpfenden Männchen, Fahnen, die kreiselnden @ usw., die man häufig, überwiegend auf privaten Seiten sieht. Oft klicke ich einfach ganz schnell weg, weil die Dinger einfach nur nerven.
Gibt es auch einen Weg, die Animation abzuschalten, um die Seite in Ruhe zu lesen?

Nichts einfacher als das: Die Esc Taste ist dein Freund.


Rechte Maustaste ohne Maus

Donnerstag, 6. November 2008

Weil diese Frage immer wieder gestellt wird:
"Wie macht man einen Rechtsklick - zum Beispiel, um eine Datei zu speichern - wenn die rechte Maustaste nicht zur Verfügung steht, oder eine Maus nicht bedient werden kann?"

Ganz einfach:
Mit der Tab-Taste den Fokus auf den Link setzen.
Dann
- entweder mit der Applikationstaste - diese befindet sich meist links neben der rechten STRG Taste, und trägt ein Symbol, das ein Navigationsmenü darstellen soll.
- oder mit UMSCHALT+F10
das Kontextmenü öffnen.

Nachtrag 12.08.2013

So. Obiges gilt für Windows.
Kontextmenü aufrufen alias rechte Maustaste mit der Tastatur emulieren geht natürlich auch auf dem Mac OS X: crtl + Leertaste.

Nachtrag 10.01.2014

Die beschriebene Methode eignet sich aus mehreren Gründen nicht zum Speichern von Grafiken. Zum einen muss das Element fokussierbar sein. Das ist bei Grafiken nur dann der Fall, wenn die Grafik als Link dient. Aber selbst dann geht es nicht. Weil das Kontextmenü, wenn es mit der Tastatur geöffnet wird, keinerlei Befehle zur Behandlung von Grafiken enthält. (Diese Einschränkung gilt übrigens unabhängig von Browser und Betriebssystem.)

Screenshot Kontextmenü mit der Maus geöffnet
Wenn das Kontextmenü mit der rechten Maustaste aufgerufen wird, stehen verschiedene Befehle zum Arbeiten mit der Grafik zur Verfügung
Screenshot Kontextmenü mit der Tastatur geöffnet
Die Befehle zum Arbeiten mit der Grafik fehlen im Kontextmenü, wenn das Menü mit der Tastatur aufgerufen wird.

Kommentarspam - meine Lösung

Samstag, 16. August 2008

Nach vierwöchiger Testphase kann ich sagen: meine Lösung reicht - für meine Zwecke.

Ich prüfe einfach, wie lange es dauert, bis ein Formular - in diesem Fall der Kommentar hier im Blog - abgeschickt wird. Und alles unter 10 Sekunden ist böse.

Die Technik, obwohl nicht neu, habe ich, zusammen mit anderen bekannten Techniken, noch einmal beschrieben: Techniken zur Abwehr von Kommentarspam
Ich muss gestehen, dass tatsächlich während Testphase ein einziger Spambot 15 Sekunden bis zum Abschicken wartete, und damit den Schutz aushebelte.
Ich kann damit leben. Ich muss diesen Spam-Kommentar eben manuell löschen. Zusammen mit - viel häufigeren - manuellen Spam-Einträgen folgender Art:

… bin zufällig auf diese Seite gestoßen und bin sehr überrascht was es hier alles für interessante Themen gibt. Werde jetzt öfters mal vorbeischauen.

Sollte in Zukunft maschinell produzierter Spam doch häufiger vorkommen, dann ist meine Wahl: zusätzlich Methode 2: ein verstecktes Feld, das nicht ausgefüllt werden darf.

In jedem Fall habe ich für mich eine Lösung gefunden, die niemanden belästigt, vor allem niemanden aussperrt, und dennoch die bösen Bots mit ausreichender Zuverlässigkeit aussperrt.

Gegen die plumpen Versuche, sich mittels manueller Kommentare der oben zitierten Art Backlinks zu erschleichen, hilft manuelles Löschen (zumindest der Links in den Kommentaren).
Da ich die Kommentare in meinem Blog ohnehin lese, kein größeres Problem.


Spamschutz - ohne Rechenaufgabe

Samstag, 19. Juli 2008

Seit langem setzte ich als Schutz gegen Kommentarspam eine Rechenaufgabe ein. Mit vollem Erfolg. Kein einziger böser Bot machte sich die Mühe, 5 plus 3 auszurechnen.
Seit heute gibt es - versuchsweise - eine neue Art des Spamschutzes. Nein, kein CAPTCHA! Menschliche Besucher werden von meiner Technik nicht belästigt oder gar ausgesperrt; sie merken gar nichts von einem Spamschutz. Das Ausfüllen eines zusätzlichen Feldes ist nicht mehr erforderlich.
Ob der Schutz wirksam ist, wird sich zeigen. Aus diesem Grund werde ich die Technik auch erst nach einer maximal mehrwöchigen Testphase veröffentlichen.
Vorab sei nur so viel verraten: Ganze 6 Zeilen PHP sind hierfür erforderlich!


Testwerkzeuge und Validatoren

Dienstag, 22. April 2008

Sauberen, korrekten (X)HTML- und CSS-Code schreiben - ob von Hand, oder mit einem CMS-System, mit einer Blog- oder Forensoftware, ist eine Sache. Aber auch hierbei gilt: Kontrolle ist besser. Um Webseiten nach allen denkbaren Kriterien zu testen, gibt es eine Fülle von Werkzeugen, viele davon online.

Ich habe mal in meine Werkzeugkiste gegriffen, und stelle hier meine wichtigsten Tools vor.


Der nackte Tag

Mittwoch, 9. April 2008

Hoppla! Was ist denn mit dem Design passiert? Ganz einfach, webdesign weisshart beteiligt sich jedes Jahr wieder am »CSS Naked Day«. Die Idee dahinter ist recht simpel: ist die Website noch benutzbar, wenn man sämtliche Formatierungen abschaltet? Verwendet die Website semantisches Markup, oder gehen ohne das Design wesentliche Informationen verloren?

Entstanden ist die Idee im Weblog von Dustin Diaz, der den »First Annual Naked Day: April 05« ausgerufen hat. Auf dieser Seite findet man auch eine lange Liste von Websites, die ebenfalls an der Aktion teilnehmen.

… wenn dir diese Ansicht nicht gefällt, dann wähle einfach aus meinem Styleswitcher einen Style aus; dann ist der Spuk vorbei, zumindest so lange, bis Du Deinen Browser neu startest.


Der nackte Tag 2008

Dienstag, 8. April 2008

Am 9. April ist es wieder so weit:
Meine Seiten werden einen Tag lang nackt, ohne jegliches Styling dargestellt.
Die Idee von Dustin Diaz ist jetzt schon im vierten Jahr.
Damit soll gezeigt werden, dass ordentlich strukturierte Seiten auch ohne Styling, ohne CSS, ordentlich lesbar und benutzbar bleiben. Der erste und wichtigste Schritt zur Barrierefreiheit.


Wave, das Werkzeug zum Testen auf Barrierefreiheit

Montag, 31. März 2008

Automatische Tools zum Test auf Barrierefreiheit haben alle ihre - bekannten - Grenzen. Die meisten Tools weisen auch deutlich darauf hin. Manche zeigen auch detailliert auf, wo die Notwendigkeit einer zusätzlichen manuellen Überprüfung durch einen Experten besteht.
Alle mir bekannten Tools können aber eins nicht: Seiten "live" testen, also nach einem Neuaufbau der Seite, z. B. nach der Auswahl einer Option, die geänderte Seite erneut beurteilen.
Die neue Wave 4.0 Beta kann auch das. Und ist damit das erste Werkzeug, mit dem ich meinen Chat automatisiert testen kann.
Hier das Ergebnis.
Möglicherweise landest du mit obigem Link auf der Login-Seite. Aber, da die Seite ja bedienbar bleibt, einfach einloggen, und Wave testet auch den Chat selbst.


Farbkontrast und Helligkeitsdifferenz nach W3C

Mittwoch, 26. März 2008

Die Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (BITV) schreibt vor:

Texte sind so zu gestalten, dass die Kombinationen aus Vordergrund und Hintergrundfarbe auf einem Schwarz-Weiß-Bildschirm und bei der Betrachtung durch Menschen mit Farbfehlsichtigkeiten ausreichend kontrastieren.

Was "ausreichend" ist, definiert W3C in Form von 2 Algorithmen.

Diese Forderung zu erfüllen, bereitet häufig Schwierigkeiten. Manchmal scheint es, als ob zu einer gegebenen Hintergrundfarbe oder Schriftfarbe überhaupt keine Schriftfarbe bzw. Hintergrundfarbe existiert, die die strengen Forderungen des W3C nach ausreichender Helligkeitsdifferenz und gleichzeitig ausreichendem Farbkontrast erfüllt.

Und dies ist tatsächlich bei sehr vielen Farben der Fall.

Ich habe die Algorithmen des W3C mal in eine anschauliche Form übertragen. Dort kann man eigene Farben vorgeben, oder einfach zufällige Farben durch Neuladen der Seite erzeugen lassen. Das Script generiert daraus automatisch

  1. die Farbe mit der bestmöglichen Helligkeitsdifferenz (also entweder Weiß oder Schwarz), und
  2. die Farbe mit dem bestmöglichen Farbkontrast,

und stellt die Ergebnisse jeweils als Schriftfarbe zur gewählten Hintergrundfarbe und als Hintergrundfarbe zur gewählten Schriftfarbe dar.
Die Zahlenwerte für Helligkeitsdifferenz und Farbkontrast nach W3C werden ausgegeben, und anhand der Minimalforderung bewertet.

Ein wenig Spielen mit zufälligen Farben liefert hin und wieder überraschende Ergebnisse. Manche zulässige Farbkombinationen kann ich kaum lesen.


Captchas sind ein Irrweg

Sonntag, 16. März 2008

Sie schließen Menschen von der Benutzung der dahinter liegenden Dienste aus.
Wie oft schon habe ich - obwohl mit keiner nennenswerten Sehschwäche geschlagen - beim dritten oder vierten erfolglosen Versuch, so ein Captcha zu entziffern, entnervt aufgegeben.

Aber sie hindern "böse" Bots nicht daran, solcherart vermeintlich geschützte Dienste für ihre Zwecke zu missbrauchen:

… Nach Angaben des Maildienstleisters MessageLabs liegt die Erkennungsrate der Captchas (Completely Automated Public Turing Test to Tell Computers and Humans Apart) durch die Spammer-Tools zwischen 20 und 30 Prozent…

Quelle: Heise Security

Eine Trefferquote von "nur" 20 Prozent ist für einen Spambot - anders als für mich - kein Grund, von seinem Treiben Abstand zu nehmen. Bots werden also von Captchas nicht wirkungsvoll ausgesperrt, wohl aber Menschen! Was für eine Perversion.


Ein barrierefreier? Online Video Player

Mittwoch, 12. März 2008

Wie zugänglich sind Online Flash Player für behinderte Surfer, die auf Hilfsmittel zum Betrachten von Webseiten angewiesen sind?
Ich hab' mich mit dieser Frage recht intensiv beschäftigt, und eine pragmatische Lösung erarbeitet.
Artikel lesen

Daß meine Lösung funktioniert, daran habe ich wenig Zweifel.
Erhebliche Zweifel habe ich aber, ob mein Artikel, und insbesondere der Versuch einer Anleitung zum Nachbau richtig und verständlich sind. Ich würde mich daher mehr als sonst über entsprechendes feedback freuen.


Firefox und der Zurück-Button

Donnerstag, 6. März 2008

Eine Detail, das mich schon lange gestört hat, ohne dass ich mir dessen eigentlich richtig bewusst war:
Wenn ich einem Link auf einer Seite folge, und dann mit dem Zurück-Button oder der Zurück-Taste zur aufrufenden Seite zurückkehre, dann erwarte ich eigentlich, dass ich mich an der gleichen Stelle, an der gleichen Scroll-Position wiederfinde.

Der IE macht das auch erwartungsgemäß. Der Firefox nicht. Und das ist irritierend.

Dabei handelt es sich um einen bekannten Bug im Firefox: http://kb.mozillazine.org/Scroll_position_on_web_pages_not_remembered
Und auf dieser Seite fand ich auch gleich noch einen Workaround: Eine Extension für den Fuchs: http://www.gozer.org/mozilla/extensions/
dort "Restore Scroll Position v0.5.9.10"


Hören statt Sehen

Montag, 3. März 2008

Eine akustische Seite. So überschreibt der blinde Webmaster Robert Gemeinhardt seine Homepage. Robert verwendet die fast vergessene Aufnahmetechnik Kunstkopfstereophonie, um möglichst realistische räumliche Tondokumente aus dem Alltag zu erstellen. Ob sich dem sehenden Hörer die alle Feinheiten dieser Aufnahmen ebenso erschließen, wie Robert das in seinen Anmerkungen beschreibt?
Um ein komfortables Stöbern durch die zahlreichen Tonbeispiele zu ermöglichen, setzt Robert meinen mp3-Player ein.


Menü unten?

Mittwoch, 27. Februar 2008

Das Menü gehört mit zu den wichtigsten Komponenten einer Website. Kein Zweifel. Und deshalb befindet es sich auch immer oben, links oder rechts, auf jeden Fall aber »above the fold«, ist also ohne Scrollen sichtbar.
Nutzer von Screen Readern, PDAs und Handys, sowie Suchmaschinen sind diesbezüglich ganz anderer Meinung. Sie hätten gerne das Wichtigste, nämlich den Inhalt, zuerst.
Die Lösung, um Alle zu bedienen: Das Menü kommt im markup, im Quelltext, ans Ende, und wird per CSS in die linke oder rechte Navigationsspalte positioniert. Damit die oben erwähnten Nutzergruppen das Menü leicht erreichen, gibt es einen skip link ganz am Anfang der Seite, um das Menü direkt anzuspringen. Zu erreichen (zu sehen) ist dieser skip link mit der Tab-Taste.
Ich hab' jetzt mal etwas anderes probiert: Auf dieser Seite bleibt die Navigation unten. Aus Designgründen.
Schön. Und gewagt. Wenn das Browserfenster des Besuchers, warum auch immer, so klein ist, dass er das Menü nur durch Scrollen erreicht? Ist das nicht irritierend?
Nein!
Denn in diesem Fall wird das Menü eben oben angezeigt.
Ich erreiche dies durch ein pfiffiges Javascript. Danke an SELFHTML
(Sollte Javascript nicht verfügbar sein, bleibt das Menü eben unten. Aber die Seite funktioniert weiterhin.)

Nachtrag: Hab' ich eigentlich erwähnt, daß der IE das natürlich nicht kann?


Komfortable Formulare

Montag, 25. Februar 2008

Mehrzeilige Texteingabefelder in Formularen <textarea> sind auf den meisten Webseiten aus Designgründen viel zu klein. Häufig passen nur 5 oder 6 Zeilen in das Eingabefeld, dann erscheint ein Scrollbalken. Damit wird es äußerst unbequem, das Geschriebene zur Korrektur noch einmal zu lesen.
Safari-Nutzer können das Textfeld mit der Maus vergrößern, und Firefox-Nutzern steht eine gleichwertige Extension zur Verfügung, wie ich hier beschrieben habe.
Eine weitere, elegante Lösung habe ich kürzlich gefunden (ich weiß leider nicht mehr wo, dennoch danke an Unbekannt).
Mittels eines Javascript eventhandlers wird das Textfeld automatisch nach unten verlängert, sobald bei der Texteingabe die letzte sichtbare Zeile erreicht ist:

<textarea onkeyup="this.style.height=Math.max(this.scrollHeight,150) + 'px';this.style.overflow='hidden'" …

Mit den 150 px Höhe muß man eventuell ein wenig experimentieren, um ein Springen der angezeigten Höhe zu vermeiden.
Diese Javascript-Lösung ist selbstverständlich unobtrusive, d. h. wenn Javascript nicht zur Verfügung steht, verhält sich das Texteingabefeld ganz normal, wie oben beschrieben.
Klar, dass ich das gleich hier mal probieren musste.


Jenseits von Barrierefreiheit

Donnerstag, 7. Februar 2008

Ist Ihre Website »compliant«?
Web Compliance ist nicht auf Barrierefreiheit allein beschränkt, sondern stellt ein umfassendes Konzept dar, das folgende Bereiche beinhaltet:

  • Standardkonformität und Interoperabilität.
  • Qualitätssicherung und Optimierung von Ressourcen.
  • Sicherheit und Datenschutz.
  • Auffindbarkeit von Ressourcen durch Suchmaschinen und Optimierung des Rankings der Suchergebnisse.
  • Unterstützung von Corporate Identity.

Das Fraunhofer Institut für Angewandte Informationstechnik (FIT) hat ein neues Werkzeug zum Testen der Compliance entwickelt. Eine kostenlose Demo [Beta] gibt es hier: http://imergo.de/

Sie können eine URL Ihrer Wahl auf Validität und Compliance mit verschiedenen nationalen und internationalen Bestimmungen für Barrierefreiheit prüfen lassen.

Eine Warnung sei angebracht:
Das Tool stellt hohe Ansprüche an die Kenntnisse des Webmasters, wenn es darum geht, die Auswertung zu verstehen und aufgezeigte Fehler abzustellen.


Das Internet der Zukunft ist barrierefrei

Mittwoch, 6. Februar 2008

Kongress Banner AbIDas Aktionsbündnis für barrierefreie Informationstechnik veranstaltet am 9. und 10. April 2008 in Berlin einen Kongress zum Thema "Digital informiert - Im Job integriert".
Infos und Anmeldung unter http://kongress2008.abi-projekt.de


Sanftes Scrollen - wieder aktiviert

Edit 06.02.2008: Ein neuer Anlauf. Das Bildschirmflackern sollte behoben sein (siehe Kommentar). Und auch der Zurück-button funktioniert.
Über Rückmeldungen und Kommentare würde ich mich freuen.

Edit 3.2.2006: wegen eventueller Probleme mit der accessibilty (Flackern) und der usability (die Zurück - Funktionalität des Browsers geht nicht mehr) hab ich das sanfte Scrollen - schweren Herzens - vorläufig? wieder deaktiviert.
Den Beitrag hier lasse ich stehen: das tool ist einfach zu interessant.
weiterlesen…


Verstecker Sprunglink - ist mein IE6 kaputt?

Freitag, 18. Januar 2008

Seiteninterne Sprunglinks, etwa zum Inhalt, oder zur Navigation, sind ein wichtiges Element, um die Benutzung von Webseiten ohne Maus, ausschließlich mit der Tastatur zu erleichtern.
Vielfach werden diese Sprunglinks per CSS versteckt, und nur beim Durchtabben mit der Tastatur angezeigt.
Hierfür gibt es eine etablierte Technik, die eigentlich immer und überall funktioniert.
Eigentlich.
Nur nicht mit dem IE6 auf der folgenden Testseite, die ich eigens erstellt habe, um diese Technik in verschiedenen Browsern zu testen.
http://webdesign.weisshart.de/test/skiptest/skip.html

Hier der Quelltext der Seite:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">

<head>
<title>Titel</title>
<meta http-equiv="Content-Style-Type" content="text/css" />

<style type="text/css">

#skip a:link,
#skip a:visited {
position:absolute;
left:-500px;
top:-500px;
width:0;
height:0;
display:inline;
}

#skip a:focus,
#skip a:hover,
#skip a:active {
position:absolute;
left:0;
top:0;
width:auto;
height:auto;
display:block;
}

</style>

</head>
<body>

<div id="skip"><a href="#navsprung">Sprung zur Navigation</a></div>

<div id="inhalt">
<h1>Titel</h1>
<p>Irgendwelche Inhalte</p>
<p><a href="http://www.example.com">ein normaler Link</a></p>
</div>

<p>Viele Trennlinien, um Raum zu schaffen:</p>
<hr /><hr /><hr /><hr /><hr /><hr /><hr /><hr />

<h2><a name="navsprung">Navigation</a></h2>

</body>
</html>


Online Banking mit mobilen Geräten

Montag, 29. Oktober 2007

Inzwischen kann ich unterwegs fast alles, was das Internet bietet, mit meinem PDA erledigen. Information aller Art abfragen, meine Homepage aktualisieren, ja sogar Börsen- und Bankgeschäfte erledigen. Mit entsprechend gestalteten Seiten sind auch der relativ kleinen Bildschirm und die mancherorts recht schlechte Internetanbindung kein Problem.

Auch meine Bank bot eine entsprechende, für mobile Geräte optimierte Seite an, auf der ich bequem mal schnell z.B. Zahlungseingänge checken konnte.
"Konnte", denn seit kurzem hat sich dieses Angebot geändert, und sieht jetzt so aus:

Das Menü auf der mobilen Seite der Stadtsparkasse MünchenAnstelle eines Zugangs zum online banking findet sich jetzt lediglich der Menüpunkt "TelefonBanking", und dahinter verbirgt sich eine Seite mit der Telefonnummer der Bank.
Auch eine Art von mobile banking.
Ich weiss nicht, ob ich darüber lachen soll, ob ich mich ärgern soll, oder die Bank wechseln.
Natürlich kann ich auch die "normale" Seite zum online Banking aufrufen. Aufgrund der Dateigößen und der unübersichtlichen Gestaltung der Seiten ein äusserst mühseliges Unterfangen.
Mal sehen, ob und wie die Bank auf meine diesbezügliche Anfrage reagiert.

__________________________
So, die Antwort ist da:

Mit der Umstellung können unter http://mobile/…..de nur noch mobile Services wie Börsenkurse und aktuelle Hinweise zur Verfügung gestellt werden. Sie können alternativ versuchen, ob unser InternetBanking unter https://homebanking…..de über den mobilen Browser Ihres PDAs nutzbar ist.

Kein weiterer Kommentar meinerseits.


Safari für Windows

Sonntag, 8. Juli 2007

Gerade entdeckt:
Safari Browser für Windows
Erster Eindruck: problemlos zu installieren, und funktioniert tadellos.
Für Webworker, die zugängliche Seiten schreiben wollen, aber sich dafür nicht extra einen Mac kaufen können/wollen, eine tolle Sache - vorausgesetzt, der Safari verhält sich unter Windows genau so wie auf dem Mac.
Ich werde über meine weiteren Erfahrungen hier berichten.


HTML Tidy als Firefox Extension

Donnerstag, 7. Juni 2007

Die Anzeige von HTML Tidy in der Toolbar des BrowsersWebdesigner, die sich um validen Code bemühen, kennen die "wichtigste" Firefox Extension: Die Web Developer Toolbar.
Noch einen Schritt weiter geht die Extension HTML Tidy. Jawohl, der Veteran HTML Tidy ist auch als Firefox Extension verfügbar:
Download und Installation
Tidy verwendet den Algorithmus des W3C Konsortiums, und bietet aussagekräftige Hinweise zu Fehlern und deren Behebung.
Und das Schönste: Die Extension zeigt direkt in der Toolbar des Browsers eventuelle Fehler. Ganz praktisch, um schnelle Änderungen auf der eigenen Seite auf Validität zu überprüfen.


Flash - Musik per Flash Player barrierefrei einbinden

Dienstag, 22. Mai 2007

Notenblatt: Franz gute Nacht
Unter dem Titel "Musik auf Webseiten barrierefrei anbieten als Flash Stream" habe ich einen Artikel online gestellt, der einen möglichen Weg zur barrierefreien Einbindung eines Flash Musik Players aufzeigt.
Ich hoffe auf eine rege Diskussion, und freue mich über Kritik und/oder Anregungen.


Über den (Un-)Sinn von Browserweichen

Mittwoch, 9. Mai 2007

Mit sogenannten Browserweichen versuchen geplagte Seitenschreiberlinge seit Unzeiten, die unterschiedliche Interpretation von CSS durch die verschiedenen Browser in den Griff zu bekommen.
So bedauerlich die uneinheitliche Unterstützung der Standards durch die Browserhersteller auch ist - die vermeintliche, gutgemeinte, Abhilfe kann gründlich in die Hose gehen:

die Seite von Michls Cafe ohne CSS
Screenshot der Seite von Michl's Cafe
ohne CSS

Ich bin heute zufällig über die Seite von Michl's Cafe gestolpert. Und hab' nicht wenig gestaunt, eine Seite ohne jegliche Formatierung anzutreffen. HTML pur, kein CSS, aber auch keine Tabellen. Einfach HTML. Valide noch dazu, und semantisch korrekt ausgezeichnet, also anscheinend keine Stümperseite. Sollte es tatsächlich so etwas geben? Eine offensichtlich aktuelle Site, die korrektes, valides XHTML bietet, ganz ohne Formatierungen?
Hat mein Firefox ein Problem?
Also ein Versuch mit Opera.
Gleiches Ergebnis.

Erst ein Blick in den Quelltext zeigte die Ursache: Eine ausgefeilte Javascript Browserweiche, die nicht weniger als 3 x 10 = 30 unterschiedliche Betriebssystem/Browserkombinationen abfragt, und das jeweils passende CSS einbindet.

Wenn - ja wenn Javascript aktiviert ist.

Ist es aber bei mir erst mal nicht, wenn ich auf fremden Seiten surfe. Dank Firefox und seinen nützlichen Erweiterung. (Warum Opera das CSS nicht erkannte, obwohl ich dort Javascript nicht deaktiviert habe, hab' ich nicht mehr untersucht. Vielleicht liegt es daran, dass ich die neueste Version 9.2 installiert hab'?)
Und ohne Javascript wird auf diesen Seiten gar kein Stylesheet eingebunden.

Ich bewundere den Eifer des Webdesigners, der 30! Stylesheets erarbeitet hat. Leider in meinem Fall vergeblich.

Die Moral von der Geschicht?
Javascript nie ohne fallback!

Der Webdesigner der zitierten Seite möge Nachsicht mit mir haben: Das Beispiel ist rein zufällig, und die Kritik absolut konstruktiv zu verstehen. Zumal es sich um eine vorbildlich barrierefreie Seite handelt.


Tastaturkürzel für Webseiten und der Firefox

Montag, 5. März 2007

Tastaturkürzel, (engl. access keys) werden dazu benutzt, bestimmte Seiten oder Sprungmarken schnell anzuspringen.
Auf meiner Seite verwende ich diese Tastaturkürzel.

Der Einsatz von Tastaturkürzeln ist nicht unumstritten. Unter anderem deshalb, weil die Kombination Alt+Taste für fast alle Kombinationen vorbelegt ist: vom Browser, oder von unterschiedlichen Hilfsprogrammen wie z.B. Screenreadern.
Unkritisch verwendbar sind unter diesem Aspekt eigentlich nur die Ziffern 0 bis 9.

Unter Windows gilt die Kombination Alt+Tastenkürzel.
So war das zumindest bisher.
Der Firefox in der neuesten Version 2.0.0.2 hat hier eine Änderung eingeführt:
Alt+Umschalt+Tastenkürzel. release notes

Damit wären die oben beschriebenen Konflikte beseitigt, und der Einsatz auch von Buchstaben für Tastaturkürzel möglich. "Wären", wenn das Standard wäre. Ist es aber nicht.

So blieb nur der Schreck, als anscheinend plötzlich die Tastaturkürzel auf meinen Seiten nicht mehr funktionierten. Und noch etwas mehr Verwirrung, was die Thematik Tastaturkürzel betrifft. Siehe dazu einen Beitrag bei www.einfach-fuer-alle.de


Barrierefreies Javascript?

Freitag, 12. Januar 2007

Ich bezeichne meinen Chat als barrierefrei.
Nein, mein Chat ist nicht barrierefrei.
Und zwar, weil WAI und BITV unter anderem verlangen, dass barrierefreie Webseiten auch ohne Javascript zugänglich sein müssen.
In letzter Zeit wird viel über barrierefreies pdf und barrierefreies flash diskutiert.
Wer keinen pdf reader oder kein flash installiert hat, wird auch zu barrierefreien pdfs und barrierefreiem flash keinen Zugang erhalten.

Ist die Analogie erkennbar?
Ich behaupte einfach, dass mein Chat "barrierefreies Javascript" verwendet.
Die Seite, die der Browser darstellt, beinhaltet nämlich gar kein Javascript mehr.
Vielmehr wird durch Javascript - genauer: AJAX - eine (fast) normale (X)HTML Seite erzeugt. (Dass die Quelltext-Anzeige des Internet Explorer dies nicht zeigt, ändert nichts an der Tatsache.) Und damit der Browser dieses Kunststück vollbringen kann, muss natürlich Javascript erlaubt sein.

Noch ein Vergleich gefällig?
Ein hochgradig Hörbehinderter, der sein Hörgerät nicht einschaltet, kann nicht Radio hören.
Wer Javascript deaktiviert hat, kann den Chat nicht benutzen.
Sturheit und Starrsinn sind keine Barrieren.

Weitere Aspekte und denkbare Kritikpunkte:

  • HTML und CSS validieren, das Javascript erzeugt keine Fehler und Warnungen.
  • Der Chat verwendet weder Frames noch Layout-Tabellen.
  • Die Seite ist semantisch korrekt gegliedert, und mit (zum Teil unsichtbaren) Überschriften strukturiert. Listen und Formularelemente sind mit (unsichtbaren) Hinweisen versehen.
  • Die Schriftgröße kann (fast) beliebig skaliert werden.
  • Kontraste: da jeder Benutzer des Chat die Möglichkeit hat, sowohl die Hintergrundfarbe (verschiedene Skins) als auch die eigene Nick- und Textfarbe zu wählen, kann eine unglückliche Kombination zu schlechten Kontrasten führen. Dieses Manko ist durch wenige, einfache Anpassungen am Script bei Bedarf leicht zu beheben. Durch Wahl der Anzeigeoption "Farben aus" kann der User dies abstellen. In der Demoinstallation auf meiner Seite nehme ich dieses Manko zugunsten des Geschmacks der Mehrheit der typischen Chatter in Kauf.
  • Es werden animated gifs für verschiedene Smileys verwendet. Der Admin kann entsprechende Smileys löschen.
  • Uralt Browser wie IE 5.0 und Netscape Navigator 4, und natürlich auch alle Textbrowser, wie z.B. Lynx, die kein AJAX verstehen, bleiben leider aussen vor. (IE ab Version 5.5 kann AJAX.)
    Kann man die Verwendung eines Browsers aus dem vorigen Jahrtausend auch schon als Sturheit bezeichnen?
  • Last but not least: Der Chat ist mit einer Vielzahl von Screenreadern auch von Blinden benutzbar. Und dieses Argument zählt meines Erachtens letztlich mehr, als buchstabengetreues Einhalten von Vorschriften und Normen
  • Muss ich eigentlich noch erwähnen, dass auch Blinde selbstverständlich meine Smileys "sehen"?

Wie bringe ich meine Seite bei Google ganz nach oben?

Mittwoch, 27. Dezember 2006

Bei dieser Fragestellung sollte man vielleicht unterscheiden:

Haben Sie eine "Meine Oma, mein Hund, und mein Gartenzwerg mit der rosanen Mütze" Homepage, dann kann ich Ihnen garantieren, daß ich Ihre Homepage auf die erste Seite bei Google bringe.
Ob Sie sich diesen Service leisten wollen, steht auf einem anderen Blatt.

Sollten Sie jedoch beabsichtigen, Ihr Gewerbe mit dem Suchbegriff "Versicherungsvergleich" auf Top-Positionen in die Suchmaschinen zu bringen, dann sollten Sie erstens viel Geld bereitlegen, und zweitens niemandem glauben, der Ihnen das garantiert.

Zwischen diesen beiden Extremen gibt es jedoch ein weites Feld (kommerzieller) Seiten, die durch technische Mängel ihres Internetauftritts mögliche gute Plazierungen in Suchmaschinen verschenken, und damit potenzielle Kunden nicht erreichen. Eine Analyse der fraglichen Seiten zeigt meist recht schnell Fehler, die zu einer schlechten Plazierung führen, und Verbesserung ist in vielen Fällen mit relativ einfachen Maßnahmen möglich.

Aber bitte erwarten Sie kein Rezept a la "man nehme …."


Opera Browser für PDA

Dienstag, 26. Dezember 2006

Moderne Handys, PDAs und handhelds können Internet. Mehr oder weniger gut. Am "weniger" sind in der Regel die Seitenschreiberlinge schuld. Seiten mit Tabellellayout, wie sie von fast allen CMS und WYSIWYG Editoren leider immer noch produziert werden, machen auf den kleinen Displays wirklich keine Freude.
Aber auch Dinge, die mit dem handheld Sinn machen würden, scheitern oftmals am verfügbaren Browser. Auf handheld mit Windows ist in der Regel der Internet Explorer vorinstalliert. Und der versteht Javascript nur unvollständig - und damit ist Online-Banking meist außen vor. Eigentlich schade.
Aber es gibt für handheld den Opera mobile. Der kann nicht nur ordentlich Javascript, sondern sogar AJAX. Zum Beleg hier ein Screenshot meines AJAX Chats auf dem PDA:

Der Chat, wie er auf dem PDA dargestellt wird


Warum barrierefreies Internet?

Montag, 16. Oktober 2006

Unter diesem Thema fand am 12.10.06 im TechGate Vienna eine Veranstaltung statt, die in jeder Hinsicht meine Erwartungen übertraf. Ich möchte mit diesem kurzen Beitrag den Veranstaltern meinen herzlichen Dank bezeugen.

Der atemberaubende Blick aus dem 19. Stockwerk über das sonnige Wien war die perfekte Einstimmung auf anstrengende 6 Stunden Zuhören.

Die Wahl der Themen und die Abfolge der Beiträge war perfekt, und ließ nie Müdigkeit aufkommen. Von der trockenen Theorie, die der W3C Web Accessibility Specialist Shadi Abou-Zahra in lockerer Form vortrug, über die persönlich gefärbten Meinungen Jo Spelbrinks und der "eierlegenden Wollmilchsau" Tomas Caspers', bis zur Vorstellung namhafter barrierefreier Auftritte (kurier.at und wien.at) spannte sich ein bunter Bogen, der, nie mit erhobenem Zeigefinger, aber auch nie oberflächlich oder seicht, viele Aspekte der komplexen Thematik dem Teilnehmer nahebrachte.

Die Organisation war perfekt, und die Moderatoren hatten die Veranstaltung stets mit lockerer Hand im Griff.

Ich wünsche der Veranstalterin accessible media, daß diese Veranstaltung sie einen Schritt weiterbringt auf dem Weg zu ihren Zielen.

Eine Nachlese zur Veranstaltung mit Links zu externen Berichten gibt es auf der Seite von accessible media.

Daß ich mir persönlich anschließend noch ein paar Tage in einer wunderschönen Stadt gönnte, und bei dieser Gelegenheit eine "Internetbekanntschaft" zu einem real existierenden Wesen wurde, sei nur am Rande erwähnt.


Mein Bildschirm gehört mir - warum target=_blank böse ist.

Dienstag, 11. Juli 2006

Viele "Webdesigner" verwenden das Attribut target="_blank" für externe Links, in der Absicht, Besucher auf Ihrer Seite zu halten.
Diese Technik ist benutzerunfreundlich: Der Bildschirm des Benutzers gehört ihm, und nicht dem Webdesigner.

Schlimmer noch: der Schuß geht nach hinten los, und die Absicht unseres "Webdesigners" verkehrt sich ins Gegenteil. Der "Zurück-button" des Browsers funktioniert nämlich auf neu geöffneten Fernstern nicht. Und damit werden weniger geübte Surfer, wenn sie das Browserfenster auf Bildschirmgröße eingestellt haben, gar nicht mehr auf die Seite zurückfinden, die sie mit Klick auf den Link verlassen haben.

Und erfahrene Surfer? Nun, die wissen, daß man z.B. mit Rechtsklick ein Kontextmenü öffnen, und jeden Link wahlweise in einem neuen Browserfenster öffnen kann.
Noch schneller: Strg + Klick (Firefox), oder Shift + Klick (IE, Opera)
Aber dies geschieht eben dann bewußt, und entsprechend der Absicht des Benutzers, und nicht in Form einer Bevormundung durch den "Webdesigner".

Einen Grundsatzartikel zu dieser Thematik hat Altmeister Jakob Nielsen schon vor vielen Jahren in seine Liste der 10 schlimmsten Fehler des Webdesign aufgenommen.

Und wer es gar nicht lassen kann: in diesem Beitrag habe ich eine Technik vorgestellt, wie man dem Benutzer die Entscheidung überlassen kann.


Aktionsbündnis für barrierefreie Informationstechnik

Dienstag, 2. Mai 2006

Das Unterstützer-Logo des Aktionsbündnis für barrierefreie Informationstechnik mit Link zum AbI webdesign.weisshart.de ist Unterstützer im Aktionsbündnis für barrierefreie Informationstechnik.

Information soll allen Menschen zugänglich gemacht werden. Natürlich auch im Internet. Menschen mit Behinderungen sind häufig von der Benutzung des Internets wegen völlig unnötiger Barrieren ausgeschlossen.

Daher haben sich Behindertenverbände und Experten im Aktionsbündnis für barrierefreie Informationstechnik (AbI) zusammengeschlossen.

AbI steht dabei für:
A - Aktionsbündnis für
b - barrierefreie
I - Informationstechnik

Gemeinsam unterstützen sie die Umsetzung von Barrierefreiheit in der Informationstechnik.

AbI hat sich die Umsetzung des bestehenden Ordnungsrahmens (mit SGB IX und dem Behindertengleichstellungsgesetz) zum Abbau dieser Barrieren zum Ziel gesetzt.

Bisher haben sich bereits eine ganze Reihe an Partnern und Unterstützern AbI angeschlossen. Weitere Initiativen sind eingeladen, sich an dem Aktionsbündnis aktiv zu beteiligen.


Schriftgröß individuell einstellen

Donnerstag, 13. April 2006

eine Brille, die auf einem Buch abgelegt ist Wer darauf angewiesen ist, weiß in der Regel, wie man die Schrift in seinem Browser vergrößern kann. Und das funktioniert auch, wenn der Ersteller der Website dies ermöglicht. Leider tun das viele Seitenschreiberlinge nicht, entweder aus Unwissenheit, oder, schlimmer, aus Borniertheit, nach dem Motto: »wie meine Seiten aussehen, bestimme ich.«
Klar, daß ich auf diesen Seiten die individuelle Einstellung der Schriftgröße zulasse.

Ich bin aber noch einen Schritt weiter gegangen, und biete jetzt für jedermann eine komfortable Möglichkeit an, die Schriftgröße in 15% Schritten zu vergrößern oder zu verkleinern.
Zu finden unter der Überschrift »Darstellung«
Die Einstellung wird per cookie 1 Jahr lang gespeichert, so daß Sie bei Ihrem nächsten Besuch auf diesen Seiten Ihre ganz persönliche Einstellung wieder vorfinden.


webdesign weisshart am 5. April nackt

Dienstag, 4. April 2006

Hoppla! Was ist denn mit dem Design passiert? Ganz einfach, webdesign weisshart beteiligt sich am »CSS Naked Day«. Die Idee dahinter ist recht simpel: ist die Website noch benutzbar, wenn man sämtliche Formatierungen abschaltet? Verwendet die Website semantisches Markup, oder gehen ohne das Design wesentliche Informationen verloren?

Entstanden ist die Idee im Weblog von Dustin Diaz, der den »First Annual Naked Day: April 05« ausgerufen hat. Auf dieser Seite findet man auch eine lange Liste von Websites, die ebenfalls an der Aktion teilnehmen. Die Technik dahinter ist übrigens denkbar einfach – man muss dazu einfach nur sein /css/-Verzeichnis umbenennen.

Nachtrag: auch wenn heute erst der 4. April ist, auf der anderen Seite unseres Planeten ist bereits der 5. April. Daher dauert es auch 48 statt 24 Stunden, bis dieser Zustand vorbei ist.

… es sei denn, Du wählst aus meinem Styleswitcher einen Style aus; dann ist der Spuk vorbei, zumindest so lange, bis Du Deinen Browser neu startest.

Nachtrag 2: … und weil's so schön war, hab ich die »Nacktversion« auch noch meinem Styleswitcher hinzugefügt.


Flash XHTML valide einbinden

Donnerstag, 30. März 2006

Ja, man kann Flash sehr wohl XHTML valide einbinden.
Dazu muß lediglich der Code, der in vielen Beispielen zu finden ist, gehörig entrümpelt werden.
Hier eine Demo, die auch noch Spaß macht.


Externe Links in neuem Fenster öffnen?

Mittwoch, 29. März 2006

Fenster mit Geranien Die Geister scheiden sich daran, wie denn nun ein Link am besten geöffnet werden soll. Die einen schätzen ein neues Fenster, um die alte Ansicht nicht zu verlieren. Andere hassen das Fenstergewirr.

Ich überlasse die Wahl meinem Besucher!

In der Standardeinstellung werden Links im gleichen Fenster geöffnet. Vorteil: die Zurücktaste funktioniert wie gewohnt.
Und wer Links in einem neuen Fenster öffnen will, kann das jederzeit. Zum Beispiel so: Klick mit der rechten Maustaste, und dann die entsprechende Auswahl treffen (z.B.: "Link in neuem Fenster öffnen"). Moderne Browser bieten zu diesem Zweck mehr Komfort.

Bei Dr. Web hab' ich mir jetzt eine pfiffige Lösung abgeguckt.
Das sieht so aus (hier nur ein Muster ohne Funktion):

Fremde Seiten in neuem Fenster öffnen?

In Aktion zu sehen hier im Blog gleich nach der Überschrift, oder auf meiner Referenzseite Suchscript im Menü.

Das Ganze erfordert allerdings Javascript. Und wer Javascript nicht aktiviert hat? Nun, dem steht eben dieser zusätzliche Komfort nicht zur Verfügung. Aber die Funktionalität der Seite ist natürlich gewährleistet. Der Fachausdruck hierfür heißt "unobtrusive Javascript". (Eine griffige deutsche Übersetzung für diesen Begriff hab' ich noch nicht gefunden. Aber dafür eine hervorragende Abhandlung zum Thema Javascript bei SELFHTML)


Webseiten ohne Maus bedienen

Dienstag, 14. März 2006

… in diese Verlegenheit bin ich kürzlich gekommen. Maus nicht zum Notebook eingepackt - und dann war da irgend ein Defekt am eingebauten Mauspad.
Jetzt galt es, Webseiten ausschließlich mit der Tastatur zu bedienen. Daß dabei die Tab-Taste die wichtigste Taste ist, war mir natürlich klar. Aber auf den meisten Seiten kam ich damit nicht weit.
Als Konsequenz aus dieser Erfahrung hab ich meine eigenen Seiten noch einmal nachgebessert. Wozu ich Tastaturkürzel eingebaut habe, und warum beim Durchtabben der jeweils aktive Link deutlich gekennzeichnet wird, ist mir jetzt erst richtig klar.
Wenn Sie wollen, probieren Sie's einfach einmal aus, und legen Sie die Maus beiseite. Sie werden staunen.
Es gibt übrigens viele Menschen, die wegen motorischer Einschränkungen die Maus nicht bedienen können, und immer auf diese Weise surfen …


Websites in allen gängigen Browsern live testen

Sonntag, 5. März 2006

Wer Webseiten entwickelt, kennt das Problem. Die fertigen Seiten müssen zu allen Browsern kompatibel sein und die Darstellung sollte stimmen. Die Vielfalt der Betriebsystem- und Browser-Kombinationen macht jedoch einen Test schwierig.

Hier gibt es einen preiswerten Dienst, der es jedem Entwickler ermöglicht, seine Seiten live unter beliebigen Browsern und Betriebssystemen zu testen, ohne diese selbst vorrätig halten zu müssen.
weiterlesen…


Wie schnell sind mobile Webseiten

Mittwoch, 8. Februar 2006

Laaaaaangsam!

Jedenfalls, solange Sie kein UMTS Gerät der neuesten Generation besitzen, oder sich außerhalb des (nur langsam wachsenden) UMTS Empfangsbereichs befinden.
In beiden Fällen müssen Sie die Internetseiten über GPRS laden.
GPRS überträgt maximal 53,6 kbit/s, ist also theoretisch nur etwas langsamer als die früher weit verbreiteten 56 kbit Modems.
Aber eben nur theoretisch. Weil Sie sich die Bandbreite mit Millionen von Handy Nutzern teilen, sinkt die effektiv verfügbare Datenrate in der Hauptverkehrszeit drastisch. Das können auch einmal nur 5 kbit/sec oder noch weniger sein. weiterlesen…


Webdesign für PDA / handhelds

Dienstag, 7. Februar 2006

Unter dem Titel "Webdesign für alle Browser" hab ich hier kürzlich gezeigt, wie meine Seite auf einem PDA aussieht. Der Screenshot dort stammt von einem XDA mit Windows CE und dem Internet Pocket IE Browser.

Diese Seite auf einem Palm Jetzt hab ich endlich auch einen Screenshot von einem Palm. Danke Jonas alias Archer.
Schade ist nur, daß anscheinend der user den Palm erst in den sogenannten "optimierten Modus" zwingen muß.
weiterlesen…


Mein Suchscript gewinnt 2 mal beim BIENE Award 2005

Montag, 23. Januar 2006

Die Biene - ein Qualitätszeichen für barrierefrei SeitenDer BIENE-Preis wird an die besten barrierefreien Webseiten verliehen. Biene steht für "Barrierefreies Internet eröffnet neue Einsichten".
Mehr als 320 Webseiten wurden für den Wettbewerb 2005 eingereicht, 26 davon qualifizierten sich für das Finale. Insgesamt 16 Internet-Angebote haben die Aktion Mensch und die Stiftung Digitale Chancen im Wettbewerb für ein barrierefreies Internet ausgezeichnet. Der Auszeichnung vorausgegangen waren ein umfangreiches Testverfahren und die Entscheidung einer prominent besetzten Jury aus Medienmachern und Multiplikatoren.

Gleich zwei der prämierten Webauftritte verwenden mein Suchscript:
Das österreichische Jüdische Museum, BIENE in Bronze,
und Rechtsanwalt Dr. Oliver Tolmein, Sonderpreis.


Webdesign für alle Browser

Samstag, 21. Januar 2006

Ja, für alle! und damit meine ich nicht nur Firefox, Opera oder den IE, sondern z.B. auch Browser, die auf einem PDA oder sogar Handy laufen.
Das sieht am Beispiel dieser Seite dann so aus:

Diese Seite auf einem PDAWohlgemerkt:
Es handelt sich nicht um eine spezielle Version dieser Seite, sondern um exakt dieselbe Seite, mit allen Inhalten, und mit der vollen Funktionalität. Lediglich Designelemente, die zum Lesen des Inhalts nicht unbedingt erforderlich sind, werden für handhelds per CSS ausgeblendet. Dafür werden andere Elemente eingeblendet: auf dem Bild zu sehen: der Sprunglink zum Überspringen der Navigation, direkt zum Inhalt. Auf diesen Displays, gerade mal 240 × 320 Pixel klein, hat einfach nicht viel Platz. Und Ladezeit ist ein K.o.-Kriterium.
Wer Lust hat, sich meine Seiten mal in einem PDA anzuschauen, und mit anderen Webseiten zu vergleichen, ist herzlich eingeladen. Ich freu mich über jede Kritik.


Usability und Navigation

Montag, 2. Januar 2006

Eine wenig bekannte, aber nichts desto weniger berechtigte Forderung aus der Ecke usability lautet:
Die aktuelle Seite darf in der Navigation kein aktiver Link sein (sie sollte sogar für die Nutzer von screenreadern speziell ausgezeichnet sein, z.B. als "Standort").
Im Weblog gibt es diesbezüglich eine Besonderheit:
Sobald ich mir die Kommentare zu einem Beitrag anschaue, oder aus dem Archiv einen älteren Beitrag aufrufe, bin ich zwar immer noch im Weblog, aber eben nicht auf der Startseite des Blogs.
Wenn ich nun auf die Startseite des Blogs zurück wollte, dann war, aus oben genannten Gründen, der Link im Menü nicht aktiv.
Das war nicht gut.
Ich hab's geändert.
Der Link im Menü ist jetzt immer aktiv, außer auf der Startseite des Weblogs.


Suchformular im Weblog

Samstag, 31. Dezember 2005

so, das dürfte die letzte Aktion des Jahres sein:
Ich hab das Suchformular für die Suche im Weblog an die gleiche Position im Menü gestellt, an der auch die allgemeine Seitensuche zu finden ist. Aus Gründen der usability schon lange notwendig.
(Daß die Blogsuche nur die Beiträge selbst, aber nicht die Kommentare durchsucht, ist eine andere Geschichte - aber vielleicht ist das ganz vernünftig so?)


Mit Lynx ins Intenet

Sonntag, 20. November 2005

Screenshot: Diese Seite im Lynx Browser

Dem Webmaster zeigt Lynx kompromißlos den wahren Inhalt seiner Internet-Seiten: So wie Lynx die Seiten anzeigt, d.h. ohne graphischen Schnickschnack, ohne Skript-Elemente, so "sehen" auch die Suchmaschinen die Internet-Seiten. Und auf diese Art zeigt sich recht einfach, wieso manche Internet-Seiten von den Suchmaschinen kaum oder nur zu unpassenden Suchwörtern gefunden werden. Mit Lynx sieht deshalb man auch, ob man Webseiten nach HTML-Standard erstellt hat oder Webseiten, die sich nur unter bestimmten Browsern oder gar nur unter bestimmten Browser-Versionen darstellen lassen.

Einen einfachen Weg, Lynx ohne großen Aufwand zu installieren, bietet Daniel A. Rehbein auf seiner Seite www.mein-dortmund.de


Flash XHTML valid einbinden

Samstag, 27. August 2005

Die Flash Analoguhr, tausend mal im Netz, ist jetzt auch in meinem Menü zu bewundern.
Ja, ich weiß, Du hast selbst eine Uhr …
aber vielleicht wunderst Du Dich ja, wie lange Du auf meinen Seiten verweilst.
Spaß beiseite:
Die Uhr dient nur dazu, zu zeigen, daß man Flash auch XHTML valide einbinden kann (der erste Schritt zur Barrierefreiheit). Der von Macromedia empfohlene Weg macht nämlich die Seiten invalide.
Wie es geht, kannst Du Dir ja im Quellcode meiner Seiten anschauen.
Beschrieben wird die Methode bei alistapart


Bobby ist umgezogen

Donnerstag, 5. Mai 2005

Das beliebte online tool Bobby ist umgezogen.
Hierhin: webxact.watchfire.com
Und das Papperl gibt es dort nicht mehr. Damit dürften Tausend von Webseiten, die sich bisher damit geschmückt haben, obsolet sein.


Das Weblog ist nur bedingt barrierefrei?

Freitag, 25. März 2005

Bobby, der accessability Validator, den ich routinemäßig meine Seiten testen lasse, mag das Weblog nicht.
Der einzige Punkt, der bemängelt wird:
Alle Links zum Kommentieren sind gleich bezeichnet.
Na ja, ob das eine echte Barriere ist?
Auf jeden Fall hab ich auf der Weblog Seite den Bobby Link aus dem Footer rausgenommen.
110%ig?
von mir aus!


Screenreader - wie Blinde surfen

Samstag, 18. Dezember 2004

Zu den wichtigsten Elementen auf einer Webseite zählt die Navigation. Wenn eine Seite wirklich für Alle zugänglich sein soll, dann muß auch und vor allem die Navigation unter allen denkbaren Bedingungen funktionieren.
Daß meine Seite auch unter Extrembedingungen zugänglich ist, dafür steht das folgende Beispiel:
Die Navigation, wie sie von Vorlesesoftware (sogenannten Screenreadern) "gesehen" wird,
hier zum Anhören als Flash Live Stream,
und hier zum download im mp3 Format (87 kB)

Dank an Eva Papst für die Audio Datei.


Sprachauszeichnung

Donnerstag, 16. Dezember 2004

Das war schon lange auf der todo list:
Vollständige Sprachauszeichnung für Screenreader auf allen Seiten.
Auch das ist jetzt abgehakt - zumindest fast: Wie ich mit Englisch - Deutsch zusammengesetzten Wortungetümen wie z.B. Browserfenster umgehen soll, weiß ich nicht so recht. Ich hab mal gelesen, daß die Screenreader bei jedem Sprachwechsel eine mehr oder weniger lange Pause einlegen. Und dann klingt das so: Browser……..fenster.

Und noch ein Problem bleibt:
beim Schreiben hier im Weblog" muß ich jeden Sprachwechsel manuell codieren; und das ist nicht nur mühsam, sondern beinhaltet auch die Gefahr, daß sich Syntaxfehler einschleichen. Also schreiben - validieren - korrigieren u.s.w.
Mal sehen, ob ich Wordpress nicht doch noch so konfigurieren kann, daß die Tags zur Sprachauszeichnung einfacher einzufügen sind.


Hierarchische Navigationsmens und Screenreader

Mittwoch, 15. Dezember 2004

Das Navigationsmenü auf dieser Seite ist als <ul> ausgezeichnet, und hierarchisch gegliedert. Damit kann ich u.a. Submenüs kontextabhängig ein- und ausblenden.
Wie die Struktur der Navigation aussieht, kann man am besten auf der Sitemap sehen.
Screenreader haben damit Probleme, weil sie die Listenstruktur nicht erkennen.
Bei einfachfueralle.de wird eine Lösung für dieses Problem vorgestellt, unter Verwendung von logischen Textauszeichnungen mittels <dfn>.
Ich hab das mal hier eingebaut. Zu sehen ist das auf dem Bildschirm aber nur im Style "easy" (und am besten wieder auf der Sitemap). Für alle anderen Styles werden diese logischen Textauszeichnungen per CSS ausgeblendet.
Und im Quellcode kann man sich natürlich das ganze Menü anschauen.


Styleswitcher - aktiver Style

Samstag, 4. Dezember 2004

Was für die Navigation gilt, gilt auch für den Styleswitcher:
die aktuelle Auswahl sollte gekennzeichnet und kein aktiver Link sein - ein häufig vernachlässigtes usability feature.
Ich hab das heute mal umgesetzt. Und da meine Navigation einschließlich Styleswitcher per PHP eingebunden wird, mußte ich noch eine Abfrage einbauen, welcher Style gerade aktiv ist. Und das funktioniert natürlich per cookie-Abfrage.


Barrierefreiheit

Mittwoch, 27. Oktober 2004

Barrierefreiheit ist ein wichtiges Thema auf diesen Seiten (und nicht nur hier!)
Heute hab ich dazu einige Anregungen von Eva Papst, Verlagsleitung des Bundes-Blindenerziehungsinstituts in Wien erhalten.
Die wesentlichen Kritikpunkte waren:

  • accesskeys: manche machen den Browser kaputt
  • kein Link zur aktuellen Seite
  • Sprachwechsel kennzeichnen

Manche accesskeys machen den Browser kaputt

Die Accesskeys sind ja heiß umstritten, aber dass Sie mir z.B. ALT*D wegnehmen, womit ich doch ins Datei-menü komme, schmerzt ein wenig. Gerade wer keine Maus hat und auf die Tastatur angewiesen ist, benötigt die browser-eigenen Kombinationen dringend!

Die Konsequenz aus diesem Hinweis war drastisch: Ich hab alle accesskeys mit Buchstaben rausgenommen, und verwende nur noch die Ziffern 0 - 9. Denn je nach Browser und der auf diesem Browser eingestellten Sprache können eventuell alle Buchstaben zur Bedienung des Browsers erforderlich sein.

Kein Link zur aktuellen Seite

Noch ein Hinweis auf ein usability-Merkmal: Eine Seite sollte nicht auf sich selbst verweisen und nicht als Link, sondern als Standort angedruckt sein. Ich weiß, dass dies so manches CMS vor Probleme stellt, aber es handelt sich dabei ja nicht um ein BF-Merkmal, sondern eine sehr berechtigte Anforderung aus der Ecke Usability, also für alle!

Ja, ja, das wußte ich ja. Aber mein Menü wird dynamisch per PHP erstellt und in die einzelnen Seiten eingebunden. Und da war doch einiges an Handarbeit erforderlich, um diesen Hinweis umzusetzen. Aber ich denke, die Arbeit hat sich gelohnt.

Sprachwechsel kennzeichnen

…auf die kleinen Mängel weißt man aber hin - wie z.B. auf die fehlenden Sprachwechsel.

Die Auszeichnung von Sprachwechsel betrifft vor allem die vielen Anglizismen, ohne die es anscheinend nicht geht; Homepage ist das erste Beispiel. Und die Auszeichnung eines Sprachwechsels muß im Quelltext vorgenommen werden - da hilft kein PHP, kein CSS und kein Javascript. O.k., ich hab mal angefangen damit.


Archiv:

Kategorien:

Creative Commons Lizenzvertrag
Alle Texte (nicht Bilder!) Creative Commons CC BY-NC-SA 3.0 DE