Wie beurteilt man die Barrierefreiheit von Desktop-Anwendungen?


Einleitung

Die Zugänglichkeit bzw. die Barrierefreiheit von Webseiten ist mittlerweile ein verbreitetes Kriterium, wenn es darum geht, ob Webanwendungen oder -Seiten von Menschen mit Behinderungen genutzt werden können. I.d.R. wird mit Zugänglichkeit und Barrierefreiheit die Zielgruppe der blinden und sehbehinderten Menschen angesprochen, weil diese durch die Nutzung eines Bildschirms am stärksten betroffen sind. Es gibt aber auch Barrieren für andere Menschen, die weniger offensichtlich sind. Z.B. können komplizierte Tastenkombinationen für motorisch eingeschränkte Menschen zur Barriere werden oder Informationen die nur akustisch verfügbar sind für gehörlose Menschen unzugänglich sein.

Auch ich werde mich im Wesentlichen der Zielgruppe der blinden und sehbehinderten Menschen widmen, möchte aber betonen, dass dies nur ein, wenn auch großer Aspekt des Themas ist. Für Feedback und Input zu den anderen Aspekten bin ich gleich wohl immer dankbar.

Auf dieser Seite möchte ich mich nun, abseits der Zugänglichkeit von Webseiten, der Zugänglichkeit von Desktop-Anwendungen widmen. Damit sind alle Nicht-Web-Anwendungen gemeint egal mit welcher Technologie etc. sie erstellt wurden. Es gibt zwar eine ganze Reihe von Checklisten und Anleitungen zu diesem Thema, aber sie beleuchten das ganze immer nur aus der technischen Sicht einer bestimmten Entwicklungsumgebung. Was aber, wenn die Umgebung noch gar nicht gesetzt ist und erst anhand der möglichen Zugänglichkeit entschieden werden muss? Wann ist eine Anwendung zugänglich und wann nicht? Nicht zuletzt soll diese Seite auch Nicht-Techniker an das Thema heranführen und sie dazu befähigen, die Zugänglichkeit einer Anwendung zu beurteilen.

Das hier vorgestellte Verfahren ist auch auf Webseiten und Webanwendungen anwendbar, aber es gibt für diesen Bereich bereits gute und erprobte Prüfverfahren, die ich hier nicht in Zweifel stellen möchte. Apropos: Das vorgestellte Verfahren ist aus meiner Sicht eine Art Rahmen. Wenn Checklisten, detaillierte Prüfwerkzeuge helfen können, die einzelnen Prüfungen nachvollziehbar und reproduzierbar auszugestalten, dann finde ich dies sehr hilfreich. Ich möchte diesen Artikel also nicht als Gegenvorschlag oder Alternative, sondern als grundsätzliche Herangehensweise verstanden wissen.

Definitionen

Ich versuche hier mal ein paar Definitionen, so wie ich sie auffasse und verstehe. Sie sind zur Diskussion gedacht.

Zugänglichkeit einer Anwendung

Eine Anwendung ist für ein Arbeits- oder Aufgabengebiet zugänglich, wenn alle Anwendungsfälle, die für bestimmte Aufgaben oder Arbeitsgebiete notwendig sind, mit einem Screenreader ausführbar sind. Die Unterstützung durch einer externen Hilfe z.B. das Klicken durch eine Hilfsperson, oder das Vorlesen von Bildschirminhalten sind dabei unzulässig. Die Zugänglichkeit beschreibt das zwingend notwendige Minimum an Nutzbarkeit einer Anwendung durch einen Screenreader-Nutzer, ohne dem ein Einsatz nicht mehr möglich ist. Dies gilt auch für die benötigte Zeit zur Erledigung einer Aufgabe: Können Informationen zwar theoretisch gefunden werden, aber die Suche braucht inakzeptabel viel Zeit, dann ist die Anwendung trotzdem unzugänglich.

Äquivalent dazu kann man ein Gebäude als Zugänglich für einen Rollstuhlfahrer betrachten, wenn er ohne fremde Hilfe, aber evtl. mit einiger Mühe, alle Räume und Einrichtungen benutzen kann, die er für seinen Aufenthalt braucht.

Barrierefreiheit

Die Barrierefreiheit einer Anwendung für ein Aufgabengebiet bedeutet, dass alle anwendungsfälle für ein bestimmtes Aufgabengebiet oder Arbeitsgebiet ohne Einschränkungen in ähnlicher Zeit wie bei einem Anwender ohne Behinderung ausgeführt werden können. Die Barrierefreiheit bedeutet also, dass ein Screenreader-Nutzer genauso effizient und Mühelos mit einer Anwendung arbeiten kann, wie alle anderen Anwender auch. Dabei ist es zulässig, dass spezielle Kenntnisse des Screenreaders notwendig sind, um diese Effizienz zu erreichen. Es ist auch zulässig und oft auch sinnvoll, wenn ein Screenreader-Nutzer einen anderen Weg durch einen Anwendungsfall wählt. Z.B. kann er statt ein Bild in die richtige Größe zu ziehen, die Größe durch einen Eigenschaftsdialog angeben.

Die Notwendigkeit für spezielle Screenreader Kenntnisse ergibt sich daraus, dass bei einer Anwendung evtl. nicht alle relevanten Informationen direkt am Fokus dargestellt werden. Es ist also in bestimmten Situationen notwendig, in andere Ecken zu schauen, Zusatzinformationen und abzurufen, die jenseits des Fokus stehen. Anwendung sind nicht dafür verantwortlich, alle Informationen so aufzubereiten, dass sie automatisch vom Screenreader vorgelesen werden. Oft ist es auch der Anwender, der entscheiden muss, ob er zum aktuellen Zeitpunkt Zusatzinformationen wünscht. Ein Beispiel: Eclipse zeigt an, wenn man in einer Programmzeile einen Fehler gemacht hat. Dies könnte permanent beim Schreiben vorgelesen werden, was sehr störned sein kann, aber wenn ich weiß, dass ich gerade eine Methode schreibe, dann weiß ich auch, dass noch Fehler enthalten sind – die Methode noch nicht fertig ist. Sehende Anwender ignorieren die Hervorhebung und so muss es dem Anwender überlassen sein, ob er diese Zusatzinformationen haben möchte.

Eine Anwendung ist streng genommen auch dann barrierefrei, wenn sie sich an die Standards der zugänglichkeitsschnittstellen hält, aber der Screenreader nicht wie von der Schnittstelle vorgesehenarbeitet. Das nutzt dem Anwender nichts – er kann dann immer noch nicht mit der Anwendung arbeiten, aber die Verantwortung liegt beim Screenreader.

Äquivalent dazu bedeutet die Barrierefreiheit für einen Rollstuhlfahrer, dass er nicht über die Postrampe das Gebäude von der Rückseite betreten muss, sondern genauso einfach und mühelos das Gebäude betreten und verlassen kann wie alle anderen Personen auch. Ob die Türen durch Fernbedienung oder angebrachte Schalter geöffnet werden, während ein anderer Anwender sie schlicht mit der Hand öffnet ist dabei unerheblich. Ist der Rollstuhl aber breiter, als es die Norm vorsieht, dann ist das Gebäude, der eigentümer nicht daran Schuld, dass der Anwender eine Tür nicht passieren kann.

Die Barrierefreiheit stellt damit entgegen der Zugänglichkeit das Optimum dar. Barriere bedeutet zwar in erster Linie etwas unüberwindbares, aber ich möchte hier auch niedrige Barrieren adressieren.

Abweichende Auffassungen

Einige Experten sin der Meinung, dass es keinen wirklichen Unterschied zwischen Barrierefreiheit und Zugänglichkeit gibt. Mir geht es in erster Linie um eine praxisnahe Auslegung der Begriffe und dort erlebe ich den Unterschied. Es gibt Anwendungen, die man mit einem Screenreader mehr schlecht als Recht bedienen kann. Es dauert alles ein wenig länger, ist nicht wirklich komfortabel und man muss die Hindernisse kennen. Das ist nicht barrierefrei, aber zur Not nutzbar und damit zugänglich. Letztlich ist es unerheblich, ob die Anwendung nun als zugänglich oder nicht barrierefrei bezeichnet wird. Sie ist nur mühsam und damit nicht ohne Hindernisse bedienbar und das ist i.d.R. problematisch. Weil sich viele Anwendungen in eben diesem Status befinden, wenn es gut läuft, halte ich dies für einen wichtigen Punkt. Ein Arbeitnehmer, der auf die Anwendung angewiesen ist, könnte u.U. bereits seine Arbeit aufnehmen, aber es sind weitere Verbesserungen zur Erreichung der Barrierefreiheit notwendig. Das ist nicht Schöndenkerei, sondern einfache Betriebswirtschaft. Solange der Anwender ineffizient und möglicherweise fehlerträchtig mit der Anwendung arbeiten muss, kostet er mehr Geld als mit einer barrierefreien Anwendung. Außerdem hat eine solche barrierebehaftete Anwendung großen Einfluss auf das Wohlbefinden des Anwenders. Wenn Word sehr langsam läuft oder alle paar >Minuten einen Fehler anzeigt, dann nervt das. Der Anwender wird, egal wie toll die Funktionen der Anwendung auch sein mögen das Programm verabscheuen. Das gleiche gilt für Anwendungen, die für Screenreader-Nutzer Barrieren enthalten.

Anwendungsfälle für ein bestimmtes aufgabengebiet

Warum mache ich eine Einschränkung auf die Anwendungsfälle eines bestimmten Arbeits- oder Aufgabengebiets? Warum fordere ich nicht, dass alle Anwendungsfälle zugänglich oder barrierefrei sein müssen? Ich möchte das an einem Beispiel deutlich machen. Die Nutzung von Word als Textverarbeitungsprogramm ist für viele blinde Menschen kein Problem. Es gibt eine Vielzahl von Schreibkräften, die genau damit ihren Lebensunterhalt verdienen und sich nicht verstecken müssen. Für dieses aufgabengebiet ist Word zumindest Zugänglich, wenn nicht barrierefrei. Versucht hingegen ein Anwender mit ähnlichen Einschränkungen mit Word anspruchsvolle Layouts zu erstellen, Bilder zu platzieren oder andere Aufgaben die für aufwändige Präsentationen gebraucht werden, so wird Word sich sehr schnell als nicht mehr barrierefrei oder gar unzugänglich erweisen. Und was ist Word nun? Ist Excel nur deshalb unzugänglich, weil man mit einem Screenreader Diagramme nicht justieren kann? Wenn das Justieren von Bildern und Diagrammen für die Arbeit notwendig ist, dann ja, aber sonst nein! Ist PowerPoint zugänglich, weil man eine Reihe von Textfolien erstellen, sie einer Masterfolie zuweisen und andere Dinge tun kann? Oder ist die Anwendung unzugänglich, weil es nicht möglich ist diese hübschen Folienübergänge aufeinander abzustimmen und damit ein professionelles Bild abzugeben? Es kommt auf die Anforderungen an!

Mit einem Screenreader bedienbar

Ein Anwendungsfall ist mit einem Screenreader bedienbar wenn die folgenden Kriterien erfüllt sind:

  • Es kann mind. ein bestimmter aktueller Screenreader verwendet werden. Es ist zwar wünschenswert, aber nicht notwendig, dass alle üblichen Screenreader verwendet werden können.
  • Der Anwender verfügt über das notwendige Fachwissen für den Anwendungsfall und ist mit dem Aufbau der Benutzeroberfläche vertraut. Es geht also nicht darum sich die Oberfläche zu erschließen, sondern sie z.B. nach einer Schulung bedienen zu können.
  • Alle Aktionen sind mind. über Kontextmenüs verfügbar und können optional über Tastenkombinationen durchgeführt werden. Menüs sind dabei zwingend, Tastenkombinationen wünschenswert, weil davon ausgegangen werden muss, dass ein Anwender nicht alle Tastenkombinationen im Kopf haben kann. Ein Beispiel für diesen Missstand ist Audacitty. Hier sind viele Aktionen zwar über Tastenkombinationen erreichbar, aber nicht über das Menü. Damit müsste der Anwender ständig eine Referenz der Befehle zur Hand haben. Ein Positivbeispiel ist dagegen die Entwicklungsumgebung Eclipse bei der alle Befehle sich in Menüs befinden und für die gleichzeitig die Tastenkombinationen verfügbar sind und auch vorgelesen werden.
  • Spezielle Kommandos des Screenreaders sind zur Abarbeitung des Anwendungsfalls zulässig, sollten aber nach Möglichkeit vermieden werden. Solche Kommandos können notwendig sein, wenn verschiedene Informationen während der Arbeit aus der Oberfläche abgerufen werden müssen. Z.B. kann es notwendig sein einen bestimmten Eintrag aus der Statuszeile auszulesen.
  • Der Anwender kann ohne die Hilfe einer anderen Person oder Zusatztools den Anwendungsfall durchführen. Solche Zusatztools könnten z.B. OCR-Aufrufe sein um eigentlich unzugängliche Informationen auszulesen.

Durchführung eines Tests auf Zugänglichkeit oder Barrierefreiheit

Grundsätzlicher Ablauf

  1. Ein Fachanwender, Arbeitgeber oder anderweitig verantwortlicher liefert eine Liste der Anwendungsfälle, die mit der Anwendung durchführbar sein müssen, damit sie als Zugänglich bzw. barrierefrei gelten kann. Das hängt im Wesentlichen davon ab, welche Arbeiten mit der Anwendung ausgeführt werden sollen. Gibt es hier keine klaren Angaben bzw. Begründungen, warum bestimmte Anwendungsfälle ausgeschlossen werden sollen, so betrifft der Test alle Anwendungsfälle, die mit der Anwendung möglich sind.
  2. Der Hersteller der Anwendung liefert für alle Anwendungsfälle, die zuvor identifiziert wurden, ein bzw. mehrere Sequenzdiagramme, die dokumentieren, wie der Anwendungsfall mit der Anwendung durchgeführt werden kann. Das Sequenzdiagramm muss mind. alle notwendigen Tastatureingaben enthalten und sollte wenn möglich die Reaktion des Screenreaders darstellen. Die Sequenzdiagramme sind in PlantUml zu erstellen, damit sie für blinde und sehbehinderte Menschen wie für alle anderen zugänglich sind. Hier zeigen sich ggf. erste Unzulänglichkeiten z.B. wenn ein Anwendungsfall nur mit Unterstützung der Maus durchgeführt werden kann. Anwendungsfälle, die es erforderlich machen, eine Maus zu bedienen gelten als unzugänglich.
  3. Anwender, die mit einem zu testendem Screenreader und der Anwendung vertraut sind, prüfen nun direkt die Anwendungsfälle. Sie orientieren sich dabei an den Sequenzdiagrammen. Hier können Unterschiede in den Screenreadern, den Plattformen etc. identifiziert werden. Durch die Orientierung an Anwendungsfällen und dokumentierten Sequenzdiagramen, die durch die Anwendungsfälle führen, können Barrieren eindeutig und nachvollziehbar lokalisiert und dokumentiert werden. Die Sequenzdiagramme sollten auch alle fachlich relevanten Informationen berücksichtigen, die während des Anwendungsfalls angezeigt werden. Es ist nicht ausreichend Aktionen durchzuführen und dabei von Vorgaben und Ausgaben auszugehen. Man muss sich einen Anwender vorstellen, der die Anwendung und insbesondere den Anwendungsfall zum ersten Mal durchführt. Dieser Anwender wird penibel auf alle Meldungen, Statusanzeigen etc. reagieren.
  4. Eine Aufnahme des Tests, Protokolldateien wie die Log-Datei von NVDA bzw. ein Mitschnitt von Ein- und Ausgaben als Video dokumentieren den Test nachvollziehbar. Wird zusätzlich eine Zeitangabe bei allen Ein- und Ausgaben mitgeschrieben, können Unterschiede in den Screenreadern und den Herangehensweisen der Tester lokalisiert werden.
  5. Am Ende eines Tests müssen für alle Anwendungsfälle die Testergebnisse zeigen ob sie unzugänglich, zugänglich bzw. barrierefrei sind. Durch das detaillierte Auflisten der Anwendungsfälle kann z.B. priorisiert werden, welche davon korrigiert werden müssen um einen Minimaleinsatz zu ermöglichen.

Anwendungsfälle durch Verantwortliche

In der Vergangenheit habe ich Anwendungen oft durch intuitives Ausprobieren getestet. Ein solches Verfahren ist für komplexe Anwendungen nicht möglich und liefert nur punktuelle Ergebnisse. Im besten Fall taugt ein solches Vorgehen als Vortest um zu prüfen, ob ein vollständiger Test überhaupt Sinn macht. Lassen wir also die Leute, die fachlich von der Anwendung etwas verstehen, auswählen welche Anwendungsfälle relevant sind. Bei Anwendungen, die der BITV oder anderen gesetzlichen Regeluneen unterliegen sind dies quasi alle. Die einzige Ausnahme dürften Anwendungsfälle darstellen, bei denen der Anwendungsfall selbst optische Anforderungen hat. z.B. wird es nicht möglich sein, das Zuschneiden von Grafiken barrierefrei zu gestalten, weil hierfür das Sehen des Bildes zwingend notwendig ist.

Ausführungspfad durch Hersteller

Man könnte anhand der Dokumentation der anwendung versuchen, die einzelnen Anwendungsfälle abzuarbeiten. Es ist aber nicht einzusehen, dass ein Tester nach Tastenkombinationen, Menüeinträgen etc. sucht, um die Tests durchführen zu können. außerdem besteht damit immer die Gefahr, dass ein Hersteller sich bei seinen eigenen Tests auf unbekannte Tastenkombinationen beruft. Lassen wir also diejenigen, die die Anwendung erstellt haben, dokumentieren, wie die Anwendungsfälle barrierefrei abzuarbeiten sind. Zur Erinnerung: Barrierefreiheit ist eine Bringschuld der Hersteller.
Damit die Abarbeitung der Anwendungsfälle nachvollziehbar dokumentiert ist, werden Sequenzdiagramme verwendet. Sie sind genau für solche Zwecke gedacht, bei denen es darum geht, detailliert darzustellen, wie eine Kommunikation zwischen Anwender und System ablaufen muss. Eine Verwendung von Aktivitätsdiagrammen bei Anwendungsfällen mit vielen Verzweigungen ist möglich. PlantUml ist derzeit die einzige tragfähige Darstellungsmöglichkeit von UML-Diagrammen für blinde und sehbehinderte Menschen. Gleichzeitig ist sie einfach erlernbar und liefert optisch relativ ansprechende Ergebnisse.
Ein Sequenzdiagramm enthält dabei bei einer Benutzereingabe eine Nachricht vom Anwender an das System. Die Ausgabe hingegen verläuft vom System über den Screenreader zum Anwender. Damit kann deutlich gemacht werden, dass das System eine bestimmte Reaktion zeigt und wie der Screenreader sie verarbeitet. Werden spezielle Screenreaderkommandos genutzt z.B. um Drag-And-Drop auszuführen, so verläuft auch die Eingabe über drei Stationen: Vom Anwender zum Screenreader und von dort zum System.

Plausible Ausführungspfade

Ein vom Hersteller gelieferter Ausführungspfad für einen Anwendungsfall zeigt zunächst nur, dass der Anwendungsfall mit der Tastatur bedient werden kann. Aber würde ein blinder oder sehbehinderter Anwender diesen Weg auch finden? Äquivalent dazu würde man fordern, dass rollstuhlgerechte Toiletten in einem Gebäude ausgeschildert sind. Das mühevolle suchen selbst kann man als Barriere auffassen.

Sind alle relevanten Informationen auf dem Weg verfügbar?

Kommen wir nun zum Kern der Fragestellung: Eine Anwendung kann nur zugänglich bzw. barrierefrei sein, wenn zu jedem Zeitpunkt der Abarbeitung eines Anwendungsfalls alle erforderlichen (und falls möglich auch alle weiterhin hilfreichen Informationen) zur Verfügung stehen. Immerhin folgt der Anwender in der Praxis nicht einem vorgegebenen Weg, sondern muss anhand seiner konkreten Situation entscheiden, welche Optionen er auswählt etc. Die Frage lautet also: Kann ein Anwender den gleichen Anwendungsfall mit anderen Daten genauso problemlos ausführen wie es der Ausführungspfad vorsieht? Der Hersteller kann hierfür Anmerkungen bzw. Unterdiagramme verwenden um deutlich zu machen welche Informationen wie gewonnen werden.

Ein Beispiel: Ein Anwender möchte ein Dokument aus Word heraus auf einem bestimmten Drucker doppelseitig ausgeben.

  • Er öffnet das Dokument
  • Er wählt die Aktion Drucken entweder per Tastenkombination oder aus dem Menü.
  • Der Drucken-Dialog erscheint.
  • Der Anwender benötigt nun folgende Informationen um seine Arbeit erfolgreich auszuführen:

    • Ist der richtige Drucker ausgewählt?
    • Ist die Option doppelseitig ausgewählt
  • Der Anwender aktiviert den Schalter Drucken.

Während für alle Anwender ohne Einschränkung die Informationen über den ausgewählten Drucker und die relevanten Optionen unmittelbar sichtbar sind, müssen diese vom Screenreadernutzer nacheinander eingeholt werden. Gelingt das Beschaffen der Informationen nicht – weil z.B. die Druckerauswahl nicht per Tastatur angesprungen werden kann, so ist der Anwendungsfall nicht barrierefrei. Der Anwender kann zwar die relevanten Aktionen auslösen, ihm fehlen aber relevante Informationen um zu entscheiden wie er vorgehen muss. Welche Informationen im Anwendungsfall an welcher Stelle relevant sind, ergibt sich aus den möglichen weiterenVverzweigungen. Wenn es nur eine mögliche Option gibt, sind i. d. R. keine relevanten Informationen für eine Entscheidung vorhanden. U.U. sind bestimmte Informationen für nachfolgende Schritte notwendig – z.B. wenn eine Meldungsbox über Erfolg oder Misserfolg einer Aktion informiert, aber nur die Option OK hat. Dann kann der Anwender zwar direkt keine Entscheidung fällen, braucht die angezeigte Meldung aber für weitere Schritte.

Wie kann ein Hersteller die benötigten Informationen für einen Screenreadernutzer identifizieren?

Alle Informationen, die an einem bestimmten Punkt im Ausführungspfad notwendig sind ergeben sich aus folgenden Fragen:

  • Aufgrund welcher Informationen wähle ich die nächste Aktion?
  • Was prüfe ich als Anwender vor der Aktion?
  • Welche bisherigen Ergebnisse und Informationen ziehe ich für die Entscheidung heran?
  • Warum wähle ich diese Option genau zu diesem Zeitpunkt?
  • Was will ich mit der Auswahl einer Aktion oder Option erreichen?

Diese Fragen erfordern sicher einige Übung. Aber im Endeffekt sollten sie fast alle benötigten Informationen identifizieren. Auf diese Art und Weise wird der Hersteller konsequent mit seiner Anwendung konfrontiert – ist die Benutzerführung überhaupt logisch und sinnvoll? Ist überhaupt eine stringente Benutzerführung erkennbar und dokumentiert?^

Diese Fragen beantworten nur, was benötigt wird, aber nicht, ob sie für den Screenreader erreichbar sind. Dies benötigt detaillierte kenntnisse von Screenreadern und Zugänglichkeitsschnittstellen. So lange sich der hersteller an die empfohlenen Richtlinien zur Zugänglichkeit von Anwendungen (abhähngig von der verwendeten Technologie) hält, hat er gute Chancen, dass der Screenreader findet, was der Anwedner sucht.

Dokumentation des Tests

Tests sind nur dann belastbar, wenn sie nachvollziehbar, wiederholbar und dokumentiert sind. Wie können wir unumstößlich Barrieren oder eben die Zugänglichkeit beweisen, wenn wir nicht dokumentieren was wir getan haben und wie das System reagiert hat? Ein zusammenfassendes Testprotokoll ist sicher in jedem Fall notwendig, aber als Vorarbeit ist eine vollständige Dokumentation von Ein- und ausgaben erforderlich. Hier können glücklicherweise Aufnahmen (audio und video), Log-Dateien etc. weiterhelfen. Welche für einen Test relevant sind, hängt von der zu testenden Anwendung, dem verwendeten Screenreader bzw. der Großschriftsoftware ab. Solche Protokolle können teilweise auch dann ausgewertet werden, wenn die zu testende Anwendung nicht verfügbar ist. Sie sind gleichzeitig sehr gute Fehlerbeschreibungen bei Barrieren, mit denen Entwickler sich umgehend mit der Beseitigung beschäftigen können.

Apropos Großschrift: Viele Anwender mit einer Sehbehinderung erleben Barrieren durch fest eingestellte Schriften, Schriftgrößen und Farbdarstellungen. Ein Test kann und sollte nach Möglichkeit in den Anwendungsfällen prüfen, ob die relevanten informationen ausreichend optisch gestaltet sind und ob ein Anwender mit Sehbehinderung die Darstellung seinen Bedürfnissen anpassen kann. Eine weitere Barriere kann auch sein, wenn relevante Informationen zu stark über den Schirm verstreut sind. Komplexe Anwendungen verwenden mittlerweile so viele Fenster, dass Anwender ohne Seheinschränkungen zwei große Monitore verwenden, um die benötigten Informationen gut darstellen zu können.

Fazit

Das hier vorgestellte Verfahren beschreibt nicht, wie eine Anwendung barrierefrei gestaltet werden kann, sondern wie man die Zugänglichkeit überprüfen kann. Die Anwendung des Verfahrens benötigt keine technischen Spezialkenntnisse. Allerdings werden rudimentäre Grundlagen im Lesen von UML-Diagrammen benötigt. UML ist in jedem Fall die richtige Wahl, weil nur diese Sprache eine anerkannte, tragfähige und praktikable Möglichkeit zur Darstellung des Systemverhaltens ist. Die erwähnten UML-Diagramme sind in PlantUml gut genug umgesetzt, sodass einer Nutzung von allen beteiligten nichts im Wege steht. Das Vorgehen liefert eine systematische Lokalisierung von Barrieren aus
Sicht der beteiligten Hilfsmittel. Tests können anhand der Anwendungsfälle parallelisiert, verglichen und zusammengeführt werden. Verantwortlichen und Herstellern wird von Beginn an bewusst, welche Teile der Anwendung barrierefrei sein müssen. Ein Hersteller, der es mit der Barrierefreiheit ernst nimmt sollte beim Erstellen der Sequenzdiagramme die meisten Barrieren bereits selbst finden können. Das Vorgehen kann auch bei Agilen Entwicklungen genutzt werden um neue oder geänderte Userstories bei ihrer Umsetzung auf Barrierefreiheit zu prüfen.

Ein Gedanke zu „Wie beurteilt man die Barrierefreiheit von Desktop-Anwendungen?

  1. Johannes

    Hallo Heiko, der Entwurf ist aus meiner Sicht schon sehr gut, wenn man bedenkt, dass es uns IT-lern nicht immer leicht fällt, die Technik außer Acht zu lassen. Mir fehlt jedoch ein wesentliches Kriterium zur Definition der Barrierefreiheit, nämlich der Zeitfaktor. Barrierefreiheit ist gegeben, wenn eine Aktion bei einem versierten Screenreaderbenutzer nur unwesentlich länger dauert als ohne Verwendung des Screenreaders. Dies schließt die Ergebniskontrolle ein. Beispiel: Wenn man mit sehr vielen Tastenkombinationen ein Ergebnis kontrollieren muss, das der Sehende sofort optisch erfasst, ist die betreffende Funktion nicht barrierefrei. Weiterhin ist es wichtig, dass barrierefreie Anwendungen schon bei Installation funktionieren, ohne dass Zusatzpakete installiert werden müssen. Hier ist die Ausweis-App ein schlechtes Beispiel! Zumindest muss dem Anwender in barrierefreier Weise die Installation aller zur Barrierefreiheit wichtiger Komponenten ermöglicht werden. Viele Grüße. Johannes

    Antworten

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>