Als Tim Berners-Lee im Jahre 1990 das World Wide Web erfand, gab es nur einen Browser. Auch die darauf folgenden 5 Jahre wurden WWW-Seiten überwiegend von Computern mit WWW-Browsern durchsurft. Seit dem auch andere Geräte das Internet bevölkern, wird das Thema Accessibility für Webdesigner immer interessanter.
Accessibility (deutsch : Erreichbarkeit/Zugänglichkeit) im Webdesign bedeutet Informationsangebote so zu gestalten, dass sie möglichst viele Benutzer abrufen können.
Das Thema Accessibility hat naturgemäß einen sehr technischen Charakter, da es darum geht, mit welchen Geräten Informationen abgerufen werden und wie diese genau funktionieren. Die Kenntnis der Funktionsweisen von Server- und Client-Geräten ist notwendige Voraussetzung für die Gestaltung "erreichbarer" Webseiten.
Konkret stehen zwei Fragen im Vordergrund:
- Welche Geräte können im WWW surfen?
- Welche Geräte werden in absehbarer Zukunft dazukommen?
Zur ersten Frage: Es gibt u. a.
- Computer mit den verschiedensten Browsern
- Handliche, tragbare Geräte jeglicher Art ( Handys, Palmtop-Browser etc.)
- 10 Jahre alte Systeme mit Windows 3.1 + Netscape 2.0 oder DOS bzw. Unix (und Derivate) im Textmodus
- Internet-Cafes mit Linux- oder Free-BSD-Arbeitsplätzen
- Sehbehinderte Surfer mit Screenreadern (5) oder Brailletastatur
- Drucker ! (Website-Infos werden nicht selten ausgedruckt und vom Papier gelesen)
Zur zweiten Frage:
- Auch in naher Zukunft wird es alte Browser im Internet geben
- Gewöhnliche Haustelefone werden ein kleines Farb-Display mit integriertem Browser und Einwahlprogramm besitzen. Erste Modelle sind bereits auf dem Markt
- Spielkonsolen mit WWW-Zugang werden immer häufiger vorkommen
- Der akustische Kanal wird durch Innovationen wie das Web-Radio, Sprachverarbeitung für Websites an Bedeutung gewinnen
- ... und bestimmt noch einiges mehr.
Das hervorstechendste Argument für Accessibility im Webdesign ist jedoch zweifellos die Berücksichtigung von Anwendern mit Behinderungen. Das World Wide Web sollte mit der selben Selbstverständlichkeit, mit der eine Gesellschaft Behindertenparkplätze oder -Aufzüge einrichtet, die Belange dieser Anwender berücksichtigen. Erfreulicherweise beschäftigen sich bereits viele Menschen mit diesem Thema.
Unter Berücksichtigung dieser Accessibility-Aspekte, entscheiden sich technische Glaubenskriege wie "Frames - Ja oder Nein ?" oder "Plugins - Ja oder Nein ?" quasi von selbst: In beiden Fällen "Nein" oder nur mit Angebot einer Alternative, die sich an den kleinsten gemeinsamen technischen Nenner (siehe unten) hält.
Einige der Nicht-PC-Geräte besitzen Browser, die weder mit Frames, noch mit Plugins umgehen können.
Das heißt nicht, dass JavaScript, Flash oder Frames nicht eingesetzt werden sollten; es bedeutet, dass derlei Features zum Abruf einer Information nicht zwingend notwendig sein sollten.
Mit einer einzigen Version eines Informationsangebots wird eine 100%ige Accessibility zu allen möglichen Clients nicht zu gewährleisten sein. Dafür liegen derzeit die Standards zu weit auseinander. Ein Webdesigner kann jedoch Prioritäten setzen und entscheiden:
- Ob er durch Einsatz einer fortgeschritteneren Webtechnik potentielle Besucher von vornherein ausschließen möchte,
- Ob er die Informationslücke - die schon zwischen Menschen mit und ohne Internet-Zugang herrscht - weiter dadurch vergrößern möchte, in dem er Angebote schafft, die nicht von behinderten Anwendern wahrgenommen werden können oder von jenen, die nicht mit dem neuesten Stand der Technik gerüstet durchs Internet surfen (es gibt nicht wenige Schulen und Bildungseinrichtungen, die mit gespendeten 486'ern + Win 3.1 und Netscape 3.0 ins Internet gehen).
Manche argumentieren, "dass es nicht nötig sei, alle möglichen Clients zu berücksichtigen, weil in den Logfiles sowieso keine exotischen Clients auftauchen". Diese Exoten tauchen aber vielleicht deshalb so selten in den Logfiles auf, weil die meisten Webseiten sie nicht berücksichtigen. Wenn eine Webseite erst einmal "accessible" ist, sieht man auch die verschiedensten Besucher (Atari Computer, Lynx etc.) in den Logfiles.
Praktisches Fallbeispiel
Dieses Beispiel zeigt die Entscheidungsstrategie bei der Lösung der Frage:
"Wie viel Versionen zu einem Informationsangebot benötige ich, um sie für bestimmte Clients erreichbar zu machen?"
Setzen wir voraus, dass die Website für folgende Clients erreichbar sein soll:
- Ältere Browser
- Moderne Browser mit vorinstallierten Plugins
- Palmtops
- Screenreader, Brailletastaturen
- Drucker
Schritt A : Funktionsmengen bilden
Die Funktionsmenge ist nichts weiter als ein Auflistung der Features/Funktionalitäten der WWW-Clients. Funktionsmengen der obigen Clients wären:
- Ältere Browser:
{HTML 2.0, keine Frames, 256 Farbpalette, keine Plugins, kein JavaScript} - Moderne Browser mit vorinstallierten Plugins:
{DHTML, teilweise XML, Frames, Flash, Real Audio und div. andere Plugins vorinstalliert oder leicht installierbar, Java und JavaScript, Active Skripting- was jedoch nicht bei allen Usern aktiviert ist.} - Palmtops:
{z.T. keine Farben (2 Farben oder Grauabstufung), kleineres Display, Positivdarstellung besser (als weiße Schrift auf schwarzem Hintergrund), kein Java, JavaScript oder Plugins} - Screenreader, Brailletastaturen:
{HTML 3.2, keine Plugins, Javascript hängt vom verwendetem Browser ab} - Drucker:
{HTML 3.2, schwarz/weiß und idealerweise höchstens 4 Grauabstufungen}
Schritt B : Obermenge der technischen Anforderungen bilden
Um zu bestimmen mit welchen Techniken eine Webseite realisiert werden soll, bildet man die Obermenge der technischen Anforderungen. Die Luxusklasse an Funktionskomfort bieten die modernen PC-Browser wie Netscape 4.7x oder MSIE 5.x. Durch Abwägen und Verzicht auf einige Features wird nun die Obermenge der technischen Anforderungen gebildet.
Nehmen wir an, wir können auf Features wie DHTML-Animationen, XML, JAVA, Active Scripting und PlugIns verzichten, möchten aber an einigen Stellen optional Animationen anbieten und entscheiden uns für den Einsatz von Flash3.
Die Obermenge der technischen Anforderungen (OT) ist also:
OT = {HTML Version < 4.0, JavaScript, Flash3, 16bit Farben}
Schritt C : Technischen kleinsten gemeinsamen Nenner bilden
Der Kern jeder Accessibility-Überlegungen ist es, sich klarzumachen, welche Funktionalitäten von allen Clients unterstützt werden.
Der technisch kleinste gemeinsamer Nenner ist die Menge an Techniken, mit der alle Clients umgehen können.
In unserem bisherigen Beispiel wäre der technisch kleinste gemeinsame Nenner (tKGN):
tKGN = { HTML 2.0, 2 Farben und schwarz auf weiß}
optional: JavaScript
Schritt D : Definition der verschiedenen Versionen
Bisher wurde folgendes ermittelt:
OT = {HTML Version < 4.0, JavaScript, Flash3, 16bit Farben} und
tKGN = { HTML 2.0, 2 Farben und schwarz auf weiß}
optional: JavaScript
OT und tKGN widersprechen sich bzw. die Implementierung einer einzigen Version des Informationsangebots erfüllt nicht alle technischen Anforderungen.
Damit erhält man für dieses Fallbeispiel mindestens 2 Versionen : eine OT-Version und eine tKGN-Version.
Man weiß jetzt, das man für die High-End-Version Features wie HTML 3.2, JavaScript, Flash3, 16bit Farben und für alle anderen Clients HTML 2.0, 2 Farben und schwarz auf weiß benötigt.
Die Fragestellung "Wie viel Versionen zu meinem Informationsangebot benötige ich, um sie für bestimmte Clients erreichbar zu machen?" wäre jetzt beantwortet.
Schritt E : Abgleich des tKGN mit allen übrigen Funktionsmengen
Wir haben in Schritt A fünf verschiedene Funktionsmengen ermittelt. Die zweite Funktionsmenge (Moderne Browser) beinhaltet schon die Features, die auch in unserer Obermenge der technischen Anforderungen (OT) stehen. Damit muß tKGN nicht mit Funktionsmenge 2 verglichen werden.
Man muss nun entscheiden, ob die Reduzierung der restlichen Funktionsmengen der Client-Typen
1. Ältere Browser
3. Palmtops
4. Screenreader, Brailletastaturen
5. Drucker
auf den tKGN (HTML 2.0, 2 Farben und schwarz auf weiß) befriedigende Ergebnisse bringt. Kurz gesagt die Frage lautet: "Ist eine HTML 2.0 Version mit schwarz auf weiß Darstellung akzeptabel für ältere Browser, Palmtops, sehbehinderte und Drucker?"
Wäre die Antwort auf die Frage in einem der Fälle "Nein", z.B. "Eine HTML 2.0 und s/w-Darstellung ist inakzeptabel für ältere Browser", dann hätte dies eine dritte Version zu Folge.
Ist die Antwort "Ja", so bleibt es bei der Entscheidung, 2 Versionen zu implementieren.
Hätte dieses Beispiel zusätzlich die Anforderung gehabt, Handys zu bedienen, wäre als dritte Version eine WML-Version erforderlich gewesen. Denn WML ist weder mit OT, noch mit tKGN erfüllt.
In diesem Zusammenhang sei noch kurz angemerkt, dass serverseitig ausgeführte Script-Sprachen wie ASP, PHP, iHTML oder Serverside JavaScript per definition keine besonderen technischen Anforderungen an einen Client stellen. Unsere Webseiten können daher selbst mit dem Steinzeit-Browser Lynx begangen werden.
Zurück zum Fallbeispiel; man kommt also zum Schluss, zwei Versionen zu implementieren. Bei der Umsetzung der optionalen Features wie Flash oder JavaScript kommt man schnell mit den Themen PlugIn-Erkennung, JavaScript-Erkennung oder auch Browser-Erkennung in Berührung. Da die kompletten Ausführungen zu diesem Thema den Rahmen des Artikels sprengen wuerden, sei hierzu nur kurz folgendes angemerkt :
Zum Thema Browsererkennung gibt es viele Ressourcen im Netz (10). Ein häufiger Fehler in diesem Zusammenhang ist, dass Webdesigner manchmal nur zwischen Netscape und MSIE unterscheiden. Opera-User und andere erhalten häufig keine Alternative. Zwar kann sich der 4'er Opera auch als Netscape oder MSIE identifizieren, fraglich bleibt jedoch, wie dann die Darstellung ist (besonders bei CSS Anweisungen) und wie viel Anwender diese Funktion aktiviert haben.
Um zu erkennen, ob JavaScript aktiviert ist kann man im einfachsten Falle so vorgehen: Neben der zu verarbeitenden JavaScript-Funktion setzt man einen Meta-Refresh-Tag wie
in den -Bereich der Seite. Sollte JavaScript deaktiviert sein, würde der Anwender nach 5 Sekunden automatisch auf eine alternative Seite ohne JavaScript geleitet.
Ein zuverlässige Erkennung des Flash-Plugins erhält man unter http://www.flashworker.de/ und unter http://www.moock.org/webdesign/flash/.
Zusammenfassend ist Accessibility also ein Thema, dass immer mehr ernst zu nehmen ist. Das WWW ist dabei, alles zu vernetzten. Vom Toaster über den Hausserver im Keller bis zum Kühlschrank wird irgendwann mal alles im Netz hängen. Je mehr Geräte dazukommen und je unterschiedlicher die Standards sind, desto aufwendiger wird es in Zukunft werden, ein universell erreichbares Informationsangebot zu gestalten.
