Barrierefreiheit aus der Perspektive eines sehgeschädigten Anwenders

By Alexander Kuban, Accessibility Competence Center, SAP User Experience, SAP AG – 7. Juni 2005

English Version

Wahrnehmung

Blinde und stark sehbehinderte PC-Anwender haben im Vergleich zum normal sehenden Anwender einen eingeschränkten Überblick über das Programmfenster bzw. den gesamten Bildschirm. Sie haben meistens nur direkte Informationen über das Fensterelement, welches gerade den Fokus hat. Im Zuge wachsender Anwendungserfahrung verinnerlichen sie häufig verwendete Programmfenster und verschaffen sich so einen Überblick. In dieser Situation ist eine klare Gliederung und explizite Benennung der Fensterinhalte, gemessen an den Arbeitsabläufen, sehr hilfreich. Informationen, die zu einem bestimmten Zeitpunkt des Arbeitsablaufes nicht notwendig sind, sollten deshalb auch nicht angezeigt werden. Sie sollten aus technischen Gründen nicht nur ausgeblendet werden, da sie dann lediglich für normal sehende Anwender unsichtbar sind. Für die Hilfsmittel, die sehgeschädigte Menschen verwenden, sind sie oft weiterhin vorhanden und stören den Arbeitsablauf.

Diese Hilfsmittel sind zum einen Bildschirmvorleseprogramme, die den Inhalt des Programmfensters interpretieren und ihn per Sprachausgabe vermitteln. Zusätzlich kann hier eine Braillezeile per Treiber in das Bildschirmvorleseprogramm integriert werden, mit deren Hilfe der Bildschirm zeilenweise gelesen werden kann.

Sehbehinderte Menschen hingegen verwenden Bildschirmvergrößerungsprogramme, die die Umgebung um den Mauszeiger oder Cursor in einer wählbaren Rate vergrößern. Diese Hilfsmittel können ebenfalls durch Sprachausgaben ergänzt werden.

Mögliche Einstellungen (Zeichensatz, Schriftgröße etc.) auf Ebene des Betriebssystems haben den Nachteil, dass sich der Fensterinhalt absolut vergrößert, was häufiges horizontales oder vertikales Blättern notwendig macht und die Effizienz der Arbeit beeinträchtigt.

Informationen über solche Hilfsmittel und deren Hersteller finden sich auf: https://www.rehadat.de

 

Navigation, Selektion und Fokus

Sehgeschädigte PC-Nutzer bedienen sich zur gesamten Navigation der Tastatur. Sie bewegen sich so nicht nur innerhalb einer Applikation, sondern navigieren auch zwischen mehreren Applikationen hin und her. Lediglich einige stark sehbehinderte Anwender können je nach Sehkraft und Gesichtfeld die Maus benutzen. Während der Navigation haben sie jeweils nur Informationen über das Fensterelement, welches gerade den Fokus hat.

Unter "Fokus" ist in diesem Zusammenhang entweder der Cursor in einem Eingabefeld oder der gepunktete Rahmen um z. B. eine Drucktaste oder ein Ankreuzfeld zu verstehen. Es kann sich auch um die geänderte Schrift- und/oder Hintergrundfarbe eines Eintrags in einem Baum oder einem Listenfeld (Listenfeld, kombiniertes Eingabefeld, Ausklappliste etc.) handeln.

Zur Navigation und Auswahl bzw. Aktivierung eines Oberflächenelements werden die von der Bedienungsoberfläche angebotenen Navigationstasten (Cursortasten, Tab-Taste mit Erweiterung durch die Strg- und die Umschalttaste) oder Auswahltasten (Leertaste, Eingabetaste) verwendet.

Bildwechsel und Fokus

Für den tastaturbasierend arbeitenden Anwender ist es zum direkten Einstieg in die Bearbeitung in hohem Maße hilfreich, einen Fokus im Programmfenster zu setzen. Das Setzen des Fokus' sollte hierbei der Programmlogik folgen, damit der Cursor immer dort zu finden ist, wo er im Sinne des Arbeitsablaufes sein sollte.

Vorteil von Hotkeys

Funktionen, die beispielsweise nur über die Werkzeugleiste zur Verfügung stehen, stellen eine Schwierigkeit für sehgeschädigte Anwender dar. Der Anwender muss in diesem Fall nämlich zunächst das Objekt selektieren, auf das er eine Funktion anwenden möchte und anschließend navigieren, um die gewünschte Funktion auszulösen. In solchen Fällen sollte ein Hotkey zum Auslösen der Funktion zur Verfügung stehen. Damit entfällt die Navigation nach der Auswahl des Objekts und der Arbeitsablauf wird beschleunigt.

 

Identifikation von Fensterinhalten

Für das vom sehgeschädigten Anwender verwendete Hilfsmittel ist es wichtig, dass das Programmfenster eine technische Struktur hat, die sich an den Standards des zugrunde liegenden Programmiermodells orientiert. An ihr kann z. B. ein Bildschirmausleseprogramm erkennen, ob ein fokussiertes Element eine Drucktaste, ein Eingabefeld oder ähnliches ist. Elemente, die aus Einzelkomponenten des Programmiermodells gänzlich neue Elemente definieren, kann ein Bildschirmvorleseprogramm nicht eindeutig identifizieren oder erkennt sie sogar falsch. Durch fehlgeleitete Rückschlüsse auf die Bedienung kann es zu Fehlbedienungen kommen.

Durch den Bezeichner, der technisch mit dem Fensterelement verbunden sein muss, erfährt der Anwender, wie das aktuell fokussierte Element heißt und weiß damit, wozu das Element dient. Die technische Assoziation ist zwingend notwendig, damit das Bildschirmvorleseprogramm diese beiden Informationen bestimmen und vermitteln kann.

Der Bezeichner eines Fensterelementes muss kurz, aber zugleich aussagekräftig sein. Idealerweise sollte der Bezeichnung möglichst sichtbar sein und nicht erst durch eine Aktion des Anwenders sichtbar werden. Dies ist besonders wichtig für Anwender, die mit einer Braillezeile arbeiten, da sie sonst nur grafische Symbole angezeigt bekommen, die für sie keine direkte Bedeutung haben.

Kombinationen aus Oberflächenelementen, wie z. B. ein zu einem Auswahlschalter gehörendes Eingabefeld oder eine Ausklappliste, die zur Festlegung eines Bezeichners dient, erschweren das Verständnis und sind häufig schwer bis gar nicht per Tastatur bedienbar.

 

Problemfelder

Die zunehmend interaktive Ausgestaltung von Anwendungen und die technische Abhängigkeit oder Inbezugsetzung von strukturierten Fensterinhalten bergen mitunter große Risiken im Hinblick auf die Barrierefreiheit und die effiziente Tastaturbedienbarkeit in sich. Wenn sich beispielsweise ein Teil des Programmfensters durch das Navigieren in einem anderen Bereich ändert, so setzt dies voraus, dass der Anwender extrem viel navigieren muss, um den veränderten Fensterbereich zu erreichen und durch ihn hindurch zu navigieren, um die neuen Inhalte zu interpretieren oder auszuwerten. Änderungen des Programmfensters solcher Art sollen also nicht nur durch Navigation, sondern durch explizite Selektion erfolgen.

Ein weiteres Problem für die Barrierefreiheit sind die sich neu etablierenden Technologien des Bildaufbaus und der Interaktion.

Programmoberflächen, die ganz oder teilweise aus einer Grafik bestehen, haben im Hinblick auf die Barrierefreiheit mehrere gravierende Nachteile:

  • Wenn z. B. das gesamte Programmfenster oder ein Teil von ihm aus einer großen Grafik mit klickbaren Bereichen besteht, ist hier zum einen keine Tastaturbedienbarkeit möglich. Zum anderen können die interaktiven Bereiche von Bildschirmvorleseprogrammen nicht erkannt werden, weil das Programmfenster an dieser Stelle lediglich eine visuelle anstelle einer technischen Struktur hat und nur aus Pixeln besteht.
  • Darüber hinaus wirken sich Änderungen bezüglich Schriftart und -größe, Kontraste und ähnliches, die in den Systemeinstellungen des Betriebssystems vorgenommen wurden, auf solche Fensterbereiche nicht aus. Auch dann nicht, wenn die Bedienungsoberfläche dies sonst zulässt. Für Anwender, die farbenblind sind, sind diese Programmteile nicht bedienbar.

 

Aspekte zur Unterstützung des Anwenders durch Effizienz und Ergonomie

Ein zentraler Aspekt einer betriebswirtschaftlichen Anwendung zur Unterstützung des Betriebsablaufes und dessen Verwaltung ist das Eingeben und Ändern von Daten. Deshalb soll die Tastatur für die Ausgestaltung der Navigation stets im Mittelpunkt stehen. Sie erlaubt sowohl die Eingabe von Daten und soll deshalb auch das Auslösen aller Funktionen des Systems unterstützen, um eine Arbeit mit mehreren Eingabemedien zu vermeiden. Für Anwender, die die Maus nicht benutzen können, ist dies extrem wichtig. Bei rein tastaturbasierender Arbeit muss im Sinne der Effizienz gewährleistet sein, dass man mit wenigen Tastendrücken jeweils zwischen den für den aktuellen Arbeitsschritt relevanten Daten schnell hin und her navigieren kann. Bildschirmbereiche, in denen Übersichts- und Detaildaten angezeigt werden, sollten deswegen unmittelbar nebeneinander platziert werden. Fensterbereiche, die Elemente zur Auswahl von Funktionen beinhalten, sollten nie zwischen solchen Bereichen platziert sein. Sie sollen über Menüs, die per Tastendruck aktiviert werden, erreichbar sein.

Elemente, die der Navigation dienen, sollten per Tastendruck ebenfalls direkt fokussierbar sein (z. B. Ctrl+y für die Ordnerliste in Microsoft Outlook). Sie sollten über Menüs zur Verfügung stehen, die per Tastendruck ohne zusätzliche Navigation aktivierbar sein. Auf diese Art und Weise kann der Fensterinhalt auf das Nötige reduziert werden und kann so wesendlich übersichtlicher und im Hinblick auf die Bedienung ergonomischer zur Verfügung gestellt werden.

 

Aspekte der Informationsübermittlung durch Spracheausgabe und Braillezeile

Während des Navigierens übermitteln die Sprachausgabe und die Braillezeile Informationen über den Fensterinhalt. Während die Sprachausgabe jeweils nur Informationen über das aktuell fokussierte UI-Element übermittelt, steht bei der zusätzlichen Benutzung einer Braillezeile ein gesamter Überblick über die Bildschirmzeile zur Verfügung, sobald ein Element den Fokus hat. Unter "Zeile" ist hier eine Gruppe von horizontal angeordneten Fensterelementen zu verstehen. So unterstützt die horizontale Anordnung semantisch zueinandergehöriger Elemente die bessere Interpretierbarkeit für blinde Anwender, die eine Braillezeile als Ergänzung zum Bildschirmvorleseprogramm verwenden.

Der Aspekt der horizontalen Anordnung von Oberflächenelementen ist für stark sehbehinderte Anwender mit einer Einschränkung des Gesichtsfeldes auch sehr hilfreich.

Für die Vermittlung von Bildschirminhalten ist es wichtig, dass dem Bildschirmvorleseprogramm bzw. dem Bildschirmvergrößerungsprogramm die Attribute, die das Fensterelement kennzeichnen (Bezeichner, Status), zur Verfügung stehen. Bei strukturierten Elementen (Tabellen, Bäume) sollten zusätzlich auch Informationen zur Fokusposition innerhalb der Struktur zur Verfügung stehen.

Zur optimalen Unterstützung des Anwenders ist die Abfolge dieser einzelnen Attribute und Eigenschaften sehr wichtig:

  • Als erstes sollte der Name des Elements, gefolgt vom Typ übermittelt werden. Als letzte Informationen sollten dann noch der Status und die Position und eine Anweisung, wie das Element zu bedienen ist, bekannt gegeben werden. Auf diese Weise kann als erstes am Namen des Elements erkannt werden, ob es das gewünschte Element ist. Wenn dann nach Miteilung des Typs bekannt ist, wie das Element zu bedienen ist, kann die Interaktion stattfinden. Wenn aber gleich im Anschluss mitgeteilt wird, dass das Element nicht verfügbar ist, kann weiter navigiert werden.
  • Die Position und die Navigations- bzw. Interaktionshilfe hat für den direkten Arbeitsablauf oft eine untergeordnete Funktion, hilft aber bei der Orientierung.
  • Die Information, um welche Art von Oberflächenelement es sich handelt und wie es zu bedienen ist, wird dann erst relevant, wenn die Interaktion mit dem Element gewünscht ist.
  • Die Hinweise über die Position und die Bedienung sind per Einstellung ein- und abschaltbar, denn sie werden ab einem gewissen Stand der Anwenderkenntnis nicht mehr benötigt.

Von Seiten der Technologie sollten diese Informationen an einer Schnittstelle in Form von Metadaten zur Verfügung stehen, die dann ein technisches Hilfsmittel zur Bereitstellung bzw. Übermittlung der Information verwenden kann.

Dies setzt zwar voraus, dass das Hilfsmittel diese Metadaten interpretieren kann. Sobald dies aber gewährleistet ist, vermittelt es dem Anwender die Oberfläche in einer Weise, die ihm auch von anderen Plattformen her vertraut ist. Auf Seiten der Technologie verringert dieses Vorgehen gleichzeitig den allgemeinen Entwicklungs- und Übersetzungsaufwand.

Ein solches Ineinandergreifen von GUI- und Hilfsmitteltechnologie hat darüber hinaus den Vorteil, dass der Hersteller der Hilfsmitteltechnologie in seinem Produkt Einstellungsmöglichkeiten vorsehen kann, die sich gezielt an Benutzerwünschen ausrichten.

Attribute "Nicht verfügbar" und "Nur lesen"

Bei der Übermittlung des Status von Elementen gilt es zwischen dem Attribut "Nicht verfügbar" und dem Attribut "Nur lesen" zu unterscheiden. "Nur lesen" ist ein Attribut für Texte, wenn diese nicht änderbar, sehr wohl aber ganz oder teilweise markierbar sein sollen, um sie über die Zwischenablage übertragen zu können. "Nicht verfügbar" ist ein Attribut für interaktive Elemente, wie z. B. eine Drucktaste oder ähnliches, die im aktuellen Anwendungskontext nicht zur Verfügung stehen.

An der Ansage eines der beiden Attribute erkennt der Anwender, welche Interaktionen auf das Element angewendet werden können und welche nicht.

Eine diesen Regeln nicht entsprechende Verwendung ist für den Benutzer irreführend.

Braillezeilen und Ergonomie

Wird ergänzend zum Bildschirmvorleseprogramm und seiner Sprachausgabe zusätzlich eine Braillezeile eingesetzt, hat der Anwender einen Überblick über eine gesamte Bildschirmzeile, sobald ein Element auf dieser Zeile den Fokus hat. Hier werden keine Attribut- und Typinformationen übermittelt, sind aber bei Bedarf abrufbar. Diese Zusatzinformationen können zwar wahlweise permanent angezeigt werden, nehmen so aber Platz in Anspruch, der für die Gesamtübersicht einer Bildschirmzeile verloren geht. In der Regel wird in diesen Modi sogar nur das jeweils fokussierte Element auf der Braillezeile mit Namens-, Typ- und Statusinformationen dargestellt, die dann eine ganze Zeile in Anspruch nehmen.

 

Tabellen

Bei strukturierten Inhalten wie z. B. Tabellen bzw. Listen sind die Informationen schwieriger zu interpretieren und zu handhaben als in Formularen. Diese zeigen zwar jeweils nur eine Ausprägung einer Informationsart (z. B. die Details einer Rechnung) an, sind aber aufgrund ihrer einfacheren Gestaltung durch die Abfolge von Ausgabefeldern einfacher zu erfassen als tabellarische Darstellungen. Diese bieten zwar mehr Informationen auf einen Blick, woraus der blinde oder stark sehbehinderte Anwender aber keinen Nutzen ziehen kann.

Bei Tabellen oder listenartigen Ausgaben ist die Verfügbarkeit von Überschriften für Spalten und Zeilen sehr wichtig, damit ein blinder Anwender weiß, welcher Art die Information in einer Tabellenzelle ist. Die Spaltenüberschriften fungieren hier sozusagen als Feldbezeichner der Zelle.

Die Überschrift einer Tabellenspalte muss technisch als eine solche definiert sein und sollte nur beim Eintritt in die Spalte angesagt werden. Bei vertikaler Navigation ist sie eine redundante Information und sollte für den Benutzer nur bei Bedarf über das verwendete Hilfsmittel abrufbar sein.

Sind mehrere Strukturen gleichzeitig sichtbar, die sich in Abhängigkeit zueinander ändern, ist dies mit hohem Navigationsaufwand für den sehgeschädigten Anwender verbunden, um die Daten interpretieren zu können.

Ein Beispiel hierfür ist die Auswahl eines Objekts in einer Tabelle, worauf die Details in einem zweiten Fensterbereich angezeigt werden.

In einem solchen Fall wäre ein explizites Setzen des Fokus', nachdem der Anwender einen Befehl zur Anzeige von Detaildaten gegeben hat, sehr hilfreich.

Um jedoch weniger Massendaten anzuzeigen und diese gleichzeitig besser handhaben zu können, wäre ein Suchdialog, der die Eingabe von Suchbegriffen unter gleichzeitiger Verkettung mit relationalen Daten ermöglicht, eine Alternative. Als Ausgabe der gefundenen Daten wäre ein Formular ideal, um sehgeschädigten Anwendern die Sichtung der Daten zu vereinfachen.

 

top top