Artikel-Hilfsmenü

Kommentieren

Freitag, 16. Oktober 2009 – aktualisiert am Freitag, 6. August 2021

Webdesign · JavaScript

Kapitelverzeichnis

• 1 Ist JavaScript böse?
• 2 JavaScript ist "unreif" für Screen Reader.
• 3 JavaScript - no problem?
• 4 "Gutes" JavaScript
  • 4.1 Das Drei-Schichten-Modell
  • 4.2 Graceful Degradation
  • 4.3 Progressive Enhancement
• 5 Best Practice (JavaScript wird erwachsen.)
• 6 Testen, testen, testen!
• 7 Beispiele
  • 7.1 Böse
  • 7.2 Gut
    • 7.2.1 Das Script zum Beispiel (neue Seite)

Die WCAG 1.0 und die BITV schreiben vor:

6.3 Sorgen Sie dafür, dass Seiten verwendbar sind, wenn Scripts, Applets oder andere programmierte Objekte abgeschaltet sind oder nicht unterstützt werden.

Diese Vorschrift wurde häufig fehlinterpretiert, und fälschlicherweise geschlussfolgert:
"JavaScript ist nicht barrierefrei."

Mit JavaScript wurde und wird aber auch tatsächlich viel Unfug getrieben:
- ungefragt und unerwartet neue Fenster (popups) öffnen,
- Browser in die Vollbildanzeige zwingen,
- das Kontextmenü deaktivieren,
- die Statusleiste missbrauchen, etc.

Schlimmer: Flyout-Navigationsmenüs und andere MouseOver-Ereignisse, die nur mit der Maus ausgelöst werden können, und Webseiten für Tastaturnutzer unbenutzbar machen.

Welchen Schaden kann JavaScript anrichten?

Mathias Schäfer hat unter dem Pseudonym molily dazu eine schöne Abhandlung erstellt.

molilys Fazit:

Wenn Sicherheitslücken in Browsern entdeckt werden, ist in den meisten Fällen JavaScript im Spiel.

Anmerkung: Die richtige Schlussfolgerung daraus lautet aber nicht: JavaScript deaktivieren! sondern: Browser updaten!

Das schlimmste denkbare Szenario ist Cross Site Scripting (XSS). Eine Beschreibung, wie XSS funktioniert, einschließlich einer Demo, hat Heise online gestellt.

Das größte Sicherheitsrisiko von JavaScript ist die Abhängigkeit von globalen Variablen, insbesondere von impliziten globalen Variablen.

Quelle: JSLint

Fazit: JavaScript selbst ist nicht böse, aber es kann von bösen Buben als Werkzeug verwendet werden, Böses anzustellen.

Um diesen bösen Buben das Handwerk zu legen, muss der Webworker die möglichen Fehlerquellen kennen, und durch "richtiges" Scripting vermeiden.

Was, wenn JavaScript nicht verfügbar oder deaktiviert ist?

Sind nicht-JavaScript-fähige UAs (Browser) noch im Einsatz? Wohl eher nicht, wenn man mal von Textbrowsern wie Lynx absieht.

Und wenn JavaScript deaktiviert ist? Nun, die "JavaScript-Deaktivierer" (z. B. mittels der Firefox-NoScript-Extension) sollten wissen, was sie tun.

Das, in den meisten aktuellen Screen Readern, wohl am häufigsten auftretende "Fehlverhalten" dürfte sein, dass der Screen Reader Nutzer klickt und erwartet, dass "etwas passiert": entweder auf eine neue Seite zu kommen bzw. zum ausgewählten Inhalt zu springen. In vielen Fällen wird jedoch erstmal nichts passieren.

Quelle: protofunc.com/category/javascript/ajax

Ein wenig Hintergrundwissen zu Screen Readern

Warum passiert anscheinend (für Screen Reader Nutzer) nach einem Klick nichts?

• Screen Reader lesen – entgegen landläufiger Meinung – nicht den Bildschirm! Vielmehr legt der Screen Reader eine virtuelle Kopie einer Seite an, und arbeitet dann mit dieser Kopie. Diese Kopie wird durch JavaScript-Manipulationen des DOM nicht aktualisiert. Die Kopie weiß also nicht, dass "etwas passiert" ist.
• Unterschiedliche Fokus Verfolgung:
  Bildschirm – Sprachausgabe – Braille-Zeile
• Screen Reader haben umfangreiche Konfigurationsmöglichkeiten. Der Webworker kann sich noch weniger als bei Browsern darauf verlassen, eine Standardkonfiguration anzutreffen.

WAI-ARIA - und alles wird gut?

aria-live-Regionen sind ein mächtiges Werkzeug, um auch Screen Reader Nutzern zu signalisieren, dass "etwas passiert" ist.

Beispiel: Ein AJAX Chat signalisiert einkommende Nachrichten mit einem Signalton. Wenn ARIA verfügbar ist, wird (zusätzlich) die einkommende Nachricht selbst vorgelesen. – Progressive Enhancement.

Aktuell unterstützen leider nur wenige Screen Reader ARIA live-regions:
Jaws 10.0 mit Firefox 3.x, und der kostenlose Screen Reader NVDA.

• WCAG 2.0 macht in der Neufassung deutlich, dass JavaScript an sich nicht böse ist, und kein Kriterium für oder gegen Barrierefreiheit darstellt. Sofern die entsprechenden Forderungen der WCAG 2.0 selbst erfüllt sind.
• Das Modul BIK BITV-Test der DIAS GmbH schreibt sogar für einen zukünftigen BITV 2.0 Test explizit vor: "JavaScript ist aktiviert"
• Das Web 2.0 funktioniert ohnehin nur mit JavaScript richtig.
• JavaScript ist häufig das Mittel der Wahl, um Flash zugänglicher zu machen. Beispiel: Steuerung eines Flash-Players durch externes JavaScript.

Wenn es die "Großen" tun - kann man JavaScript also bedenkenlos einsetzen?

Unobtrusive JavaScript = unaufdringliches? anständiges? JavaScript

Das Drei-Schichten-Modell

Das Wissen um die Notwendigkeit, Stuktur (HTML) und Design / Präsentation (CSS) zu trennen, ist inzwischen glücklicherweise weit verbreitet. Nun separieren wir auch noch die Verhaltensebene (JavaScript).

• Wikipedia definiert:

  Separation of functionality (the "behavior layer") from a Web page's structure/content and presentation.

  
  Beispiel:
  Aus <input type="text" name="date" onchange="validate(this);" />
  wird <input type="text" name="date" />
  Ein Code Beispiel, wie diese Trennung funktioniert, wie man die Verhaltensebene separiert, d. h. das JavaScript aus dem HTML-Markup in eine externe JavaScript-Datei auslagert, liefert Wikipedia selbst.
  
  In kurzen Worten: Nach dem Laden der Seite (onload) wird eine Funktion aufgerufen, die alle input-Tags mit dem Namen "date" sucht, und diesen Tags den onchange Event-Handler hinzufügt.
  
  
• A List Apart: Articles: JavaScript MVC

  separating code into Model, View, and Controller

  
  M V C: So wird das Drei-Schichten-Modell bei A List Apart genannt. Ein guter Aufsatz zur Vertiefung dieses Themas.
  
  
• http://ichwill.net

  JavaScript ist ein mächtiges Werkzeug um Webseiten mehr Leben einzuhauchen und sie für den Besucher einfacher bedienbar zu machen.
  - Es steht über der Seitenstruktur "Was ist dieser Text?" (HTML)
  - und dem Seitenstil "Wie soll das Element dargestellt werden" (CSS).
  - JavaScript ist die dritte Ebene - das Verhalten "Was macht dieses Element?"

• Frameworks wie jQuery, Prototype oder MooTools können hilfreich sein beim Separieren der Verhaltensebene.
  Aber Achtung! Verwenden Sie keinen Code, den Sie nicht verstehen.

Die ideale Seitenstruktur

Russ Weakley verwendet in seinem Webstandards-Workshop (deutsche Übersetzung) die ideale Seitenstruktur folgendes Diagramm, um die Trennung der 3 Schichten zu illustrieren:

Graceful degradation = anmutige? geschmeidige? Verschlechterung?

Die Fähigkeit eines Systems, kontrolliert auf Fehler zu reagieren.
Mit Graceful degradation wird die Eigenschaft eines (Computer-)Systems bezeichnet, auf Fehler und unerwartet eintreffende Ereignisse sicher und angemessen zu reagieren: Ein Fehler im Einzelsystem reduziert die Funktionalität des Gesamtsystems nur schrittweise, etwa durch eine verminderte Qualität oder einen reduzierten Funktionsumfang.
Beispiele:

• Alternativtexte für Grafiken
• Anstelle von Flash-Filmen Bilder anzeigen.
• Ebenso kann in JavaScript so entwickelt werden, dass DOM-Operationen bei nicht verfügbarem JavaScript durch ein Neuladen der Seite ersetzt werden.

Progressive Enhancement = schrittweise Verbesserung = (gedankliche) Umkehrung des Prinzips graceful degradation

Progressive Enhancement bei Wikipedia

Progressive Verbesserung (engl. progressive enhancement) beschreibt eine Methode im Webdesign, die Barrierefreiheit, semantische Auszeichnung und Trennung von Information und Präsentation beinhaltet, um eine Website auch für Endgeräte benutzbar zu machen, die nur über eingeschränkte Funktionen (JavaScript-/CSS-/Flash-Unterstützung) verfügen. Die Philosophie dahinter ist, dass Webseiten grundsätzlich mit jedem Webbrowser und jeder Art Internetverbindung in ihrer grundlegendsten Form - der Bereitstellung von Information - zugänglich sein sollten und Benutzern mit besserer Bandbreite und fortgeschritteneren Browsern mit erweiterter Funktionalität eine verbesserte Version der Seite dargestellt wird.

Progressive Enhancement bedeutet, ein System so zu konzipieren, dass es a priori nicht zu einem Fehlverhalten kommt.

Beispiele für Progressive Enhancement gefällig?

• WebKit basierte Browser wie Safari und Google Chrome können mit Skiplinks nicht ohne weiteres umgehen. Mit etwas JavaScript gewürzt klappt das jedoch, z. B. auf dieser Seite hier. Erklärung
• Externe Links erkennt man im Markup an "http".
  Dies kann man nutzen, um per JavaScript allen externen Links eine Klasse zuzuweisen, z. B. class="ex", sowie den Text "externer Link: ".
  In einem letzten Schritt werden alle Links mit der Klasse "ex" per CSS aufgewertet:
  Der Text "externer Link: " wird versteckt und nur Screen Readern gezeigt, und dafür wird ein passendes Symbol als background-image vor den Link gesetzt.
• Das ganze Konzept von WAI-ARIA ist ein Paradebeispiel für Progressive Enhancement

Besser als Chris Heilmann in seinem Vortrag (in englischer Sprache) JavaScript "Best Practices" kann man es nicht darstellen.

Die Quintessenz dieses Vortrags:
JavaScript wird erwachsen. Aus einem Werkzeug für Spielereien wird ein Werkzeug zur Erstellung ernsthafter Anwendungen.

JavaScript Best Practices gleichen häufig denen in anderen Programmiersprachen:
– Kapselung und Trennung der Ebenen,
– Vermeidung von globalen Variablen,
– Sinnvolle Namenskonventionen,
– Verwendung von geeigneten Entwurfsvorlagen,
– und von systematischen Tests.
Diese Grundsätze sind unverzichtbar bei der Entwicklung großer Anwendungen, wurden aber in der JavaScript-Programmierung bisher zu wenig beachtet. Die Beachtung dieser Grundsätze ist unverzichtbar, wenn JavaScript den Übergang von einer "Spielzeug-Sprache" zu einem Instrument für ernsthafte Entwicklung schaffen soll.

Testen Sie Ihre Scripts, bevor es Ihre Kunden tun!
Der kleinste Scriptfehler kann ihre ganze Site für einen bestimmten Client unbrauchbar machen.
Erarbeiten Sie sich eine Strategie, wie Sie mit möglichst wenig Aufwand bei jeder Änderung alle notwendigen Tests durchführen können.

Werkzeuge, um das Script selbst auf Fehlerfreiheit zu testen (debuggen)

• Die JavaScript-Konsole von Firefox
• Natürlich braucht der IE mal wieder eine Sonderbehandlung. Der IE verwendet die Microsoft-eigene, proprietäre Entwicklung JScript. Und die will natürlich auch separat debugged werden. Wenigstens bringt die neueste Version IE 8 endlich einen brauchbaren Debugger mit.
• JSLint – der "Validator" für JavaScript.

  Warning! JSLint will hurt your feelings.

  JSlint deckt gnadenlos das größte Sicherheitsrisiko, nicht initialisierte globale Variablen auf.

Die Funktion des Scripts und die Barrierefreiheit testen

• Windows - Mac - Linux. Pro Betriebssystem jeweils mindestens 5 Browser. Das macht 15 Konfigurationen, die man zum Testen vorhalten müsste.
  Eine elegante Alternative - Browserpool - Websites in allen gängigen Browsern live testen - ist leider seit längerer Zeit offline.
• Nicht zu vergessen: Handys und PDAs.
• Maus weglegen! Ein einfacher, aber wirkungsvoller Test, der alle offensichtlichen Barrieren aufdeckt, die Tastaturnutzer antreffen könnten.
  Hinweis: Alle Screen Reader Nutzer sind Tastaturnutzer!
• Funktionstests mit Screen Readern sind letztlich unverzichtbar.
  • Optimal: Test durch blinde Screen Reader Nutzer mit unterschiedlichem Kenntnisstand und unterschiedlicher Ausrüstung.
  • Alternativ, aber nicht unumstritten: Selbst testen mit Jaws und Selbst testen mit NVDA (Umstritten, da Screen Reader Nutzer letztlich andere Strategien anwenden als sehende Tester.)
• Last but not least: JavaScript ausschalten – Stichwort: Graceful degradation.

Wie so oft: Schlechte Beispiele sind leichter zu finden als gute.
Nein, ich werde jetzt nicht eines der zahlreichend Dreamweaver-DropDown-Menüs zeigen, die die Existenz von Untermenüs nur mit aktiviertem Javascript verraten. Im Gegenteil: Ein Menü, das nur durch Deaktivieren! von Javascript zugänglich wird – böses JavaScript in Hochform.

Die Google-Webmastertools setzen ein Menü mit "Klappfunktion" ein. Screenshot:

Nach dem Anklicken der mit einem Pluszeichen (Grafik) bezeichneten Überschriften öffnet sich eine Art Untermenü. Screenshot:

Leider sehen diese Überschriften nur aus wie Links. Sie sind aber keine Links, und daher mit der Tastatur nicht erreichbar. Wie so oft: Eine einzige Unsauberkeit, und die Seite ist für eine ganze Benutzergruppe nicht bedienbar! Erst wenn man JavaScript deaktiviert, wird das Menü aufgeklappt und mit der Tastatur bedienbar. Screenshot:

Ein gutes Beispiel?

Schauen Sie sich mal das Kapitelverzeichnis am Anfang dieses Artikels an. Auch dort gibt es die "Klappfunktion". Erkennbar an [+] (erweitern) (Natürlich nur, wenn JavaScript verfügbar ist.) Und wenn Ihr Screen Reader ARIA unterstützt (empfohlen: Jaws 10.0 oder NVDA und Firefox ab Version 3) wird nach Klick auf den Link die Änderung zu [-] (reduzieren) korrekt angesagt.

Klar, dieses Beispiel ist konstruiert, und dient hier nur der Demonstration. Es gibt sinnvollere Anwendungen für die "Klappfunktion".
Die hier gezeigte Methode, ein dropdown-Menü zu erstellen, muss keineswegs besser sein, als andere Techniken. Es soll nur eine Anwendung der in diesem Artikel vorgestellten Methoden aufgezeigt werden.

Detaillierte Beschreibung des Scripts auf einer eigenen Seite.

Weitere Quellen

• Dirk Ginader: Accessible Javascript with and without WAI ARIA

JavaScript Grundlagen

• SELFHTML - immer noch das Standardwerk
• Barrierefreies JavaScript