Top 10 der größten Stolperfallen für barrierefreie DMS-Entwicklung

Zusammenfassung der Projektergebnisse

Erarbeitet im Rahmen des Forschungsprojekts iDESkmu - inklusive Dokumentenmanagementsysteme und Enterprise Content Managementsysteme in kleinen und mittleren Unternehmen, Verwaltungen und Verbänden der Selbsthilfe

Gefördert durch den Ausgleichsfonds für überregionale Vorhaben zur Teilhabe schwerbehinderter Menschen am Arbeitsleben des Bundesministeriums für Arbeit und Soziales

Projektträger: Der Blinden- und Sehbehindertenverein Hamburg e.V. (BSVH)

Projektpartner: HAVI Solutions GmbH & Co. KG sowie die Universität Siegen (Lehrstuhl Wirtschaftsinformatik und Neue Medien und Junior-Professur Wirtschaftsinformatik/IT für die alternde Gesellschaft)

Verfasser 
HAVI Solutions GmbH & Co. KG, Projektpartner iDESkmu
Detlef Girke, BITV-Consult, externer Berater iDESkmu

Quelle: iDESkmu 2021

Nächster Meilenstein im Projekt iDESkmu erreicht

Nach der Prüfung der Benutzeroberflächen von marktführenden DMS-Herstellerinnen und Herstellern hat das Team von iDESkmu die größten Einschränkungen in der Barrierefreiheit ermittelt und in einer gewichteten Liste zusammengefasst, um daraus Empfehlungen für Entwicklerinnen und Entwickler dieser Systeme abzuleiten.

Geprüft wurde auf Grundlage des BIT inklusiv Anwendungssoftware-Tests der Stufe I, welcher die Konformität mit der europäischen Norm EN 301 549 prüft, die Grundlage ist für die Beurteilung der Barrierefreiheit gem. der Verordnung zur Schaffung barrierefreier IT des Bundes von 2019. Der Test ist unter https://biti-wiki.de vollständig und öffentlich zugänglich dokumentiert.

Bewertungen nach diesem Prüfverfahren erfolgen nach dem folgenden Schema:

BewertungBeschreibung
Erfüllt:es gibt keinerlei Einschränkungen oder Barrieren
Leichte Einschränkung:es gibt zwar einen geringfügigen Mangel, doch wirkt sich dieser auf die barrierefreie Nutzung nicht negativ aus
Einschränkung:eine Nutzung ist zwar möglich, aber mit Hindernissen, die vor allem Zeit kosten und die Geduld von Anwenderinnen und Anwendern herausfordert
Barriere:eine Nutzung ist nur unter Aufwendung großer Anstrengungen und Kreativität im Umgang mit Hilfsmitteln möglich
Blockade:eine Nutzung ist für mindestens eine Gruppe von Menschen mit Behinderung nicht möglich

Um die zehn größten Stolpersteine herauszufinden, wurden die einzelnen Prüfschritte zunächst klassifiziert in 

  1. Anforderungen, ohne die keine Barrierefreiheit möglich ist, 
  2. Anforderungen, die für einen Grad der Barrierefreiheit sorgen, der Menschen mit Behinderung zur grundsätzlichen Nutzung des betreffenden DMS befähigt, 
  3. Anforderungen, die maximal als Einschränkung bewertet werden können. 

Dabei wurden sie anhand ihrer Bewertung wie folgt gewichtet:

Bewertung
Nicht anwendbar:
Erfüllt:
Leichte Einschränkung: 
Einschränkung: 
Barriere: 
Blockade: 

Die Prüfschritte, die mit Blockade bewertet wurden, sind also auch die, auf die Entwicklerinnen und Entwickler zukünftig verstärkt achten sollten.

Je höher der Punktabzug für ein DMS insgesamt ist, desto größer wird der anzunehmende Überarbeitungsaufwand hinsichtlich der Barrierefreiheit. Ein Beispiel ist der Einsatz von Farben: Während viele Anwendungen, die nicht barrierefrei sind, mit einem Ampel-System zur Kennzeichnung von z. B. Bearbeitungszuständen arbeiten, nutzen barrierefreie Anwendungen farbunabhängige Darstellungsformen für einen Status, damit sie auch von farbfehlsichtigen Menschen genutzt werden können.

Aus dem Vergleich der Prüfergebnisse durch das Team von iDESkmu ergeben sich die folgenden Prüfschritte als die mit den zehn größten Einschränkungen – sortiert nach Häufigkeit des größten Punktabzugs:

  • 4.01.0 - Wiedergabe von Text
  • 4.02.0 - Name für grafische Bedienelemente und Anzeigen
  • 3.01.0 - Tastaturbedienung für Bedienelemente
  • 7.02.1 - Objektinformationen für Hilfstechniken verfügbar machen
  • 4.03.1 - Name, Rolle, Wert für Formularfelder
  • 1.01.0 - Ausreichender Kontrast
  • 3.06.1 - Deutlich sichtbarer Tastaturfokus
  • 5.03.1 - Kontrastmodus ist nutzbar
  • 2.06.1 - Ausreichende Anweisungen für Benutzereingaben
  • 4.04.0 - Name für Gruppen von Elementen

Die folgenden Kriterien bilden denjenigen Teilbereich der Basiskriterien ab, die im Rahmen unserer Prüfungen negativ bewertet werden mussten. Ohne die Einhaltung dieser Kriterien ist keine barrierefreie Nutzung von DMS möglich:

  • 4.01.0 - Wiedergabe von Text
  • 4.02.0 - Name für grafische Bedienelemente und Anzeigen
  • 3.01.0 - Tastaturbedienung für Bedienelemente
  • 1.01.0 - Ausreichender Kontrast
  • 4.04.0 - Name für Gruppen von Elementen

Für Entwicklerinnen und Entwickler bedeutet das, dass sie vor allem auf die korrekte Wiedergabe aller textlichen Elemente durch Screenreader achten müssen. Das kann in der Regel durch eine Kombination aus der Bedienung mit der Tab-Taste sowie den Pfeiltasten bewerkstelligt werden. Manche Texte in Anwendungen sind aber nicht in der Tab-Reihenfolge enthalten. Das sind oft weniger relevante Infotexte, z. B. zur Version der Anwendung. Dennoch sollte es auch dafür eine Möglichkeit des Auslesens mit dem Screenreader geben.

Ein weiterer Stolperstein sind die Bezeichnungen grafischer Bedienelemente und die korrekte Konfiguration von Formularfeldern. Oft sind diese in der Accessibility-Schnittstelle nicht sauber implementiert, so dass Menschen, die z. B. auf einen Screenreader angewiesen sind, sich nicht in der Anwendung zurechtfinden können, weil dieser z. B. bei einem Formularfeld die Beschriftung des darüber liegenden Formulars vorliest oder bei Bedienelementen nur "Schalter" oder etwas Falsches ausgibt.

Als weiterer wichtiger Punkt ist die Navigation innerhalb der Anwendung mittels Tastatur zu nennen. Das lässt sich am einfachsten durch wiederholtes Drücken der Tab-Taste prüfen. Zum einen sollte daher eine nachvollziehbare Tab-Reihenfolge gegeben sein, zum anderen darf es keine Situation geben, in der man mit ausschließlicher Tastaturbedienung „gefangen“ ist, also in eine sogenannte Tastaturfalle gerät, aus der man nur herauskommt, wenn man mit der Maus irgendwo in die Anwendung klickt. Wer keine Maus hat, kommt dann nicht weiter. Viele Menschen mit körperlicher/visueller Beeinträchtigung sind ausnahmslos auf die Tastaturbedienung angewiesen. Darum ist bei der Entwicklung stets zu prüfen, ob die Anwendung komplett und komfortabel mit der Tastatur zu bedienen ist, z. B. mit Tastaturkürzeln für ein schnelles Anspringen wichtiger Funktionen oder Bereiche wie Navigation, Strukturbaum, Inhaltsbereich oder Statuszeile. Und all dies sollte natürlich nicht nur dann funktionieren, wenn man einen Screenreader benutzt, sondern immer.

Bedeutend hierbei ist außerdem, dass von Screenreadern der Name des betreffenden Bereichs ausgegeben wird. Das ist wichtig, denn sonst muss bei Nutzung eines Screenreaders erst hin und her gesprungen werden, um aus dem Kontext den Anwendungsbereich erraten zu können.

Auch ist bei der Tastaturbedienbarkeit die lineare Reihenfolge der Elemente wichtig, um Menschen mit Behinderung nicht unnötig zu verwirren. Wenn z.B. ein Mensch mit Sehbehinderung auf die Verwendung von Vergrößerungssoftware angewiesen ist und beim wiederholten Drücken der Tab-Taste Elemente erreicht, die in keinem sinnvollen Kontext zueinander stehen, dann kann das auch bei vollständiger Tastaturbedienbarkeit als gravierender Mangel betrachtet werden. Glücklicherweise ist dieses Kriterium bei den meisten DMS erfüllt.

Außerdem gilt es bei der Entwicklung von User Interfaces darauf zu achten, dass die Elemente mit ausreichendem Kontrast zum Hintergrund versehen sind, bzw. dass es die Möglichkeit gibt, diesen manuell zu konfigurieren. Ansonsten können Menschen mit visueller Beeinträchtigung die Elemente nicht deutlich erkennen.

Von den Prüfschritten, die bei Erfüllung zu einer (wenn auch nicht immer komfortablen) Nutzung führen und mit denen Herstellerinnen und Hersteller zeigen können, dass sie die Prinzipien der Barrierefreiheit grundsätzlich verstanden haben und umsetzen können, sind noch vier in unserer Top 10:

  • 7.02.1 - Objektinformationen für Hilfstechniken verfügbar machen
  • 4.03.1 - Name, Rolle, Wert für Formularfelder
  • 3.06.1 - Deutlich sichtbarer Tastaturfokus
  • 2.06.1 - Ausreichende Anweisungen für Benutzereingaben

Also zwei weitere Kriterien, die beim Einsatz von z. B. Screenreadern zum Tragen kommen, weil bei Erfüllung die semantische Korrektheit von Elementen immer berücksichtigt und die Accessibility API des Betriebssystems mit allen für Hilfsmittel notwendigen Informationen versorgt wird.

Der aktuelle Tastaturfokus sollte immer sehr leicht erkennbar sein. Wenn man mit der Maus navigiert, dann hat man als sehender Mensch immer die Möglichkeit zu erkennen, wo man sich gerade befindet. Ein kurzes Wackeln an der Maus zeigt das durch die Bewegung des Mauszeigers noch deutlicher an. Der Tastaturfokus ist aber statisch. Und wenn er nur durch einen dünnen Rahmen gekennzeichnet ist, dann haben nicht nur Menschen mit Sehbehinderung Probleme zu erkennen, wo am Bildschirm sie sich gerade befinden, sondern selbst Menschen mit guten Augen. Das haben unsere Interviews mit Betroffenen und Nicht-Betroffenen eindeutig gezeigt. Ein recht dicker schwarzer Rahmen um das gerade im Fokus befindliche Element wird von nahezu allen Nutzerinnen und Nutzern - entgegen allen Befürchtungen von Designern - als angenehm empfunden.

Und wer wünscht sich das nicht? Eine Anwendung, die sich selbst erklärt. Kontextuelle Hilfefunktionen, für sich sprechende Beschriftungen und Tooltipps, die ihrem Namen gerecht werden. All das zeigt nicht nur, dass an Menschen mit Behinderung gedacht wurde, es ist auch bedeutend für eine gute Usability, denn solche Anweisungen machen eine intuitive Nutzung innerhalb der Anwendung möglich.

Zu guter Letzt gibt es noch ein Kriterium, dessen Nichteinhalten zwar weniger gravierende Folgen hat, weil es z. B. Hilfsmittel gibt, die diese Funktion ebenfalls bereitstellen, es ist aber bei vielen Menschen mit Sehbehinderung sehr beliebt, weil es auf den ersten Blick eine schnelle Abhilfe verspricht:

  • 5.03.1 - Kontrastmodus ist nutzbar

Den Kontrast einer Anwendung mit wenige Klicks in den Windows-Einstellungen ändern zu können, ist ein sehr hilfreiches Feature. Leider wurde dieses Feature in den letzten Jahren nicht konsequent an die neueren Oberflächen-Technologien angepasst. So kommt es mittlerweile leider häufiger vor, dass eine Anwendung nach Aktivierung des Kontrastmodus schlechter nutzbar ist als zuvor, weil z.B. plötzlich schwarze Schrift auf schwarzem Grund dargestellt wird.

Aber es gibt einen Ausweg: Wenn der Kontrastmodus unter Windows nicht gut nutzbar sein sollte, kann eine professionelle Vergrößerungssoftware hinzugezogen werden, welche immer auch verschiedene Modi zur Individualisierung der Vorder- und Hintergrundfarbe bereitstellt. Daher wird dieser Mangel als nicht so gravierend angesehen. Zwar wäre es der optimale Zustand, wenn solche Hilfsmittel Teil des Betriebssystems wären, doch auch mit dem in Windows eingebauten Screenreader verhält es sich so, dass Drittanbieter-Software immer noch die bessere Wahl ist. Es bleibt zu hoffen, dass Microsoft seine Kontrasteinstellungen wieder dem Stand der Technik anpasst.

Bei Anmerkungen und auch bei Fragen zur Umsetzung der aufgeführten Punkte steht das Team von iDESkmu – insbesondere Detlef Girke, Inhaber von BITV-Consult, und Paul Matthias von der Firma HAVI zur Verfügung.

Paul Matthias pmatthias@havi.de

Detlef Girke girke@bitvconsult.de

Sie möchten mehr über iDESkmu erfahren?

Wir informieren Sie gerne!

E-Mail: info@projekt-ideskmu.de