Traditionell war für blinde Rechnerbenutzer MS-DOS die bevorzugte
Plattform. Die weitgehende Verdrängung, die in den letzten Jahren
zugunsten von MS-Windows in seinen verschiedenen Inkarnationen
stattfindet, zwingt viele Blinde sich - mit Hilfe spezieller
Zugangslösungen - mit diesem Betriebssystem zu beschäftigen.
Neben den hohen Kosten, die eine solche Zugangslösung verursacht,
ist die Einarbeitung sehr zeitaufwendig. In diesem Artikel sollen die
Möglichkeiten von Linux als Alternative beleuchtet werden. In einem
zweiten Teil wird das Forschungsprojekt Aranea vorgestellt,
das einen nichtvisuellen Zugang zu grafischen Benutzungsschnittellen
ermöglicht und für das auch ein Interface zum X Window System
geplant ist.
Inhalt
Das Studienzentrum für Sehgeschädigte
Motivation
Hardware zum Zugriff auf Computer
Braillezeilen
Sprachausgaben
Linux als Alternative
Die unterschiedlichen Distributionen
Debian 2.0
Red Hat 5.2
SuSE 6.0
Linux-Software für Blinde
Brltty
Festival 1.3.1
TXT2PHO 0.8.7 kombiniert mit MBROLA 3.01
Fazit
Aranea
Strukturüberblick
Treefactory
ASCII Factory
Braillegrafik
Natural Command Language
Musik
Zusammenfassung
Literatur
Das Studienzentrum für Sehgeschädigte (SZS) ist aus dem Modellversuch "Informatik für Blinde - Studium für Sehgeschädigte in Informatik und Wirtschaftsingenieurwesen" hervorgegangen. Dieser war vom Herbst 1987 bis Frühjahr 1993 anteilig vom Bundesministerium für Bildung und Forschung in Bonn und vom Baden-Württembergischen Ministerium für Wissenschaft und Forschung gefördert worden. Basierend auf technischen Entwicklungen in der Fakultät für Informatik - Institut für Betriebs- und Dialogsysteme - und auf Erfahrungen aus der Beratungsarbeit mit behinderten Studierenden, war das Ziel dieses Modellvorhabens, Sehgeschädigten Studienmöglichkeiten und dementsprechende Berufsfelder zu eröffnen, die ihnen bisher nicht zugänglich waren.
Im Wintersemester 1998/99 studieren 11 Blinde und 16 Sehbehinderte die Fächer Informatik, Wirtschaftsingenieurwesen, Geophysik, Biologie und Pädagogik, Soziologie, Philosophie (MA). Sieben Sehgeschädigte haben in der Zwischenzeit ihr Studium mit dem Diplom abgeschlossen und sind in unterschiedlichen Wissenschafts- bzw. Berufsbereichen tätig.
Das SZS sieht seine Aufgabe auch darin, andere Hochschulen im In- und Ausland beim Auf- und Ausbau vergleichbarer Zentren zu unterstützen, Betroffene über mögliche Bildungs- und Berufswege zu informieren und zu beraten. So ist das SZS in mehreren Programmen der Europäischen Gemeinschaft (LEONARDO, SOCRATES) involviert, ein Informatikstudium für sehgeschädigte Studierende in enger Verbindung mit dem SZS ist an der TU Budapest im Aufbau. Ein unmittelbarer Verbund besteht mit den Zentren der TU Dresden und der Universität Linz/Österreich.
Die Forschungsaktivitäten des SZS beziehen sich auf die Betreuung von Studien-, Diplom- und Examensarbeiten vor allem im Bereich der Informatik (Hard- und Softwareentwicklung für Sehgeschädigte, Mensch-Maschine-Dialog).
Für blinde Personen hat der Computer in den letzten Jahren eine herausragende Wichtigkeit erreicht. Einige ausschlaggebende Gründe hierfür sind:
Elektronische Information ist wesentlich kompakter als die traditionellen Alternativen Brailleausdruck oder Tonbandkassette. Erst durch den Computer wurden größere Mengen an Literatur transportabel und handhabbar.
Der Computer ermöglicht die direkte Zusammenarbeit mit Sehenden, da beide dieselben Daten verwenden.
Mit Einführung des WWW ist die Menge an im Netz verfügbarer Information explosionsartig gewachsen. Der Computer erschließt auch dem blinden Rechnerbenutzer diese Quellen.
Zum besseren Verständnis der folgenden Abschnitte ist es notwendig einen Einblick in die Technologien, die blinden Personen den Zugriff zum Rechner erlauben, zu gewinnen. Die Ausführungen sollen allerdings eher kurz und nicht allzu technisch sein.
Gebräuchlich sind heute vor allem Braillezeilen und Sprachausgaben, weitere Verfahren wie z.B. die Folienauswölbung durch mechanisch bistabile Noppen oder hydrostatischen Druck oder auch die elektrokutane Stimulation spielen im Alltagseinsatz keine nennenswerte Rolle und werden deshalb hier nicht weiter vertieft. Der interessierte Leser sei auf die Fachliteratur verwiesen.
Die Brailleschrift geht auf Louis Braille zurück, der einen taktilen Code des französischen Militärs zu einer digitalen Schrift bestehend aus sechs Punkten, die in einem 2×3 Raster angeordnet sind, weiterentwickelte. Später wurde diese Darstellung auf ein 2×4 Raster erweitert, so dass nun 256 Zeichen darstellbar sind.
Technisch realisiert werden diese Zeichen in sogenannten Braillemodulen, die mittels eines piezoelektrischen Mechanismus 8 Kunststoffstifte heben können. Üblicherweise werden 40 oder 80 dieser Module zu einer Braillezeile zusammengefasst.
Bei der Ansteuerung sind zwei Prinzipien üblich:
Hardwarezeilen lesen den Bildschirminhalt über eine Steckkarte direkt vom ISA-Bus. Der Vorteil dieser Zeilen ist darin zu sehen, dass kein Treiber zur Ansteuerung benötigt wird. Prinzipbedingt funktionieren diese Braillezeilen natürlich nur in Verbindung mit ISA-Grafikkarten, die inzwischen jedoch nicht mehr produziert werden. Dementsprechend verschwindet diese Technologie langsam vom Markt.
Softwarebraillezeilen werden von einem Treiber (auch Screenreader genannt) angesteuert, der sich die Daten verschafft und entsprechend aufbereitet.
Der Preis einer Braillezeile ist größtenteils eine Funktion der Anzahl der Braillemodule. Zeilen mit 80 Braillemodulen liegen ca. bei DEM 25000 bis DEM 35000, für ein Gerät mit 40 Modulen muss man ca. DEM 10000 bis DEM 15000 veranschlagen.
Sprachausgaben sind in der Lage einen elektronischen Text in gesprochene Sprache mit mehr oder weniger natürlicher Betonung und Prosodie zu wandeln. Bis vor einigen Jahren waren Sprachausgaben noch ausschließlich in Hardware realisiert, die fortschreitende Technik ermöglicht nun jedoch auch die Implementierung als Software.
Der Preis einer Sprachausgabe beträgt durchschnittlich etwa DEM 1200. Dieser Preisunterschied in Kombination mit der unterschiedlichen Struktur des sozialen Systems hat dazu geführt, dass in den USA hauptsächlich Sprachausgaben verwendet werden, während in Westeuropa Braillezeilen weiter verbreitet sind.
Lange Zeit wurde die Verwendung von Linux durch den Mangel an Treibern für gängige Braillezeilen verhindert. Ein potentieller Nutzer war genötigt zusätzlich zu einem Linux-Rechner einen zweiten unter MS-DOS als Terminal zu verwenden - ein Aufwand den eher wenige bereit waren auf sich zu nehmen. Gerade in jüngster Zeit wurden jedoch immer mehr Braillezeilen in den Open-Source-Treiber brltty integriert - teilweise mit Unterstützung der Hersteller -, zu einem größeren Teil jedoch durch Reverse-Engineering. Seit diese direkte Hardwareunterstützung existiert, entscheiden sich immer mehr blinde Rechnerbenutzer für Linux, da dieses Betriebssystem ihnen einige Vorteile bietet.
Wie aus den vorigen Abschnitten schon ersichtlich wurde, wird der Textmodus von blinden Rechnerbenutzern bevorzugt, und auch die Hilfsmittel sind auf diesen Zugangsweg zugeschnitten. Da Linux - genauso wie MS-DOS - kommandozeilenorientiert arbeitet, bietet es den Vorteil einer direkten Zugriffsmöglichkeit.
Wenn bevorzugt im Textmodus gearbeitet wird, hat die Verfügbarkeit von Applikationen und Utilities, die auf der Konsole arbeiten, einen sehr hohen Stellenwert. Linux kann als Mitglied der Unix-Familie hier auf einen reichen Satz von Programmen aus den unterschiedlichsten Bereichen zurückgreifen. Die konsequente und eigentlich auch angemessene Trennung von Betriebssystem und grafischer Benutzungsoberfläche fördert Neu- und Weiterentwicklungen solcher Anwendungen in höchstem Maße. Im Vergleich dazu ist bei der Microsoft-Windows-Familie Betriebssystem und Benutzungsschnittelle in einem monolithischen Block integriert, was die Entwicklung von Konsolenanwendungen erschwert, wenn nicht sogar verhindert.
Das Multi-Tasking von Linux in Kombination mit der Möglichkeit mehrere Konsolen gleichzeitig zu benutzen erhält hierbei eine besondere Bedeutung. Der Rechner wird neben der eigentlichen Arbeit noch für Aufgaben benutzt, die ein Sehender mit anderen Hilfsmitteln löst, beispielsweise das Ausführen von Nebenrechnungen sowie das Benutzen von Wörterbuch, Notizzettel oder Kalender.
Legacy Anwendungen und alte Datenbestände können im DOSEmu weiterverwendet werden. Dieser Emulator ist inzwischen so weit entwickelt, dass selbst (Hardware-)Sprachausgaben und andere Hilfsmittel angesprochen werden können, und der allmähliche Umstieg erleichtert wird.
Geschätzt wird auch die weitgehende Konfigurierbarkeit der Arbeitsumgebung. Die meisten Applikationen lassen sich in weiten Grenzen an die eigenen Bedürfnisse und Vorstellungen anpassen, so dass eine adäquate Arbeitsweise unterstützt wird. Da Linux selbst und fast alle Programme als Open Source verfügbar sind, kann notfalls durch eine Änderung im Sourcecode relativ schnell und unproblematisch eine entsprechende Anpassung durchgeführt werden. Bei kommerzieller Software ist dies oft ein zeitaufwendiges und mühsames, dafür selten von Erfolg gekröntes Unterfangen. In dieselbe Kategorie fallen auch die hervorragenden Möglichkeiten der Batchverarbeitung. Die Ausgaben und Returncodes von Programmen können mit sehr mächtigen Ausgabeumleitungsmechanismen sowie leistungsfähigen Skriptsprachen nachbearbeitet und gefiltert werden, um eine sinnvolle Darstellung zu erreichen. So kann beispielsweise der Status eines Programmes problemlos als kurzer Sound ausgegeben werden.
Für Blinde ist die Nutzung des Internet als Kommunikations- und Informationsplattform von großer Bedeutung. Um hier eine sichere und komfortable Informationsgewinnung und Kommunikation zu ermöglichen, sind gute Netzwerkfunktionen eine wichtige Voraussetzung. Linux bietet in diesem Bereich auch bei rein textbasiertem Zugang hervorragende Möglichkeiten. Ein weiterer nicht außer Acht zu lassender Aspekt sind die Kosten: Linux und die dafür verfügbare Software sind im Gegensatz zu anderen Betriebssystemen meist kostenlos, so dass zusätzlich zu der ohnehin sehr teuren Spezialhardware nicht noch erhebliche Mehrkosten entstehen.
Beim Umstieg auf Linux müssen aber auch Nachteile in Kauf genommen werden. So ist die Einarbeitungszeit länger, da Linux wesentlich komplexer ist als MS-DOS. Zudem gibt es für Linux noch keine zuverlässige Spracheingabe und die meisten Hardware-Hersteller stellen für ihre Geräte keine Linux-Treiber zur Verfügung und sind oft auch mit entsprechenden Informationen sehr zurückhaltend.
Interessant für blinde Benutzer, die sich für Linux entschieden haben, ist nun die Frage, welche der zahlreichen Distributionen am besten für ihre Zwecke geeignet ist. Am Studienzentrum für Sehgeschädigte wurden zusammen mit blinden Studenten die drei gängigsten Distributionen - Red Hat 5.2, Debian 2.0 und SuSE 6.0 - evaluiert.
Als Schnittstelle wurde eine Software-Braillezeile benutzt, da die Installation mit einer Hardwarezeile ohnehin relativ problemlos möglich ist. Bei der Installation interessierte vor allem wie weit diese selbständig durch Blinde durchgeführt werden kann. Des Weiteren wurde untersucht, wann im Verlauf der Installation es möglich ist einen Brailletreiber - in diesem Falle brltty - zu starten. Das nächste Ziel des Tests war es brltty durch Eintrag in einem Bootskript bei Systemneustarts automatisch starten zu lassen.
Ein weiterer Gesichtspunkt der untersucht wurde, war die Zusammenarbeit der diversen Installations-Tools - wie z.B. YaST oder dselect - unterschiedlicher Distributionen mit der Braillezeile. Die Idee dabei war, eine Minimalinstallation vorzunehmen, um so früh wie möglich den Brailletreiber zu starten. Die individuelle Installation bestimmter Pakete sollte nachträglich erfolgen. Getestet wurde jeweils eine Installation von CD-ROM mit Hilfe einer Bootdiskette. Die Bootdisketten bieten leider derzeit keine Unterstützung einen Treiber einzubauen.
Das Debian-Installations-Menü bietet als Einzige der getesteten Distribution eine Rescue-Shell, mit der ein Treiber zu starten wäre. Leider funktioniert diese Shell so unzuverlässig, dass dies im Test nicht gelang.
Nach der Installation des Profils "Basic" ist es möglich einen Brailletreiber auf das installierte System zu kopieren. Allerdings muss es sich um eine statisch gelinkte und ausführbare Datei handeln, da die Minimalinstallation keinen gcc und nicht notwendigerweise die passenden Shared Libraries enthält. Zusätzlich wird die deutsche Umsetztabelle text.german.tbl benötigt.
Die nachträgliche Installation mit dem Tool dselect gestaltet sich für Braillezeilenbenutzer sehr schwierig, da die Braillezeile an den Hardwarecursor angekoppelt ist und dieser nicht mitgeführt wird. Außerdem nimmt die Installation relativ viel Zeit in Anspruch, da selbst bei der Installation nur eines Paketes der komplette Bestand durchgegangen wird.
Auch das automatische Starten des Treibers ist nicht ganz einfach, da die dafür zuständige Datei bootmisc.sh vor der Initialisierung der seriellen Schnittstelle ausgeführt wird. Abhilfe schafft ein Skript, das den Brailletreiber startet, und das in dem Verzeichnis rc.boot/ abgelegt wird.
Diese Distribution bietet keine Möglichkeit während der Installation einen Brailletreiber zu starten. Erst nach dem Booten des installierten Systems ist es möglich einen Brailletreiber auf das System zu kopieren und dann zu starten. Dabei ist ein weiterer Nachteil für Braillezeilenbenutzer, dass das Installations-Tool schon einen Großteil der Konfiguration vornimmt.
Leider gibt es für Red Hat nur Installations-Tools, die für die grafische Oberfläche X11, wie z.B. glint oder control-panel. Eine nachträgliche Installation bestimmter Pakete im Textmodus muss daher "von Hand" mit Hilfe des Red-Hat-Package-Managers (rpm) vorgenommen werden. Allerdings wird die Red-Hat-Distribution mit dem Konfigurationstool linuxconf ausgeliefert. Da dieses im Textmodus arbeitet ist es auch für blinde Benutzer möglich, die Konfiguration auf einfache Weise zu manipulieren.
Auch bei SuSE gibt es vor dem Booten des installierten Minimalsystems keine Möglichkeit einen Brailletreiber zu starten. Wie bei Red Hat wird auch hier mit der Erstinstallation schon ein Großteil der Konfiguration vorgenommen.
Nachdem ein Brailletreiber auf das Minimalsystem kopiert ist, ist es möglich ihn durch einen entsprechenden Eintrag im Bootskript boot.local automatisch bei einem Systemstart zu aktivieren. Da der Brailletreiber hier relativ früh im Bootvorgang gestartet wird, ist es für blinde Benutzer sogar möglich, das weitere Booten (z.B. die Netzwerkinitialisierung) zu verfolgen.
SuSE wird mit YaST, einem leistungsfähigen Installations- und Konfigurationstool, ausgeliefert. Dieses Programm arbeitet im Textmodus und ermöglicht so blinden Rechnerbenutzern nachträglich die Konfiguration zu manipulieren oder zusätzliche Pakete zu installieren. Leider wird eine Cursormitführung nicht vollständig gewährleistet. Da der Cursor und damit die Anzeige der Braillezeile immer in die letzte Zeile springt, ist die Paketauswahl bei Benutzung einer Braillezeile schwerfällig. Dieses Problem im Quellcode zu beheben ist zwar möglich, aber nicht trivial, weshalb hier der Hersteller gefragt ist.
Neben den diversen, nützlichen Anwendungen, wie z.B. der textbasierte WWW-Browser lynx, die mit den gängigen Linux-Distributionen ausgeliefert werden, gibt es auch spezielle Anwendungen für Blinde. Hierbei handelt es sich vor allem um Treiber für Braillezeilen und sogenannte Text-to-Speech-Systeme (TTS), die Text als gesprochene Sprache ausgeben können.
Folgende Software-Pakete wurden auf der SuSE-Distribution getestet. Auf den anderen Distributionen funktionieren sie aber in der selben Weise, sie sind z.T. sogar im Debian- bzw. Red-Hat-Paketformat erhältlich.
Brltty ist ein Screenreader und somit dafür zuständig den Bildschirminhalt aufzubereiten und zu Braillezeile und/oder Sprachausgabe zu schicken. Diese Informationen stehen bei Linux glücklicherweise mit den vcsa-Devices zur Verfügung, so dass keine Änderungen am Kernel notwendig sind. Neben der Darstellung des reinen Textes beherrscht brltty noch die Anzeige von Textattributen und enthält eine Cut-and-Paste-Funktion ähnlich gpm sowie Cursorbewegung durch Routing Keys. Das Programm ist im SZS im täglichen Betrieb und hat sich sowohl hinsichtlich der Stabilität als auch des Funktionsumfanges sehr gut bewährt, allerdings ist die Unterstützung der Sprachausgaben noch sehr neu und deshalb auch noch nicht so weit fortgeschritten.
Bei der Sprachausgabe Festival handelt es sich um ein komplettes TTS-System, welches auf den Edinburgh Speech Tools aufbaut. Es ermöglicht die Ausgabe von Texten als gesprochene Sprache über eine gewöhnliche Soundkarte und Lautsprecher. Zur Zeit wird die englische sowie die spanische Sprache unterstützt. Neben den Speech Tools und dem Festival-Paket benötigt man ein umfangreiches Wörterbuch und eine Sprach-Datenbank. Diese Pakete sind für den privaten Gebrauch - auch als Quellcode - frei verfügbar.
Aussprachequalität und Geschwindigkeit von Festival sind aber eher gering. Die Stimme hört sich z.T sehr mechanisch an und ist dadurch fast unverständlich. Obwohl Festival ein TTS-System ist, ist es auch in der Lage externe Synthesizer wie den unten beschrieben MBROLA einzubinden. Die Qualität wird aber gegenüber der ausschließlichen Benutzung von MBROLA nicht wesentlich verbessert.
Für deutschsprachige Benutzer empfiehlt sich zur Sprachausgabe die Kombination aus dem deutschen TTS-Front-End Txt2Pho und dem Sprach-Synthesizer MBROLA. Da beide Programme als ausführbare Dateien frei verfügbar sind, ist die Installation denkbar einfach. Eine kommerzielle Version ist auch mit Quellcode erhältlich.
Txt2Pho verwandelt zunächst Texte oder Textdateien mit Hilfe eines speziellen Wörterbuchs in eine Reihe von Phonemen. MBROLAs Aufgabe ist es, diese Phoneme in gesprochene Sprache, bzw. Sound-Dateien umzuwandeln. Dazu wird eine Diphon-Datenbank für die entsprechende Sprache benötigt. Solche Datenbanken - meist sehr groß (10 MByte) - gibt es bereits für mehrere Sprachen und mit mehreren Stimmen; z.B. Englisch, Niederländisch, Französisch und diese jeweils mit männlichen und weiblichen Stimmen. Die Qualität dieser Kombination ist durchweg als sehr gut zu bezeichnen.
Zudem gibt es weitere interessante Applikationen, die auf MBROLA aufbauen. Emacspeak kann mit MBROLA eine Sprachausgabefunktion für den Editor Emacs bereitstellen. Screader kann bei Einbindung von FreePhone - ein Präprozessor ähnlich wie Txt2Pho - den Inhalt des Bildschirms vorlesen.
Wie die vorangehenden Ausführungen zeigen, stellt das Betriebssystem Linux eine attraktive Alternative für blinde Rechnerbenutzer dar. Dies bestätigen auch die im Studienzentrum für Sehgeschädigte gesammelten Erfahrungen. Die hier seit einigen Jahren eingesetzten Distributionen der SuSE GmbH haben sich in vielfältiger Weise bewährt und erfreuen sich auch bei blinden Studierenden einer immer größer werdenden Beliebtheit. Zunehmend lässt sich auch der Einsatz von Linux im privaten Bereich beobachten.
Das größte Hindernis bei einem Wechsel ist die Problematik der Installation. Um Linux als Blinder selbst installieren zu können, sind von den Herstellern von Braillezeilen sowie den Distributoren noch weitere Anstrengungen notwendig. Auch die Forschungsaktivitäten am Studienzentrum für Sehgeschädigte werden in dieser Richtung weiterlaufen.
Des Weiteren ist bei der Weiterentwicklung der grafischen Benutzeroberflächen zu beachten, dass die Trennung von Betriebssystem und Oberfläche weiter erhalten bleibt. Die Tatsache, dass es für Red Hat nur noch grafische Installationstools gibt, deutet bereits an, dass diese Trennung zunehmend vernachlässigt wird.
Für Linux gibt es bereits mehrere Anwendungen zur Sprachausgabe. Die Forschung auf diesem Gebiet ist aber nicht nur für Sehgeschädigte und Blinde von Interesse, denn akustische Benutzungsschnittstellen werden in Zukunft bei der Steuerung von Computern eine tragende Rolle spielen. Praktisch jede Fernbedienung ließe sich z.B. durch eine akustische Systemsteuerung ersetzen. Das im Folgenden vorgestellte Forschungsprojekt Aranea beschäftigt sich ebenfalls mit diesem Themengebiet.
In order to make an apple pie from scratch, you must first create the universe.
- Carl Sagan, Cosmos
Nachdem die Arbeit am Computer lange Zeit textorientiert war, erfreuen sich in den letzten Jahren die grafischen Benutzungsschnittstellen einer immer größeren Beliebtheit.
Diese Entwicklung wurde sowohl von den blinden Rechnerbenutzern als auch den Hilfsmittelfirmen lange Zeit ignoriert. Erst als absehbar war, dass um den Anschluss an den Arbeitsmarkt nicht zu verlieren ein Arbeiten mit solchen grafischen Schnittstellen auch für blinde Rechnerbenutzer unumgänglich ist, wurde mit der Erforschung alternativer Zugangsmöglichkeiten begonnen. Einige der dabei auftretenden Schwierigkeiten seien hier exemplarisch genannt:
Viele direktmanipulative Techniken - wie z.B. das Ziehen eines Objektes auf einen Papierkorb - beruhen auf einem Gesamtüberblick des Bildschirms. Die Darstellung als Text erlaubt jedoch nur einen lokalen Überblick.
Piktogramme und grafische Darstellungen sind dem sehenden Benutzer zwar oft sehr sinnfällig, die automatische Erkennung und Beschreibung der Bedeutung ist jedoch nur in Sonderfällen zu leisten.
Die moderne Technik erlaubt die Verwendung sehr vieler Farben auf dem grafischen Bildschirm, die in immer größerem Maße dazu genutzt werden Information zu kodieren. Beispielhaft sei die Hervorhebung von besonders wichtigen Informationen oder die visuelle Abgrenzung verschiedener Bereiche genannt.
Prinzipiell ist die Bildschirmauflösung zwar begrenzt, die Auflösung ist jedoch so hoch, dass Koordinaten vom Benutzer als kontinuierlich wahrgenommen werden. Bei akustischer oder haptischer Ausgabe ist die Auflösung wesentlich geringer, so dass entsprechende Mechanismen zur Umsetzung gefunden werden müssen.
Die Verwendung einer Vielzahl verschiedener Zeichensätze ist bei grafischen Benutzungsschnittstellen nicht unüblich. Die Merkmale dieser Zeichensätze finden weder in Brailledarstellung noch in der natürlichen Sprache eine direkte Entsprechung, so dass oft eine attributierte Darstellung gewählt werden muss.
Erst seit jüngster Zeit werden Zugangslösungen zu grafischen Benutzungsschnittstellen erforscht und entsprechende Programme sind am Markt erhältlich. Obwohl die Nützlichkeit solcher Produkte in der Praxis nicht in Frage gestellt werden soll, ist diese Entwicklung nicht ohne Kritik zu sehen. Der Zugang ist nur ein mittelbarer, d.h. es steht die Bedienung der Benutzungsschnittstelle im Vordergrund und nicht die Bedienung des zugrundeliegenden Systems.
Meist sind die Komponenten Dienstleistung und Bedienung jedoch nicht als einzelne Entitäten greifbar, d.h. die Entwicklung eines interaktiven Systems ist oft sehr eng mit der Entwicklung der Benutzungsschnittstelle verbunden. Die Kommunikation wird auf relativ niedrigem Niveau nach Art und Ablauf schon beim Systementwurf beschrieben und eine Anpassung zur Laufzeit an die aktuell vorliegende Situation und die Bedürfnisse bzw. Vorlieben des Benutzers sind nur in vergleichsweise geringem Umfang möglich. Lösungsansätze werden zwar in den sogenannten User Interface Management Systemen (UIMS) erforscht, allerdings hat sich diese Technik am Markt bisher nicht durchgesetzt.
Die von den Hilfsmittelfirmen angebotenen Zugangslösungen bilden geschlossene Systeme, die - da es sich um kommerzielle Projekte handelt - nicht im Quellcode vorliegen. Es ist folglich nicht möglich verschiedene Repräsentationen zu kombinieren, neue hinzuzufügen oder Änderungen anzubringen, um so vergleichende Untersuchungen und objektive Messungen durchführen zu können. Der Hintergrund der Entwicklung von Aranea war deshalb eine Basis für derartige Forschung zu entwickeln. Wichtig war folglich auch die konsequente Einhaltung einer erweiterbaren und parametrisierbaren Architektur. Kriterien der Benutzbarkeit im täglichen Arbeitsablauf müssen hinter diesen Zielen zurücktreten, obwohl zu hoffen ist, dass auf dieser Basis in einem evolutionären Prozess auch ein brauchbares Hilfsmittel für blinde Rechnerbenutzer entsteht.
Wie bereits im vorigen Abschnitt erwähnt, steht nicht die Benutzung im Arbeitsalltag im Vordergrund. Vielmehr soll erforscht werden, wie durch die Zusammenwirkung verschiedener alternativer Zugangswege eine multimodale Schnittstelle geschaffen werden kann, die einen nichtvisuellen Zugang zu grafischen Benutzungsschnittstellen ermöglicht.
Folgende Teilprobleme müssen hierzu gelöst werden:
Als Implementierungsplattform wurde das JDK gewählt, das mit dem Accessibilty Toolkit bereits eine gewisse Grundstruktur bietet. Die Implementierungsarbeiten konzentrieren sich deshalb naturgemäß auch auf AWT und Swing, über eine offene Schnittstelle ist aber auch die Anbindung anderer Toolkits möglich. Ganz konkret wird bereits an einer Implementierung für GTK gearbeitet.
Die folgende Abbildung gibt einen Überblick der Gesamtstruktur.
Im Wesentlichen lassen sich 4 Komponenten ausmachen:
Diese Komponente dient als zentrale Verwaltungsinstanz und verteilt alle Ereignisse entsprechend der voreingestellten Testkonfiguration.
Die Factories implementieren die verschiedenen Zugangsmodi und werden in den folgenden Abschnitten noch näher beleuchtet.
Die Bridge schleust Ereignisse in das System ein und wandelt diese in ein kanonisches Format.
Hier werden die Aktionen und Reaktionen des Benutzers protokolliert.
Den interessantesten Teil stellen sicher die Factories dar, deshalb sollen diese im Folgenden näher beschrieben werden. Alle Beispiele beziehen sich auf den folgenden Originaldialog.
First things first - but not necessarily in that order.
- The Doctor, Doctor Who
In vielen Fenstersystemen sind die Komponenten in einem Baum angeordnet. Der Vaterknoten dient dabei als Container für weitere Fenster und beschränkt deren Darstellungsbereich. Meist haben Komponenten, die in einem engen Sinnzusammenhang stehen auch einen geringen Abstand in dieser Hierarchie. Diese Lokalität macht eine Darstellung des Dialoges durch Abwandern der Baumstruktur sinnvoll.
Dieser Ansatz stellt somit einen inhaltsbasierten Zugang dar, d.h. es wird von der Darstellung abstrahiert und nur die Funktion der Dialogelemente dargestellt. Eine solche Abstraktion von der visuellen Darstellung kommt dem blinden Nutzer zunächst entgegen. Während ein sehender Benutzer die Möglichkeit hat eine dargebotene Dialogsituation als ganzes, d.h. auf einen Blick zu erfassen, muss ein blinder Benutzer einen unbekannten Dialog Schritt für Schritt zusammensetzen. Der strukturierte Ansatz erlaubt es die relevante Information sehr kompakt und eindeutig darzubieten.
Es darf jedoch nicht übersehen werden, dass die Struktur der Dialoge auf den Sehenden optimiert ist. Die Wahrnehmung sehender Personen ist wohl erforscht und die Ergebnisse finden Eingang in die modernen grafischen Benutzungsschnittstellen, sei es durch die Verwendung von Metaphern oder der Benutzung von aus dem täglichen Leben vertrauten Modellen. Die Ausnutzung dieser Gesetze erlaubt dem sehenden Benutzer einen schnellen Rückschluss auf die Art der einzelnen Dialogkomponenten bzw. das Auffinden einer gewünschten Komponente. Dies bedingt jedoch andererseits, dass die Dialogstruktur eine ganze Reihe von Artefakten enthält, die meist auch eine Entsprechung im Strukturmodell finden ohne eine sinnvolle Strukturinformation zu tragen. Leider ist es oft nicht möglich algorithmisch zu entscheiden ob eine Information in das Modell aufgenommen werden soll bzw. wie eine entsprechende Umstrukturierung vorzunehmen ist.
Die geometrische Information ist nicht direkt zugreifbar, damit sind alle Situationen, in denen die Anordnung der einzelnen Element Information trägt, mit diesem Ansatz nur sehr schwierig zu erfassen. Insbesondere kann dies auch die Zusammenarbeit mit Sehenden, die gewohnt sind in geometrischen Begriffen zu argumentieren, beeinträchtigen.
Measure with a micrometer. Mark with chalk. Cut with an axe.
Die ASCII Factory stellt den grafischen Dialog mittels ASCII-Zeichen dar. Insbesondere die Berandungen und Beschriftungen können so in eine unmittelbar zugreifbare Form umgesetzt werden. Die geometrische Anordnung und somit auch die darin enthaltene Information bleibt weitgehend erhalten und bildet ein gemeinsames Bezugssystem für die Zusammenarbeit mit Sehendenden.
Ihre Grenzen findet diese Darstellung in der sehr hohen Bildschirmauflösung. Objekte, die am Bildschirm relativ kompakt dargestellt werden können, brauchen bei einer Umsetzung nach ASCII viel Platz. Dies hat zur Folge, dass sich oft eigentlich disjunkte Objekte bei der Darstellung überlappen. Auch ein Zoomen, d.h. ein kleinerer Skalierungsfaktor schafft hier keine Abhilfe, da damit im Gegenzug der ASCII-Bildschirm größer und die Übersicht entsprechend geringer wird.
Im Gegensatz zum strukturierten Modus ist der leere Raum Bestandteil der Darstellung und muss vom Benutzer mit abgetastet werden, was sich negativ auf die Geschwindigkeit der Erfassung einer Dialogsituation und den Überblick auswirkt.
Die Braillegrafik-Factory ähnelt dem strukturierten Modus, geht aber von einem Ausgabegerät mit frei adressierbaren Pixeln aus. Ein solches Gerät ist zwar am Markt noch nicht erhältlich, es wird jedoch intensiv an einer Realisierung gearbeitet.
Drawing on my fine command of language, I said nothing.
Die Natural Command Language nutzt die Sprache als Ein- und Ausgabemodus. Wie der Name schon andeutet, hat der Dialog eher den Charakter einer Kommandosprache, denn den einer zwischenmenschlichen Kommunikation. Der nachstehende Beispieldialog soll die Art der Kommunikation verdeutlichen.
Click the checkbox Which checkbox do you mean, is Closable, is Maxable, is Iconifiable or is Resizable is Resizable OK Click all the checkboxes except is Closable OK Select Layer OK Type 4 OK Move mouse to Make then click left mouse button OK
Wie man leicht erkennen kann, ist eine recht enge Grammatik ähnlich einer Kommandosprache vorgegeben, das System kann jedoch bis zu einem gewissen Grad Mehrdeutigkeiten erkennen und durch Nachfragen auflösen.
Ein entscheidendes Problem wird das Scoping, d.h. die Entscheidung, welche Objekte zu einem bestimmten Zeitpunkt sichtbar sind, darstellen. Bei dem sehr einfachen Beispieldialog sind relativ wenige Mehrdeutigkeiten möglich, bei einem komplexen Interface wird man jedoch immer nur einen Teil der Dialogkomponenten betrachten, um die Anzahl der Kommandos und Nachfragen zu minimieren.
How wonderful opera would be if there were no singers.
Mit diesem sehr innovativen und experimentellen Modul sollen die Möglichkeiten zur Darstellung von Dialogen mittels Musik untersucht werden. Dieses Idee scheint zunächst vielleicht etwas ungewöhnlich, jedoch hat die Musik insbesondere in Kombination mit anderen Zugangsmodi ein hohes Potential innerhalb kurzer Zeiträume auch relativ komplexe Situationen zu beschreiben. Selbst ein untrainierter Benutzer kann problemlos eine Vielzahl an Melodien, Rhythmen und Instrumenten unterscheiden und korrekt zuordnen. Mit diesen Merkmale sollen verschiedene Eigenschaften der Dialogelemente kodiert und dem Benutzer angeboten werden.
Zu einem späteren Zeitpunkt soll dieses Modul mit einem ebenfalls in Planung befindlichen 3D-Sound-System verbunden werden, so dass einzelne musikalische Elemente noch im Raum plaziert werden können.
'Well, we are wizards,' said Ridcully. 'We're supposed to meddle with things we don't understand. If we hung around waitin' till we understood things we'd never get anything done.'
- Terry Pratchett, Interesting Times
Aranea ist ein multimodaler Zugang zu grafischen Benutzungsschnittstellen mit flexibler Basisarchitektur. Forschungsschwerpunkt bildet der Zugang blinder Rechnerbenutzer zu modernen interaktiven Systemen, obwohl die Ergebnisse zumindest teilweise auch für Sehende Gültigkeit besitzen werden.
An Aranea wird aktiv entwickelt. Mehrere Zugangswege sind bereits implementiert, weitere befinden sich in Arbeit bzw. im Planungsstadium. Erste informelle Tests haben bereits Ergebnisse getätigt; diese sollen in Zukunft noch formalisiert und konkretisiert werden.