Javascript, ja oder nein?

[molily]

Hallo,

Was ich mich die ganze Zeit bei der Diskussion Frage, warum ein Shop mit JS schneller fertig und billiger sein soll als einer ohne?

Ist es nicht eher umgekehrt?

Kann man generell nicht sagen. Oft ist es von Vorteil, gewisses Kundenverhalten zu antizipieren und diese, vom Kunden vermutlich benötigten Daten, bereits in js-arrays, variablen oder wo auch immer parat zu haben, ohne jedesmal wieder einen serverrequest senden zu müssen. Spart auch Bandbreite.

Genau, besonders »in« ist ja das dynamische Nachladen von Daten vom Server via JavaScript.

Nur ging der Thread gegen Ende zu eher um andere Themen als nur um JS. Ich sehe, js richtig und dosiert eingesetzt, einen Vorteil für den Shopbesucher, ich sehe eher nicht, inwieweit js die Accessibility behindern könnte, anyway, das scheint mir ein anderes Thema zu sein...

Meinst du das jetzt ernst?

Wenn du eine Webanwendung so aufbaust, dass sich das Interface vor allem über JavaScript ändert, anstatt dass serverseitig-dynamisch weitesgehend in sich statische Seiten generiert werden, funktionieren viele essentielle Grundkonzepte der Zugänglichkeit nicht. Das einfache Lesen von Webseiten z.B. mit Screenreadern beruht eben darauf, dass es eine statische Seite gibt, in der sich der Benutzer langsam zurechtfinden kann. Er erlebt die Site also eher als ein Hypertext, durch das er sich über Hyperlinks, Buttons, Formulare usw. selbstbestimmt navigieren kann. Wenn allerdings Interaktion darüber stattfindet, dass JavaScript irgendwelche Teile des bestehenden Dokuments austauscht, schlägt diese Navigation, die Interaktion über immer neue Dokumente realisiert, fehl. Selbst wenn die alternativen Zugangsarten JavaScript und das dynamische Ändern eines Dokuments prinzipiell unterstützen - denn in der Accessibility geht es vor allem um besondere abweichende bzw. eingeschränkte Zugangsarten -, ist damit noch längst nicht gesagt, dass diese Änderungen beim Benutzer ankommen und dieser damit so einfach zurechtkommt wie mit statischen Seiten. Für viele Benutzer sind Webanwendungen, die auf JavaScript setzen, sicher bequemer, ebenso können solche Webanwendungen durchaus für bestimmte Gruppen, auf die die Accessibility zielt, zugänglich gestaltet werden, aber für Benutzer mancher alternativer Zugangsarten stellen sie Barrieren dar.

GMail ist ein Beispiel für eine Webanwendung, die bei der Kommunikation mit dem Server stark auf JavaScript setzt. Klar, die konstruierte Zielgruppe besteht vor allem aus Menschen ohne motorische, kognitive oder sinnliche Einschränkungen mit High-End-Zugängen, die keinerlei Ansprüche an die Anpassungsfähigkeit und alternative Bedienbarkeit haben. Daher war GMail z.B. für Screenreader, Kleingeräte wie auch für gängige Browser ohne XMLHttpRequest-Unterstützung unbenutzbar, Tastaturnavigation ging nicht, Linearisierbarkeit konnte man vergessen, das Interface brach mit verschiedenen assistiven Techniken. Schlichtweg das Musterbeispiel einer Webanwendung, die vielen das Lesen, Verschicken und Verwalten von E-Mails vereinfachte, also mit seinem neuen Konzept und dem einfachen und funktionalen Interface durchaus benutzerfreundlich war, aber alles andere als zugänglich bzw. kompatibel war für alle Menschen bzw. alle Zugangstechniken jenseits der konstruierten Zielgruppe bzw. der vorausgesetzten Techniken. Bei allem Lob hat Google diese Kritik berücksichtigt, heute gibt es eine technisch anspruchslose, vergleichsweise universell zugängliche HTML-Version. Weniger für den Extremfall des Blinden mit Screenreader, als für den Anwender bzw. für die bestimmten Anwendungssituationen, der bzw. die die hohen Voraussetzungen nicht vollständig erfüllt.

Mathias