Web-Accessibility (2)

Im ersten Teil ging es darum, Webseiten für nicht-PCs und Menschen mit Behinderungen zu optimieren. Der zweite Teil untersucht die Software: welche Ratschläge hat das W3C für Browser und andere Anwendungen parat?

Es ist schon relativ selten, das sich eine Organisation, die sich Web-Standards verschrieben hat, auch mit der Web-Software beschäftigt. Bisher beschränkte sich die Beziehung des W3C mit der Software hauptsächlich in den Listen, die sich z.B. auf den CSS-Seiten befinden.

Zugegeben sind diese Richtlinien für den Atari nicht ganz so wichtig, da es keine Screenreader für den ST gibt. Auf der anderen Seite gibt es, und das ist kaum bekannt, sogar eine sprechende Atari-Textverarbeitung namens "Talker".

In erster Linie richtet sich das W3C mit seiner Richtlinie nicht an Malprogramme oder Ego-Shooter, sondern an Web-Utilities, die Benutzern bei dem Erstellen von Web-Inhalten unterstützen. Dabei wird betont, das es genauso wichtig ist, das alle Internet-Inhalte erstellen wie anschauen können. Deshalb müssen auch die Tools von allen benutzbar sein.

Unter dem Überbegriff Web-Utilities versteht das W3C natürlich die HTML/XML-Editoren, Tools, die Web-Formate speichern können, Konvertierungsprogramme und Autorensysteme für Multimedia-Formate.

Nun ist mittlerweile so ziemlich jedes Programm im Sinne des W3C Internet-fähig, aber die Richtlinien richten sich hauptsächlich an die Programme, die auf die Internet-Fähigkeit abgestimmt und optimiert sind.

Web-Tools sollen laut dem W3C standardmäßig Code erzeugen, der den W3C-Standards entspricht - eine sicher nicht ganz unberechtigte Forderung, denn noch immer gibt es viele Tools, die schlechten HTML-Code erzeugen. Auch der Dokumentation soll erhöhte Aufmerksamkeit geschenkt werden, damit nicht jeder gleich die W3C-Seiten besuchen muss, um zu erfahren, was "Accessibility" bedeutet.

Allerdings kollidieren manche W3C-Standards mit dem derzeitigen Entwicklungsstand der Atari-Browser. So wird häufig die Verwendung von Style-Sheets empfohlen, u.a. auch für die Tabellenbreite und -höhe. Die Atari-Browser unterstützen jedoch (noch) kein CSS - HighWire kennt einige Stylesheet-Angaben in der Form style="..." und erst die angekündigte Version 2.0 von Adamas beherrscht CSS. Um ganz Standardkonform zu sein, könnte das Programm sogenannte Kompatibilitätsoptionen anbieten.

Keyboard

Erster Punkt beim W3C ist die durchgehende Unterstützung der Tastatur. Grundsätzlich sollte jede Funktion über die Tastatur erreichbar sein und zwar auf drei Wegen:

Es muss möglich sein, mit der Tastatur Text zu markieren und zu kopieren. In den W3C-Dokumenten wird zwar nichts über die Standard-Shortcuts gesagt, aber es kann sicherlich nicht schaden, wenn die Programme ähnliche Shortcuts verwenden. Eine kleine Liste findet sich in Tabelle 1. Auf dem Atari wird - anders als beim Windows-PC - die Tastenkombinationen nicht namentlich aus ausgeschrieben: statt Steuerung/Control schreiben Atari-Programmierer einfach ^. Das hat natürlich den Vorteil, das nicht solche Menüungetüme wie "Steuerung + Umschalttaste + U" die Menüs aufblähen.

Der Fokus des Cursors soll mit der Tastatur verschiebbar sein - darunter fällt die Tabulator-Taste, mit der man auf das nächste Eingabefeld springen kann.

Die Installation, Konfiguration und Deinstallation muss auch per Software möglich sein.

Auf dem Atari bietet es sich sehr an, mit einer modernen GEM-Library zu arbeiten. Damit sehen die Programme nicht nur modern aus - Libraries wie WinDom oder die cflib haben auch noch mehr Funktionen, um Dialoge per Tastatur zu bedienen.

Text-Nachrichten

Jedes Element, das kein Text ist, z.B. ein Icon oder ein Sound sollte mit einer Text-Erklärung begleitet werden. Dies ist für alle Benutzer interessant, denn wenn die Anwendung nur ein gesampletes "Plopp" ausgibt, wenn ein Fehler eingetreten ist, ist das nicht auf dem ersten Blick verständlich. Auch hier wäre es denkbar, Benutzern die Wahl zu lassen, zwischen nur akustischen Hinweisen, akustisch+textuell oder gar keinen Hinweisen. Natürlich sollten sich diese Hinweise an die Systemstandards halten - auf dem Atari ist eine Ausgabe direkt in die Menüleiste ein Sakrileg.

Bezieht sich der Hinweis auf ein offenes Fenster, könnte die Information in der Infozeile des Fensters angezeigt werden. Damit hält der Hinweis auch nicht den Benutzer auf. Sehr wichtige Meldungen sollten aber nach wie vor in einer Alert-Box erscheinen.

Anzeige

Bei WYSIWYG-Editoren für Formate wie HTML, XML und SMIL ist neben der grafischen Ansicht eine Text-Ansicht praktisch. Generell sollte jede Datei, die als MIME-Typ "text" hat, auch als Quelltext darstellbar sein.

Diese Textansicht ist als letzte Ausweichmöglichkeit gedacht, wenn durch die anderen Funktionen des Programms nicht klar wird, wie das Dokument aufgebaut ist. Davon profitieren natürlich auch Blinde und Sehbehinderte, die mit einem rein grafischen Programm wenig anfangen können.

Zur weiteren Verbesserung der Textansicht schlägt das W3C vor, die Ansicht mit zusätzlicher Funktionalität auszustatten wie z.B. Suchen im Text oder das Hervorheben von Links.

Ist eine Text-Ansicht im Programm enthalten, sollte der Benutzer jederzeit die Schriftgröße, -Art und -Farbe ändern können, ohne dass der Quelltext geändert wird. Ein Beispiel dafür ist die Zoom-Funktion vieler Textverarbeitungen, bei der Text größer wird, aber immer noch die gleiche Größe in Punkt hat.

Anzeige von optionalen Elementen

Viele kennen mit Sicherheit das Alt-Attribut für Bilder und andere Elemente. Damit wird ein Ersatztext für ein Bild oder ein anderes Objekt definiert. In eine ähnliche Richtung zielt das Title-Attribut.

Beide Attribute haben gemeinsam, das sie im Normalfall nicht angezeigt werden. Im Programm sollte deshalb ein Schalter vorhanden sein, um die Texte anstelle der Grafiken anzuzeigen. Diese Option kennt eigentlich jeder Browser, nicht jedoch die Möglichkeit, sowohl Grafik als auch Text darzustellen.

Bei einigen Elementen macht es auch keinen Sinn, sie vollständig durch einen Text zu ersetzen. So existiert das - selten genutzte - Summary-Attribut für Tabellen, dass den Inhalt von Tabellen zusammenfasst:

<table summary="Verschiedene Fast-Food-Gerichte">
<tr>
	<td>Hamburger</td>
	<td>Fritten</td>
</tr>
<tr>
	<td>Cheeseburger</td>
	<td>Currywurst</td>
</tr>
</table>

Andere Möglichkeiten auf das existieren einer alternativen Beschreibung hinzuweisen ist ein Tonsignal, ein Icon mit Text, eine kleine Sprechblase oder ein separates Fenster.

Wenn kein alternativer Inhalt definiert ist, kann das Tool versuchen, einen zu generieren oder es zu unterlassen. Mit dem Gedanken einer Generierung hat sich Michael Vorburger schon einmal befasst. Sein "ALTifier" generiert Beschreibungen aus dem umliegenden Text. Das in C++ geschriebene Tool wurde leider nicht als Open Source veröffentlicht, aber in der Anleitung wird die Funktionsweise sehr genau beschrieben.

Verzierungen

Elemente wie z.B. Hintergrundbilder oder andere Verzierungen sollten auf Wunsch abschaltbar gemacht werden. Das betrifft nicht nur Web-Browser, sondern auch einige andere Atari-Programme, die ein Bild als Hintergrund für ihre Dialoge verwenden. Auch im Hinblick auf die Konformität mit anderen Programmen ist es besser, dies Tools wie "Dick" zu überlassen.

Orientierung an anderen Programmen

Jedes Programm sollte sich möglichst an das Aussehen des Betriebssystems halten. Jede Abweichung wird zwar auf den einen oder anderen User grafisch attraktiv wirken, aber den Rest verwirren. Ein Beispiel sind die sogenannten Checkboxen, die auf dem Atari eckig und mit einem Kreuz oder Häkchen versehen werden. Mehrere von ihnen können in der Gruppe angekreuzt sein. Einige Programme brechen jedoch mit dieser Regel und lassen nur das Ankreuzen einer Box zu, womit das Verhalten der Objekte eher dem Radiobutton entspricht. Andere Beispiele sind die Verwendung des Touchexit-Flags für normale Dialogbuttons, Verwendung von "disabled"-Texten für anwählbare Elemente und Effekte wie Schattierung für Texteingabefelder. Allerdings stellen die Betriebssysteme auf dem Atari lange nicht so viele Objekttypen bereit, wie bspw. auf der Windows-Plattform. Ein Web-Browser braucht z.B. Frames, muss sie aber auf dem Atari selbst programmieren, während der Windows-Programmierer die Betriebssystem-Routinen benutzt. Die Vielfalt unter Windows hat aber auch seine Schattenseiten: so gibt es schon mehrere Varianten für Bedienleisten unter Menüs. Die PC-Programmierer nutzen mitunter die ganze Vielfalt von Windows und sogar die Dateiauswahl existiert in den verschiedensten Geschmacksrichtungen - da werden glatt Erinnerungen an frühere Atari-Zeiten wach, als jedes größere Programm seine eigene Dateiauswahl mitbrachte.

Systemerweiterungen können - je nach Verbreitungsgrad - zum Betriebssystem fast dazugerechnet werden. Bestes Beispiel ist BubbleGEM: dieses sehr verbreitete Tool stellte eine Sprechblasenhilfe zur Verfügung, konfigurierbar über ein CPX-Modul. Änderungen an den Einstellungen gelten dann global für alle Programme, die BubbleGEM unterstützen. Programme, die eine Alternative zu BubbleGEM eingebaut haben, bleiben dann außen vor. Darunter fällt z.B. die (abschaltbare) Adamas-eigene Sprechblasenhilfe, deren Schriftgröße nicht konfigurierbar ist.

Abschluss

Damit sind natürlich nicht die gesamten Richtlinien der W3C zusammengefasst. Im Web finden sich noch mehr Vorschläge und auch eine kleine GIF-Grafik, die "saubere" Web-Seiten und -Tools verwenden dürfen. Da ein Prüfprogramm wohl in absehbarer Zeit nicht möglich sein sollte, kann allerdings jeder diese Grafik benutzen.

[1] http://www.w3.org/WAI/
[2] http://www.vorburger.ch/projects/alt/

Shortcut	Funktion
^N		Neu
^O		Datei öffnen
^S		Speichern
^M		Speichern unter
^P		Drucken
^A		Alles markieren
^F		Suchen
^C		Kopieren
^X		Ausschneiden
^U		Schließen
^V		Einfügen
^W		Fenster wechseln
^Q		Programm beenden
Help		Hilfe
Undo		Rückgängig

Mia Jaap
Aus: ST-Computer 02 / 2003, Seite 31
Links
Copyright-Bestimmungen: siehe Über diese Seite