Fehlende Erfolgskriterien für Software in der EN 301549

, von Emanuel Helms (Kommentare: 4)

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:

Zurück

Kommentare

Kommentar von Jan Hellbusch |

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 |

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 |

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 |

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.

Einen Kommentar schreiben

Was ist die Summe aus 3 und 2?