Fehlende Erfolgskriterien für Software in der EN 301549

05. September 2019, von Emanuel Helms (Kommentare: 7)

Bypass Blocks (Umgehen von Elementgruppen) und Consistent Navigation (Konsistente Navigation) sind zwei Erfolgskriterien, die man im Kapitel 11 Software der EN 301 549 vergebens sucht. Dieses Kapitel bietet die technische Grundlage für die Prüfung von Apps. Sollte hier nachgebessert werden?

Die EU Web-Richtlinie bezieht sich, was Barrierefreiheits-Anforderungen angeht, pauschal auf geltende Standards und damit auf die europäische Norm EN 301 549 Version 2.1.2 (PDF). Diese Norm wurde Ende August 2018 vom europäischen Institut für Telekommunikationsnormen (ETSI) veröffentlicht. Sie beschreibt im Kapitel 11 Kriterien für barrierefreie Software in der Informations- und Kommunikationstechnik. Dieses Kapitel basiert im Wesentlichen auf den Erfolgskriterien der Web Content Accessibility Guidelines (WCAG) 2.1.

Wie der Name bereits erahnen lässt, liegt der Schwerpunkt der WCAG jedoch auf Erfolgskriterien für Webangebote und ist daher nicht in Gänze für Software anwendbar. Im Kapitel 11 der EN 301 549 wurden daher nicht alle Kriterien der WCAG 2.1 übernommen.

Die Entscheidung des Streichens einiger der Kriterien für die EN stößt bei einigen Nutzern von Hilfsmitteltechnologien und Accessibility-Experten jedoch auf Unverständnis. In diesem Artikel beziehe ich mich auf die fehlenden Erfolgskriterien 2.4.1 "Umgehen von Elementgruppen" und 3.2.3 "Einheitliche Navigation", die meiner Meinung nach dringend in die Norm gehört hätten.

Kriterium 2.4.1 "Umgehen von Elementgruppen"

In diesem WCAG-Erfolgskriterium geht es darum, dass Elementgruppen auf Webseiten durch Nutzer überspringbar sind und diese so schneller an die gesuchte Information oder Funktionalität gelangen. Beispiele für entsprechende Elementgruppen sind Navigations- und andere sekundäre Seiteninhalte. Durch korrekte Auszeichnung im HTML-Quelltext kann der (Hilfsmittel-) Nutzer diese Gruppen z. B. durch Sprunglinks überspringen oder mit der Hilfstechnologie direkt zu seinem Zielbereich der Webseite springen und muss sich nicht durch für ihn uninteressante Informationen und Funktionen kämpfen.

Warum dieses, für die Nutzungs-Effizienz enorm wichtige Erfolgskriterium, nicht für Software anwendbar sein soll, wird in der Norm nicht erläutert. Die entsprechende Kriteriumsnummer bleibt in der EN im Software-Kapitel 11 schlicht leer.

Übliche Tastaturkürzel zum Überspringen

Bei schon etwas komplexeren Programmen und Apps ist es mindestens für den Tastaturnutzer absolut üblich und für den Hilfsmittelnutzer schon geradezu obligatorisch, Shortcuts zu nutzen, um zwischen den verschiedenen Bereichen einer Software hin und her zu springen. Microsoft empfiehlt z. B. dazu einige Tastenkürzel in den Guidelines for Keyboard User Interface Design und auch Apple beschreibt diese im Abschnitt Keyboard - User Interaction seiner Human Interface Guidelines. Bekanntestes Beispiel dürfte die F6-Taste (unter MacOS zusammen mit der Strg-Taste) zum Wechseln des System-Cursors in das nächste Panel im aktuellen Anwendungsfenster sein.

Diese Guidelines werden von den Herstellern von Produktivsoftware seit Jahren aktiv umgesetzt und beschreiben zum Teil einen jahrzehntelangen Quasi-Standard. Ein Beispiel für die typische Nutzung ist die E-Mail-Liste in einem Mail-Programm, wo mittels F6-Taste u. a. von der Liste in den Dokumentenbereich mit dem zugehörigen Mail-Text gesprungen werden kann. Ähnlich verhält es sich im Datei-Explorer, hier kann mit der gleichen Taste von der Baumansicht im linken Bereich direkt in die Dateiliste im rechten Bereich gewechselt werden.

Überspringbarkeit kritisch wichtig bei der Benutzung vieler Anwendungen

Diese Beispiele kratzen nur an der Oberfläche. Komplexere Anwendungen wie Word und Excel im Büropaket oder Entwicklungsumgebungen mit ihren diversen Werkzeugleisten lassen sich kaum professionell ohne entsprechenden Shortcut mit der Tastatur nutzen. Diese Beispiele mögen simpel erscheinen, sparen den versierten Nutzern und auch den Hilfsmittel-Anwendern im Arbeitsalltag aber eine Menge Zeit. Zeitersparnis ist dabei ein sehr wichtiges Stichwort, ermöglicht es dem Menschen mit Behinderung doch in Zusammenhang mit einer gut programmierten Software, den behinderungsbedingten Mehraufwand an Zeit teilweise auszugleichen.

Überspringbarkeit und mobile Apps

Das gilt alles ebenso für mobile Apps, die immer funktionsreicher werden und damit die Grenzen von mobilen und stationären Systemen verschwimmen lassen. Hier bieten die Systeme in Kombination mit einer physischen Tastatur ähnliche Funktionen an, um Bereiche in einer Software anzuwählen. Hilfsmitteltechnologien wie VoiceOver oder TalkBack von Apple bzw. Google bieten den Nutzern derartige Funktionalität.

Meiner Meinung nach ist die Funktion zum Anwählen von Bereichen der Software mittlerweile Industriestandard und hätte den Software-Herstellern in der Regel keine größere Kopfschmerzen bereitet. Stattdessen würde die Übernahme des Erfolgskriteriums in Kapitel 11 nur die generelle Anwendung einer weit verbreiteten "Best Practice" der Industrie sicherstellen.

Erfolgskriterium 3.2.3 "Einheitliche Navigation"

Das Erfolgskriterium „3.2.3 Einheitliche Navigation“ fordert eine konsistente Navigation auf allen Seiten eines Webangebots, sodass der Nutzer sich leicht zurechtfindet und seinen Fokus auf das Wesentliche richten kann. Deshalb ist der Navigationsbereich z. B. immer an der gleichen Stelle und verhält sich auf allen Seiten gleichartig und somit für den Nutzer nachvollziehbar.

Konsistenz hilft allen Nutzern

Dieses Kriterium ist unbestreitbar sinnvoll für alle Nutzer, unabhängig davon, ob sie eine Hilfstechnologie nutzen oder nicht. Unverständlicher Weise hat es dieses Kriterium nicht in die Erfolgskriterien für Software der EN 301 549 geschafft. Die erläuternden Texte der WCAG 2.1 zu diesem Kriterium könnte man dabei quasi eins zu eins für Software übernehmen.

Wenn Software dieses Kriterium berücksichtigt, steigern Nutzer ihre Effizienz, da sie die Navigationsstrukturen der einzelnen Ansichten der Software nicht immer wieder durchsuchen oder auswendig lernen müssten. Nutzer könnten von der einmal erfassten Struktur im Voraus auf die Struktur in anderen Navigationsbereichen schließen.

Konsistente Navigation unterstützt die Erlernbarkeit

Eine konsistente Navigation erleichtert allen Nutzern die Einarbeitung in eine neue Software und erfordert weniger kognitive Leistungen für eigentlich triviale Aufgaben, wie dem Auffinden eines Menüpunktes. Für Menschen mit Behinderungen ist eine einheitliche Navigation besonders wichtig. Sehbehinderte Nutzer, die bei starker Vergrößerung immer nur einen kleinen Ausschnitt des Bildschirms sehen, können durch eine konsistente Positionierung die Navigation schnell wiederfinden. Wenn es dagegen zu einem ständigen Wechsel zwischen verschiedenen Layouts kommt, verlieren sehbehinderte Nutzer schnell die Orientierung auf dem Bildschirm und müssen diese erst zeitaufwändig wiedererlangen, um die Arbeit fortzusetzen.

Fazit

Bei der Übertragung von WCAG-Kriterien auf Software hat die Nicht-Übernahme der beiden Beispielkriterien sicher ihre Gründe gehabt. Ein Ausgangspunkt wird das WCAG2ICT Dokument gewesen sein. Es wäre sinnvoll, wenn die Argumente für die Entscheidung für alle öffentlich nachlesbar wären, um sie gegebenenfalls nachvollziehen zu können. Es bleibt zu hoffen, dass die von mir beschriebenen Beispiel-Kriterien doch noch ihren Weg in einer zukünftigen Version der EN 301 549-Norm finden.

Quellen:

Microsoft: Guidelines for Keyboard User Interface Design
Apple: Keyboard - User Interaction

Zurück

Kommentare

Kommentar von Jan Hellbusch | 2019-09-05

Die Erklärung steht tatsächlich in dem oben verlinkten Dokument "WCAG 2 ICT". Dort wird erklärt, dass es normalerweise kein "Satz von Software" gibt. Die beiden Erfolgskriterien (sowie zwei weitere) beziehen sich nicht auf einzelne Webseiten, sondern auf einen Satz von Webseiten. D.h. Sie müssen nach WCAG auch nicht zwingend für Webseiten eingehalten werden, sondern nur wenn die Webseite Teil eines solchen Satzes ist.

Kommentar von Emanuel Helms | 2019-09-10

Hallo Herr Hellbusch,

vielen Dank für Ihren Kommentar. Ich bin mir nicht sicher, wie sinnvoll das Konzept von „sets of software“ der ICT Task Force ist, wenn dieses doch kaum in freier Wildbahn zu finden ist. Meiner Meinung nach könnte man den „Satz von Seiten“ bzgl. Software eher mit einem „Satz von Ansichten“ gegenüberstellen. Vor allem im Bereich der mobilen Apps bietet sich der Vergleich an. Als Beispiel ist hier die Twitter-App interessant. Hier gibt es unten die Reiter bzw. Ansichten „Startseite“, „Suchen und Entdecken“, „Mitteilungen“ etc. Auf jeder der Ansichten findet man die Möglichkeit, das Account-Menü aufzurufen. Die von mir genannten Kriterien sind meiner Meinung nach sehr wichtig und es ist sehr schade, dass die Task Force die Kriterien nicht entsprechend für Software umgesetzt hat, obwohl dies durchaus möglich und sinnvoll wäre.

Kommentar von Jan Hellbusch | 2019-09-11

Mir Ist nicht ganz klar, worauf Sie sich beziehen. Das mit dem Satz von Webseiten wird ja im Glossar der WCAG 2.1 definiert. Es ist nachvollziehbar, warum beispielsweise die konsistente Navigation nicht für Software gilt. Gleichzeitig ist Konsistenz in der Navigation selbstverständlich meistens für alle Nutzer gut. Im Übrigen verlangen die WCAG 2.1 nicht eine konsistente Navigation, sondern eine konsistente Reihenfolge innerhalb von Navigationsbereichen – das wird nach meiner Erfahrung bei Software meistens erfüllt.

Man darf nicht vergessen, dass die WCAG 2.1 AA lediglich Mindestanforderungen sind (das steht auch so in der Europäischen Richtlinie 2016/2102 bezogen auf EN 301549). Wenn WCAG 2.1 AA erfüllt ist, dann sind zumindest die meisten Nutzer von der Nutzung nicht ausgeschlossen. Die BITV 2.0 sagt dazu, dass man Barrierefreiheit bei Erfüllung von WCAG 2.1 AA auch nur vermuten kann. Zwischen WCAG-konform (Mindestanforderung) und gut zugänglich oder gar "barrierefrei" kann aber immer noch ein großer Unterschied bestehen. Demnach ist nach BITV 2.0 die Erfüllung von WCAG 2.1 AA höchstens als "ausreichend barrierefrei" anzusehen. Die BITV 2.0 ist schon so zu verstehen, dass höhere Anforderungen als bloß die Erfüllung von WCAG 2.1 AA angelegt werden müssen (siehe BITV 2.0 zu "Stand der Technik").

Wenn Sie also höhere Anforderungen anlegen wollen, erklären Sie es oder dokumentieren Sie es. Aus Sicht der Barrierefreiheit ist das nur zu begrüßen.

Kommentar von Carsten Kaul | 2019-10-11

Auch ich bin bei dem Vergleich von WCAG2ITC und EN 301 549 auf diese beiden Punkte gestossen (sowie weitere) und schliesse mich in der Argumentation des Autors an und interpretiere die Definition "set of webpages" bei Software auch als "sets of views", also Bildschirmmasken.

Eine "besondere Erschwernis" für Tastaturnutzer liegt dann vor, wenn etliche (unnötige) Tab-Tasten gedrückt werden müssen nur um von A nach B zu kommen. Ich habe das bisher immer in 2.4.1 verortet. Wohin sollten wir solche Auffälligkeiten zukünftig unterbringen wenn nicht dort?

Im Übrigen halte ich auch 2.4.1 Page Titled für wichtig. Der Software-Titel erscheint beim Wechsel über Alt+Tab oder JAWS-Taste+F10.

Kommentar von joerg morsbach | 2019-11-03

Wenn man sich die Spezifikationen genau anschaut, dann muss man sich schon sehr wundern. Denn laut der EN 301 549 soll das Erfolgskriterium 2.4.1 "Umgehen von Elementgruppen", was im Original "bypass blocks" heißt, tatsächlich nicht für Dokumente, wie PDF und Software, also beispielsweise auch Native Apps anwendbar sein. Zumindest nicht für das einzelne PDF-Dokument (auch nicht für den 300-Seiter). Und auch nicht für die einzelne App. Das Erfolgskriterium 2.4.1 "Umgehen von Elementgruppen" soll nur für ein Set von Dokumenten und ein Set von einzeln startbaren Software-Anwendungen gelten.

Wie man aber von der ursprünglichen Intention der WCAG 2.4.1 Bypass Blocks (Siehe Intention für Webpages: https://www.w3.org/TR/2013/NOTE-UNDERSTANDING-WCAG20-20130905/navigation-mechanisms-skip.html#navigation-mechanisms-skip-intent-head), sich wiederholende Seitenbereich, wie Navigationen, Werbung, etc. für Tastaturnutzer überspringbar zu machen, auf diese "Adaption" für (PDF)Dokumente und Software kommt, ist absolut schleierhaft. "Ein Beispiel für eine Reihe von PDF-Dokumenten soll ein dreiteiliger Bericht sein, bei dem jeder Teil eine separate Datei ist. Am Anfang jeder Datei könnte dann als Bypass Block das Inhaltsverzeichnis zum „Navigieren“ zu den anderen Teilen wiederholt werden". Das ist absolut realitätsfern. Gleiches gilt für Software "Ein Beispiel für ein Set von Softwareprogrammen soll eine Gruppe von Programmen sein, die separat gestartet und verwendet werden können, aber zusammen verteilt werden. Alle Programme sollen dann über ein Menü verfügen, über das Benutzer die anderen Programme in der Gruppe starten bzw. zu diesen wechseln können ". Das steht unmissverständlich hier: https://www.w3.org/TR/wcag2ict/#keyterms_set-of-documents und hier: https://www.w3.org/TR/wcag2ict/#keyterms_set-of-software ...

Ich frage mich, wie man von den WCAG Erfolgskriterium 2.4.1 Bypass Blocks auf diesen Holzweg gelangen kann. Das ist ein Fehler und sollte schnellstmöglich korrigiert werden. Zumal auf der Seite https://www.w3.org/TR/wcag2ict/#navigation-mechanisms-skip selbst ja steht, dass derartige Software-Sets und Dokumenten-Sets extrem selten sind. Spätestens bei dem Satz hätte dem Verfasser ein Licht aufgehen müssen.

Antwort von Detlev Fischer

Hallo Jörg,

Was Du sagst, klingt nachvollziehbar - Du solltest diese Hinweise an die Gruppe geben, die die EN überarbeitet. Ob es eine öffentliche Kommentar-Möglichkeit gibt, weiß ich gerade nicht – ich kann dir sonst aber auch einen direkten Ansprechpartner nennen.

Detlev

Kommentar von Jan Hellbusch | 2019-11-03

@Jörg: Ich denke, Anwendungen und Dokumente muss man unterschiedlich betrachten, wenn es um die vier Anforderungen zu einem "Satz von Webseiten" geht. Wenn es um Erfolgskriterium 2.4.1 geht:

• Bei Dokumenten gibt es keine Notwendigkeit, die Problematik zu diskutieren. In Dokumenten (auch wenn sie 300 Seiten lang sind) gibt es meist keine Navigationsbereiche. Und wenn es solche Navigationsbereiche gibt (zum Beispiel ein Inhaltsverzeichnis oder eine Liste von Links), dann werden diese Bereiche im Tag-Baum normalerweise als Liste aufbereitet – dann ist das Erfolgskriterium beiläufig erfüllt. Auch wenn eine Liste nicht eingesetzt wird, folgt zumindest auf ein Inhaltsverzeichnis meist eine Überschrift. Somit wäre Erfolgskriterium 2.4.1 ebenfalls erfüllt. Sicher wird es Situationen geben, wo die Struktur in einem Dokument nicht stimmig ist und Blöcke nicht übersprungen werden können, aber mir fällt dazu kein Beispiel ein.
• Bei Software ist die Nicht-Anwendbarkeit nicht so eindeutig. Nicht alle Anwendungen verfügen über ein Menü und enthalten statt dessen eine Navigation mit aktiven Elementen. Wenn es viele Ansichten einer Software gibt und Tastaturnutzer die Navigation per Tab-Taste zuerst durchwandern müssen, dann gibt es ein Problem. Da kann die Argumentation oben nachvollzogen werden. Klassische Anwendungen haben ein Menü und Menüs stehen nur einmal in der Tab-Reihenfolge, und es gibt daher keine Notwendigkeit, das ein antabbares Element überspringbar machen zu müssen.

Ein weiterer Aspekt in der Thematik ist, in welcher Sprache die Anwendung programmiert ist. Wenn die Anwendung mit einem Browser geöffnet wird, handelt es sich per Definition um eine Webseite – egal welche Technik dahinter steckt (siehe BITV 2.0 und WCAG 2.1). In dem Fall ist Kapitel 9 der EN 301549 (also WCAG 2.1 vollständig) anwendbar.

Kurz um: Nicht Web-basierte Anwendungen, die eine (Web-ähnliche) Navigation mit einzelnen aktiven Elementen aufweisen, die außerdem in jede Ansicht per Tab-Taste durchwandert werden müssen, stellen ein mögliches Problem dar.

Die anderen Szenarien (Dokumente, Web-basierte Anwendungen, andere Anwendungen mit einem Menü statt einer Navigation) sollten aus der Diskussion ausgeklammert werden.

Kommentar von Kerstin Probiesch | 2019-11-05

Ein paar Kommentare: Bei WCAG geht es ja um jegliche Webinhalte und in Folge um Web Pages (Webseiten) im Sinne des WCAG-Glossars. Wichtig finde ich, dass man immer die Formatunabhängigkeit beachten muss. Das wird bei EN 301 549 umso wichtiger.

Ich will mich auf PDF konzentrieren. Kritisch sehe ich, wenn man vor WCAG-Hintergrund mit „Dokumenten“ PDF und allenfalls noch z.B. ein Word-Dokument meint. Eine HTML-basierte Seite bzw. Datei kann man durchaus auch als Dokument sehen. Das Denken in Formattypen steckt bzgl. WCAG voller Fallstricke und noch mehr bei EN 301549. Denn die primäre Einteilung in 9 und 10 geschieht nicht entlang von Formaten.

EN 301 549 unterscheidet web page (Kapitel 9) und nicht web page (Kapitel 10). In 10 gibt es außerdem noch nicht embedded in web pages und eine weitere Voraussetzung.

Im Kapitel 9 „Web“ steht in Note 1 „covers all web content types“ (also auch z.B. PDF, wenn es sich um eine web page handelt. Das ergibt aber bereits aus den WCAG selber). Jedes Kriterium in 9 beginnt mit: „Where ICT is a web page“ - also auch hier formatunabhängig. Der erste gedankliche Schritt ist nicht, welches Format man hat, sondern ob es eine web page (gemäß WCAG) ist oder nicht.

Daraus ergibt sich ein Mini-Entscheidungsbaum, z.B. für PDF:

Ist das PDF eine web page im Sinne der WCAG (oder als solche geplant) ? (die zwei weiteren Voraussetzungen für 10 muss man sicher auch berücksichtigen)

Bei Ja: Bypass blocks ist ein Kriterium (9.2.4.1)

Bei Nein: Bypass blocks ist nicht Mindestanforderung und daher nicht zwingend.

Wenn ich speziell und nur PDF anschaue, dann geht es 1. "wenigstens nur" um solche, die keine Webinhalte nach WCAG sind. 2. Inhaltsverzeichnisse (sofern sie überhaupt generell unter das Erfolgskriterium fallen) werden aus Überschriften generiert. Man hat meist wie auch Jan oben sagt nach einem Inhaltsverzeichnis eine Überschrift.

Kann der Fall eintreten, dass man ein Inhaltsverzeichnis hat, aber keine Überschriften? Ja. Passiert ständig und zwar, wenn man sie nicht ausgezeichnet hat und das Inhaltsverzeichnis händisch angelegt hat. Dann fliegt das PDF durch 1.3.1 Information und Beziehung und zwar unabhängig davon, ob es eine web page ist oder nicht. Und wenn ein Dokument egal welchen Formats erst gar keine (Zwischen)Überschriften hat oder z.B. nur eine Hauptüberschrift, dann wird man kein Inhaltsverzeichnis haben.

Dass Bypass Blocks generell für Dokumente entfallen sei - so verstehe ich ein paar Kommentare oben , korrigiert mich, wenn ich das falsch verstanden habe -, lässt sich imo nicht aus EN 301 549 herauslesen. Interessant wäre dennoch bei EN 301 549, welcher Gedankengang zur Streichung von Bypass Blocks für Nicht-Web-Inhalte geführt hat und damit für Dokumente, die nicht unter 9 fallen. Selber beäuge ich dessen Fehlen auch nicht ganz unkritisch und hätte das lieber drin gehabt. Allein schon, um Fälle abzufangen, an die man heute nicht mal denkt oder die extrem selten sind.

(Jesses. Ist das wieder lang)