Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Ohne Maus kein Käse. Events auf dem iPhone.

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Ohne Maus kein Käse. Events auf dem iPhone.

Auf fast jeder Webseite finden sich heute Effekte, die durch das Überfahren mit dem Mauszeiger ausgelöst werden, sei es durch ein mit dem onmouseover-Event gestartetes Javascript oder die gute alte Pseudoklasse hover:. Das beliebte iPhone kann allerdings nicht mit allen Events umgehen. Sascha Postner nimmt sich der Sache an.

Webentwickler geben in ihren Stylesheets und Skripten oft und gerne an, wie sich Links oder Elemente bei Mausberührung verhalten sollen. Dabei wird leider häufig übersehen, dass diese Effekte endgeräte-spezifisch sind. Denn wer keine Maus nutzt, tut sich natürlich mehr als schwer, den nicht vorhandenen Mauszeiger über ein Seitenelement zu bewegen, um beispielsweise ein Untermenü oder einen Tooltip mit Zusatzinformationen anzeigen zu lassen. Dies betrifft Anwender eines Screenreaders ebenso wie iPhone- bzw. iPod-Nutzer.

Die Berührung des Bildschirms eines solchen Geräts wird als "Klick" interpretiert. Mauszeigerbewegungen gibt es defacto nicht, was viele Webseiten nahezu unbedienbar machen würde. Apple versucht dieses Problem dadurch in den Griff zu bekommen, dass bei der Berührung des iPhone-Bildschirms zunächst mouseover- und mousemove-Events ausgeführt werden. Verändern sich dabei Elemente der Seite, klappt also z.B. ein Untermenü aus, wird anschließend abgebrochen und es werden keine mousedown-, mouseup- oder click-Events ausgeführt. Das funktioniert aber leider nicht immer zuverlässig.

Im schlimmsten Fall ist das Element mit dem Hover-Effekt kein Link. Dies funktioniert auf dem iPhone gar nicht. Ein Browser mehr in dem Pseudoklassen nur für a-Elemente sinnvoll einsetzbar sind.

Mit unterschiedlichen Strategien lassen sich diese Probleme jedoch adressieren und die eigene Webanwendung für das iPhone fit machen.

Spezielle Versionen von Webseiten, …

Als ein Negativbeispiel für die beschriebenen Probleme kann die Webseite von Amazon dienen, die auch in anderen Bereichen mit Worst Practice aufwarten kann. Hier funktioniert die Hauptnavigation ohne Maus überhaupt nicht. Während beim Überfahren der Navigationspunkte mit dem Mauszeiger Untermenüs ausklappen, passiert beim Klick darauf gar nichts. iPhone-Besitzer, aber auch Tastatursurfer, stehen vor einem unlösbaren Problem. Der Buchhändler bietet allerdings eine speziell auf das Apple-Gerät optimierte Seitenversion an. Diese wird automatisch beim Aufruf der Domain mit dem mobilen Safaribrowser geöffnet.

Wer diesen Weg gehen möchte kann anhand des User-Agent-Headers die Besucher mit einem iPhone bzw. iPod aussortieren und sie so auf speziell optimierte Angebote umleiten. Doch hier muss vorsichtig geprüft werden, denn bereits jetzt gibt es durch unterschiedliche Firmware-Versionen differenzierte iPod/iPhone-User-Agenten.

… angepasste Stylesheets und Skripte, …

Eine andere Strategie kann sein, konditionale CSS-Regeln für bestimmte Endgeräte, in diesem Fall das Apple Gerät, anzubieten. Da der mobile Safari-Browser aber auf das Medienattribut handheld nicht reagiert muss man sich diesbezüglich eines anderen Kniffs bemühen.

<link media="only screen and (max-device-width: 480px)" href="spezielles.css" type= "text/css" rel="stylesheet" />

Erfasst werden also alle Geräte, die sich als screen ausgeben und maximal 480px breit sind.

Apple selbst empfiehlt zudem, Skripte durch kleine Tricks anzupassen. So lässt sich z.B. ein nicht auf Klicks reagierendes Element mit onmouseover durch Hinzufügen eines onclick-Dummyevents wie gewünscht bedienen. Dieser darf sogar später wieder entfernt werden. Der Browser "merkt" sich dies und führt dennoch mouseover-Effekte aus, wie man auf unserer Beispielseite sehr gut nachvollziehen kann.

… oder besser gleich zugänglich gestalten!

Letztlich sollten Webseiten aber gleich barrierefrei und zugänglich gestaltet sein. Das umständliche Bekämpfen von Symptomen durch den Einsatz von Browserweichen und Speziallösungen wird so (fast immer) überflüssig. Es gilt schließlich nicht nur an das gerade im Medieninteresse stehende iPhone zu denken, sondern generell endgeräteunabhängig zu arbeiten. Daher gehört es zum Best Practice, zugängliche Webseiten zu gestalten. Hierzu ein Zitat aus den Richtlinien der WCAG und der BITV:

Internetangebote sind so zu gestalten, dass Funktionen unabhängig vom Eingabegerät oder Ausgabegerät nutzbar sind.

Eine Webanwendung, die von Mausbewegungen abhängig ist, geht demnach einen grundsätzlich falschen Weg. Entwickler sollten sich mehr auf den Benutzer konzentrieren. So ist das eigene Webprojekt nicht nur fit für das iPhone, sondern auch für nahezu alle anderen Arten von Endgeräten.

Möglicherweise hift das populäre iPhone so dabei, die Aufmerksamkeit auf Interaktionsmodelle jenseits der Maus zu lenken und dadurch auch bei Zuänglichkeits-Muffeln ein größeres Bewußtsein für die Notwendigkeit von Barrierefreiheit zu schaffen.

Kommentare

Sylvia Egger

Sylvia Egger
am 21.12.2008 - 11:13

Was es nicht alles gibt: max-device-width. :)

Hier stehen wir vor einem ähnlichen Problem wie mit Screenreadern, die man sozusagen kaum abfragen kann. Im Grunde ist das aber auch gut, weil man sich dann mehr darauf konzentriert, dass Webseiten auch auf anderen Ausgabemedien laufen. Und die Tastaturnavigation ist ohnehin ein Stiefkind in der Webentwicklung, das kümmert die meisten Entwickler eher wenig.

Umso interessanter ist es, dass diese Fragestellung quasi über die iPhone-Hintertür wieder auf den Tisch kommt. Ob dadurch tatsächlich ein stärkeres Bewusstsein für Barrierefreiheit zu erwarten ist, würde ich dann eher bezweifeln. Aber immerhin zeigt der Artikel, wie man über alltägliche Probleme auf dem iPhone auf grundsätzlichere Fragestellungen der Barrierefreiheit stossen kann, ein anderes Bewusstsein anstossen kann.

Permanenter Link

rbq
am 21.12.2008 - 14:18

Was es nicht alles gibt: max-device-width.

Gibt's noch nicht, das wäre CSS 3.

Ich habe aber eher das Gefühl, dass das iPhone die alte Leier mit Browserweichen und Alternativversionen wieder zum Leben erweckt.

Permanenter Link
Sylvia Egger

Sylvia Egger
am 22.12.2008 - 11:03

Gibt's noch nicht, das wäre CSS 3.

Das weiß ich durchaus, dass das CSS3 ist und es gibt es doch, wenn man das iPhone damit ansprechen kann. :)

Permanenter Link

alexander farkas
am 22.12.2008 - 13:18

... und es gibt es doch, wenn man das iPhone damit ansprechen kann.

und Firefox 3.1+ und Opera 8.0+ :-)

Permanenter Link

ChrisB
am 22.12.2008 - 21:42

Da der mobile Safari-Browser aber auf das Medienattribut handheld nicht reagiert

handheld waere die hierfuer explizit vorgesehene Meoglichkeit gewesen, um ein alternatives Stylesheet zur Anwendung zu bringen.

Dies ist aber in der Vergangenheit wohl hauptsaechlich fuer haessliche "text only"-Varianten benutzt worden. Die Browserhersteller, die einen "so gut wie vollwertigen" Browser fuer Mobilgeraete herstellen, wollten dann aber andererseits darauf auch das "echte" Internet anzeigen, und keine verkrueppelte Version - und interpretieren deshalb handheld jetzt mal lieber "vorsichtshalber" gar nicht.

Und wieder mal erschlaegt die Praxis die gar nicht mal so dumm erdachte Theorie. Mit dem Ergebnis, dass jetzt solche Kruecken wie "Browser Sniffing" oder schlimmeres wieder aufleben (muessen).

Permanenter Link

Die Kommentare sind geschlossen.