Anwendungssoftware, Stufe 0

Schließen

Der Praxistauglichkeitstest basiert auf Nutzererfahrungen, langjährige Erfahrung im Testen von Anwendungssoftware sowie auf Ergebnissen von Befragungen betroffener Nutzerinnen und Nutzer an Arbeitsplätzen im Rahmen des Projektes BIT inklusiv. Ausführliche Informationen zum Praxistauglichkeitstest finden Sie unter http://wiki.bit-inklusiv.de/index.php?title=Pr%C3%BCfverfahren_Anwendungssoftware.

Das Prüfverfahren bezieht sich auf Anwendungs-Software. Es stellt einen Katalog von Erfolgskriterien und Prüfanleitungen zur Verfügung, die zur Ermittlung der Barrierefreiheit einer Anwendung dienen. Die Erfolgskriterien sind aus den Richtlinien EN 301549 und ISO 9241-171 abgeleitet und technik-neutral formuliert, sie sind grundsätzlich auf alle Betriebssystem-Umgebungen anwendbar. Die praktischen Prüfanleitungen mit den darin verwendeten Prüftools sind technik-spezifisch, sie beziehen sich beim jetzigen Stand des Verfahrens ausschließlich auf das Windows-Betriebssystem, wobei Desktop-Rechner mit Standard-Display, Tastatur und Maus eingesetzt werden. Touch-Bedienung wurde vorerst nicht berücksichtigt.

Testausstattung

Befragung zu technischen Voraussetzungen

Im Vorfeld einer Prüfung sollten die technischen Voraussetzungen geklärt werden. Hierzu zählen neben der empfohlenen Rechner-Ausstattung unter anderem auch Angaben über bereits erfolgte Bemühungen im Bereich Barrierefreiheit, die empfohlene Hilfsmittelausstattung etc. Der für diesen Zweck vorbereitete Fragebogen wird an den Kunden geschickt. Ein beantworteter Fragebogen ist Test-Voraussetzung. Folgende Kriterien sollten mindestens erfasst werden:

Der Auftraggeber muss darüber informiert werden, dass eine Prüfung nur mit spezieller Hilfsmittelausstattung nicht als Konformitätsprüfung (s.u. „Konformitätsstufen“) gewertet werden kann.

Genaueres kann dem Fragebogen zur Vorbereitung einer Prüfung von Anwendungssoftware auf Barrierefreiheit entnommen werden (Download der Word-Datei).

Werkzeugliste

Tool die Bestandteil des Windows-SDK sind, kann man nach der Installation des SDK unter dem Pfad C:\Programme\Windows Kits\8.1\bin\x64 (bzw. x86 oder arm, je nach Systemarchitektur) finden.

Bildschirmlineal: bisher am besten geeignet ist das kostenpflichtige Tool von Keseling https://www.keseling.de/sli.htm. Das Lineal muss mit einem physischen Lineal kalibriert werden, die Kalibrierung muss bei einer Änderung der Auflösung oder der Textgröße (dpi) wiederholt werden.

Testsystem

Die Anwendung wird in einem Testsystem mit Hilfsmitteln und Testtools installiert. Die Ausstattung wird im Prüfbericht dokumentiert.

Technische Prüfung

= Testverfahren Teil I

  1. Konnten Screenreader und Testtools im Testsystem vollständig installiert werden? Falls nein– Abbruch der Prüfung.

  2. Stichprobenartige Anwendung des Prüfschritts 4.01.0 mit Screenreader NVDA: liest er die sichtbaren Texte (Beschriftungen, Inhalte) der Anwendung größtenteils vor? Falls nein – Abbruch der Prüfung.

Dokumentenprüfung

= Testverfahren Teil II

Dokumentation der Tastaturkommandos

EN 301549 Nr. 12.1.1 Accessibility and compatibility features

1. Sichtprüfung: Handbücher bzw. Online-Hilfen enthalten ein Verzeichnis der Tastaturkommandos in zusammenhängender Darstellung. Falls nicht vorhanden: Feststellen, ob die Anwendung Tastaturkommandos direkt in der Bedienoberfläche nennt oder als kontextsensitive Hilfe punktuell anbietet.

Barriere / Abbruch der Prüfung: Eine Dokumentation der Tastaturkommandos ist nicht verfügbar.

Einschränkung: Tastaturkommandos werden ausschließlich in der Bedienoberfläche der Anwendung oder als kontextsensitive Hilfe dokumentiert.

2. Die Richtigkeit und Vollständigkeit der Dokumentation kann im Rahmen der Dokumentenprüfung nicht festgestellt werden. Diese Anforderung aus DIN EN 82079 Erstellen von Gebrauchsanleitungen wird exemplarisch in der praktischen Prüfung im Prüfschritt „Vollständige Dokumentation der Tastaturkommandos“ geprüft. Das Ergebnis dieses Prüfschritts geht in das Ergebnis der praktischen Prüfung ein und wird zusätzlich im Ergebnis der Dokumentenprüfung berichtet.

Beschreibung der Accessibility-Features

EN 301549 Nr. 12.1.1 Accessibility and compatibility features

Erforderlich ist eine Beschreibung der für Menschen mit Behinderungen eingerichteten Bedienfunktionen (Vergrößerung, Orientierungspunkte, etc. (weiter ausführen).

Barrierefreiheit von Dokumentation und Dienstleistungen

EN 301549 Nr. 12.1.2 Accessible documentation

  1. Praktische Prüfung: Handbücher und Online-Hilfen sind in zugänglichem Format, d.h. die Anforderungen für barrierefreie Dokumente sind eingehalten. Verlinktes Inhaltsverzeichnis und Suchfunktion sind vorhanden. Hierzu werden die entsprechenden formatspezifischen Prüfverfahren herangezogen, u.a. BITV-Test, PDF-Accessibility-Test.

  2. Praktische Prüfung: Die Dokumentation ist über die Bedienoberfläche der Anwendung zugänglich. Hierzu werden die entsprechenden Prüfpunkte der Praktischen Prüfung = Teil III des Testverfahrens herangezogen.

    1. Ein Link zur Dokumentation ist in jedem Arbeitsschritt verfügbar. Beispiel: Die Anwendung hat im Hauptmenü einen Punkt „Hilfe“ mit dem Unterpunkt “Tastaturbefehle”.

    2. Der Link zur Dokumentation ist mit Tastatur und Screenreader bedienbar.

  3. Internetquellen, soweit darauf zur Dokumentation verwiesen wird, sind barrierefrei entsprechend WCAG Level AA. Test: BITV-Test.

ISO 9241-171 Nr. 11.2.1 Zugängliche Unterstützungsdienste zur Verfügung stellen: Sofern Support mit eingekauft wurde, muss dieser barrierefrei erfolgen. Herstellerbefragung.

Praktische Prüfung

= Testverfahren Teil III

Generelles Vorgehen

Die Prüfung muss im Vergleich mit dem BITV-Test eine höhere Komplexität bewältigen. Wir haben zwei Listen abzuarbeiten, a) den Arbeitsablauf im Sample (Szenario/Drehbuch), b) die Erfolgskriterien/den Prüfkatalog. An sich müssten die Listen kreuzweise kombiniert werden, d.h. bei jedem Erfolgskriterium ist das komplette Szenario abzuarbeiten, oder anders herum bei jedem Arbeitsschritt der komplette Prüfkatalog. Das ergäbe eine unüberschaubare Datenfülle und wäre nicht praktikabel. Im Mikro-Handling entsteht noch eine dritte Folge nach dem eingesetzten Testtool bzw. der Bearbeitungsmodalität: normale Darstellung, Mausbedienung, Tastaturbedienung, Screenreader-Darstellung, Kontrastmodus, Vergrößerung. Wie kann diese Komplexität in einen Ablauf gebracht werden?

Das Testverfahren stellt Hilfen für die praktische Durchführung der Prüfung bereit:

  1. Der Prüfkatalog ist nach den Bearbeitungsmodalitäten gegliedert, hierdurch werden praktisch zusammenhängende Prüfpunkte gruppiert, so dass die Anzahl der Durchläufe durch das Szenario reduziert werden kann.

  2. Das Prüftool/Prüfprotokoll enthält die Möglichkeit, bei jedem Prüfpunkt für jedes auffällige UI-Element des Szenarios eine Protokollzeile einzufügen. Hierdurch kann das Prüfprotokoll auch nach Kriterien der Anwendung sortiert und zusammengefasst werden.

Sample / Szenario / Drehbuch

= Testverfahren Teil III A

Mit Ausnahme einfacher Apps wird eine Anwendung niemals vollständig geprüft werden können. Es bedarf einer Auswahl typischer Elemente der Anwendung (Sample). Um eine relevante Auswahl zu treffen, geht man in Anlehnung an das Vorgehen bei Usability-Reviews von typischen Arbeitsaufgaben/ Use Cases aus, für die die Anwendung üblicherweise eingesetzt wird (Szenario). Die Arbeitsschritte des Szenarios werden als Drehbuch festgelegt und so detailliert wie nötig aufgeschrieben. Das Drehbuch ist während des Tests mehrfach abzuarbeiten.

Je nach Komplexität der Anwendung können die wesentlichen Use Cases anhand der Dokumentation ermittelt oder in Zusammenarbeit mit dem Auftraggeber der Prüfung oder mit erfahrenen Anwendern erarbeitet werden. Ein allgemeiner Teil kann formuliert werden, um immer vorkommende UI-Elemente, z.B. das Hauptmenü, zu isolieren und Dopplungen in der Feststellung von Mängeln zu vermeiden. Eine Zufallsstichprobe ist zusätzlich erforderlich, um mit begrenztem Aufwand eine Aussage über die gesamte Anwendung machen zu können.

Bei der Erstellung der Use Cases muss sich der Prüfer die fachlichen Inhalte der Anwendung soweit aneignen, dass er die Prüfschritte des Prüfkatalogs darauf anwenden kann. Ein inhaltliches Verständnis ist z.B. erforderlich für die Prüfschritte 1.05.1 „Prägnante Beschriftungen“ und 2.07.1 „Hilfen bei Fehleingaben“.

Über das Sample kann der Aufwand der Prüfung gesteuert werden. Eine vollständige Prüfung der Anwendung mit dem Ziel, alle Fehler zu finden, kann im Rahmen der betrieblichen Qualitätssicherung implementiert werden. Für einen Konformitätstest muss eine Auswahl nach standardisiertem Verfahren getroffen werden, wobei die Entscheidung über das Sample beim Prüfer liegt. Für einen Basistest (s.u. „Konformitätsstufen“) kann das Szenario je nach Beratungsauftrag stichprobenartig verkürzt werden.

Regeln für die Erstellung eines Drehbuchs

Typische Arbeitsaufgaben: Wähle exemplarische Arbeitsaufgaben, die für die Anwendung charakteristisch sind und am häufigsten genutzt werden. Beispiel: bei einem E-Mail-Client teste das Senden und Beantworten von E-Mails, nicht die Konfiguration der Internetverbindung. Marginale Programmfunktionen kommen erst dran, wenn die zentralen ausreichend getestet sind.
Wähle Arbeitsaufgaben, die im Prinzip auch von Menschen mit Behinderungen ausgeführt werden können, d.h. nicht wesentlich auf der Kontrolle grafischer oder akustischer Inhalte beruhen. Beispiel: den Zuschnitt von Bildern können Blinde und hochgradig Sehbehinderte auch dann nicht ausführen, wenn die entsprechenden Bedienelemente der Software für sie zugänglich sind.

Typischer Ablauf: Erfasse vollständige Abläufe, vom Erkunden des Bildschirms über den Aufruf einer Funktion, Kontrolle der notwendigen Einstellungen, Nutzereingaben, Meldungen der Anwendung, Ergebnis der Aufgabe. Neben dem positiven Ablauf provoziere auch Störungen und Fehlersituationen: Fehleingaben in Formularen, Abbruch von Programmfunktionen.

Typische UI-Elemente: Erfasse die UI-Elemente entlang des typischen Ablaufs vollständig. Achte auf die Übergänge zwischen den Bildschirmen und Programmsituationen. Stelle sicher, dass alle vorkommenden Typen von UI-Elementen im Sample repräsentiert sind. Falls erforderlich ergänze den typischen Ablauf um einzelne Programmsituationen.

Zufällige UI-Elemente: Während des Tests überprüfe stichprobenartig auch Elemente, die nicht zum typischen Ablauf gehören. Wenn ausreichend Zeit ist, überprüfe alle Bedienelemente und Anzeigen der ausgewählten Bildschirme/Masken/Dialoge. Ziel ist es, Abweichungen von der Standardausführung von UI-Elementen, Flüchtigkeitsfehler und Probleme bei erratischen Interaktionen zu entdecken.

Ausreichende Testdaten: Wähle ausreichend komplexe Testdaten. Beispiel: in einer Suchfunktion gib ein Suchwort ein, das eine mehrseitige Ergebnisliste ergibt. Manche Probleme treten in einfachen Fällen nicht auf, z.B. mehrfache gleich benannte Buttons edit/löschen etc.
Sorge dafür, dass Abläufe mehrmals in vergleichbarer Form wiederholt werden können, z.B. durch eine ausreichende Menge an Testdaten.

Flexible Detailtiefe: Detailliere das Drehbuch während des Tests. Bei Auffälligkeiten gehe einen Schritt tiefer ins Detail als bei positivem Ergebnis. Beispiel: Ein Button ist im Screenreader nicht als Button deklariert. Bediene den Button, auch wenn dieser Schritt im typischen Ablauf nicht vorgesehen ist, um ggf. mehr Informationen über den zugrundeliegenden Fehler zu erhalten.

Prüfkatalog / Erfolgskriterien / Prüfschritte

= Testverfahren Teil III B

Zugrundeliegende Standards / Konformitätsstufen

Die Erfolgskriterien sind unterteilt in 3 aufeinander aufbauende Stufen.

Der Basistest (Stufe 0) wurde konzipiert, um mit relativ geringem Aufwand eine Aussage über den Stand der Barrierefreiheit einer Anwendung treffen zu können. Hiermit soll der gegenwärtig in der betrieblichen Praxis verbreiteten Situation Rechnung getragen werden, dass die Anpassung von Software an Hilfstechniken wie Screenreader und Vergrößerungssoftware mangelhaft oder uneinheitlich umgesetzt ist. Der Basistest enthält einige grundlegende Kriterien und kann, in Verbindung mit der vom Hersteller der Software empfohlenen Hilfsmittelausstattung (s.o. „Befragung zu technischen Voraussetzungen“), als Test auf Basis-Zugänglichkeit angesehen werden.

Stufe I – Konformität nach EN 301549 – enthält den für die Standardkonformität entscheidenden Schnittstellentest, die Bedienung der Accessibility-Schnittstellen des Betriebssystems. Eine Konformitäts-Aussage kann nur getroffen werden, wenn die gesamte Prüfung (auch Stufe 0) mit den im Verfahren festgelegten Standard-Testtools und ohne produktspezifische Screenreader-Skripte durchgeführt wurde. Eine spezielle, vom Hersteller oder vom einsetzenden Betrieb gewünschte Hilfsmittelausstattung kann zusätzlich in einem separaten Prüfdurchgang verwendet werden, dessen Ergebnisse nicht in die Konformitäts-Aussage eingehen.

Im Prüfbericht muss die verwendete Hilfstechnik und ggf. das Vorliegen einschränkender Hersteller-Empfehlungen für die Hilfsmittelausstattung deutlich dokumentiert werden.

Gliederung des Prüfkatalogs

Das Prüfverfahren führt verschiedene Standards zusammen, benötigt daher eine eigene übergeordnete Logik.

Der Prüfkatalog folgt einer zweiten Ordnung, er steuert den Ablauf der praktischen Prüfung. Der Prüfkatalog gruppiert die Prüfschritte nach Bearbeitungsmodalitäten. Durch die Zusammenfassung von Prüfschritten mit gleichartiger Prüftechnik können die Wiederholungen des Szenarios in der Abarbeitung des Prüfkatalogs reduziert werden, idealerweise auf einen Durchlauf je Gruppe.

Die Nummern der verschiedenen Bezugssysteme – Prüfkatalog, Konformitätsstufen, Standards – werden bei den einzelnen Prüfschritten vermerkt. So können die Prüfpunkte und Testergebnisse flexibel nach verschiedenen Gesichtspunkten sortiert werden.

Bearbeitungsmodalitäten

Abschnitte des Prüfkatalogs:

  1. Sichtprüfung bei normaler Darstellung

  2. Bedienung mit Zeigegeräten (Maus, Touch)

  3. Bedienung mit Tastatur

  4. Darstellung im Screenreader

  5. Personalisierte visuelle Darstellung

  6. Personalisierte Eingabe

  7. Standardkonforme Programmierung

Für Touch und für Spracheingabe wird die Ausarbeitung zurückgestellt, da aktuell eine rasche technische Entwicklung stattfindet, die abzuwarten ist. Im Prüftool werden entsprechende Prüfschritte ohne Bewertung eingestellt, die als Sammelpunkt für Beiträge der Fachcommunity dienen sollen.

Es ist zu betonen, dass diese Einteilung der Prüfschritte sich aus der Laborsituation der Prüfung ableitet und nicht die reale Hilfsmittelnutzung der behinderten Anwender abbilden will. Es geht darum, Erfolgskriterien adäquat und effizient zu testen.

Nummerierung

Da die Prüftechnik dem technischen Wandel unterworfen ist, muss die Gliederung des Prüfkatalogs veränderbar sein. Die Nummerierung muss erweiterbar sein, d.h. auf jeder Ebene offene Stellen enthalten. So können Ergänzungen und Veränderungen eingeordnet werden, ohne gleich das ganze System zu reorganisieren.

Aufbau eines Prüfpunktes

Prüfpunkt = Test eines Erfolgskriteriums. Die Begriffe Prüfpunkt und Prüfschritt werden synomym gebraucht. „Prüfpunkt“ betont die Unabhängigkeit eines Erfolgskriteriums, „Prüfschritt“ die Einordnung in eine sinnvolle Reihenfolge.

Aufbau in Anlehnung an den BITV-Test.

Bewertung

Die Bewertung der Software findet nicht, wie im BITV-Test, summarisch je Prüfschritt statt. Bewertet werden einzelne Befunde, bezogen auf einzelne UI-Elemente, nach „erfüllt“ und „nicht erfüllt“.

3-stufige Bewertung von nicht erfüllten Prüfschritten: Blockade, Barriere, Einschränkung .

Demnach wären Blockaden als „nicht zugänglich“ und Barrieren/Einschränkungen als „zugänglich, aber ineffizient“ einzuordnen.

Die Bewertung zu „Blockade/Barriere“ orientiert sich an der Situation des routinierten Anwenders, der die Bedienoberfläche kennt. Die Bewertung zu „Einschränkung“ orientiert sich an der Situation des seltenen Nutzers, der die angebotenen Funktionen im Prinzip kennt, sich aber orientieren muss, um die Bedienelemente wiederzufinden. Nicht berücksichtigt wird die Situation des Novizen, der die Anwendung nicht kennt und alleine erkunden möchte. Zur Beurteilung der Erlernbarkeit muss in unserem Rahmen die Prüfung der Dokumentation ausreichen.

Die Bewertung bezieht sich auf Einzelbefunde, eine Zusammenfassung der Einzelbefunde je Prüfschritt bzw. ein Gesamtergebnis der Prüfung sind im bisherigen Stand des Verfahrens nicht vorgesehen. Ein aussagekräftiges Ergebnis der Prüfung entsteht aus einer Auszählung bzw. Auflistung der vorgefundenen Blockaden, Barrieren und Einschränkungen. Dopplungen (dasselbe UI Element für dasselbe Erfolgskriterium mehrmals bemängeln) sollten ausgeschlossen werden, um belastbare Kennwerte zu gewinnen. Hierauf ist im Szenario zu achten. Im Prüfkatalog wird in der Abgrenzung der Prüfpunkte auf Überschneidungen und Anschlüsse aufmerksam gemacht.

In einer Weiterentwicklung des Verfahrens kann ein numerisches Ergebnis (Score) der Prüfung eingeführt werden. Ein Ansatz hierzu könnte sein, die bemängelten Elemente zu der Grundgesamtheit aller Elemente der Anwendung ins Verhältnis zu setzen (prozentualer Wert). Ein Verfahren zur Ermittlung der Grundgesamtheit wäre zu erproben.

Abbruchbedingungen werden in der praktischen Prüfung nicht definiert. In den vorgelagerten Prüfungen und durch die Basisstufe 0 gibt es ausreichende Möglichkeiten, „Showstopper“ mit begrenztem Aufwand festzustellen. Sollte im Einzelfall dennoch ein Zustand eintreten, der den Abbruch der Prüfung rechtfertigt, so ist dies im Prüfbericht zu begründen und detailliert zu dokumentieren.

Prüfprotokoll / Reporting-Tool

Das Reporting-Tool wird als Datenbankanwendung entwickelt. Es enthält Eingabeformulare zur Erfassung des Prüfprotokolls sowie verschiedene Reports zur Auswertung der Ergebnisse.

Die Erfassung des Prüfprotokolls folgt den Prüfschritten des Prüfkatalogs, die nach Bearbeitungsmodalitäten gegliedert sind. Zu jedem Prüfschritt wird vermerkt, ob er anwendbar ist oder nicht. Zu jedem Prüfschritt können Fundstellen zugeordnet werden, je Fundstelle eine Protokollzeile/Datensatz. Fundstellen sind UI-Elemente oder Programmsituationen, in denen ein Mangel festgestellt wurde. Der Prüfer trägt die Fundstellen nach der Reihenfolge des Szenarios ein und notiert einen Kommentar sowie die Bewertung des Mangels (Blockade, Barriere, Einschränkung). Der Prüfschritt ist erfüllt, wenn keine Mängel aufgetreten sind. Es können auch Fundstellen ohne Bewertung eingetragen werden, wenn derselbe Sachverhalt bereits in einem früheren Prüfschritt gewertet wurde, oder um Beobachtungen mitzuteilen, die ein „nicht erfüllt“ nicht rechtfertigen würden.

Mängel sind per Screenshot zu dokumentieren. Das Reporting-Tool bietet idealerweise eine Möglichkeit, Screenshots und Screencasts incl. Ton anzufertigen und bei der jeweiligen Protokollzeile abzurufen.

Prüfbericht

Der Prüfbericht umfasst

Zu diskutieren wäre, ob eine Auswertung nach Art der Behinderung gewünscht wird. Nach dem Beispiel eines Mitglieds im Expertenkreis (T-Systems Multimedia Solutions Accessibility Test Center) könnten Mängel nicht nur nach Schweregrad, sondern zusätzlich nach Art der Behinderung klassifiziert werden. Hierfür wäre der Prüfkatalog entsprechend zu erweitern. Bei jedem Prüfpunkt wären die betroffenen Behinderungen anzugeben, wobei zumeist mehrere in Frage kommen. Die Zuordnungen wären aus Understanding WCAG sowie aus ISO9241-171 abzuleiten.

SW-Feature Blinde Sehbehindert Tastaturnutzer Kognitiv Behinderte
Feature N A C B -

Literatur

Prüfschritte zum Prüfplan

I. Sichtprüfung bei normaler Darstellung

Prüfschritt 1.01.0 - Ausreichender Kontrast

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Alle Schriften und Symbole der Anwendung haben einen ausreichenden Helligkeitskontrast, d.h. Vorder- und Hintergrund des Zeichens kontrastieren im Verhältnis von mindestens 4,5:1 bei normaler Schrift und von 3:1 bei großer Schrift. Große Schrift hat mindestens 18pt Versalhöhe bei normaler Strichstärke und 14pt bei Fettung.

Wenn die Anwendung ein personalisiertes Farbschema anbietet, mit dem ein ausreichender Helligkeitskontrast eingestellt werden kann, so hat die Standardversion der Anwendung einen Helligkeitskontrast von mindestens 3:1 bei allen Zeichen.

Die Kombination von gesättigtem Rot mit Schwarz ist trotz ausreichenden Helligkeitskontrasts als Vorder- und Hintergrundfarbe von Zeichen zu vermeiden.

Die Anforderung gilt nicht

  • für Bedienelemente, die aktuell nicht zur Verfügung stehen und „ausgegraut“ dargestellt sind
  • für Symbole, die mit ausreichendem Kontrast beschriftet sind
  • für Symbole, bei denen eine bestimmte Farbgestaltung wesentlich ist, z.B. für Logos
  • für Bilder

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

keine

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist immer anwendbar.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Ein Helligkeitskontrast von 3:1 ist das von ISO-9241-303 empfohlene Minimum für gut lesbare Schrift bei normaler Sehfähigkeit. Ein Kontrast von 4,5:1 wird angesetzt, um dem Verlust an Kontrastempfinden Rechnung zu tragen, der aus mäßig verminderter Sehschärfe, aus Farbfehlsichtigkeit oder aus normaler Alterung resultiert.

Die Möglichkeit einer personalisierten Farbeinstellung darf nicht dazu führen, dass die Anwendung in der Normalansicht nicht mehr gut lesbar ist. Denn Benutzer mit geringen Einschränkungen wollen in der Regel die Normalansicht verwenden, um sich leichter mit anderen Benutzern austauschen zu können.

Von diesem Erfolgskriterium profitieren auch Benutzer von Schwarzweiß-Monitoren und in Umgebungen mit starkem Lichteinfall.

Trotz ausreichender Kontrastwerte ist die Kombination von gesättigtem Rot mit Schwarz als Vorder- und Hintergrund von Zeichen nicht empfehlenswert (vgl. ISO 9241-125). Es gibt jedoch keine klaren Vorgaben für Farbwerte von gesättigtem Rot, daher kann der Prüfer nur aufgrund seiner subjektiven Wahrnehmung urteilen. Ein entsprechender Befund sollte nur als Empfehlung mitgeteilt werden.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]

  • Die Anwendung mit dem Standard-Farbschema verwenden.
  • Sichtprüfung: haben die Schriften und Symbole der Anwendung einen ausreichenden Helligkeitskontrast? Wird gesättigtes Rot in Kombination mit Schwarz vermieden?
  • Im Zweifel den Helligkeitskontrast mit dem Colour Contrast Analyser (siehe Werkzeugliste) überprüfen. Vorder- und Hintergrund der Zeichen sollen mindestens einen Kontrast von 4,5:1 bei normaler Schrift und 3:1 bei großer Schrift haben.
  • Bei sehr feinen Schriften ist ggf. die Schriftfarbe im Prüftool nicht zu treffen. Zur Abhilfe eine größere Schrift einstellen, oder unter Systemsteuerung -Anzeige die Clear-Type-Darstellung ausstellen. 
  • Bei konturierten Zeichen die Farbe der Kontur als Vordergrund auswählen.
  • Bei mehrfarbigen Icons die Farbe mit dem stärksten Kontrast gegen den Hintergrund als Vordergrund auswählen. Die Größe des Zeichens nach der Größe des so definierten Vordergrunds bemessen. Im Zweifel das Icon als Bild einordnen und nicht testen.
  • Die Maßangaben für große Schrift gelten für den Standard-Bildschirm (siehe Testsystem). Messen Sie die Höhe der Großbuchstaben E oder H (Außenmaße) bzw. die Höhe des Symbols mit dem Keseling Bildschirmlineal (siehe Werkzeugliste). 18pt entsprechen 6,35mm, 14pt fett entsprechen 4,94mm.

 

  • Falls der Helligkeitskontrast nicht ausreicht, feststellen, ob die Anwendung ein alternatives Farbschema anbietet, oder ob in der Dokumentation die Übernahme eines Windows-Farbschemas beschrieben wird. Falls ja, wie oben beschrieben überprüfen, ob das alternative Farbschema einen ausreichenden Helligkeitskontrast hat.
    Anmerkung: Der Prüfer muss nicht selbst ermitteln, welches Windows-Design für die Anwendung geeignet ist.
  • Falls das alternative Farbschema einen ausreichenden Helligkeitskontrast hat, feststellen, ob das Standard-Farbschema der Anwendung mindestens einen Kontrast von 3:1 für alle Zeichen hat.

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Kontrastwerte von weniger als 98% der Anforderung (4,41:1 bzw. 2,94:1) sind eine Einschränkung.

Kontrastwerte von weniger als 80% der Anforderung (3,6:1 bzw. 2.4:1) sind eine Barriere.

Kontrastwerte von weniger als 50% der Anforderung (2,25:1 bzw. 1,5:1) sind eine Blockade, sofern Elemente betroffen sind, die für die Arbeitsaufgabe wesentlich sind.

Gesättigtes Rot mit Schwarz als Zeichenfarbe wird nicht bewertet, eine entsprechende Beobachtung wird als Empfehlung mitgeteilt.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

Der Bewertungsmaßstab benötigt Verifizierung.

 

Referenzen

EN301549

11. 2.1.12 Contrast (minimum)

WCAG

1.4.3 Kontrast (Minimum)

WCAG-Techniques

G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text

ISO9241-171

10.4.5 Für Kontrast zwischen Vordergrund und Hintergrund sorgen

Sonstige

ISO 9241-303 Anforderungen an elektronische optische Anzeigen

ISO 9241-125 Anleitung zur visuellen Informationsdarstellung 

Zuletzt bearbeitet

31.10.2016

 

 

Prüfschritt 1.03.0 - Verzicht auf Bewegung, Blinken und Flackern

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Sich bewegende Elemente sollen nicht unaufgefordert gleichzeitig mit anderen Inhalten erscheinen, es sei denn dies ist sachlich erforderlich (Warnmeldung, Real-Time-Anwendung). Die Darbietung sich bewegender Elemente soll auf 5 Sekunden begrenzt sein oder abschaltbar sein.

Gänzlich zu vermeiden sind grell flackernde Elemente in der Größe von Schaltflächen (12 pt Kantenlänge) oder größer. Flackern ist ein Farbwechsel von mehr als 3 Blitzen je Sekunde. Grelles Flackern ist ein Farbwechsel mit einem starken Kontrast, wobei gesättigtes Rot in jeder Größe zu vermeiden ist. 

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Ein blinkender Warnhinweis wird nach fünf Sekunden dauerhaft sichtbar.

Ein Börsenticker mit beweglichen Real-Time-Informationen kann angehalten werden.

In einem Eingabefeld blinkt der Cursor langsamer als 3 mal pro Sekunde.

Fehler: Ein in eine Anwendung eingebundenes Video startet unaufgefordert.

Fehler: Ein blinkender Warnhinweis flackert grell.

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, wenn die Anwendung sich bewegende Elemente enthält.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Blinkende oder sich bewegende Elemente ziehen die Aufmerksamkeit des Benutzers auf sich. Bewegung ist sinnvoll, um auf das Eintreten wichtiger Ereignisse aufmerksam zu machen, aber sollte nur von kurzer Dauer sein, um die Konzentration auf andere Elemente der Anwendung nicht zu stören. Dauerhaft bewegte Inhalte sollten nur dann unaufgefordert präsentiert werden, wenn es sachlich erforderlich ist (Real-Time-Anwendung). Sofern dauerhaft bewegte Inhalte zugleich mit anderen Elementen angezeigt werden, müssen sie abgeschaltet oder angehalten werden können.

Grelles Flackern kann bei Menschen mit Epilepsie einen Anfall auslösen, bereits bei einer Dauer von weniger als 5 Sekunden. Grelles Flackern einzelner Elemente kann die Nutzbarkeit der gesamten Anwendung stören und ist daher gänzlich zu vermeiden. Bei welcher Größe ein flackernder Bereich schädlich ist, wird in WCAG in Bezug auf Videos ausgeführt. In Bezug auf die Elemente von Anwendungssoftware (Meldungen, Bedienelemente) muss ein kleinerer Grenzwert angenommen werden, da der Nutzer seinen Blick auf solche Elemente stärker fokussiert. Elemente, die so groß sind wie Schaltflächen, sollen nicht grell flackern. Flackern in gesättigtem Rot ist in jeder Größe schädlich.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]

Prüfen, ob sich bewegende Elemente nach spätestens fünf Sekunden automatisch enden, oder ob sie abschaltbar sind. Die Möglichkeit zum Abschalten der Bewegung (z.B. Button, Hinweis auf Tastaturbefehl) muss unmittelbar in der Nähe des sich bewegenden Elements angeordnet sein. Die Bewegung soll anhalten und nicht von alleine wieder anfangen.

Bei bewegten Inhalten, die unaufgefordert erscheinen, prüfen, ob die bewegte Darstellung sachlich erforderlich ist, weil es eine Real-Time-Anwendung ist.

Prüfen, ob keine in gesättigtem Rot flackernden Elemente vorkommen.

Prüfen, ob keine grell flackernden Elemente (nicht rot) in einer Größe von 12pt bzw. 4,23mm Kantenlänge oder mehr vorkommen. Die Maßangabe bezieht sich auf den Standard-Bildschirm (siehe Testsystem), zu messen mit dem Kieseling Bildschirmlineal (siehe Werkzeugliste). Bei Text messen Sie die Höhe der Großbuchstaben E oder Z (Außenmaße).

In Ermangelung eines Prüftools muss der Prüfer nach eigenem Ermessen entscheiden, ob „gesättigtes Rot“, „Kontrastfarben“ und eine Blinkfrequenz von 3 und mehr Blitzen je Sekunde vorliegen. Im Zweifelsfall soll eher ein Mangel befunden werden.

Flackern wird nur in Bezug auf die Bedienoberfläche der Anwendung geprüft, nicht in Bezug auf die Inhalte von Videos.

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Blockade: Die Anwendung enthält rot flackernde Elemente, oder sie enthält grell flackernde Elemente von 12pt Kantenlänge oder größer.

Barriere: Die Anwendung präsentiert unaufgefordert bewegte Elemente, die länger als 5 Sekunden dauern und nicht abschaltbar sind.

Einschränkung: Die Anwendung präsentiert unaufgefordert bewegte Elemente von mehr als 5 Sekunden Dauer, die abschaltbar sind, die aber sachlich nicht erforderlich sind.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfschritt geht es darum, die Störung der visuellen Wahrnehmung durch bewegte Elemente zu vermeiden. Daher wird hier nur geprüft, ob Bewegung kurz oder abschaltbar ist und unterhalb der Schwellenwerte für gesundheitliche Beeinträchtigungen bleibt. Die weitere Steuerung bewegter Inhalte, etwa um Text in Ruhe lesen zu können, wird im Prüfschritt 2.03.1 "Bewegte Inhalte sind steuerbar" geprüft.

In diesem Prüfschritt wird Bezug genommen auf die Größe von Schaltflächen, diese wird definiert im Prüfschritt 2.01.2 „Ausreichende Größe von Schaltflächen“.

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

Prüftool für Flackern suchen.

Der Ausdruck „grelles Flackern“ wurde gewählt, um die komplizierten Formulierungen der Standard-Dokumente zu veranschaulichen. Beobachten, ob der Ausdruck allgemeinverständlich ist und in der Community akzeptiert wird.

Der Grenzwert 12 pt Kantenlänge für grell flackernde Elemente, die fokussiert werden müssen, wurde hypothetisch festgelegt. Beobachten, ob der Wert von der Forschung verifiziert wird.

 

Referenzen

EN301549

11. 2.1.18 Pause, stop, hide

11. 2.1.19 Three flashes or below threshold

WCAG

2.2.2 Pausieren, beenden, ausblenden

2.3.1 Grenzwert von dreimaligem Blitzen oder weniger

K5 Nicht störend

WCAG-Techniques

G176: Den blitzenden Bereich klein genug halten

ISO9241-171

10.1.1 Anfälle verursachende Blinkraten vermeiden

 

Zuletzt bearbeitet

29.09.2016

 

 

Prüfschritt 1.04.0 - Ton ist steuerbar

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Automatisch abgespielte Töne dauern nicht länger als drei Sekunden oder sind abschaltbar.

Die Lautstärke von Tondokumenten kann unabhängig von der Lautstärke des Screenreaders geregelt werden.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Signaltöne und akustische Meldungen, die den Benutzer auf ein Ereignis aufmerksam machen sollen, dauern nicht länger als drei Sekunden.

Eine Anwendung mit Hintergrundmusik kann über die Lautstärkeregelung des Betriebssystems so leise gestellt werden, dass der Ton nicht mehr zu hören ist.

Ein Tondokument, das automatisch zu spielen beginnt, kann über einen mit Tastatur und Screenreader bedienbaren Schalter beendet oder unterbrochen werden.

Ein Tondokument, das für die Arbeitsaufgabe wichtig ist, kann in der Lautstärke so geregelt werden, dass der Ton sich deutlich von der Sprachausgabe des Screenreaders unterscheidet.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, wenn eine Anwendung Tonelemente nutzt.

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Nutzer von Screenreadern können es schwierig finden, die Sprachausgabe zu verstehen, wenn gleichzeitig andere Töne abgespielt werden. Daher müssen automatisch abgespielte Töne kurz sein oder abgeschaltet bzw. heruntergeregelt werden können. Die Lautstärke von Tondokumenten muss unabhängig von der Lautstärke des Screenreaders geregelt werden können, damit die verschiedenen Tonquellen ausreichend kontrastieren.

Die Bedienelemente zur Steuerung des Tons müssen für Screenreadernutzer zugänglich sein, um diesen Prüfpunkt zu erfüllen.

Von diesem Prüfpunkt profitieren auch Nutzer mit Aufmerksamkeitsstörungen, die bei laufendem Ton Schwierigkeiten haben, sich auf die Bedienung der Anwendung zu konzentrieren.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]

Wenn ein Tonelement automatisch abgespielt wird, prüfen, ob es länger als drei Sekunden dauert. Wenn das der Fall ist: Prüfen, ob es einen Mechanismus (Button oder Lautstärke-Regler) gibt, mit dem sich der Ton abschalten oder herunterregeln lässt.

Bedienelemente der Anwendung, die den Ton abschalten oder herunterregeln, darauf überprüfen, ob sie mit Tastatur und Screenreader zugänglich sind, siehe die Prüfschritte „Nutzung aller Funktionen über die Tastatur ermöglichen“ und „Name für grafische Bedienelemente und Anzeigen“. Die Lautstärkeregelung des Betriebssystems muss in diesem Zusammenhang nicht überprüft werden.

Bei Tondokumenten, und wenn ein automatisch abgespielter Ton nur durch Lautstärkeregelung abschaltbar ist: Überprüfen, ob die Lautstärke der Anwendung unabhängig von der Lautstärke des Screenreaders geregelt werden kann. Hierfür kann es genügen, wenn die Anwendung auf die Lautstärkeregelung des Betriebssystems zugreift, die für die verschiedenen Anwendungen separat eingestellt werden kann.

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Der Prüfschritt ist erfüllt, wenn automatisch abgespielte Töne nicht länger als drei Sekunden dauern, oder wenn es Bedienelemente zur Steuerung des Tons gibt, die mit Tastatur und Screenreader zugänglich sind. Bei Tondokumenten, und wenn ein automatisch abgespielter Ton nur durch Lautstärkeregelung abschaltbar ist, muss die Lautstärke unabhängig von der Lautstärke des Screenreaders regelbar sein.

Blockade: Automatisch abgespielte Töne von mehr als 3 Sekunden Dauer können nicht abgebrochen oder heruntergeregelt werden.

Blockade: Bedienelemente zur Steuerung des Tons sind mit Tastatur und Screenreader nicht zugänglich.

Wenn die Lautstärke von Tondokumenten nicht unabhängig von der Lautstärke des Screenreaders geregelt werden kann, so ist zu bewerten, ob dennoch eine ausreichende Unterscheidung der Tonquellen möglich ist. Je nach der Schwere der Beeinträchtigung ist es eine Blockade, Barriere oder Einschränkung.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfschritt geht es darum, dass die Sprachausgabe des Screenreaders nicht von Tönen der Anwendung überlagert werden darf. Es geht nicht darum, dass ein Tondokument für Screenreadernutzer zugänglich und benutzbar sein muss. Die Bedienelemente des Audio- bzw. Videoplayers werden daher ausschließlich unter dem Gesichtspunkt überprüft, ob der Ton mit Tastatur und Screenreader abgeschaltet oder heruntergeregelt werden kann. Weitere Funktionalitäten des Players, z.B. Start und Pause, werden in anderen Prüfschritten untersucht.

Mängel in der Steuerung des Tons, die auf mangelnder Zugänglichkeit mit Tastatur und Screenreader beruhen, sollen nicht mehrfach angerechnet werden.

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

Da Screenreadernutzer bei laufendem Ton Schwierigkeiten haben können, die Bedienelemente zur Regelung des Tons zu finden, wird in Unterstanding WCAG empfohlen, auf das automatische Abspielen von Ton- und Videodokumenten gänzlich zu verzichten. Sollte unser Prüfverfahren diese strengere Auslegung übernehmen?

In dem Fall wäre es ein Mangel, wenn automatisch abgespielter Ton länger als 3 Sekunden läuft, auch wenn er ausgeschaltet werden kann.

Referenzen

EN301549

11. 2.1.11 Audio control

WCAG

1.4.2 Audio-Steuerelement

1.4.7 Leiser oder kein Hintergrund-Audioinhalt

K5 Nicht störend

WCAG-Techniques

ISO9241-171

10.6.2 Lautstärkeregelung ermöglichen

10.6.5 Einstellbarkeit des Hintergrundgeräuschs und anderer Audiokanäle

10.8.1 (Medien) Benutzern die Funktionen "Stopp", "Start" und "Pause" zur Verfügung stellen

Prüfschritt 1.10.0 - Alternativen für Abbildungen und Multimedia-Inhalte

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Abbildungen und Multimedia-Inhalte in Anwendungen sind mit Text- oder Medienalternativen versehen, um Benutzer zu unterstützen, die Inhalte nicht sehen oder hören können, es sei denn die Multimedia-Inhalte sind selber Medienalternativen.

  • Für Abbildungen (Diagramme, technische Zeichnungen, Landkarten etc.) wird eine Beschreibung bereitgestellt.
  • Für Nur-Video-Inhalte  (bewegte Bilder ohne Ton) wird eine textuelle Beschreibung bereitgestellt.
  • Für Nur-Audio-Inhalte wird eine Transkription des gesprochenen Textes bzw. eine Beschreibung der zu hörenden Töne bereitgestellt.
  • Für Videos (synchrone Audio- und Video-Inhalte) werden synchronisierte Untertitel bereitgestellt.
  • Für bedeutungstragende stumme Sequenzen in Videos werden gesprochene Beschreibungen (Audiodescription) in die Tonspur integriert, oder es wird eine separate textuelle Beschreibung aller visuellen Informationen bereitgestellt.

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Eine Landkarte enthält Symbole, die das Vorhandensein von Bodenschätzen anzeigen. Als alternative Beschreibung ist eine Tabelle beigefügt, die die Bodenschätze und die Orte ihrer Verbreitung enthält.

Ein Organigramm ist als synoptische Darstellung abgebildet, in der die Beziehungen durch Pfeile angedeutet sind. Eine alternative Darstellung ist verfügbar, die die Struktur als Text beschreibt.

Einer Audio-Aufnahme wird ein Text-Transkript bereitgestellt, das direkt beim Audio-Clip abrufbar ist.

Eine Animation in einem Tutorial zeigt, wie ein Automotor funktioniert. Der Text des Tutorials enthält eine vollständige Beschreibung des Automotors.

Ein Lehrfilm ist mit Untertiteln ausgestattet, die die Inhalte der Tonspur synchron wiedergeben. Die Untertitel umfassen gesprochene Inhalte mitsamt einer Benennung des Sprechers, sowie eine Beschreibung von nichtsprachlichen Tönen.

Ein Lehrfilm ist mit einer Audiodescription ausgestattet, die die nicht auf der Tonspur erläuterten visuellen Inhalte beschreibt und in die Pausen der Tonspur integriert.

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, wenn fest installierte Multimedia-Inhalte in einer Anwendung enthalten sind, z.B. Bedienungsanleitungen oder Hintergrundinformationen.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Medienalternativen helfen Menschen mit Sinnesbehinderungen, die visuelle oder auditive Inhalte nicht wahrnehmen können. Audiodateien sind für hörbehinderte Nutzer nicht oder nur eingeschränkt zugänglich, deshalb ist eine Transkription erforderlich. Stumme Videodateien (etwa eine Film- oder Animationssequenz, die zeigt, wie ein Gerät zusammengesetzt wird) sind für blinde und sehbehinderte Nutzer nicht zugänglich, deshalb ist eine Medienalternative in Form von Text oder einer Audiodatei erforderlich.

Text ist als Medienalternative vielfältig einsetzbar, z.B. können Menschen, die taub-blind sind, den Text in Braille lesen. Darüber hinaus unterstützt Text die Möglichkeit, nach Medieninhalten zu suchen und Inhalte auf eine Vielzahl von Arten zu einem neuen Zweck zu verbinden.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]

Prüfen, ob für Abbildungen und Multimedia-Inhalte Text- oder Medienalternativen zur Verfügung stehen, so dass blinde, sehbehinderte oder gehörlose Benutzer gleichermaßen die Funktionen nutzen können.

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Bewertung von Mängeln nach der Bedeutung der ausfallenden Information für die Erledigung der Arbeitsaufgabe.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Der Prüfschritt bezieht sich auf fest implementierte Medien. Er bezieht sich nicht auf auswechselbare Inhalte von Diashows, Media-Playern etc.

Multimedia-Inhalte, die eine Dokumentation der Anwendung selbst darstellen, werden im Prüfplan „Dokumentenprüfung“ geprüft.

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

-

Referenzen

EN301549

11. 2.1.1 Non-text content (screen reading supported)

11. 2.1.2 Audio-only and video-only (pre-recorded)

11. 2.1.3 Captions (pre-recorded)

11. 2.1.4 Audio description or media alternative (pre-recorded)

11. 2.1.5 Captions (live)

11. 2.1.6 Audio description (pre-recorded)

WCAG

1.1.1 Nicht-Text-Inhalte

1.2.1 Reine Audio- und Videoinhalte (aufgezeichnet)

1.2.2 Untertitel (aufgezeichnet)

1.2.3 Audiodeskription oder Medienalternative (aufgezeichnet)

1.2.4 Untertitel (Live)

1.2.5 Audiodeskription (aufgezeichnet)

WCAG-Techniques

BITV-Test

1.1.1b Alternativtexte für Grafiken und Objekte

1.2.1a Alternativen für Audiodateien und stumme Videos

1.2.2a Videos mit Untertiteln

1.2.3a Audiodeskription für Videos

ISO9241-171

10.1.3 Zugängliche Alternativen für aufgabenrelevante Audio- und Videoinformationen zur Verfügung stellen

 

Zuletzt bearbeitet

28.11.2016

 

III Bedienung mit Tastatur

Prüfschritt 3.01.0 - Tastaturbedienung für Bedienelemente

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Die Anwendung soll auch ohne Maus, also ausschließlich mit der Tastatur, zu benutzen sein. Alle Aktionen, die mit der Maus ausführbar sind, sollen auch mit der Tastatur ausführbar sein, mit Ausnahme von bewegungsabhängigen Funktionen wie Handschrift oder Zeichnungen.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Alle Bedienelemente können mit TAB oder Pfeiltasten fokussiert und mit ENTER oder SPACE ausgelöst werden.

Ein Schieberegler zur Steuerung der Lautstärke kann mit TAB angesprungen und wieder verlassen werden, mit den Pfeiltasten kann die Einstellung geändert werden.

Ein geöffnetes Dialogfenster kann mit dem Schließen-Button oder mit der ESC-Taste geschlossen werden.

In einem Eingabefeld kann Text mit der Tastatur zeichenweise fokussiert und markiert werden.

Eine Software verwendet einen Scrollbar, um lange Inhalte auf begrenztem Raum anzuzeigen. Der nicht sichtbare Bereich kann auch mit den Pfeiltasten und mit den Tasten SEITE AUF und SEITE AB sichtbar gemacht werden.

Ein Programm zum rechnergestützten Zeichnen (CAD) wird üblicherweise mit einer Maus verwendet, es bietet aber auch die Möglichkeit, Punkte anhand ihrer x-, y- und z-Koordinaten festzulegen und Zeichnungselemente aus einer hierarchischen Liste von Unterbaugruppen und Teilen auszuwählen oder mit Hilfe der Pfeiltasten zwischen den auf der Anzeige dargestellten Elementen zu navigieren.

Fehler (Tastaturfalle): Wenn in einer Gruppe von Bedienelementen die TAB-Reihenfolge rückwärts gegangen wird, gerät der Tastaturfokus in eine Schleife, aus der er nur durch Neustart der Anwendung befreit werden kann.

Fehler (Tastaturfalle): Ein in eine Anwendung integriertes Video akzeptiert Tastaturbefehle, jedoch kann der Fokus nicht mit der Tastatur aus dem Video herausbewegt werden.

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist immer anwendbar.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Die Bedienung soll geräteunabhängig möglich sein. Das bedeutet: Sie muss sowohl mit der Maus als auch mit der Tastatur möglich sein. Auch spezielle Eingabegeräte verhalten sich wie eine Maus oder eine Tastatur.

Auf die Tastaturbedienung angewiesen sind u.a. motorisch eingeschränkte Menschen, deren Feinmotorik für die Mausbedienung nicht ausreicht, oder Blinde, bei denen die für die Mausbedienung erforderliche Hand-Auge-Koordination ausfällt.

Die Tastaturbedienbarkeit einer Anwendung erhöht ebenfalls die Gebrauchstauglichkeit für Menschen ohne Behinderungen, da sie einen effizienten Bedienweg bei intensiver Nutzung bereitstellt.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]

Die für die aktuelle Situation des Szenarios einzusetzenden Tastaturbefehle ermitteln, über die Dokumentation oder über andere Quellen wie kontextsensitive Hilfe, Herstellerinterview, eigene Erprobung. Anmerkung: Soweit die Tastaturbefehle nicht dokumentiert sind, unterliegt ihre Berücksichtigung dem Prüfauftrag.

Praktische Erprobung: Können alle Bedienelemente mit der Tastatur fokussiert, eingestellt und ausgelöst werden? Dabei sowohl vorwärts als auch rückwärts durch die Reihe der Elemente gehen. Sich öffnende Dialoge und eingebundene Fremdformate besonders beachten.

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Eine Tastaturfalle ist eine Blockade.

Andere Mängel werden nach der Bedeutung des ausfallenden Elements für die Arbeitsaufgabe bewertet.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfschritt geht es darum, dass alle Bedienelemente mit der Tastatur erreichbar und bedienbar sind. Gegenstand anderer Prüfschritte sind die folgenden Aspekte:

  • Nicht-Bedienelemente siehe 3.03.0 „Direktzugriff auf Funktionsbereiche der Anwendung“ und 3.04.1/3.05.2 „Tastaturbedienung für Anzeigen“
  • Zur Effizienz und Erwartungskonformität siehe 3.08.1 „Keine unerwartete Kontextänderung“, 3.09.2 „Effiziente Tastatursteuerung“, 3.10.2 „Tastaturkonventionen der Plattform befolgen“
  • Zur Dokumentation der Tastaturbefehle siehe 3.11.0 „Vollständige Dokumentation der Tastaturbefehle“ und 3.12.2 „Kontextsensitive Hilfe für Tastaturbefehle“

Folgende Bedienelemente werden bereits in anderen Zusammenhängen geprüft und sollen in diesem Prüfpunkt ausgenommen werden, um eine Dopplung zu vermeiden:

  • Bedienelemente zur Steuerung des Tons
  • Bedienelemente zum Öffnen der Dokumentation oder Online-Hilfe

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

 

Referenzen

EN301549

11. 2.1.15 Keyboard

11. 2.1.16 No keyboard trap

WCAG

2.1.1 Tastatur

2.1.2 Keine Tastaturfalle

K5 Nicht störend

WCAG-Techniques

ISO9241-171

9.3.2 Nutzung aller Funktionen über die Tastatur ermöglichen

 

Zuletzt bearbeitet

31.10.2016

 

 

Prüfschritt 3.03.0 - Direktzugriff auf Funktionsbereiche

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Verschiedene Funktionsbereiche der Anwendung wie Menü, Werkzeugleiste und Statuszeile sowie verschiedene Inhaltsbereiche wie Baumansicht und Detailansicht können durch einen Tastaturbefehl angesprungen werden.

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

In Office-Anwendungen mit der ALT-Taste  zwischen Menü und Dokument wechseln.

Im Dateimanager mit TAB zwischen Adresszeile, Baum und Dateiliste wechseln.

Mit F6 zwischen den Abschnitten (Panes) einer Anwendung wechseln (Windows Standard).

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, wenn die Anwendung optisch unterscheidbare Funktionsbereiche hat.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Anwendungsprogramme bieten sehenden Benutzern eine visuelle Ordnung, mit deren Hilfe sie sich orientieren können. Diejenigen, die diese Ordnung nicht nutzen können – zum Beispiel, weil sie blind sind oder nur einen kleinen Ausschnitt sehen können – sind darauf angewiesen, dass die Struktur unabhängig von der Darstellung auf dem Bildschirm zugänglich und nutzbar ist. Der Direktzugriff auf Funktionsbereiche der Anwendung erlaubt Nutzern assistiver Technologien, sich ein mentales Modell vom Aufbau der Anwendung zu machen. Auch sehende Tastaturbenutzer und Benutzer von Spracheingaben profitieren davon, wenn sie Bereiche überspringen bzw. direkt anspringen können.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]

Die generellen Tastaturbefehle der Anwendung ermitteln, über die Dokumentation oder über andere Quellen wie kontextsensitive Hilfe, Herstellerinterview, eigene Erprobung.

Gibt es Tastaturbefehle für einen Direktzugriff auf die sichtbar unterschiedenen Funktionsbereiche der Anwendung wie Hauptmenü, Werkzeugleisten, Statuszeile, Datenbereich?

Falls ja, praktische Erprobung: Tastaturbefehl zum Direktzugriff auf die Funktionsbereiche anwenden und überprüfen, ob der Tastaturfokus folgt (ggf. mit TAB oder Pfeiltasten ein Element innerhalb des Funktionsbereichs auswählen).

Falls ein Funktionsbereich keine fokussierbaren Elemente enthält, kann er für diesen Prüfschritt nicht ausgewertet werden. Zur weiteren Prüfung siehe 4.04.0 „Name für Gruppen von Elementen“ und 5.04.1 „Fokusverfolgung im Großbildsystem“.

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Mängel sind eine Einschränkung.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

Die Zuordnung dieses Prüfschritts zu Stufe 0/I = Konformität mit EN 30549 stützt sich auf EN 301549 Nr. 11. 2.1.7 Info and relationships, obwohl dieses Erfolgskriterium sich eher auf die Benennung der Funktionsbereiche als auf ihre Tastaturbedienbarkeit bezieht. WCAG 2.4.1 „Blöcke umgehen“ bezieht beide Aspekte, Tastaturbedienung und Benennung, mit ein, und wird damit der praktischen Nutzbarkeit von programmatisch erkennbaren Strukturmerkmalen besser gerecht. EN 301549 hat den WCAG-Punkt nicht übernommen – eine Entscheidung, die überdacht werden sollte.

 

Referenzen

EN301549

11. 2.1.7 Info and relationships

WCAG

1.3.1 Info und Beziehungen

2.4.1 Blöcke umgehen

WCAG-Techniques

ISO9241-171

9.3.17 Die Navigation von Steuerungselementen durch Gruppierung erleichtern

 

Zuletzt bearbeitet

29.09.2016

 

 

Prüfschritt 3.07.0 - Sinnvolle Fokus-Reihenfolge

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Beim Navigieren mit der Tastatur erhalten die Bedienelemente einer Anwendung den Fokus in einer Reihenfolge, die der logischen Struktur oder dem Bedienablauf entspricht. Dies ist in der Regel der Fall,

  • wenn die Bedienelemente beim sequentiellen Navigieren in einer Reihenfolge fokussiert werden, die der sichtbaren Anordnung entspricht,
  • wenn beim Aktivieren einer Funktion das Ziel der Aktion den Tastaturfokus erhält,
  • wenn ein sich öffnender Dialog den Tastaturfokus erhält,
  • wenn beim Schließen eines Dialogs der Fokus zu seiner Ausgangsposition oder zum logisch folgenden Element zurückkehrt.

Die sinnvolle Reihenfolge muss nicht immer eindeutig sein, beispielsweise kann eine Tabelle sowohl zeilen- als auch spaltenweise gelesen werden.

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Beim Navigieren mit TAB und Pfeiltasten bewegt sich der Tastaturfokus entlang der logischen Blöcke der Bedienelemente.

In einer Baumstruktur kann der Benutzer mit den Pfeiltasten aufwärts und abwärts gehen. Pfeil-rechts öffnet eine Ebene, Pfeil-links schließt eine Ebene.

In einer Suchfunktion öffnet sich ein Dialog mit erweiterten Suchoptionen und einem OK-Button. Nach dem Beenden des Dialogs mit OK landet der Tastaturfokus auf dem ersten Element der angezeigten Suchergebnisse.

Fehler: Ein Formular ist in zwei nebeneinander stehende Blöcke angeordnet, wobei links Eingabefelder für Kontaktdaten mit Name, Anschrift etc. und rechts Checkboxen mit verschiedenen Statusangaben wie Kunde, Interessent etc. stehen. Beim Bedienen mit TAB erreicht der Benutzer abwechselnd ein Element des linken und des rechten Blocks.

Fehler: Beim Schließen eines Dialogfeldes kehrt der Fokus nicht zum auslösenden Button zurück, sondern landet am Anfang des Bildschirms.

Fehler: Beim Öffnen eines Dialogfelds erhält ein Element den Fokus, das aus Sicht des Anwenders zufällig erscheinen muss, weil es weder der aktuellen Aufgabe, noch einer Default-Position, noch dem zuletzt aktivierten Element entspricht. (Nicht verlangt wird, dass der Fokus immer auf dem ersten Bedienelement eines Dialogfensters stehen muss.)

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist immer anwendbar.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Durch eine nicht nachvollziehbare Reihenfolge der fokussierten Elemente kann die Tastaturbedienbarkeit für jeden Benutzer erheblich beeinträchtigt werden. Sehbehinderte oder blinde Benutzer werden darüber hinaus in ihrer Fähigkeit eingeschränkt, sich ein mentales Modell der Anwendung zu manchen.

Nach einem Dialog muss der Benutzer ggf. viele Tasten betätigen, um zu seiner vorigen Position zurückzukehren, falls der Tastaturfokus nicht automatisch wiederhergestellt wird.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]

Praktische Erprobung:

-         die unter Beschreibung und Beispiele genannten Fälle nachvollziehen

-         bei Mängeln feststellen, wie viele Bedienschritte (Tastenanschläge) benötigt werden, um zu der für die Arbeitsaufgabe sinnvollen Reihenfolge zurückzukehren

-         bei Mängeln feststellen, ob der Tastaturfokus gut sichtbar ist (Prüfschritt 3.06.1)

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Wenn mehr als drei Bedienschritte (Tastenanschläge) benötigt werden, um zu der für die Arbeitsaufgabe sinnvollen Reihenfolge zurückzukehren, so ist dies eine Barriere.

Wenn bei Benutzereingaben die Reihenfolge des Tastaturfokus willkürlich erscheint, und zugleich der Fokusindikator nur schwach sichtbar ist, so ist dies eine Barriere.

Alle weiteren Mängel sind eine Einschränkung.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

 

Referenzen

EN301549

11. 2.1.22 Focus order

WCAG

2.4.3 Fokus-Reihenfolge

WCAG-Techniques

ISO9241-171

9.2.3 Bei Wiedererhalten des Tastaturfokus den letzten Stand bereitstellen

9.3.18 Steuerungselemente in Gruppen anordnen, die der Navigationsreihenfolge entsprechen

 

Zuletzt bearbeitet

24.11..2016

 

Prüfschritt 3.11.0 - Vollständige Dokumentation der Tastaturbefehle

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Keine

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist immer anwendbar.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Nach DIN EN 82079 Erstellen von Gebrauchsanleitungen ist die Dokumentation ein Bestandteil des Produkts und muss richtig, vollständig und zielgruppengerecht aufbereitet sein.

Besonders wenn Nutzer auf die Tastatur angewiesen sind, benötigen sie eine vollständige Dokumentation der Tastaturbefehle, um die Bedienung der Anwendung erlernen zu können. Selten gebrauchte Tastaturbefehle sind den Benutzern nicht geläufig und müssen nachgeschlagen werden können.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]

Ermitteln Sie die für die aktuelle Situation des Szenarios einzusetzenden Tastaturkommandos über die Dokumentation oder über andere Quellen wie kontextsensitive Hilfe, Herstellerinterview, eigene Erprobung.

Prüfen Sie, ob die ermittelten Tastaturkommandos richtig und vollständig in der zusammenhängenden Dokumentation der Anwendung oder in der Windows-Hilfe verzeichnet sind.

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Mängel sind eine Einschränkung.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfpunkt geht es um die Dokumentation im Sinne einer zusammenhängenden Darstellung von Bedienfunktionen. Eine kontextsensitive Hilfe, die punktuelle Hinweise auf Tastaturkommandos geben kann, ist Gegenstand des Prüfpunkts „kontextsensitive Hilfe“.

In diesem Prüfpunkt geht es um die Inhalte der Dokumentation. Die Barrierefreiheit der Dokumentation und der barrierefreie Zugang zur Dokumentation sind Gegenstand des Prüfplans „Dokumentenprüfung“.

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

 

Referenzen

EN301549

12.1.1. Accessibility and compatibility features

WCAG

-

WCAG-Techniques

ISO9241-171

11.1.1 Verständliche Dokumentationen und Hilfen zur Verfügung stellen

Weitere Standards

DIN EN 82079 Erstellen von Gebrauchsanleitungen

 

Zuletzt bearbeitet

29.09.2016

 

IV Darstellung im Screenreader

Prüfschritt 4.01.0 - Wiedergabe von Text

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Alle sichtbaren Texte der Anwendung werden vom Screenreader vorgelesen.

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Alle Beschriftungen, Anweisungen, Meldungen und Textinhalte der Anwendung werden vom Screenreader vorgelesen.

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist immer anwendbar.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Der Prüfschritt spiegelt das erste Kennenlernen einer Anwendung, in der der Bildschirminhalt von oben bis unten unten linear im Screenreader gelesen wird. Dabei sollen mindestens alle sichtbaren Texte der Anwendung wiedergegeben werden. Ausfälle sind ein Hinweis auf nicht standardkonforme Programmierung, die in späteren Prüfschritten weiter untersucht wird.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]

Nach dem Öffnen der Anwendung zunächst feststellen, wo der Tastaturfokus steht. Ab hier mit der Screenreader-Funktion „Alles lesen“ die Bildschirminhalte von oben bis unten lesen. An den Anfang des Bildschirms gehen und ab hier die Bildschirminhalte bis zum Einstiegspunkt lesen.

Werden alle sichtbaren Texte der Anwendung vom Screenreader vorgelesen?

Falls einzelne Texte nicht vorgelesen werden, das Element nach Möglichkeit mit der Tastatur fokussieren und erneut vorlesen lassen.

Bei fortgeschrittener Abarbeitung des Szenarios wiederholen sich Bildschirmbereiche wie etwa das Hauptmenü der Anwendung. In diesem Fall den Tastaturfokus auf den Anfang des neu angezeigten Bildschirmbereichs setzen und ab hier lesen.

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Mängel werden nach der Bedeutung des fehlenden Teils für die Arbeitsaufgabe bewertet.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfschritt geht es um die Wiedergabe sichtbarer Texte. Keine Rolle spielen weitere ggf. vom Screenreader ausgegebene Informationen wie die Namen grafischer Bedienelemente, Erläuterungen zu Bedienelementen etc.

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

 

Referenzen

EN301549

11. 2.1.14 Images of text

11. 2.1.38 Name, role, value

11. 3.3.2.7 Values

11. 3.3.2.10 Text

 

WCAG

1.4.5 Bilder eines Textes

4.1.2 Name, Rolle, Wert

WCAG-Techniques

ISO9241-171

 

Zuletzt bearbeitet

29.08.2016

 

Prüfschritt 4.02.0 - Name für grafische Bedienelemente und Anzeigen

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Grafische Bedienelemente und Anzeigen ohne sichtbare Beschriftung haben einen programmatisch erkennbaren Namen, der den Zweck des  Elements  in natürlicher Sprache zutreffend beschreibt. Der Name soll möglichst kurz und prägnant sein.

Soweit Text abgebildet ist, gibt der Name den Inhalt des Textes wieder.

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Nicht sinnvolle Namen sind deskriptive Beschreibungen der Grafik wie z.B. „grüner Haken“ für einen OK-Button oder „Briefumschlag“ für den Aufruf eines Kontaktformulars.

Nicht sinnvoll sind z.B. Bezeichnungen aus der Programmierung wie „element5“ oder „xyz.png“.

Ein OK-Button hat den grafischen Schriftzug „OK“. Der Button hat einen programmatisch erkennbaren Namen „OK“.

Bei Statusanzeigen sind sowohl der Name als auch der angezeigte Wert erkennbar. Beispiel: Ein Icon für den Internetzugriff hat verschiedene Darstellungen je nach dem Status der Verbindung. Name ist „Internet“, Werte sind „verbunden“ und „nicht verbunden“.

Im übrigen gelten die im Prüfschritt 1.05.1 „Prägnante Beschriftungen“ ausgeführten Gestaltungsregeln.

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, wenn grafische Bedienelemente und Anzeigen vorhanden sind.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Rein grafische Elemente sind für blinde Benutzer nicht zugänglich. Der programmatisch erkennbare Name dient dazu, dem Benutzer die Identität des Elements über den Screenreader mitzuteilen. Dasselbe gilt für Benutzer von Spracheingaben, die das Element über den Namen auswählen können.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests}

Alle grafischen Elemente der Anwendung mit Tastatur oder Screenreader fokussieren und feststellen, ob ein zutreffender Name gesprochen wird, der den unter Beispiele genannten Gestaltungsregeln entspricht.

Eine doppelte Ausgabe des Namens für ein Element bzw. zwei verschiedene Namen sollen nicht vorkommen.

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Mängel werden nach der Bedeutung des Elements für den geprüften Arbeitsschritt bewertet.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Folgende Bedienelemente werden bereits in anderen Zusammenhängen geprüft und sollen in diesem Prüfpunkt ausgenommen werden, um eine doppelte Bewertung zu vermeiden:

  • Bedienelemente zur Steuerung des Tons
  • Bedienelemente zum Öffnen der Dokumentation oder Online-Hilfe

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

 

Referenzen

EN301549

11. 2.1.1 Non-text content (screen reading supported)

11. 2.1.38 Name, role, value

11. 3.3.2.5 Object information

WCAG

1.1.1 Nicht-Text-Inhalt

4.1.2 Name, Rolle, Wert

WCAG-Techniques

ISO9241-171

8.1.1 Für jedes Benutzungsschnittstellen-Element einen Namen vorsehen

8.1.4 Namen für unterstützende Technik verfügbar machen

8.5.4 Informationen zu Benutzungsschnittstellen-Elementen für unterstützende Technik verfügbar machen 

 

Zuletzt bearbeitet

29.08.2016

 

 

Prüfschritt 4.04.0 - Name für Gruppen von Elementen

Gewichtung:
1
Anwendung:
Anwendung auf Seite/Szenario
Beschreibung:

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Gruppen von Bedienelementen und Anzeigen, Funktionsbereiche der Anwendung, Dialogboxen etc. haben einen programmatisch erkennbaren Namen, der den Inhalt in natürlicher Sprache zutreffend beschreibt. Es gelten die im Prüfschritt 1.05.1 „Prägnante Beschriftungen“ ausgeführten Gestaltungsregeln.

Falls sichtbare Überschriften oder Titel vorhanden sind, ist der Name damit identisch.

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Die Funktionsbereiche von Word heißen „Menüband“, „Dokument“ und „Statuszeile“. Der Name wird beim Fokussieren der Gruppe mit F6 vom Screenreader angesagt.

Der Druckdialog hat den sichtbaren Titel „Drucken“. Der Titel wird beim Öffnen des Dialogs vom Screenreader angesagt.

Eine Gruppe von Auswahlschaltern (Radiobuttons) hat die Überschrift  “Bonität geprüft“, die Optionen haben die  Beschriftungen „ja“, „nein“, „in Arbeit“. Die Überschrift wird bei der Aktivierung der Optionen vom Screenreader mit vorgelesen.

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, wenn die Anwendung optisch unterscheidbare Funktionsbereiche und Gruppierungen hat  oder Dialogfenster öffnet.

 

Begründung

[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]

Anwendungsprogramme bieten sehenden Benutzern eine visuelle Ordnung, mit deren Hilfe sie sich orientieren können. Diejenigen, die diese Ordnung nicht nutzen können – zum Beispiel, weil sie blind sind oder nur einen kleinen Ausschnitt sehen können – sind darauf angewiesen, dass die Struktur unabhängig von der Darstellung auf dem Bildschirm zugänglich und nutzbar ist. Die Benennung von Gruppen, Funktionsbereichen und Dialogfenstern erlaubt es Nutzern assistiver Technologien, sich ein mentales Modell vom Aufbau der Anwendung zu machen. Programmatisch erkennbare Namen treten dort ein, wo sichtbare Überschriften und Titel fehlen, da sie für den sehenden Nutzer nicht erforderlich sind.

Benutzer von Spracheingaben können Funktionsbereiche über ihren Namen direkt anspringen.

 

Prüfanleitung

[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests}

Funktionsbereiche der Anwendung, Gruppen von Elementen und Dialogfenster durch die entsprechenden Tastaturkommandos fokussieren. Sagt der Screenreader einen Namen bzw. eine vorhandene sichtbare Überschrift an?

Falls ein Tastaturkommando nicht verfügbar ist, den Bereich mit Screenreader-Funktionen fokussieren.

 

Bewertungsalternativen

[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]

Mängel werden nach ihrer Bedeutung für die Ausführung der Arbeitsaufgabe bewertet.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

 

Offene Fragen

[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]

 

Referenzen

EN301549

11. 2.1.7 Info and relationships

11. 2.1.34 Labels or instructions

11. 2.1.38 Name, role, value

11. 3.3.2.5 Object information

3.2.9 Parent-child relationships

WCAG

1.3.1 Info und Beziehungen

3.3.2 Beschriftungen oder Anweisungen

4.1.2 Name, Rolle, Wert

WCAG-Techniques

H71: Providing a description for groups of form controls using fieldset and legend elements

ISO9241-171

8.1.1 Für jedes Benutzungsschnittstellen-Element einen Namen vorsehen

9.3.17 Die Navigation von Steuerungselementen durch Gruppierung erleichtern

10.5.1 Eindeutige und verständliche Fenstertitel vorsehen

 

Zuletzt bearbeitet

29.09.2016

 

 


Schließen