Barrierefreiheit/WWW-Design für Sehbehinderte

Informationen zum Autor

Name:

Helga Parslow

E-Mail:

Homepage:

(keine)

Hinweis:

Dieser Artikel ist eine Textübertragung aus dem aktuell.de.selfHTML-Bereich. Seine Inhalte sind möglicherweise veraltet.

• zuerst erschienen: 31.12.1998,
• letzte Aktualisierung: 29.06.2001

Der Fortschritt in der Computertechnik bringt mit sich, dass der Trend immer stärker zu grafischen Oberflächen geht. Sehbehinderte und Blinde werden wieder mehr und mehr von der Nutzung aktueller Systeme ausgegrenzt, weil die bisherigen Hilfsmittel an diesen Benutzerschnittstellen nicht unbedingt einsetzbar sind. Wie also müssen Web-Designer ihre Angebote aufbauen, damit diese auch Behinderten zur Verfügung stehen?

Motivation

Im Juni 1996 wurde der Artikel 3 des Grundgesetzes geändert: 'Niemand darf wegen seiner Behinderung benachteiligt werden.' Von dieser Gesetzesänderung haben aber bisher außer den beteiligten Politikern fast nur Betroffene Kenntnis genommen. In der breiten Öffentlichkeit ist der Anspruch an die Gesellschaft, der dadurch formuliert wurde, nach wie vor kein Thema. Es ist klar, dass eine Gestezesänderung an sich noch kein Bewußtsein verändert. (Dazu müsste der Gesetzgeber begleitende Öffentlichkeitsarbeit betreiben.) Immer noch gelten Fragen als berechtigt wie: 'Muss man denn wirklich alle berücksichtigen?' 'Muss ein Rollstuhlfahrer in einem Flugzeug untergebracht werden können?'

So, wie Städteplaner jeden Tag daran erinnert werden müssen, dass es Rollstuhlfahrer gibt (die Hauptgruppe derer, die unter der Gedankenlosigkeit von Planern zu leiden haben), so muss auch bei World Wide Web – Designern Bewußtsein geschaffen werden dafür, dass nicht alle Leser ihrer Seiten welche sind, dass nicht alle Benutzer ihrer Informationsangebote Hacker sind.

Vor Jahren bot die Datenverarbeitung Sehbehinderten gerade noch eben die Möglichkeit, dass sie mit Hilfe technischer Hilfen am Arbeitsprozess teilnehmen konnten. Elektronische Linsen, ggfs Braille-Ausgabe erlaubten sogar Blinden die Bedienung von den damals nur textorientierten Ein/ Ausgabegeräten und damit Integration in die Brufswelt.

Seit einigen Jahren nimmt nun der Einsatz von grafischen Oberflächen in der Datenverarbeitung immer mehr zu. Damit werden bisher von diesem Personenkreis genutzte Werkzeuge immer unbrauchbarer und die Sehbehinderten wieder mehr an den Rand der Gesellschaft in die Isolation gedrängt.

Das Werkzeug 'Internet' könnte Blinden und Sehbehinderten einen wesentlichen Teil an selbstbestimmtem Leben bieten/wiedergeben und ihnen ermöglichen, 'gleichberechtigt' an den gesellschaftlichen und wirtschaftlichen Tätigkeiten in ihrem Umfeld teilzunehmen.

Über die berufliche Eingliederung hinaus bietet das Internet allen in ihrer Mobilität eingeschränkten Behinderten 'Mobilität' am Schreibtisch.

Informationen, die eine sehende Person sich überall besorgen kann, wäre, nicht zuletzt auch bei eingeschränkter Mobilität, für diese Personengruppe wenigstens gut am Computer erhältlich. Viele Auskunftssysteme, z. B. Fahrpläne, Flugpläne, Programme, Recherchen aller Art lassen sich über das Internet einholen. Inzwischen ist 'electronic Commerce' ein fester Begriff, Bankgeschäfte und anderweitiger (bald rechtsverbindlicher) Geschäftsverkehr werden schon heute über dieses Medium abgewickelt.

Die Frage, die hier untersucht werden soll, ist deshalb, wie muss Internet sein, damit es auch von speziell Sehbehinderten und Blinden genutzt werden kann. Wo liegen die Anforderungen von Sehbehinderten an das Design von World Wide Web – Seiten, welche Hilfsmittel für Blinde gibt es, welche Anforderungen stellen diese Hilsmittel an das Design von World Wide Web – Seiten, damit die Technik nicht weitere Hürden aufbaut, sondern Chancen eröffnet.

Technische Hilfsmittel

Bei den Hilfsmitteln, die zur Verfügung stehen, ist naturgemäß zu unterscheiden, ob die betroffene Person blind oder sehbehindert ist. Einige Hilfsmittel (zum Tasten) können fast ausschließlich von Blinden verwendet werden, andere (optische) nur von Sehbehinderten (bis zu einem gewissen Grad). Akustische Hilfsmittel dagegen sind von allen Personen benutzbar (soweit sie nicht zusätzlich hörbehindert sind), von Sehbehinderten wie Sehenden, die akustische Wiedergabe hilft sogar noch (sehenden) Analphabeten.

Taktil

Das wohl bekannteste Hilfsmittel für Blinde ist die Braille-Schrift. Braille-Zeilen für Rechner sind nicht neu. Sie sind allerdings nur von einem 'geringen' Teil der Betroffenen nutzbar.

Die meisten Blinden sind nicht blind von Geburt an, sondern sind erst später erblindet. Deshalb beherrschen viele von ihnen kein Braille, sondern sind auf andere Hilfe angewiesen. Braille ist textorientiert, ist deshalb auf textorientierte Browser angewiesen. Bilder oder gar Videos können nicht unmittelbar in Braille umgesetzt werden.

International ist Braille ohnehin nicht so verbreitet wie in Deutschland. Eine Braille-Zeile für einen Rechner kostet im Moment ca. 25 T D M. Das wird zwar von deutschen Versorgungsämtern als Rehabilitationsmaßnahme gezahlt, aber offensichtlich ist das in vielen anderen Staaten nicht üblich.

Akustisch

Nicht zuletzt deshalb wird außerhalb Deutschlands, besonders in den U S A, stärker auf die Sprache als Hilfsmittel gesetzt. Werkzeuge für Sprachausgabe (screenreader) gibt es, auch bereits akustische Browser speziell für das World Wide Web.

Screenreader setzen nicht Text in Sprache um, sie erzeugen synthetische Laute, die als Sprache verstanden werden können.

Bei Werkzeugen für die Spracheingabe ist die Installation für eine behinderte Person nicht ohne Hilfe, welcher Art auch immer, durchzuführen. Der Rechner muss erst mal die Sprache der Person verstehen lernen, die später das Werkzeug benutzen wird. Dazu müssen Eingaben 'an der Tastatur' gemacht werden. Texte werden eingetippt und zusätzlich gesprochen, sodass der Rechner sich 'an die Stimme gewöhnen' kann.

Bei dem Versuch einer Implementation gab es allerdings noch Probleme, ein Werkzeug für Sprachausgabe und ein Werkzeug für Spracheingabe gleichzeitig anzubinden. Bisher ging nur entweder oder. Dieses Problem wird aber gelöst werden.

Im Juni 1997 hat das World Wide Web Consortium (W3C) angekündigt, einen 'Working Draft' zu einem Vorschlag für A C C S (Audio Cascading Style Sheets) zu erarbeiten. Diese style sheets sollen speziell auf die Notwendigkeiten beim Einsatz von audio basierten World Wide Web – Werkzeugen eingehen. Damit wird der erste Schritt getan weg von der heute rein am Visuellen orientierten Darstellung.

Optisch

Als technische Hilfen werden auch elektronische Linsen angeboten, die Schrift extrem vergrößern können. Da diese aber, wie bereits erwähnt, nur in eingeschränktem Maße für einen bestimmten Personenkreis in konkreten Anwendungsfeldern hilfreich sind, werden sie hier nur der Vollständigkeit halber erwähnt und nicht weiter betrachtet.

Normen und Standards

Die Aufstellung von Richtlinien für die Gestaltung von HTML-Dokumenten für Endbenutzer mit Spezialanforderungen ist derzeit im Gange. Gerade für Sehbehinderte und Blinde gibt es bereits eine Reihe von Vorschlägen zur HTML – Standardisierung, die hier aufgelistet werden:

• A C T-Center,

'Accessible Web Page Design',

• Adaptive Technology Research Center, University of Toronto,

'Guide to Accessible HTML, Accessibility for Persons with visual disabilities',

• DO – IT (Disabilities, Opportunities, Internetworking & Technology),

'DO – IT HTML Guidelines',

• Paul Fontaine, Center of Information Technology Accomodation, General Service Administration,

'Writing Accesible HTML Documents'

• Trace R & D Center, University of Wisconsin – Madison,

'Unified Web Site Accessibility Guidelines', Version 6.6, April 1996

Das IFIP-Modell zu Mensch Maschine Schnittstellen (IFIP: International Federation for Information Processing) sieht für den Endbenutzer mindestens vier Schnittstellen vor:

• die Terminal-Schnittstelle, die den Ein/Ausgabefluß von und zur Maschine betrachtet,
• die Dialog-Schnittstelle, die die Form und Art der Dialogprozesse reguliert (Menüs, Buttons, Muttersprachliche Darstellung für mehrere Sprachen, ...),
• die Funktions-Schnittstelle, die die Benutzung von Anwendungen reguliert, und schließlich
• die Organisations-Schnittstelle, die Beziehungen zwischen verschiedenen Benutzern betrachtet, und die deshalb für diese Arbeit als nicht relevant angesehen wird.

Design auch für Seh- (und anderweitig) Behinderte

Inzwischen gibt es im World Wide Web eine Reihe von Aktivitäten, die dieses Ziel verfolgen und durch ihre aktive Berichterstattung Bewußtsein für dieses Ansinnen bilden. Nicht zuletzt hat sich auch das W 3 C dieser Aufgabe angenommen und die WAI (Web Accessability Initiative) – siehe WAI – .

Genauso macht sich die Initiative Aktion 'offene Website' für das gleiche Ziel stark. Ansatz dieser Aktion ist, dass Blinde und Sehbehinderte wegen der technischen Hilfsmittel in erster Linie auf LYNX angewiesen sind, einen textorientierten Web-Browser. Angebote im World Wide Web werden danach bewertet, inwieweit sie mit einem solchen Browser verarbeitet werden können.

Eine Seite kann als speech friendly bezeichnet werden, wenn sie sich an textorientierten Browsern orientiert, weil Sprachein- /ausgabe Textteile besonders gut umsetzen kann. Graphik soll aber nicht verbannt werden, man sollte nur jeweils dort, wo es angebracht ist, Alternativen vorsehen.

Wer softwareergonomische Designkriterien ohnehin berücksichtigt, wird feststellen, dass diese von den 'Richtlinien für Sehbehinderte' gar nicht so weit weg sind. Die Toleranzschwelle gegenüber design – überladenen Seiten hat nur im Laufe der Zeit zugenommen.

Design-Kriterien

Jeder weiß, dass nichts soviel Zeit kostet wie nachträgliche Änderungen, wie Wartung und Aktualisierung an Beiträgen, wenn dieses nicht von Anfang an vorgesehen wurde. Beiträge/ Seiten sollten deshalb von Anfang an so entworfen werden, dass sie bei unterschiedlichen Browser-Einstellungen funktional gleiche Ergebnisse liefern.

Bei der vorwiegend visuellen Darstellung im World Wide Web sind im Wesentlichen vier Fälle zu unterscheiden:

• Die Darstellung ist textorientiert, dann dürften keine weiteren Eingriffe notwendig sein.
• Der Beitrag enthält einzelne Bilder. Diese sollten dann im Einzelnen mit Alt Key (s.u.) und D Anker (s.u.) versehen werden. So sind Text, Bild und Beschreibung jeweils an einer Stelle in der Quelle verankert, eine Änderung läßt sich 'lokal' durchführen.
• Im Beitrag sind einzelne Seiten völlig grafisch aufgebaut (oder z.B mit frames, image maps, ..), dann empfiehlt sich, eine nur-Text Seite aufzubauen und den Wechsel am Kopf der Seite anzubieten.
• Der Beitrag ist völlig grafisch aufgebaut (oder z. B. zweispaltig..), dann empfiehlt sich doch, insgesamt den ganzen Beitrag zweimal vorzuhalten, einmal so, wie gewünscht, einmal als 'nur Text' für alle diejenigen, die darauf angewiesen sind.

Bei den Konfigurationen drei und vier ist der Aufwand für Aenderungen von Natur aus größer als in der Konfiguration zwei. Änderungen müssen gegebenenfalls zweimal, in zwei verschiedenen Quellen, durchgeführt werden.

Trotz aller Standards kann nicht davon ausgegangen werden, dass jeder Browser eine Quelle in der gleichen Weise interpretiert. Deshalb ist wichtig, Beiträge 'für Alle' mit verschiedenen Browsern zu testen, und dabei auch gleich zu berücksichtigen, dass nicht auf allen Schreibtischen jeweils die neueste Hardware und Software verfügbar ist (z. B. monochrome Darstellung).

Konkrete Empfehlungen

Ein Teil der im weiteren beschriebenen Empfehlungen wurde den 'W 3 C – guidelines für HTML – Design' [WAI] entnommen. Einige Aspekte lassen sich allerdings nicht auf HTML – Ebene erreichen, sie müssten auf Browser-Ebene durchgeführt werden.

'WWW für Alle' heißt nicht nur für Sehbehinderte und Sehende. Da Untersuchungen vorliegen, die für Personen mit motorischen Behinderungen zu beachten sind, wurden auch diese Hinweise mit aufgenommen. Vieles ist deckungsgleich, einige wenige Hinweise sind extra.

Seitenaufbau

Obwohl das konkrete Layout nicht beim Design, sondern beim Anwenden festgelegt wird (Fenstergröße / Textgröße / Textfonts), kann durch das Design schon die Handhabbarkeit unterstützt werden.

Durch Text kann man scrollen, es macht also nichts, wenn eine Seite voll ist, aber Seiten mit grafischen Darstellungen sollten nicht überladen sein. Sehbehinderte können dann schlecht fokussieren, Screenreader haben Probleme, die Information richtig zuzuordnen.

Leerzeichen und Leerzeilen auf einer Webseite zeugen nicht unbedingt von der Einfallslosigkeit des Designers. Es kann auch gewollte Übersichtlichkeit sein.

Bewegte Bilder, z. B. dauernd laufende Animation, machen auf einer Messe Sinn, wo man Publikum anziehen will, in 'WEB Seiten für Alle' bringt es unnötige Unruhe.

Navigation

Es hilft dem hörendem Leser, wenn alle Navigations- Elemente wie z. B. Menüs oder Schaltzeilen (mit Buttons) vorher durch ein Wort angekündigt werden.

Graphik- und Textmodus

'Ein Bild sagt mehr als tausend Worte'. Wer 'WWW für Alle' entwirft, will und soll natürlich nicht auf dieses Ausdrucksmittel verzichten, es gibt sie ja weiterhin auch noch, die Sehenden. Aber jede Graphik sollte hinterlegt sein mit einem kurzem Text beziehungsweise mit einer Beschreibung, die dem nicht Sehenden einen Eindruck verschafft.

Seiten, die stark grafisch aufgebaut sind, sollten als Alternative von vornherein eine weitere Seite im Textmodus anbieten.

Alt Key

Hinter jeder Graphik, die mehr ist als Zierde, die in einer Textversion nicht einfach weggelassen werden kann, hinter jedem Button, der angeklickt werden kann, sollte ein Alt Key mit einem alternativen Text angegeben sein. Diese Beschreibung sollte eine sinnvolle inhaltliche Erklärung sein, besonders dann, wenn es sich um Buttons handelt (nicht nur das beliebte 'hier klicken').

Die Beschreibung sollte aber andrerseits so kurz gefaßt sein, dass die Seite im Text-Modus noch ansehbar ist und nicht das ganze Layout verschoben wird. Sie sollte auch deshalb kurz gefaßt sein, damit sie für Blinde bei Sprachausgabe, für Benutzer von textorientierten Browsern noch zumutbar ist.

Tags

Die meisten Browser arbeiten nach der Methode, wenn ich ein Tag nicht kenne, ignoriere ich es. Dies sollte beim Design berücksichtigt werden bzw. aktiv mit verwendet werden, dort, wo gewollt. Tags, die nahtlos ignoriert werden können, mögen den alternativen Entwurf von Seiten für Text- und Graphikversion im ein oder andern Falle vereinfachen. Wichtig dabei ist, dass der Entwurf nur original HTML verwendet. Textfonts

Weil (s.o.) jeder Leser im World Wide Web die Möglichkeit hat, Form und Größe der Schrift lokal festzulegen, verbietet es sich fast von selbst, feste Fonts zu benutzen. Damit werden gegebenenfalls völlig ohne Not Teilnehmer als Leser ausgeschlossen. (Es macht schon Sinn, dass zumindestens einige Browser dem Leser diese Entscheidung selbst überlassen.)

Farben

Stark Sehbehinderte sehen besser, je kontrastreicher die Information aufgebaut ist. Aus diesem Grunde sollte die Darstellung von Hintergrund (farbig/ grafisch) abschaltbar sein.

Bei zu starkem Farb – Einsatz erkennen Sehbehinderte nicht die unterschiedlichen Farben, sondern nur noch 'bunt'. Außerdem: Wenn ein Benutzer nur eine geringe Farbtiefe auf seinem Rechner eingestellt hat, könnten 'seltsame Erscheinungen' auftreten. Mancher wird sich noch an DOS erinnern, wo in einigen Editoren je nach Farbeneinstellung Markierungen oder andere Editor-Elemente nicht mehr zu sehen waren.

Web-Designer sollten sich außerdem dessen bewußt sein, dass ein nicht geringer Teil der Sehenden Probleme mit dem Erkennen/ Unterscheiden von rot und grün haben. Also sollten (vor allem diese beiden) Farben nicht als kritische Erkennungsmerkmale eingesetzt werden.

Buttons /Schaltflächen

Buttons sollten eine gewisse Mindestgröße und genügend Abstand voneinander haben. Sehbehinderte (und motorisch Behinderte) haben Probleme, mit der Maus genau in ein Mini-Feld hinein zu zielen. Aus dem gleichen Grund sollte die Eingabe – Toleranz von Schaltfächen größer sein als die sichtbare Schaltfläche. (man kann schon klicken, wenn man erst in der Nähe eines Buttons ist). Dies ist allerdings keine 'Leistung' von HTML, sondern muss im jeweiligen Browser eingebaut werden. Da evtl. mehrere Schaltflächen nahe beieinander liegen, muss das Element, was als das Gemeinte erkannt wurde, vom Browser markiert werden, sodass der Benutzer erkennt, welche Aktion ausgeführt werden wird.

Tabellen /Spalten

Ältere Text – Browser sowie die meiste Screenreader Softwareprodukte können Tabellen und /oder Spalten nicht bearbeiten. Screenreader scannen den Schirm Zeile für Zeile (selbst wenn es erste Software gibt, die intelligenter ist). Bei einem zweispaltigen Text wird schlimmstenfalls die erste Zeile der zweiten Spalte direkt hinter die erste Zeile der ersten Spalte gehängt. Bei Tabellen kann das gut gehen, solange in keiner Zelle ein Umbruch stattfindet. Sobald aber nur in einer Zelle ein Text umgebrochen wird, gilt hier das gleiche wie für mehrspaltigen Text. Es ist dabei wieder zu beachten, dass ein Designer keinen Einfluss auf die Darstellung seiner Seite auf dem Schirm hat (haben sollte). Textumbruch hängt von der lokalen Einstellung des Lesenden ab.

Zusätzlich kann es bei Tabellen Probleme geben, wenn eine Tabelle mit Positionsrahmen aufgebaut wird. Da heute immer mehr auch Textverarbeitungssysteme Konvertierungsprogramme zu HTML anbieten, und diese Konvertierungsprogramme mehr oder weniger gut sind beziehungsweise sein werden, ist auch hierauf zu achten.

Man muss also Spalten generell vermeiden, Tabellen so aufbauen, dass sie auch sequentiell Zeile für Zeile gelesen werden können. Am Besten jedes Element in eine neue Zeile (jede Zelle mit CR-Tag). Der 'Textmodus' muss ohne störende Tags für die 'Positionsrahmen' erstellt werden.

Einem 'hörendem' Leser hilft eine 'Ankündigung' der Spalten oder Zeilen bei der Orientierung.

Formulare

Hier liegen einmal widersprüchliche Anforderungen von Sehbehinderten und motorisch Behinderten vor. Die W3C 'guidelines regarding physically handicapped end users' sehen vor, dass möglichst alle Voreinstellungen bereits eingetragen sind, wenn das Formular am Bildschirm erscheint, Die 'guidelines regarding visually impaired and blind people' empfehlen das Gegenteil, weil Blinde durch Ausgabe von Voreinstellungen irritert werden könnten. W3C empfielt deshalb, in Formularen jeweils eine Check Box vorzusehen, sodass ein Benutzer entscheiden kann, ob das Formular bereits ausgefüllt sein soll oder nicht.

Abkürzungen

Es hat sich als wirksam herausgestellt, Abkürzungen jeweils mit einem Blank zwischen den Buchstaben zu versehen. Ansonsten versuchen Sprachausgabe-Werkzeuge, aus einem Begriff ein Wort zu erzeugen. (Man stelle sich vor, 'G M D' als Wort gesprochen.)

Listen

Auch kurze Elemente einer Liste sollten einzeln mit einem Punkt abgeschlossen werden, damit bei der Sprachausgabe am Ende jedes Elementes die Stimme gesenkt wird. Listenelmente sollten möglichst nummeriert werden, nicht nur aufgezählt, um das navigieren einfacher zu machen.

Wenn nicht nummeriert wird, sondern nur Aufzählungszeichen eingesetzt werden, sollten diese, wo ihre Erwähnung keine Information bringt, mit einem Alt – Tag mit einem Blank versehen werden. Andernfalls lesen einige Screenreader das Aufzählungszeichen mit vor.

Es hilft dem Leser/ Hörer, wenn im Textmodus vor einer Liste ihr Aufbau beschrieben wird (Anzahl Elemente, weitere Unterteilungen,...).

Tastatur - Kommandos

Wenn der Einsatz einer Maus beschwerlich ist, können Kommando-Eingaben über Tastatur als Ersatz für einzelne Aktionen dienen, z. B. zum Markieren von Text, 'Verstehen' eines Links nach der Eingabe von nur ersten Zeichen, Navigieren per Tab (z. B. mit den Pfeil-Tasten durch Links oder Tabellen.

Timer

Zeitschranken als Wartezeit auf eine Eingabe sollten vermieden werden. Nicht nur motorisch behinderte haben Probleme, die Antwort rechtzeitig einzugeben. Auch auf Sehbehinderte, die länger zum Lesen benötigen, auch auf Blinde, die die Anfrage langsamer als Sehende 'begreifen', sollte dabei Rücksicht genommen werden. Doppelklick

Der Doppelklick sollte möglichst nicht eingesetzt werden. Motorisch Behinderte haben Schwierigkeiten, ihn auszuführen, selbst wenn die Zeit, die zur Verfügung steht, groß angesetzt wird.

Sticky Keys

Personen mit motorischen Behinderungen haben ggfs. Probleme, Tastenkombinationen wie CTRL A zu bedienen. Deshalb kann ein Eingriff in den Browser vorgenommen werden, der Tasten wie CTRL, ALT, ... 'festhält', bis eine zweite Taste gedrückt wurde. Dies könnte auch Sehbehinderten die Eingaben erleichtern.

Filter Keys

Filter Keys bedeuten, dass nach dem Anschlag einer Taste erst eine gewisse Zeit vergangen sein muss, bevor eine weitere Taste angeschlagen werden kann. Dieser Eingriff in einen Browser ist sinnvoll für die Bedienung durch motorisch Behinderte. Der Ansatz wurde der Vollständigkeit halber hier mit aufgeführt.

Forschungsprojekte

Im folgenden werden einige Forschungsprojekte aufgeführt, die sich mit der Integration von Behinderten in die Informationswelt des World Wide Web befassen. Die Liste ist weder umfassend noch vollständig.

• ERBUS

D V B S und I B M.

Ziel des Projektes ist die Erschließung des Einsatzes grafischer Benutzeroberflächen für Blinde und hochgradig Sehbehinderte im Beruf.

Die Selbstorganisation der Blinden und Sehbehinderten befassen sich in ihrem 'gemeinsamen Fachausschuß Informationstechnik' mit den Zugangsmöglichkeiten zu den grafischen Oberflächen. Als selbst 'Betroffene' sind sie kompetente Tester der angebotenen Werkzeuge.

• TEDIS

G M D, Forschungsschwerpunkt: Kooperations- und Kommunikationssysteme.

Ziel des H C I (Human Computer Interface) Projektes TEDIS (Telearbeit für Behinderte) ist, für Menschen mit unterschiedlichsten Behinderungen durch Telearbeit Teilnahme am beruflichen Alltag zu ermöglichen.

Die begleitende sozialwissenschaftliche Technikfolgenabschätzung hat ergeben, dass die Frage 'Integration oder Isolation', die bei Telearbeit ohnehin immer gestellt wird, trotz aller kritisch differenzierten Betrachtung insgesamt positiv beurteilt wurde.

Die ersten beiden Telearbeiter sind schwerst körperbehindert, jetzt gerade wird an der Anpassung für Blinde gearbeitet sowie gleichzeitig an 'dem Gegenteil', an einem Arbeitsplatz für Menschen, die nur noch ihre Augen bewegen können.

• EASY

D V B S.

Ziel des Projektes ist es, die 'Informationsbehinderung' von Blinden und Sehbehinderten zu mildern. Es soll ein elektronisches Auskunfts- und Dialogsystem entworfen und realisiert werden.

• 'Studienunterlagen'

Institut für Informationssysteme der T U Dresden

Ziel des Projektes ist es, blinden Studenten Studienmaterialien über das World Wide Web zur Verfügung zu stellen. Es soll ein Scriptreader für S G M L-kodierte hyper-text basierte Unterlagen entwickelt werden. Das System wird unter Windows 3.1 realisiert.

Siehe auch

• WAI-ARIA
• Grafik/Farbkonzept/Farben und Kontraste
• Barrierefreiheit