Seit der Einführung von Google Docs im Jahr 2006 [1] zeichnet sich ein Trend ab: Immer mehr Software-Anwendungen laufen nicht mehr als Desktop-Anwendung auf unseren Rechnern – sondern im Webbrowser. Dies hat in der Praxis viele Vorteile: Die Software kann ohne zusätzlichen Installationsaufwand auf jedem Rechner genutzt werden, Dateien und Dokumente lassen sich einfach austauschen und kollaboratives Arbeiten ist nahtlos möglich. Ein ähnlicher Trend ist gegenwärtig auch bei behörden- und unternehmensinternen Fachanwendungen zu beobachten.
Für Menschen ohne Einschränkungen kann es im Browser zu Verwirrungen zwischen browserspezifischer und anwendungsspezifischer Navigation kommen – insbesondere dann, wenn die Navigationskonzepte nicht an die Paradigmen des Webs angepasst wurden. Für Menschen mit Behinderungen ist der Unterschied zwischen Web- und Desktop-Anwendungen jedoch wesentlich gravierender. Bei der Einführung von neuen Software-Anwendungen ist daher darauf zu achten, dass die richtigen Teile des Prüfprozesses der EN 301 549 angewendet werden.
Der Prüfprozess der EN 301 549 differenziert zwischen Web und Software
Bei der Prüfung der Barrierefreiheit kann nach den Prüfschritten der WCAG 2.1* [4] und nach denen der EN 301 549 [2] unterschieden werden. Die Gemeinsamkeiten und Unterschiede beider Leitlinien hat meine Kollegin Lynn Habermann bereits in ihrem Beitrag “Barrierefrei nach WCAG 2.1 – oder: Was für die Erfüllung der BITV 2.0 wirklich zählt” näher erläutert.
Im Rahmen der Prüfung muss festgelegt werden, ob es sich um eine Web- oder Desktop-Anwendung handelt. Diese Unterscheidung ist wichtig, da je nach Art der Anwendung teilweise andere Prüfkriterien untersucht werden oder bestimmte Prüfschritte gar nicht angewendet werden können. Welche Gemeinsamkeiten und welche Unterschiede gibt es bei der Prüfung dieser beiden Anwendungen? Welche unterschiedlichen Anforderungen haben die Anwendungen? Was ist zu beachten, damit die Prüfung der Barrierefreiheit möglichst effektiv und effizient durchgeführt werden kann? Mit diesen Fragen beschäftigt sich der folgende Blogbeitrag.
* Zum Zeitpunkt des Verfassens dieses Artikels ist die WCAG 2.1 die aktuelle Version. Ende April 2023 wird allerdings die neue Version 2.2 erwartet. Diese baut auf der WCAG 2.1 auf und erweitert den Katalog um 9 weitere Kriterien. Der Beitrag Wissenschaftlich fundierte Usability und User Experience: Welche vier neuen Normen sollten UUX Expert*innen kennen? von Patryk Watola erläutert alle Neuerungen diesbezüglich im Detail.
Die Differenzierung zwischen Web- und Desktop-Anwendungen ist essentiell
In der DIN EN 301 549 werden insgesamt vier verschiedene Anwendungsarten unterschieden. Diese sind: Hardware, Web-Anwendungen, Nicht-Web-Dokumente und Software. In diesem Blogbeitrag wird jedoch nur auf die Unterscheidung zwischen Web-Anwendungen und Desktop-Anwendungen (Software) eingegangen.
Web-Anwendungen laufen im Browser der Benutzer*innen
Web-Anwendungen sind nach der EN 301 549 wie folgt definiert:
“[Eine] nicht eingebettete Ressource, abgerufen von einem einzelnen URI unter der Benutzung von HTTP plus jeder anderen Ressource, die beim Rendern benutzt wird oder die dazu bestimmt ist, mit der Ursprungsressource zusammen durch einen Benutzer[*innen]agenten gerendert zu werden.”
DIN EN 301 549, Abschnitt 3 (Nach WCAG 2.1 [4]) [2]
In den meisten Fällen sprechen wir umgangssprachlich oft von Webseiten und meinen damit auch komplexere Anwendungen, die über einen Weblink im Internetbrowser zugänglich sind. Diese Web-Anwendungen werden in Abschnitt 9 der EN 301 549 ausführlich behandelt.
Alles, was keine Web-Anwendung ist, ist Software
Die Logik der EN 301 549 mag auf den ersten Blick verwirrend erscheinen. Denn auch eine Web-Anwendung ist Software. Wenn wir aber im Kontext der Norm von Software sprechen, dann wird dieser Begriff letztlich als Synonym für Nicht-Web-Software verwendet. Der Abschnitt 11 des Standards heißt daher schlicht “Software” und enthält Anforderungen an:
- Plattform-Software,
- Software, die eine Benutzungsschnittstelle bereitstellt,
- Autorenwerkzeuge,
- Software, die als Assistenztechnologie arbeitet sowie
- mobile Anwendungen.
Diese Anforderungen gelten daher für alle Arten von Software mit Ausnahme von Web-Anwendungen. Diese so genannte Nicht-Web-Software wird wie folgt definiert:
“Software, die weder eine Webseite selbst, noch in Webseiten eingebettet ist, noch beim Rendern oder bei der Ausführung der Seite verwendet wird”.
DIN EN 301 549, Abschnitt 3 [2]
Anders als bei den Anforderungen für Webseiten existieren bei den Anforderungen in Abschnitt 11 teils unterschiedliche Versionen für offene und geschlossene Funktionalität. Entsprechend werden hier einige bestimmte Anforderungen zusätzlich in zwei Unterabschnitte unterteilt.
Viele Prüfschritte gelten für beide Anwendungstypen
Für beide Anwendungen, ob nun Web oder Desktop, gelten zunächst einmal alle Prüfschritte der Abschnitte 5 bis 7 der DIN EN 301 549, soweit diese anwendbar und prüfbar sind.
Die allgemeinen Anforderungen (Abschnitt 5) gelten sowohl für Web-Anwendungen als auch für Desktop-Anwendungen
Abschnitt 5 der EN 301 549 umfasst die allgemeinen Anforderungen. Dieser Abschnitt enthält unter anderem Prüfschritte zur geschlossenen Funktionalität, Prüfschritte zu Barrierefreiheitsfunktionen, der Nutzung biometrischer Merkmale, bedienbaren Elementen, Tastenwiederholungen und gleichzeitigen Benutzer*innenhandlungen, mit jeweils eigenen Unterpunkten.
Zweiwege-Sprachkommunikation (Abschnitt 6) kann sowohl in Web-Anwendungen als auch in Desktop-Anwendungen genutzt werden
In Abschnitt 6 werden Anwendungen mit Zweiwege-Sprachkommunikation behandelt. Dies umfasst alle Anwendungen, die eine Zweiwege-Sprachkommunikation in Form von z.B. einer Anruf- oder Chatfunktion besitzen. Unter anderem wird in diesem Abschnitt die Sprachqualität, Echtzeit-Textkommunikation, Anruf-Identifizierung, Videokommunikation und Alternativen zu videobasierten und sprachbasierten Diensten behandelt.
Videofähigkeiten (Abschnitt 7) sind für Web-Anwendungen und Desktop-Anwendungen analog zu prüfen
Der siebte Abschnitt der EN 301 549 behandelt alle Anwendungen, die Videofähigkeiten besitzen. Dazu zählen z.B. Prüfschritte über die Technologie zur Verarbeitung von Untertiteln und für die Audiodeskription sowie über Bedienelemente für diese.
Sobald eine Anwendung die Kriterien der Anwendbarkeit erfüllt und es technisch möglich ist, die Punkte zu prüfen, prüfen wir sowohl bei Web- als auch bei Desktop-Anwendungen diese Prüfschritte.
Die spezifischen Prüfschritte sind in Kapitel 9 und 11 definiert
Kommen wir nun zu den Prüfschritten, die sich ausschließlich mit Web-Anwendungen bzw. Desktop-Anwendungen (Software) befassen. Wie bereits erwähnt, werden Web- und Desktop-Anwendungen in zwei verschiedenen Abschnitten der EN 301 549 behandelt, die Prüfpunkte in Abschnitt 9 gelten für Web-Anwendungen und die Prüfpunkte in Abschnitt 11 für Software bzw. Desktop-Anwendungen.
Diese beiden Kapitel sind sich trotzdem aber relativ ähnlich und verfolgen meist einen ähnlichen Aufbau. Die meisten Prüfschritte in den Abschnitten 9 und 11 sind somit quasi identisch zueinander und die Anwendungen lassen sich mittels derselben Kriterien prüfen, auch wenn die Prüfschritte gesondert in zwei Kapiteln aufgelistet werden. Eine komplette Übereinstimmung ist aber trotzdem nicht vorhanden und auch die Anforderungen sind nicht bei jedem Prüfschritt gegeben. Die Unterschiede zwischen den beiden Kapiteln sollen in den folgenden Abschnitten näher beleuchtet werden.
Bei Desktop-Anwendungen muss zwischen geschlossener und offener Funktionalität differenziert werden
Zu den Abweichungen bei den Prüfschritten von Web- und Desktop-Anwendungen gehören in erster Linie zunächst alle softwarespezifischen Prüfschritte unter 11.5. Diese gelten somit nur für Software-Anwendungen, nicht aber für Web-Anwendungen.
Der Abschnitt 11.5 beinhaltet zunächst eine Unterteilung in Software mit geschlossener Funktionalität sowie Software mit offener Funktionalität. Hier ist es notwendig, die Unterschiede zu kennen und die zu prüfende Software richtig einzuordnen. So handelt es sich um eine Software mit geschlossener Funktionalität, wenn “es sich um Nicht-Web-Software handelt, die eine Benutzerschnittstelle bereitstellt, welche für Assistenztechnologien zum Vorlesen des Bildschirms geschlossen ist.” [3]
Offene Funktionalität hingegen trifft zu, “wenn es sich um Nicht-Web-Software handelt, die eine Benutzerschnittstelle bereitstellt und den Zugriff auf Assistenztechnologien zum Vorlesen des Bildschirms unterstützt.” [3]
Haben wir definiert, um welche Art von Software es sich handelt, gelten jeweils andere Prüfschritte, aufgeteilt in den Abschnitt für Software mit geschlossener Funktionalität (11.5.1) sowie die Prüfschritte für Software mit offener Funktionalität (11.5.2). Am Beispiel von Software mit offener Funktionalität möchte ich nun näher darauf eingehen, wie genau wir bei Nestler UUX Consulting Software auf Barrierefreiheit prüfen und welche Prüfschritte dabei beachtet werden müssen.
Bei einer offenen Funktionalität fokussiert sich die Prüfung auf die Nutzbarkeit mit Assistenztechnologien
Insgesamt enthält der zweite Teil mit den Prüfschritten für Software mit offener Funktionalität 17 Prüfschritte, die sich hauptsächlich mit der Verwendung von Assistenztechnologien, wie z.B. Screenreadern in Verbindung mit der zu prüfenden Software befassen. Dabei prüfen wir als UUX-Expert*innen zunächst, z.B. mit Assistenztechnologien wie einem Screenreader, ob sich dieser in der Software-Anwendung einwandfrei ausführen lässt und etwas Sinnvolles beim Vorlesen zumindest einiger Elemente der Anwendung ausgibt.
Ebenfalls wird zu Beginn geprüft, ob es sich bei der Software nicht bereits um assistive Software handelt, d.h. die Software selbst ein Screenreader, eine Vergrößerungssoftware oder ein Spracheingabesystem ist.
Viele Prüfschritte drehen sich um die klare Beschreibung und flexible Darstellung der Inhalte
Danach gehen wir hier weiter ins Detail und schauen uns an, ob bei beliebigen Elementen der Desktop-Anwendung beispielsweise der Name, der Status und die Beschreibung ausgegeben werden. Ebenfalls nehmen wir bei der Prüfung z.B. die Windows Bildschirmlupe zur Hilfe und schauen, ob diese dem Tastaturfokus auf bestimmte Elemente innerhalb der Anwendung folgt, auch bei einer Bildschirmvergrößerung auf beispielsweise 400%. Dabei sollte das im Tastaturfokus befindliche Element immer auf dem Bildschirm sichtbar sein.
Datentabellen müssen im Rahmen einer Prüfung auf Barrierefreiheit besonders sorgfältig geprüft werden
Im nächsten Schritt wird die Navigation innerhalb der Datentabellen der Software untersucht. Dabei untersuchen wir unter anderem, ob es möglich ist, innerhalb der Datentabellen mit Hilfe von definierten Shortcuts der verwendeten Assistenztechnologie, also z.B. eines Screenreaders, oder mit Hilfe von Pfeiltasten in verschiedene Richtungen zu navigieren. Außerdem schauen wir uns als UUX-Expert*innen an, ob der Screenreader die Zeilen- und Spaltennamen sowie die Werte innerhalb der Tabelle ausgibt. Gleichzeitig wird auch hier wieder untersucht, ob der Tastaturfokus dabei an der ausgewählten Stelle verbleibt oder sich die Ansicht für die Nutzer*innen verschiebt.
In der Vergangenheit haben wir bereits häufiger Softwareanwendungen geprüft, die zum größten Teil aus mehreren kleineren Tabellen bestanden, in denen die Nutzer*innen navigieren und Daten eintragen mussten. Natürlich hat die Software den Anspruch, für alle zugänglich zu sein. Dabei ist es laut EN 301 549 für die Barrierefreiheit notwendig, dass alle Nutzer*innen mittels der Tastatur in der Anwendung navigieren können. Bei unserer heuristischen Bewertung der Barrierefreiheit stellen wir jedoch regelmäßig fest, dass nicht alle Tabelleninhalte mit der Tastatur angesteuert werden können.
Darüber hinaus war es beispielsweise bei einer dieser Anwendungen nicht möglich, die Tabellen mit einem Screenreader zu navigieren, da der Screenreader die Namen bzw. Überschriften der Tabellen sowie die wesentlichen Spaltennamen der Tabellen nicht vorlesen konnte. Dadurch war die Anwendung mit dem Screenreader nicht vollständig nutzbar und Menschen mit Behinderungen können die Tabellen nicht verstehen.
Desktop-Anwendungen müssen auch ohne Maus uneingeschränkt nutzbar sein
Generell konnten wir in dem oben genannten Beispiel feststellen, dass nicht nur in den Tabellen, sondern in der gesamten Software einige Inhalte nicht über die Tastatur erreicht und so beispielsweise Bedienelemente innerhalb der Anwendung nicht ausgewählt werden konnten.
Bei der Prüfung dieser konkreten Software haben wir auch versucht, mittels der Tabulator-Taste durch die Anwendung zu navigieren, um festzustellen, ob es an einem Punkt der Desktop-Anwendung zu einer sogenannten Tastaturfalle kommt. Dies war aber nicht der Fall.
In dem Prüfprozess geht es – ähnlich wie bei Web-Anwendungen – auch um semantische Strukturen
Insgesamt sollte der Screenreader den gesamten Teil der Anwendung vorlesen können und so allen Nutzer*innen ermöglichen, die Software zu verstehen. Dies wird mit einer Reihe weiterer Prüfschritte getestet:
- Beispielsweise sollte der Screenreader nach dem Prüfschritt Prüfung von Werten auch sich ständig verändernde Werte, wie die Eigenschaften (Sekunden, Minuten) einer Uhr ausgeben können.
- Ferner sollten uns die Beschriftungen aller Elemente korrekt vorgelesen werden (Label-Beziehungen).
- Der Prüfschritt Formatierter Text definiert, dass der Screenreader den Nutzer*innen auch die Eigenschaften von formatierten Text ausgeben sollte.
- Genauso sollten alle verfügbaren Handlungen innerhalb der Software vom Screenreader ausgegeben und ausgeführt werden können. Hierbei handelt es sich z.B. um Eingabefelder oder um das Auswählen eines Buttons. So sollte es mittels des Screenreaders möglich sein, in einem Feld einen Text einzugeben bzw. einen “OK-Button” auszuwählen und damit eine Handlung zu bestätigen.
- Ebenfalls sollten Werte mittels des Screenreaders verändert werden können, beispielsweise indem Nutzer*innen über einen Pfeil eine andere Zahl o.ä. auswählen (Änderung von Werten).
- Weiter überprüfen wir, ob der Screenreader uns über auftretende Änderungsbenachrichtigungen innerhalb der Software informiert. Dies können z.B. Fehlermeldungen oder Fortschrittsbalken sein.
- Ebenso prüfen wir, ob die Struktur innerhalb der Software logisch erscheint. Dies ist der Fall, wenn die Element-Blöcke, die innerhalb der Anwendung optisch wie auf einer Ebene wirken, tatsächlich auch technisch so umgesetzt wurden. Dies wird auch als Eltern-Kind-Beziehung bezeichnet.
Bei all diesen Prüfschritten geht es im Kern um die Frage, ob sich die visuelle Gestaltung der Oberfläche auch in der semantischen Struktur des Interfaces wiederfindet. Nur wenn dies der Fall ist, können auch blinde Menschen die inhaltlichen und strukturellen Zusammenhänge und Abhängigkeiten zwischen den einzelnen Elementen der Oberfläche verstehen – und mit den Elementen adäquat interagieren.
Das zentrale Problem: Bei Desktop-Anwendungen steht kein Quelltext zur Verfügung
Abgesehen von diesen softwarespezifischen Prüfschritten, sind sich Web- und Desktop-Anwendungen inhaltlich in einer Vielzahl weiterer Prüfschritte sehr ähnlich.
Jedoch hängt der wesentliche Unterschied mit der Tatsache zusammen, dass die zu prüfende Software im Gegensatz zu Web-Anwendungen keinen Quelltext bereitstellt. Der Quelltext ist jedoch für die Prüfung diverser Prüfschritte notwendig, in der Regel sind das die Prüfpunkte, die mit einer von der WCAG 2.1 geforderten Vorgehensweise untersucht werden. Die WCAG 2.1 bezieht sich jedoch immer auf Webseiten und bietet keine alternative Vorgehensweise für Software oder Nicht-Web-Dokumente an, die ihren Quelltext nicht öffentlich machen. [4]
Sollen nun die Prüfschritte der WCAG 2.1 (nach den Vorgaben der EN 301 549) analog für Desktop-Anwendungen geprüft werden, so kann durch die analytische Prüfung der Desktop-Anwendung an einigen Stellen nicht die gleiche Prüftiefe wie bei Web-Anwendungen erreicht werden.
Einige Prüfschritte lassen sich bei Desktop-Anwendungen nicht in vergleichbarer Tiefe prüfen
Für viele der Prüfschritte haben wir im Team inzwischen praktikable Workarounds entwickelt, die eine vergleichbare Prüftiefe ermöglichen. An einigen Stellen stoßen aber auch wir noch an die Grenzen unserer Möglichkeiten: Bei einem unserer letzten Gutachten waren es beispielsweise am Ende insgesamt acht Prüfschritte, die wir nicht in der Tiefe prüfen konnten. Der Grund: Es war nicht möglich, die semantische Struktur aus dem Quellcode der Software einzusehen.
Unter anderem konnten wir dadurch keine verlässlichen Informationen über die Hauptsprache der Software erhalten und ob die verwendete Auszeichnungssprache korrekt verwendet wurde. Wir konnten nicht feststellen, ob interaktive Bedienelemente wie Links und Buttons programmatisch ermittelbare Namen und Rollen haben und alle verfügbaren nicht-textuellen Inhalte (z.B. Grafiken) Textalternativen haben, die den jeweiligen Zweck äquivalent erfüllen. Ebenso konnte aufgrund des fehlenden Quelltextes nicht untersucht werden, ob visuell sichtbare Überschriften semantisch als Überschriften gekennzeichnet sind und ob Softwareinhalte unabhängig von ihrer Darstellung in einer sinnvollen Reihenfolge angeordnet sind.
In Bezug auf diese Aspekte konnten wir nur explorativ das Verhalten des Screenreaders beobachten und so indirekt Rückschlüsse auf die semantischen Strukturen ziehen. Dieses Vorgehen ist sehr explorativ und zeitaufwändig. Letztlich kann eine solche Überprüfung nur stichprobenartig erfolgen – insbesondere bei einem im Projektalltag starren Budget- und Zeitrahmen. Die Verzahnung mit den Entwickler*innen ist bei solchen Projekten in der Regel enger: Wir liefern in diesen Fällen keine umfassende Liste problematischer Stellen – sondern Beispiele für Probleme. Die Identifikation weiterer Stellen mit potentiell ähnlichen Stellen liegt bei Desktop-Anwendungen dann stärker in der Verantwortung der Entwickler*innen als dies bei Web-Anwendungen üblicherweise der Fall ist.
Im Gegensatz dazu lassen sich diese Prüfkriterien bei Web-Anwendungen ohne große Probleme begutachten, da dort der Zugriff auf den Quellcode zu jeder Zeit über den Browser gegeben ist.
Unser Fazit: Die Prüfung von Desktop-Anwendungen ist möglich, benötigt aber erheblich mehr Erfahrung
Insgesamt fragen wir uns, warum es so kompliziert sein muss, Desktop-Anwendungen zu testen und warum die EN 301 549 keine alternativen Testmöglichkeiten für Software bietet. Der häufige Verweis auf die WCAG 2.1 ist nur bedingt hilfreich, da diese – wie der Name schon sagt – für Webanwendungen entwickelt wurde.
Dass Web- und Desktop-Anwendungen sich unterscheiden und nicht die gleiche Ausgangslage für die Prüfung bieten, ist keine Beobachtung, die wir erst seit kurzem gemacht haben, sondern betrifft schon lange alle Hersteller*innen von Software, die ihre Anwendungen barrierefrei gestalten möchten.
Aus unserer Sicht ist es unlogisch, dass die EN 301 549 an vielen Stellen für Web- und Desktop-Anwendungen das gleiche Vorgehen fordert, ohne eine praxisgerechte Unterstützung zu geben. Die Prüfschritte für Desktop-Anwendungen müssen dringend überarbeitet werden, so dass eine vollständige Prüfung ohne Zugriff auf den Quellcode möglich ist.
Weiterführende Links
[1] https://de.wikipedia.org/wiki/Google_Docs
[2] Barrierefreiheitsanforderungen für IKT-Produkte und -Dienstleistungen; Englische Fassung EN 301549 V3.2.1:2021; deutscher Text (E DIN EN 301549:2021-08 Abschnitt 14)
0 Kommentare zu “Barrierefreiheit: Worin unterscheidet sich die Prüfung von Web- und Desktop-Anwendungen?”