Anwendungssoftware, Stufe II

Beschreibung

Version vom 24.07.2018. Zur alten Version.

[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 4,5:1 bzw. 3: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 66,6% der Anforderung (3:1 bzw. 2: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

24.07.2018 von Detlef Girke

Beschreibung

Aktuelle Version (16.05.2020) - zur früheren Version

[Technikneutrale Beschreibung des Erfolgskriteriums]

Die Anwendung verwendet gut lesbare Schriften. Die auf dem Bildschirm dargestellten Zeichen müssen scharf, deutlich und ausreichend groß sein sowie einen angemessenen Zeichen- und Zeilenabstand haben. Es gelten die folgenden Spezifikationen:

• Die Anwendung wird auf dem ausgewählten Bildschirm (siehe Testsystem) mit scharfen Zeichen dargestellt.
• Lateinische Schriftzeichen erscheinen in einem Sehwinkel von mindestens 16 Bogenminuten, dies entspricht einer Versalhöhe von 2,9 mm bei einem Leseabstand von 50 cm (= Standard-Bildschirm des Testsystems).
• Der Zeichensatz hat eine Zeichenbreite der Großbuchstaben (ausgenommen Buchstabe „I“) von 70 Prozent bis 100 Prozent der Versalhöhe, sowie eine Mittelhöhe der Kleinbuchstaben von etwa 70 Prozent der Versalhöhe.
• Sehr feine Schriften werden vermieden.
• Großschreibung sowie die Textattribute fett, kursiv und unterstrichen werden nur in geringem Umfang zur Hervorhebung weniger Worte verwendet.
• Der horizontale Zeichenabstand beträgt mindestens ein Bildelement (Pixel).
• Bei Beschriftungen beträgt der vertikale Zeichenabstand (Zeilenabstand) mindestens ein Bildelement (Pixel).
• Bei Fließtext beträgt der vertikale Zeichenabstand (Zeilenabstand) mindestens 25 Prozent der Versalhöhe.
• Fließtext kann auf 80 Zeichen pro Zeile angepasst werden (z.B. durch Verringern der Fensterbreite).

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]

Die Anwendung soll mindestens die Anforderungen der Bildschirmarbeitsverordnung für gut lesbare Schriften einhalten, die auf normalsichtige Benutzer ausgerichtet sind. Gut lesbare Schriften sind für alle Benutzer wichtig, um eine Anwendung effizient zu nutzen, insbesondere aber für Menschen mit einer leichten Beeinträchtigung des Sehens aufgrund normaler Alterung.

Als Mindest-Sehwinkel wird der in ISO 9241-303 für lateinische Schriftzeichen gesetzte Wert von 16 Bogenminuten angenommen. Die meisten Arbeitsaufgaben erfordern einen Sehwinkel von 20-22 Bogenminuten, bis hin zu 31 Bogenminuten. Die für den Standard-Bildschirm berechnete Schriftgröße von 2,9 mm Versalhöhe gilt somit als Mindestgröße für alle Schriften.

Die Möglichkeit einer vergrößerten Darstellung kann nur dann gegen die Anforderung einer ausreichenden Schriftgröße aufgerechnet werden, wenn die Vergrößerung mängelfrei funktioniert. Grundsätzlich aber darf die Möglichkeit einer Individualisierung 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.

Prüfanleitung

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

Die Anwendung auf dem Standard-Bildschirm oder auf einem Bildschirm nach Herstellerempfehlung (siehe Testsystem) darstellen.

Sichtprüfung: Werden die Spezifikationen der Anforderung eingehalten? Im Zweifelsfall Zeichengrößen und Abstände nachmessen mit dem Keseling Bildschirmlineal (siehe Werkzeugliste).

Die Versalhöhe entspricht der Höhe der Großbuchstaben E oder Z. Die Breite der Großbuchstaben ist zu messen an den Buchstaben H und M. Die Mittelhöhe der Kleinbuchstaben entspricht der Höhe der Buchstaben z oder x. Es gelten jeweils die Außenmaße. Der vertikale Zeichenabstand (Zeilenabstand) ist zu messen zwischen Kleinbuchstaben mit Unterlänge und Großbuchstaben mit Oberlänge – zum Beispiel erste Zeile der Kleinbuchstabe q, zweite Zeile der Großbuchstabe Ü. Pixel sind zu erkennen in der Lupe des Bildschirmlineals.

Sehr feine Schriften sind in der Lupe des Bildschirmlineals daran zu erkennen, dass sie keine durchgehenden Linien in der Schriftfarbe bilden. Diese Schriften sollten bereits im Prüfschritt 1.01.0 „Ausreichender Kontrast“ aufgefallen sein.

Bei Mängeln im Anschluss die Prüfschritte 5.01.1 „Schriftvergrößerung auf 200%“ und 5.02.2 „Bei vergrößerter Darstellung Layout anpassen“ durchführen.

Bewertungsalternativen

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

Mängel sind eine Einschränkung.

Schriftgrößen von weniger als 2,9 mm sind eine Einschränkung.

Sofern zugleich Mängel bei der Vergrößerung vorliegen, siehe Prüfschritte 5.01.1 „Schriftvergrößerung auf 200%“ und 5.02.2 „Bei vergrößerter Darstellung Layout anpassen“, gilt das Folgende:  
Schriftgrößen von weniger als 80% der Anforderung (2,3 mm) sind eine Barriere.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Referenzen

EN301549

-

WCAG

1.4.8 Visuelle Präsentation

WCAG-Techniques

ISO9241-171

-

Sonstige

ISO 9241-303 Anforderungen an elektronische optische Anzeigen

DGUV-Richtlinie 215-410 Bildschirm- und Büroarbeitsplätze

Zuletzt bearbeitet

16.05.2020

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

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Beschriftungen von Elementen und Überschriften von Elementgruppen beschreiben knapp die Funktion der zugeordneten Elemente.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Beschriftungen von Bedienelementen benennen die damit ausgelöste Funktion, z.B. "Drucken".

Beschriftungen von Eingabefeldern benennen den erwarteten Inhalt, z.B. "Vorname" und "Nachname". 

Überschriften von Elementgruppen geben einen übergeordneten Begriff, z.B. "Anschrift", oder fassen den Inhalt zusammen, z.B. "Persönliche Daten".

Beschriftungen sind möglichst kurz, z.B. anstelle von „Drucken-Schaltfläche“ oder „Diese Schaltfläche druckt das aktuelle Dokument aus“ wird „Drucken“ verwendet. Ausnahme: Elemente, die ein reales Objekt oder Subjekt (wie z. B. ein Dokument, eine Örtlichkeit oder Personen) repräsentieren, dürfen mit dem Namen dieses Objektes bzw. Subjektes versehen werden, selbst wenn dieser Name zu lang oder zu kryptisch ist, um ihn leicht lesen zu können.

Die besonders markanten Teile der Beschriftung stehen am Anfang, so dass Benutzer nicht alles lesen müssen, um das Element identifizieren zu können. Beispiel: die Überschriften im Einstellungen-Dialog heißen „Benutzerinformationen“ und „Produktinformationen“, nicht „Informationen über den Benutzer“ und „Informationen zum Produkt“.

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]

In diesem Abschnitt geht es um sichtbare Beschriftungen, die, anders als programmatisch erkennbaren Namen von Elementen und Gruppen, nicht immer erforderlich sind. Denn es gibt auch andere visuelle Gestaltungsmittel, um den Sinn eines Buttons oder den Umfang einer Gruppe darzustellen.

Wenn vorhanden, sollen sichtbare Beschriftungen und Überschriften die Funktion der betreffenden Elemente knapp und sachlich zutreffend beschreiben. Diese Anforderung kann banal erscheinen, denn jede sorgfältig gestaltete Anwendung sollte sich um prägnante Beschriftungen bemühen. Knappe und zutreffende Benennungen und Zusammenfassungen helfen jedem Anwender, den Sinn eines Elements oder einer Gruppe von Elementen schnell zu erfassen. Besonders aber helfen sie Nutzern von Sprachausgaben, die die visuelle Gestaltung nicht sehen können und somit keine kontextuellen Hinweise zum Sinn der Elemente haben.

Prüfanleitung

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

Sichtprüfung: sind die in den Beispielen ausgeführten Anforderungen erfüllt?

Bei stark fachlich geprägten Anwendungen wird der Prüfer vorab eine Einweisung in Anspruch nehmen, um die in den Beschriftungen verwendeten Fachbegriffe zu klären.   

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]

Sichtbare Beschriftungen sind nur bei Formulareingaben erforderlich, dies wird im Prüfschritt 2.06.1 Ausreichende Anweisungen für Benutzereingaben geprüft.

In diesem Prüfschritt wird nicht verlangt, dass Beschriftungen leicht verständlich sind. Einfache Sprache wird im Prüfschritt 1.06.2 Verständliche Anweisungen und Meldungen geprüft.

Offene Fragen

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

Gesucht werden fachlich neutrale Beispiele für Mängel in Bezug auf dieses Erfolgskriterium.

Referenzen

EN301549

11.2.1.25 Headings and labels

WCAG

2.4.6 Überschriften und Beschriftungen (Labels)

WCAG-Techniques

ISO9241-171

8.1.2 Verständliche Namen vorsehen

8.1.6 Kurze Namen und Beschriftungen verwenden

Zuletzt bearbeitet

29.08.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Anweisungen und Meldungen sind kurz, einfach und für den Benutzer verständlich.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Benachrichtigungen werden in der Sprache des Benutzers angezeigt, Terminologie aus der Programmierung wird vermieden.

Jedes in Anweisungen und Meldungen vorkommende Wort ist im Duden oder in einem für die Anwendung gebräuchlichen Fachwörterbuch zu finden oder wird in einem mit der Software mitgelieferten Glossar erläutert.

Erforderliche Systemcodes werden unmittelbar erläutert.

Anweisungen und Meldungen sind in einfachen Sätzen verfasst, jeder Satz stellt nur einen Gedanken dar.

Kurze Meldungen schließen die Angabe von zusätzlichen Informationen auf Anforderung nicht aus. Beispiel: Es erscheint ein Dialogfeld mit der Meldung „Die Netzwerkverbindung wurde getrennt“. Der Benutzer kann die OK-Schaltfläche betätigen, um diese Meldung zu quittieren und auszublenden, oder er kann die „Details“-Schaltfläche wählen, um Systeminformationen wie z.B. „Fehler #527: Der Thread 0xA725 hat innerhalb des vorgegebenen Zeitlimits kein Mutex ergeben“ zu sehen, die er an den technischen Service weitergibt.

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]

Einfache Sprache ist hilfreich für Menschen mit kognitiven Einschränkungen (Lese-Rechtschreibschwäche, Aufmerksamkeitsstörungen etc.) oder in angespannter Situation (Eile, Ablenkung), sie erleichtert das Erlernen der Software.

Prüfanleitung

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

Sichtprüfung.

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 formale Aspekte der Verständlichkeit im Sinne der „einfachen Sprache“. Die Verständlichkeit der Inhalte im Sinne der Arbeitsaufgabe wird in diesem Prüfschritt nicht geprüft. Inhaltlich zutreffende Bezeichnungen werden im Prüfschritt 1.05.1 Prägnante Beschriftungen geprüft.

Offene Fragen

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

Referenzen

EN301549

-

WCAG

3.1.3 Ungewöhnliche Wörter

3.1.4 Abkürzungen

3.1.5 Leseniveau

WCAG-Techniques

ISO9241-171

8.4.11 Verständliche Benutzerbenachrichtigungen ausgeben

Zuletzt bearbeitet

29.08.2016

Beschreibung

Aktuelle Version (16.05.2020) - zur vorherigen Version

[Technikneutrale Beschreibung des Erfolgskriteriums]

Farbe wird nicht als einziges visuelles Mittel benutzt, um Informationen zu vermitteln, eine Handlung zu kennzeichnen, eine Reaktion zu veranlassen oder ein Element zu unterscheiden. Informationen sollen zusätzlich durch Text oder durch andere visuelle Mittel wie Symbole, Fettung, Unterstreichung, Kontrast, Einrückung etc. vermittelt werden.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Der aktive Menüpunkt in einem Anwendungsprogramm erhält als Abgrenzung zu den übrigen Menüpunkten eine grafische Markierung, etwa einen Rahmen oder einen Punkt.

Als Markierung wird eine Invertierung von Vorder- und Hintergrundfarbe verwendet.

Als Markierung wird eine Textfarbe verwendet, deren Helligkeitskontrast im Verhältnis 3:1 von der Textfarbe der umgebenden Elemente abweicht. Zusätzlich erscheint bei hover, active und focus ein Unterscheidungsmerkmal wie z.B ein Haken, Rahmen, eine Unterstreichung etc.

Rot wird verwendet, um einen Benutzer zu warnen, dass eine Anwendung nicht betriebsbereit ist, oder um eine Notsituation anzuzeigen. Die Farbe wird durch Text ergänzt, der „Warnung“ oder „Notfall“ anzeigt.

Grün wird verwendet, um eine erfolgreiche Aktion zu bestätigen. Die Farbe wird durch ein grafisches Symbol (OK-Haken) ergänzt.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist anwendbar, wenn die Anwendung nicht monochrom gestaltet ist, sondern mehr als eine Farbe für Vordergrund und Hintergrund verwendet.

Begründung

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

Bei diesem Prüfpunkt geht es um die visuelle Gestaltung einer Anwendung. Benutzer mit einer Sehbehinderung erkennen Farben oftmals nicht ausreichend, um Farbunterschiede sicher wahrzunehmen. Daher sind ausschließlich über Farben vermittelte Informationen für sehbehinderte Benutzer nicht uneingeschränkt nutzbar.

Farbunterschiede dürfen nur dann ohne ein zusätzliches grafisches Merkmal zur Übermittlung von Bedeutungsunterschieden verwendet werden, wenn der Helligkeitskontrast ausreicht. Textfarben müssen mindestens im Verhältnis 3:1 gegen die Textfarbe der umgebenden Elemente kontrastieren. Farbflächen müssen ebenfalls mindestens im Verhältnis 3:1 gegen die Umgebungsfarbe kontrastieren.

Prüfanleitung

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

Sichtprüfung: Haben farblich gekennzeichnete Elemente zusätzliche Kennzeichnungen wie sichtbare Beschriftungen/Beschreibungen, Symbole, Einrückungen, Fettungen?

Falls nein, haben sie einen ausreichenden Kontrast zu den Elementen bzw. zum Hintergrund der Umgebung? Textfarben müssen mindestens im Verhältnis 3:1 gegen die Textfarbe der umgebenden Elemente kontrastieren. Farbflächen müssen ebenfalls mindestens im Verhältnis 3:1 gegen die Umgebungsfarbe kontrastieren. Das Messen eines Kontrastunterschieds wird im Prüfschritt 1.01.0 „Ausreichender Kontrast“ behandelt. Der Kontrast der markierten Texte in sich (Textfarbe gegen Hintergrundfarbe) muss ebenfalls ausreichend sein.

Falls Farbflächen zur Kennzeichnung verwendet werden, sind die Flächen groß genug? Die Mindestgröße eines Bedienelements wird im Prüfschritt 2.01.2 „Ausreichende Größe von Schaltflächen“ definiert.

Bewertungsalternativen

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

Mängel sind eine Einschränkung oder eine Barriere, je nach der Bedeutung des Elements für den geprüften Arbeitsschritt.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfpunkt geht es um die Normalansicht einer Anwendung. Weitergehende Anforderungen an die Gestaltung bestehen für die Darstellung im Kontrastmodus, siehe Prüfschritt 5.03.1 "Kontrastmodus ist nutzbar".

Offene Fragen

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

Referenzen

EN301549

11.1.4.1 Use of colour

WCAG

1.4.1 Use of Color

WCAG-Techniques

G183: Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues on focus for links or controls where color alone is used to identify them

ISO 9241-171

10.4.1 Informationen nicht allein durch Farbe übermitteln

BITV-Test

1.4.1a Ohne Farben nutzbar

Sonstige

ISO 9241-303 Anforderungen an elektronische optische Anzeigen

DIN 32975 Gestaltung visueller Informationen im öffentlichen Raum zur barrierefreien Nutzung 

Zuletzt  bearbeitet

16.05.2020

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Anweisungen, die für das Verständnis und die Bedienung einer Software bereitgestellt werden, stützen sich nicht nur auf sensorische Merkmale von Komponenten wie Form, Größe, visuelle Position, Ausrichtung oder Ton. Anweisungen nennen auch textuelle Bestandteile der Bedienelemente, auf die sie sich beziehen.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Ein Button ist grün und hat die Aufschrift „Weiter“. Wenn in einer Anleitung auf den Button verwiesen wird, so wird er nicht als „der grüne Button“ bezeichnet, sondern als „der grüne Weiter-Button“.

Ein Button zum Absenden eines Formulars ist rund, hat ein grafisches Pfeil-Symbol und einen unsichtbar hinterlegten Namen „Senden“. Wenn in einer Anleitung auf den Button verwiesen wird, so wird er nicht als „der runde Button“ oder als „der Pfeil“ bezeichnet, sondern z.B. als „der runde Senden-Button“.

Eine Liste mit Berufsbezeichnungen steht in der linken Spalte und hat die Überschrift „Berufe“. Die Anleitung lautet „Markieren Sie in der linken Spalte den Beruf“.

Bei der Meldung eines Mail-Eingangs ertönt ein Signalton, die Anleitung lautet: „Der Beep macht aufmerksam auf die Anzeige „Neue Mail“ in der unteren rechten Ecke des Bildschirms“

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, wenn in einer Programmsituation Anleitungen zur Bedienung gegeben werden. Er bezieht sich ebenso auf Hilfetexte, die im Kontext abgerufen werden können.

Begründung

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

Benutzer sollen Anweisungen zur Bedienung einer Software auch dann verstehen können, wenn sie Form, Farbe, Position oder Ausrichtung von bestimmten Bedienelementen sowie Signaltöne nicht wahrnehmen können. Beim Einsatz von Hilfstechniken gehen sensorische Merkmale von Bedienelementen oftmals verloren. Bei veränderter Bildschirmauflösung kann sich das Layout der Anwendung verändern, etwa von mehrspaltiger auf einspaltige Darstellung wechseln. Deswegen müssen Bedienelemente in Anweisungen oder Hilfetexten mit ihrem Namen bezeichnet werden. Ebenso benötigen gehörlose Nutzer, die Signaltöne nicht wahrnehmen können, eine visuelle oder textuelle Beschreibung des Bedienelements bzw. der Programmsituation.

Die Anforderung verlangt nicht, auf die Beschreibung sensorischer Merkmale zu verzichten, denn diese sind wichtig u.a. für Menschen mit kognitiven Einschränkungen.

Prüfanleitung

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

Sichtprüfung: Den Inhalt von Anweisungen und Hilfetexten darauf überprüfen, ob sie ein Element durch Angabe des Namens, einer Überschrift oder anderer textlicher Bezüge ausreichend beschreiben und nicht nur sensorische Merkmale wie Farbe etc. angeben.

Beispiele für Bezugnahmen, die nur sensorische Merkmale nennen:

• Klicken Sie auf den grünen Knopf, um ...
• Über die runde Taste können Sie...
• Der rot eingerahmte Kasten enthält Infos zu ...
• Klicken Sie im Menü rechts...
• In der breiten Spalte steht...
• Wenn der Beep ertönt, gehen Sie bitte …

Solche Bezugnahmen sind ohne die Nennung textueller Bezüge nicht nachzuvollziehen.

Ausnahme: Die Angaben „oben“ oder „unten“ können ausreichend sein, wenn sie einer Position entsprechen, die im Quellcode bzw. in einer linearisierten Darstellung vor oder nach der aktuellen Position erscheint.

Bewertungsalternativen

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

Mängel sind eine Einschränkung.

Ein Mangel kann als Barriere eingestuft werden, wenn der Nutzer keine andere Möglichkeit hat, das beschriebene Element zu finden.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfschritt geht es um die Gestaltung von Anweisungen und Hilfetexten. Erfolgskriterien für die Gestaltung von Bedienelementen werden in anderen Prüfschritten behandelt, u.a.   1.07.1 „Information nicht allein durch Farbe übermitteln“, 1.09.2 „Warnmeldungen sowohl optisch als auch akustisch anzeigen“, 4.02.0 „Name für grafische Bedienelemente und Anzeigen“.

Die Anforderung gilt auch für separat mit der Software ausgelieferte Dokumentationen, diese werden im Prüfplan „Dokumentenprüfung“ geprüft.

Offene Fragen

-

Referenzen

EN301549

11. 2.1.9 Sensory characteristics

WCAG

1.3.3 Sensorische Merkmale

WCAG-Techniques

G96: Providing textual identification of items that otherwise rely only on sensory information to be understood

ISO9241-171

Zuletzt bearbeitet

29.08.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Signale, die den Benutzer auf Ereignisse außerhalb seines aktuellen Arbeitsschritts aufmerksam machen, werden sowohl optisch als auch akustisch dargestellt oder sind einstellbar.

Ein Signal im Sinne dieses Prüfschritts ist eine auffällige, kurze Nachricht an den Benutzer. Signale sollen bemerkt werden, aber nicht den aktuellen Arbeitsschritt des Benutzers unterbrechen.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Ein E-Mail-Programm sendet eine Nachricht an die Windows Taskleiste, wenn eine neue Mail eintrifft. Die Nachricht besteht aus einem Icon mit dem Tooltipp „neue Mail“ und zusätzlich einem Signal, das einstellbar ist. Der Benutzer kann entweder einen Signalton oder ein kurzes Blinken wählen, oder das Signal ganz abschalten.

Eine Datenbankrecherche sendet eine Nachricht, dass die gebuchte Nutzungsdauer in Kürze abläuft. Die Nachricht erscheint in der oberen rechten Ecke des Bildschirms, zu Beginn ertönt ein Signalton, dann blinkt die Nachricht kurze Zeit.

Fehler: Eine Nachricht erscheint kurzfristig am Rande des  Bildschirms ohne einen begleitenden Signalton.

Fehler: Ein Warnton macht auf das baldige Ende der Akkuladung aufmerksam. Es gibt keine Möglichkeit, eine visuelle Warnung (Lichtsignal, Bildschirmmeldung) einzustellen.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist anwendbar, wenn die Software Signale verwendet.

Begründung

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

Software muss eine Bandbreite menschlicher Fähigkeiten unterstützen, um für alle Benutzer zugänglich zu sein. Eine Nachricht, die die Aufmerksamkeit des Benutzers auf sich ziehen will, muss sowohl optisch als auch akustisch wahrnehmbar sein. Blinde und Sehbehinderte sehen nur einen kleinen Ausschnitt des Bildschirms und benötigen akustische Unterstützung, um eine Nachricht am Rande des Bildschirms zu bemerken. Hörbehinderte Menschen benötigen ein visuelles Signal, um eine Situation zu bemerken, auf die mit einem Warnton aufmerksam gemacht wird.

Prüfanleitung

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

Sichtprüfung, Erprobung der Einstellmöglichkeiten.

Bewertungsalternativen

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

Mängel werden nach der Bedeutung der ausfallenden Information für die Arbeitsaufgabe bewertet.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Referenzen

EN301549

WCAG

WCAG-Techniques

ISO9241-171

10.6.7 Benutzern die Auswahl einer visuellen Alternative zur Audioausgabe ermöglichen

Sonstige

ISO 9241-20 Leitlinien für die Zugänglichkeit der Geräte und Dienste in der Informations- und Kommunikationstechnologie (IKT)

Zuletzt bearbeitet

29.09.2016

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Der Benutzer kann Größe und Position von Anwendungsfenstern einstellen. Er kann festlegen, dass ein Anwendungsfenster immer im Vordergrund ist.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Ein sehbehinderter Benutzer verwendet einen größeren Schriftgrad, was dazu führt, dass Text über den unteren Rand einer Dialogbox hinaus verläuft. Daraufhin vergrößert er die Dialogbox, um den gesamten Text sehen zu können.

Ein Dialogfenster öffnet sich an einer ungünstigen Position auf dem Bildschirm, wo es Daten überlagert, die der Benutzer zur Beantwortung des Dialogs einsehen möchte. Der Benutzer kann das Dialogfenster verschieben und damit das Problem lösen.

Fehler: Ein Dialogfenster lässt sich nicht verschieben oder in der Größe ändern.

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]

Menschen mit Sehbehinderungen nutzen die Vergrößerungsoptionen des Betriebssystems oder ein externes Großbildsystem. Hierbei wird entweder das Layout der Anwendung verändert, oder es kann nur ein Ausschnitt der Bedienoberfläche auf dem Bildschirm angezeigt werden. Fenster und Dialogboxen der Anwendung sollten flexibel auf die Vergrößerung reagieren, oder sie sollten vom Benutzer einstellbar sein.

Das Betriebssystem erlaubt es in der Regel, die Größe und die Position von Fenstern auf dem Bildschirm einzustellen. Anwendungssoftware soll diese Funktionalitäten nicht stören bzw. deaktivieren.

Bei der Nutzung von Vergrößerungs-Software ist es üblich, dass Nutzer zur leichteren Auffindbarkeit Fenster an bestimmen Stellen des Bildschirms platzieren. Wenn das nicht möglich ist, kann es Probleme mit der Orientierung geben.

Starre Fenster können zum Beispiel bewirken, dass das im Vordergrund befindliche Fenster durch das dahinter liegende überblendet wird oder unübersichtlich erscheint. Das Fenster im Hintergrund muss für die Arbeit aber verfügbar sein und  darf nicht geschlossen werden. Eine Größenänderung des Fensters könnte das Problem beheben, doch ist dies nicht möglich, weil die Anwendungssoftware es verhindert.

Prüfanleitung

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

Um die Größe des Fensters zu ändern, öffnen Sie das Systemmenü im Fenstertitel (Tastenkombination ALT +  Leertaste). Der Dialog öffnet sich oben links. Wählen sie mit den Pfeiltasten "Größe ändern" aus und betätigen mit der Enter-Taste. Alternativ können Sie auch ALT + G drücken. Danach sollten Sie mit den Pfeiltasten die Größe des Fensters einstellen können. Ein erneutes Betätigen der Enter-Taste bestätigt die ausgewählte Größe.

Verfahren Sie auf die gleiche Art zum Verschieben des Fensters. Diese Funktion können Sie nach Betätigen von ALT + Leertaste mit ALT + v aufrufen.

Bewertungsalternativen

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

Mängel sind eine Barriere oder eine Einschränkung, je nachdem in welchem Maße der Arbeitsablauf behindert wird.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfschritt geht es um die Einstellbarkeit von Anwendungsfernstern. Weitere Darstellungsprobleme, die mit Vergrößerung einhergehen können, sind in den Prüfschritten 5.01.1 „Schriftvergrößerung auf 200%:“ und 5.02.2 „Bei vergrößerter Darstellung Layout anpassen“ behandelt.

Offene Fragen

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

Die Fenster-Einstellung „Immer im Vordergrund“, die sehbehinderte Benutzer benötigen und die daher in der Beschreibung der Anforderung steht, wird in der weiteren Ausführung des Prüfschritts nicht mehr erwähnt. Denn in Windows wird leider diese Einstellung nicht direkt dem Benutzer zur Verfügung gestellt. Daher kann in diesem Prüfschritt nicht geprüft werden, ob eine Anwendung die Betriebssystem-Einstellung "immer im Vordergrund" übernimmt oder deaktiviert.

Referenzen

EN301549

-

WCAG

-

WCAG-Techniques

ISO9241-171

10.5.4 Alles überlagernde Anzeige von Fenstern ermöglichen ("immer im Vordergrund")

10.5.7 Positionierung der Fenster ermöglichen

10.5.8 Erneute Einstellung der Fenstergröße ermöglichen

Zuletzt bearbeitet

10.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Die Gestaltung der Anwendung einschließlich der Bezeichnung von Inhalten und Funktionen, der verwendeten Symbole, der Bedienwege und der von der Software ausgegebenen Meldungen orientiert sich an Konventionen und ist innerhalb der Anwendung einheitlich.

Gleiche Funktionen sind gleich gestaltet, verschiedene Funktionen sind unterschiedlich gestaltet.

Der Status der Anwendung ist jederzeit klar.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Menüs sind in den verschiedenen Bereichen der Anwendung gleich angeordnet.

Der Link auf die Hilfe-Seite heißt „Hilfe“. Die Seite, auf die der Link „Hilfe“ führt, hat den Titel „Hilfe“ und nicht „zusätzliche Informationen“.

Beschriftungen von grafischen Elementen sind immer auf dieselbe Weise angeordnet, so dass klar ist, zu welchem Icon eine Beschriftung gehört.

Grafische Symbole und ihre Beschriftungen werden konsistent verwendet.

Fehler: Die Suchfunktion wird mit einer Lupe dargestellt und hat ein Tooltipp „Suche“. Nur in einem Programmteil lautet das Tooltipp „finden“.

Fehler: Die Lupe ist in einem Programmteil das Symbol für die Suchfunktion, in einem anderen Programmteil der Aufruf der Detailansicht zum ausgewählten Element.

Fehler: In einem Set von Icons ist eines farblich anders gestaltet, man vermutet einen Statusunterschied. Es stammt aber nur aus einer älteren Serie und wurde vergessen auszutauschen.

Der Status eines Schalters ist jederzeit erkennbar sowie für alle vergleichbaren Schalter einheitlich gestaltet. Beispiel: Wenn keine Internetverbindung besteht, ist der Schalter „Internetverbindung“ mit einem roten Kreuz als gestört gekennzeichnet.

Editierbare und nicht editierbare Daten sind unterschiedlich gestaltet, so dass klar ist, welche Aktion hier möglich ist. Fehler: Die nicht editierbare Anzeige eines Datensatzes sieht genau so aus wie die Erfassungsmaske.

Fehlermeldungen und sonstige Benutzerbenachrichtigungen sind einheitlich gestaltet, damit der Benutzer sie einfach auffinden und die Kategorie der Information (Fehlermeldung, Mitteilung etc.) leicht unterscheiden kann. Beispiel: Fehlermeldungen werden grundsätzlich in einer Dialogbox ausgegeben, während sonstige Meldungen in einer fixierten Statuszeile am oberen Rand des Datenbereichs erscheinen.

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]

Die Orientierung an Konventionen und die einheitliche Gestaltung erleichtern das Verständnis und die Erlernbarkeit der Anwendung für alle Benutzer, insbesondere für Benutzer mit kognitiven Einschränkungen. Benutzer, die nur einen kleinen Ausschnitt des Bildschirms wahrnehmen, können sich leichter orientieren und die gesuchten Funktionen schneller finden.

Prüfanleitung

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

Sichtprüfung und praktische Erprobung: sind die genannten Gestaltungsregeln eingehalten?

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]

Windows-Konventionen für Tastaturbefehle werden im Prüfschritt 3.10.2 „Tastaturkonventionen der Plattform befolgen“ behandelt.

Die Beschriftung von Eingabefeldern wird im Prüfschritt 2.06.1 „Ausreichende Anweisungen für Benutzereingaben“ behandelt.

Offene Fragen

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

Referenzen

EN301549

-

WCAG

2.4.8 Position

3.2.3 Konsistente Navigation

3.2.4. Konsistente Erkennung

WCAG-Techniques

ISO9241-171

8.1.8 Beschriftungen von Benutzungsschnittstellen-Elementen auf dem Bildschirm angemessen anordnen

8.4.10 Benutzerbenachrichtigungen einheitlich ausgeben

BITV-Test

2.4.8a Position im Webauftritt klar.

3.2.3a Navigation einheitlich

Sonstige

ISO 9231-112 Grundsätze der Informationsgestaltung, Abschnitt 6.6 Konsistenz

ISO 9241-110 Grundsätze der Dialoggestaltung, Abschnitt 4.5 Erwartungskonformität

Zuletzt bearbeitet

31.10.2016

Beschreibung

Version vom 26.07.2018. Zur alten Version.

[Technikneutrale Beschreibung des Erfolgskriteriums]

Schaltflächen haben eine Kantenlänge von mindestens 33pt, um sicherzustellen, dass auch Menschen mit eingeschränkter Feinmotorik sie mit Hilfe einer Maus auswählen können.

Dies betrifft grafische Bedienelemente, aber auch Textlinks und Eingabefelder, deren sensible Fläche ausreichend groß sein muss. 

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]

Bedienelemente sollen nicht zu klein sein und nicht zu nah beieinander stehen. Dies erleichtert allen Mausbenutzern die Bedienung und ist besonders wichtig für Menschen mit eingeschränkter Feinmotorik der Hände und für Nutzer von alternativen Eingabegeräten wie Kopfmaus etc., damit sie Bedienelemente sicher auswählen können.

Prüfanleitung

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

Sichtprüfung: sind alle Schaltflächen ausreichend groß? Im Zweifel nachmessen mit dem Keseling Bildschirmlineal (siehe Werkzeugliste). Die Maßangabe 33pt bzw. 1,16cm bezieht sich auf den Standard-Bildschirm (siehe Testsystem). Zu messen ist die Kantenlänge der Schaltfläche bzw. des sensitiven Bereichs. Im Zweifel zunächst den Tastaturfokus auf ein Element setzen und die Kantenlänge des Fokusindikators messen.

Bewertungsalternativen

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

Kantenlängen von weniger als 98% der Anforderung (1,13cm) können bereits als Einschränkung bewertet werden. Dies liegt allerdings im Ermessen der Prüferin oder des Prüfers.

Kantenlängen von weniger als 50% der Anforderung (5,08 mm) sind eine Barriere.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Referenzen

EN301549

-

WCAG 2.1

Success Criterion 2.5.5 Target Size.

WCAG-Techniques

ISO 9241-171

9.4.3 Leicht auswählbare Ziele für Zeigegeräte zur Verfügung stellen

Zuletzt bearbeitet

29.09.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Bedienelemente unterscheiden sich von anderen Anzeigen, indem sie bei Berührung eine deutlich sichtbare Rückmeldung geben. Wenn der Mauszeiger auf ein Bedienelement zeigt, verändern der Mauszeiger und/oder das Bedienelement ihr Aussehen. Wenn ein Bedienelement ausgewählt wurde, ist der veränderte Status sichtbar.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Wenn der Mauszeiger auf ein Feld zeigt, in dem eine Texteingabe möglich ist (Formular, Textbearbeitungsprogramm), so wird er zum Caret.

Zeigt der Mauszeiger auf einen Link, so wird er zur zeigenden Hand.

Eine Schaltfläche, auf die der Mauszeiger zeigt, ändert ihr Aussehen (Farbe, Schrift, Umrandung o.ä.).

In einem E-Mail-Client wird das vom Mauszeiger berührte Element in der Liste der eingegangenen Mails durch einen andersfarbigen Hintergrund und eine Rahmenlinie am linken Rand angezeigt.

Ein aktivierter Menüpunkt oder Button ändert sein Aussehen, solange die Aktivierung andauert. 

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 sichtbare Rückmeldung ist wichtig, damit ein Benutzer erkennen kann, ob ein Bildschirmelement bedienbar ist, und ob er es mit dem Zeigegerät erfolgreich fokussiert hat. Die Rückmeldung gibt auch Information darüber, ob eine angewählte Funktion verfügbar ist oder vorübergehend nicht funktioniert, und ob eine beabsichtigte Aktivierung erfolgreich war.

Eine verlässliche Rückmeldung von Bedienelementen gibt Sicherheit in der Bedienung. Wichtig ist dies für jedermann vor allem bei selten genutzten Funktionen. Kognitiv beeinträchtige Benutzer sind auf die verlässliche Rückmeldung von Bedienelementen angewiesen.

Auch Menschen mit leichter Einschränkung des Sehens, die aus Farbfehlsichtigkeit oder aus normaler Alterung resultiert, sind Mausnutzer. Die Bedingungen für gute Sichtbarkeit von Hervorhebungen sind definiert in den Prüfschritten 1.01.0 „Ausreichender Kontrast“ und 1.07.1 „Informationen nicht allein durch Farbe übermitteln“.

Prüfanleitung

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

Erprobung: Bedienelemente mit der Maus berühren und aktivieren. Feststellen, ob eine sichtbare Rückmeldung erfolgt.

Weitere Prüfung der deutlichen Sichtbarkeit wie in den Prüfschritten 1.01.0 „Ausreichender Kontrast“ und 1.07.1 „Informationen nicht allein durch Farbe übermitteln“.

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 Rückmeldung bei Bedienung ist offenbar so selbstverständlich, dass sie in keiner der herangezogenen Richtlinien explizit formuliert wird. Daher wurde als Referenz die Anforderung an einen sichtbaren Tastaturfokus herangezogen und auf die Bedienung mit Zeigegeräten übertragen.

Referenzen

BITV-Test

2.4.7a Aktuelle Position des Fokus deutlich

EN301549

11. 2.1.26 Focus visible

WCAG

2.4.7 Fokus sichtbar (bezieht sich allerdings nur auf Tastatur)

WCAG-Techniques

ISO9241-171

Zuletzt bearbeitet

13.10.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Sich bewegende Elemente können unterbrochen und an derselben Stelle wieder aufgenommen werden, um dem Benutzer ausreichend Zeit zu geben, die Information wahrzunehmen. Bei regelmäßig aktualisierten Inhalten kann die Häufigkeit der Aktualisierung kontrolliert werden. Ausnahme: die Bewegung oder automatische Aktualisierung ist Teil einer Handlung, bei der sie unentbehrlich ist.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Ein Benutzer berührt rollenden Text mit der Maus, wodurch die Textbewegung angehalten wird, was ihm ermöglicht, den Text zu lesen, solange der Mauszeiger darauf steht. Zusätzlich sind Bedienelemente vorhanden, mit denen die Textbewegung angehalten und fortgesetzt werden kann.

Ein Börsenticker hat Bedienelemente, mit denen er angehalten und fortgesetzt werden kann. Bei Wiederaufnahme der Bewegung setzt er bei dem aktuellen Stand der Information wieder ein, denn er ist eine Real-Time-Anwendung. Zusätzlich schreibt er alle Informationen in ein Logbuch, in dem Benutzer ohne Verlust von Informationen in Ruhe lesen können.

Ein Verlaufsanzeiger besteht aus einer Statusleiste, in der die Ausführung zusammen mit einem Kobold angezeigt wird, der Kisten bewegt. Der Verlaufsanzeiger kann so konfiguriert werden, dass der Kobold nicht erscheint, aber die Statusleiste weiterhin den Status anzeigt. Der Fortschrittsbalken in einem Verlaufsanzeiger gilt als unentbehrlich.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

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

Begründung

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

Viele Benutzer haben Schwierigkeiten, blinkende oder sich bewegende Inhalte zu lesen. Personen mit eingeschränktem Sehvermögen oder Schwierigkeiten beim Lesen benötigen Zeit zur Verarbeitung der Informationen, um diese verstehen zu können.

Interaktive bewegte Inhalte können für Benutzer mit motorischen Einschränkungen problematisch sein.  

Prüfanleitung

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

Feststellen, ob sich bei dem animierten Inhalt eine Schaltfläche befindet, mit der man die Bewegung stoppen kann, eine gleichwertige nicht-animierte Version der Inhalte laden kann, oder ob es eine klare Anweisung gibt, wie die Bewegung mit der Tastatur angehalten werden kann.

Prüfen, ob die Bewegung tatsächlich anhält und auch nicht wieder automatisch beginnt.

Prüfen, ob bei erneuter Bedienung die Bewegung an derselben Stelle wieder aufgenommen wird, bzw. bei einem aktualisierten Stand, falls es ich um eine Real-Time-Anwendung handelt.

Bewertungsalternativen

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

Mängel werden nach der Bedeutung der ausgefallenen Information für die Arbeitsaufgabe bewertet.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Sich bewegende Elemente, die unaufgefordert automatisch ablaufen, werden im Prüfschritt 1.03.0 „Verzicht auf Bewegung, Blinken und Flackern“ behandelt.

Offene Fragen

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

Referenzen

EN301549

11. 2.1.18 Pause, stop, hide

WCAG

2.2.2 Pausieren, beenden, ausblenden

WCAG-Techniques

ISO9241-171

10.1.2 Steuerung zeitabhängiger Informationsdarstellung durch den Benutzer ermöglichen

Zuletzt bearbeitet

29.08.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Inhalte werden ohne Zeitbegrenzung angezeigt, die Zeitbegrenzung ist abschaltbar, oder sie kann verlängert werden.

Diese Anforderung gilt nicht für Fälle, in denen die zeitliche Begrenzung

• Bestandteil eines Echtzeit-Ereignisses (zum Beispiel einer Auktion) ist und es keine Alternative zur zeitlichen Begrenzung gibt,
• unentbehrlich  ist und eine Verlängerung der zeitlichen Begrenzung die Handlung ungültig machen würde,
• länger als 20 Stunden beträgt.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Bei einer Anmeldung wird der Benutzer aufgefordert, sein Kennwort innerhalb von 30 s einzugeben. Die verbleibende Zeit wird auf dem Bildschirm angezeigt, und es gibt ein Steuerungselement, mit dessen Hilfe der Countdown unterbrochen werden kann.

Der Benutzer darf die zeitliche Begrenzung anpassen, bevor er darauf trifft, und zwar so weitreichend, dass es sich um die mindestens zehnfache Zeit der Standardeinstellung handelt.

Der Benutzer wird gewarnt, bevor die Zeit abläuft, und bekommt mindestens 20 Sekunden Zeit, um die zeitliche Begrenzung mit einer einfachen Handlung auszuweiten (zum Beispiel: „Drücken Sie die Leertaste“) und der Benutzer darf die zeitliche Begrenzung mindestens 10 Mal ausweiten.

Fehler: Bei einer Online-Transaktion wird der Benutzer bei längerer Inaktivität ausgeloggt, ohne dass eine Warnung erscheint.

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]

Wenn Zeitbegrenzungen für Transaktionen bestehen, können Benutzer, die mehr Zeit für Eingaben brauchen, Aufgaben oft nicht rechtzeitig abschließen. Sie müssen unerwartete Änderungen an den bearbeiteten Inhalten oder am Gesamtzusammenhang der Transaktion wiederherstellen oder können die Aufgabe gar nicht erledigen.

Prüfanleitung

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

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 Erledigung 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.17 Timing adjustable

WCAG

2.2.1 Zeiteinteilung anpassbar

WCAG-Techniques

ISO9241-171

8.2.7 Steuerung zeitlich festgelegter Reaktionen durch den Benutzer ermöglichen

Zuletzt bearbeitet

01.10.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Wenn eine authentifizierte Sitzung abläuft, kann der Benutzer die Handlung nach der erneuten Authentifizierung ohne Datenverlust fortführen.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Ein E-Mail-Programm hat ein Authentifizierungs-Time-Out nach 30 Minuten. Das Programm zeigt dem Benutzer einige Minuten, bevor der Time-Out auftritt, eine Eingabeaufforderung und stellt einen Link zur Verfügung, um ein neues Fenster zur erneuten Authentifizierung zu öffnen. Das ursprüngliche Fenster mit der im Gang befindlichen E-Mail bleibt intakt und, nach der erneuten Authentifizierung, kann der Benutzer diese Daten senden.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist anwendbar, wenn Aktionen innerhalb einer Anwendung oder in Interaktion mit anderen Anwendungen zeitlich begrenzt sind oder anderen Unterbrechungen unterliegen.

Begründung

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

Zeitliche Begrenzungen können bei Personen mit Behinderungen zu Problemen führen, da sie möglicherweise länger brauchen, um die Handlung durchzuführen.

Prüfanleitung

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

Sichtprüfung/Erprobung.

Bewertungsalternativen

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

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

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Referenzen

EN301549

-

WCAG

2.2.5 Erneute Authentifizierung

WCAG-Techniques

ISO9241-171

Zuletzt bearbeitet

29.08.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Wenn ein Element Benutzereingaben erwartet, werden Beschriftungen, Anweisungen oder Hilfetexte bereitgestellt, die dem Benutzer ausreichend Information geben, um Fehler zu vermeiden.

Darunter versteht man z. B., dass Symbole für Pflichtfelder erklärt werden, dass Label für Dialogelemente vorhanden sind und dass erforderliche Eingabeformate erklärt werden. Die Aussagekraft des Labels an sich wird in diesem Prüfschritt nicht beurteilt, siehe Einordnung.

Dialogelemente, die Benutzereingaben erwarten, sind u.a. Eingabefelder, Auswahllisten, Optionsschaltflächen, Absenden-Schaltflächen.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Dialogelemente haben eine immer sichtbare Beschriftung (Label) unmittelbar vor dem Element, also darüber oder links daneben. Ausnahme: Bei Optionsschaltflächen (Checkbox, Radiobutton) ist die Beschriftung rechts neben dem Element.

Ein Eingabefeld hat anstelle einer Beschriftung eine Vorbelegung, die so lange stehen bleibt, bis der Benutzer mit der Eingabe begonnen hat, und die erneut erscheint, wenn der Benutzer den eingegebenen Inhalt löscht.

Fehler: Ein Eingabefeld hat anstelle einer Beschriftung eine Vorbelegung, die bei Aktivierung des Feldes verschwindet.

In einer Zeile mit mehreren inhaltlich zusammenhängenden Eingabefeldern, z.B. Land - Postleitzahl - Ort in einer Adresse, können die Beschriftungen am Anfang der Zeile zusammengefasst sein.

Eine Schaltfläche kann anstelle eines Textes mit einem Symbol bezeichnet werden, dessen Name bei Mouseover als Tooltipp erscheint.

Ein Suchfeld kann anstelle einer Beschriftung durch eine unmittelbar anschließende Absenden-Schaftfläche bezeichnet werden, die die Bedeutung „Suchen“ als Text oder als Symbol trägt.

Pflichtfelder: Wenn Eingaben für die Weiterverarbeitung eines Formulars erforderlich sind, so ist dies vor dem Ausfüllen ersichtlich. Beispiele:

• Wenn alle Felder ausgefüllt werden müssen, so wird dies in einer Anweisung am Beginn des Formulars erläutert.
• Ein Sternchen * in der Beschriftung eines Eingabefeldes weist darauf hin, dass diese Eingabe erforderlich ist; die Bedeutung des Sternchens als Pflichtfeldkennzeichen wird in einer Anweisung am Anfang oder am Ende des Formulars erläutert.

Eingabeformate und Werte: Wenn Eingaben in einer bestimmten Schreibweise oder in einem bestimmten Wertebereich erwartet werden, so ist dies vor der Eingabe ersichtlich. Beispiele:

• In der Beschriftung eines Datumsfeldes wird die erwartete Schreibweise dargestellt, etwa: „Geburtsdatum (tt.mm.jjjj)“.
• In der Beschriftung eines numerischen Feldes wird der erwartete Wertebereich angegeben, etwa: „Alter in Jahren (von 18 bis 35)“.
• Ein Hilfetext neben oder unter dem Eingabefeld erläutert die erwartete Schreibweise, Beispiel: „Geben Sie das Datum im Format ‚tt.mm.jjjj‘ an, z.B. ‚01.12.1950‘.“
• Es kann genügen, wenn Anweisungen oder Hilfetexte abgerufen werden können oder zu Beginn der Eingabe erscheinen. Beispiele: Neben dem Eingabefeld weist ein Symbol auf abrufbare Hilfetexte hin; bei Aktivierung des Eingabefeldes erscheint ein Tooltipp mit dem erwarteten Eingabeformat.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist anwendbar, wenn die Software Benutzereingaben erwartet.

Begründung

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

Für jeden Benutzer ist es von Vorteil, wenn beim Ausfüllen von Formularen alle erforderlichen Informationen und Eingabeformate bekannt sind. Denn es ist aufwändig, ein Formular anhand der Fehlermeldungen zu korrigieren. Dies gilt umso mehr für Benutzer, die nur einen kleinen Bildausschnitt sehen.

Die Anordnung von Beschriftungen direkt vor oder über dem Eingabefeld entspricht den üblichen Gestaltungskonventionen. Auch in ausschnitthaften Ansichten (etwa in Vergrößerungssoftware) wird schnell klar, welche Beschriftung zu welchem Feld gehört.

Prüfanleitung

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

Sichtprüfung mit praktischer Erprobung: sind die unter „Beispiele“ genannten Gestaltungsregeln eingehalten?

Die Prüfung sollte gemeinsam mit dem Prüfschritt 2.07.1 „Hilfen bei Fehlbedienung“ durchgeführt werden. Wenn Fehler gemeldet werden, so ist zu prüfen, ob eine entsprechende Anweisung bereits vor oder beim Eingeben der Daten gegeben wird.

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 Erfüllung der Arbeitsaufgabe gewertet.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfpunkt geht es um sichtbare Beschriftungen von Formularfeldern. Der für Screenreader wichtige programmatisch erkennbare Name wird im Prüfpunkt 4.03.1 „Name, Rolle, Wert für Formularfelder“ behandelt.

Eine sichtbare Überschrift für Gruppen von Eingabefeldern wird in diesem Prüfpunkt nicht verlangt. Der für Screenreader wichtige programmatisch erkennbare Gruppenname wird im Prüfpunkt 4.04.0 „Name für Gruppen von Elementen“ behandelt.

In diesem Prüfpunkt geht es um Anweisungen, die dem Benutzer vor der Eingabe zu geben sind, damit er Fehler vermeiden kann. Rückfragen des Systems und Hilfen bei eingetretenem Fehlerzustand werden im Prüfpunkt 2.07.1 „Hilfen bei Fehleingaben“ behandelt.

In diesem Prüfpunkt geht es um formale Gestaltungsregeln für Beschriftungen und Anweisungen. Die Verständlichkeit wird in den Punkten 1.05.1 „Prägnante Beschriftungen“ und 1.06.2 „Verständliche Anweisungen und Meldungen“ geprüft.

Offene Fragen

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

Referenzen

EN301549

11. 2.1.34 Labels or instructions

WCAG

3.3.2 Beschriftungen (Labels) oder Anweisungen

WCAG-Techniques

G162: Positioning labels to maximize predictability of relationships

G167: Using an adjacent button to label the purpose of a field

H90: Indicating required form controls using label or legend

G184: Providing text instructions at the beginning of a form or set of fields that describes the necessary input

G89: Providing expected data format and example

ISO9241-171

-

Zuletzt bearbeitet

14.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Wenn die Software einen Eingabefehler erkennt, unterstützt sie den Benutzer durch folgende Schritte:

• der Fehlerzustand wird für alle Benutzer erkennbar angezeigt
• das fehlerhafte Element wird eindeutig identifiziert und ist leicht auffindbar,
• der Fehler wird dem Benutzer in Textform beschrieben,
• die Fehlermeldung enthält, soweit sinnvoll, eine Korrekturempfehlung,
• der Benutzer erhält Gelegenheit, den Fehler zu korrigieren, bevor die Daten gespeichert oder versendet werden.

Eine automatische Eingabeprüfung zur Fehlererkennung ist verpflichtend, soweit sachlich möglich, für Aktionen, die den Benutzer rechtlich binden, oder die personenbezogene Daten oder sonstige aufgabenrelevante Daten dauerhaft speichern.
In solchen Fällen ist zusätzlich dem Benutzer Gelegenheit zu geben,

• die eingegebenen Daten vor dem Absenden nochmals zu überprüfen und zu bestätigen,
• oder er kann die gesendeten Daten zurückrufen bzw. die Transaktion rückabwickeln.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Der Fehlerzustand wird durch einen Signalton angezeigt, oder die Kennzeichnung „Fehler“ erscheint im Titel der Antwortseite, oder der Benutzer wird durch einen Dialog geführt, der den Fokus erhält.

Fehler: Es genügt nicht, wenn der Fehlerzustand lediglich durch einen farbigen Rahmen um das fehlerhafte Feld optisch erkennbar ist.

Fehlerhaft ausgefüllte Felder werden deutlich hervorgehoben, etwa durch einen farblich abgesetzten Rahmen und ein Symbol mit dem Namen „Fehler“.

Die Beschriftung (label) fehlerhaft ausgefüllter Felder ändert sich, indem ihnen die Bezeichnung „Fehler:“ vorangestellt wird, um auf die Fehler darstellungsunabhängig hinzuweisen.

Es erscheint eine Fehlermeldung, die den Fehler beschreibt und Korrekturhinweise gibt. Die Fehlerbeschreibung ist dem fehlerhaft ausgefüllten Feld eindeutig zuzuordnen. Beispiele: „Name ist erforderlich“, „Geburtsdatum bitte im Format dd.mm.jjjj ausfüllen“.

Fehler: Es erscheint die Meldung „Es sind Fehler aufgetreten“ ohne weitere Spezifikation.

Fehler: Es erscheint die Meldung „Es sind Fehler aufgetreten“, aber es gibt keine Möglichkeit zur Korrektur, oder die vorigen Eingaben sind nicht mehr verfügbar, so dass alle Daten neu eingegeben werden müssen.

Die Fehlermeldung und das fehlerhafte Element sind leicht auffindbar.
Beispiel 1: Die Fehlermeldung erscheint in einem Dialog, der den Tastaturfokus erhält, beim Schließen des Dialogs wird der Fokus in das fehlerhafte Feld geführt, so dass die Korrektur unmittelbar ausgeführt werden kann. Es werden alle Fehler nacheinander abgearbeitet.
Beispiel 2: Die Fehlermeldung erscheint in einem für Systemmeldungen reservierten Bildschirmbereich. Von der Fehlermeldung führt ein Link zu dem fehlerhaften Feld. Weitere Prüfung siehe unter „Einordnung“.
Beispiel 3: Die Fehlermeldung erscheint direkt beim fehlerhaften Feld. Es gibt einen Link oder einen Tastaturbefehl von einem Fehler zum nächsten.

Fehler: Es gibt keine Methode zum Auffinden der Fehler für Benutzer, die nur einen kleinen Bildausschnitt sehen.

Fehler: Die Fehlermeldung erscheint nur kurz und wird nach kurzem Blinken ausgeblendet.

Eine Anwendung, die wichtige Daten erfasst, zeigt zum Abschluss der Erfassung die eingegebenen Daten insgesamt an, fordert eine ausdrückliche Bestätigung und gibt die Gelegenheit zur Korrektur, bevor die Daten gespeichert werden.

Fehler: Eine Anwendung, die rechtlich verpflichtende Angaben verlangt, führt keine Eingabeprüfung  durch.

Fehler: Eine Anwendung, die relevante Daten dauerhaft speichert, führt die Aufforderung zum Löschen eines Datensatzes aus, ohne zuvor den Benutzer über die Konsequenzen dieser Aktion zur informieren und eine ausdrückliche Bestätigung zu verlangen, und ohne dass es eine Möglichkeit zur kurzfristigen Rückabwicklung des Löschvorgangs gibt.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist anwendbar, wenn die Software Benutzereingaben verlangt.

Begründung

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

Für Benutzer mit Behinderungen ist in vielen Fällen das Risiko von Fehleingaben größer. Benutzer mit Legasthenie vertauschen häufiger Zahlen, Benutzer mit motorischen Einschränkungen drücken häufiger versehentlich falsche Tasten. Deshalb sind alle Maßnahmen zur Überprüfung der Eingaben für diese Benutzer besonders wichtig, die automatische Eingabeprüfung ebenso wie das nochmalige Anzeigen und die Gelegenheit zum Rückgängig-Machen falscher Eingaben.

Benutzer, die nur einen kleinen Ausschnitt des Bildes sehen, bemerken einen Fehlerzustand möglicherweise nicht, sie müssen daher zu der Fehlermeldung und zu der zu korrigierenden Eingabe geführt werden.

Eine automatische Eingabeprüfung wird nicht grundsätzlich verlangt, denn in vielen Anwendungsfällen können auch unvollständige oder fehlerhafte Daten toleriert werden. Wenn aber eine Fehlerkontrolle stattfindet, soll sie den genannten Anforderungen entsprechen.

Prüfanleitung

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

Praktische Erprobung:

• Eingaben machen und dabei Fehler provozieren. Feststellen, ob Fehlermeldungen kommen.
• Falls ja, überprüfen, ob die Fehlermeldungen die beschriebenen Gestaltungsregeln einhalten.
• Falls ja, überprüfen, ob die fehlerhaften Eingaben korrigiert werden können, ohne alle Daten erneut einzugeben (Ausnahme: Passwort-Felder sollten bei Fehler gelöscht werden).
• Falls ja, überprüfen, ob nach Korrektur der Eingaben und erneutem Speichern bzw. Senden zuvor angezeigte Fehlermeldungen verschwinden.

Feststellen, ob eine Verpflichtung zur automatischen Eingabeprüfung gegeben ist.

• Falls ja und keine automatische Eingabeprüfung stattfindet, obwohl sie sachlich möglich wäre, Mangel notieren.
• Falls ja, feststellen, ob vor dem Absenden eine Gelegenheit zur Überprüfung, Korrektur und Bestätigung aller eingegebenen Daten besteht, oder ob nach dem Absenden eine Möglichkeit zum Rückruf der eingegebenen Daten besteht.

Dieser Prüfschritt erfordert ggf. anwendungsspezifische Fachkenntnisse, die der Prüfer bei der Erstellung des Szenarios recherchieren muss.

Bewertungsalternativen

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

Wenn Fehlerkontrolle verpflichtend ist, werden Mängel nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.

In allen anderen Fällen werden Mängel als Einschränkung gewertet.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Die sprachliche Verständlichkeit von Fehlermeldungen wird im Prüfschritt 1.06.2 „Verständliche Anweisungen und Meldungen“ geprüft.

Wenn die Fehlermeldung in einem für Systemmeldungen reservierten Bildschirmbereich erscheint, so ist dieser Bereich in den Prüfschritten 3.03.0 „Direktzugriff auf Funktionsbereiche“, 4.04.0 „Name für Gruppen von Elementen“ und 4.09.1 "Benachrichtigung über Änderungen" weiter zu untersuchen.

Offene Fragen

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

Referenzen

EN301549

11. 2.1.33 Error identification

11. 2.1.35 Error suggestion

11. 2.1.36 Error prevention (legal, financial, data)

WCAG

3.3.1 Fehlererkennung

3.3.3 Fehlerempfehlung

3.3.4 Fehlervermeidung (rechtliche, finanzielle, Daten)

WCAG-Techniques

G83: Providing text descriptions to identify required fields that were not completed

G84: Providing a text description when the user provides information that is not in the list of allowed values

G85: Providing a text description when user input falls outside the required format or values

G139: Creating a mechanism that allows users to jump to errors

G177: Providing suggested correction text

ISO9241-171

8.4.3 „Rückgängig“- und/oder „Bestätigen“-Funktionen zur Verfügung stellen

8.4.9 Dauerhafte Anzeige von Warnungen oder Fehlerinformationen ermöglichen

8.4.10 Benutzerbenachrichtigungen einheitlich ausgeben

8.4.12 Das Navigieren zum Auffinden von Fehlern erleichtern

Zuletzt bearbeitet

04.10.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Für alle Bearbeitungsschritte ist eine Undo-Funktion verfügbar, um eine ungewollte Aktion rückgängig zu machen. Aktionen, die nicht rückgängig gemacht werden können, erwarten vor der Ausführung eine ausdrückliche Bestätigung des Benutzers.

Nicht rückgängig zu machen sind solche Aktionen, die eine grundlegende Umgestaltung von logischen oder physikalischen Einheiten verursachen oder einen Datenaustausch mit Dritten einschließen.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Ein Benutzer schreibt einen Text in einer Textverarbeitung und löscht dabei versehentlich einen Absatz. Die Rückgängig-Funktion ermöglicht es ihm, zum vorigen Zustand zurückzukehren.

Ein Benutzer schreibt eine E-Mail und drückt dabei versehentlich den Shortcut für das Absenden der E-Mail. Da diese Aktion sich nicht rückgängig machen lässt, zeigt die Software einen Bestätigungsdialog an, bevor das Senden beginnt.

Ein Benutzer ist im Begriff, eine Festplatte zu formatieren. Da dies ein Arbeitsgang ist, der sich nicht rückgängig machen lässt, zeigt die Software einen Bestätigungsdialog an, bevor die Formatierung beginnt. 

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]

Obwohl es sich dabei um ein allgemeines ergonomisches Prinzip handelt, ist die „Rückgängig“-Funktion besonders wichtig für Benutzer, durch deren Behinderungen das Risiko von Fehleingaben erhöht ist. Benutzer mit motorischen Einschränkungen drücken häufiger versehentlich falsche Tasten, Benutzer die nicht die gesamte Anzeige wahrnehmen können, übersehen häufiger unabsichtlich ausgelöste Aktionen. Diese Benutzer können viel Zeit und Aufwand benötigen, um nach derartigen Fehleingaben den vorigen Zustand wiederherzustellen.

Prüfanleitung

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

Stichprobenartige Erprobung während der Bearbeitung des Szenarios: Überprüfen Sie, ob die jeweiligen Arbeitsschritte rückgängig gemacht werden können. Provozieren Sie Fehleingaben und überprüfen Sie, ob die ausgelösten Aktionen rückgängig gemacht werden können, oder ob ein Bestätigungsdialog erscheint.

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]

Das Rückgängig machen von rechtlich verpflichtenden Formulareingaben wird im Prüfschritt 2.07.1 „Hilfen bei Fehleingaben“ behandelt.

Offene Fragen

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

Referenzen

EN301549

-

WCAG

3.3.6 Fehlervermeidung

WCAG-Techniques

ISO9241-171

8.4.3 „Rückgängig“- und/oder „Bestätigen“-Funktionen zur Verfügung stellen

Zuletzt bearbeitet

16.09.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Für Texteingaben steht eine konfigurierbare Rechtschreibhilfe zur Verfügung, mit Ausnahme von Aufgaben, bei denen die Fähigkeit des Benutzers, orthographisch richtig zu schreiben/zu buchstabieren, geprüft wird.

Die Anwendung nutzt eine systemweite Rechtschreibhilfe oder bietet eine eigene Rechtschreibhilfe an.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Die Rechtschreibhilfe zeigt mögliche Fehler an und macht Korrekturvorschläge, sofern sie bekannt sind.

Die Funktion soll nur auf frei formulierte Texteingaben anwendbar sein, nicht auf Dateneingaben wie Name, Ort etc. Die Funktion soll auf Nur-Text- Eingabefelder ebenso anwendbar sein wie auf Rich Text-Editoren.

Da die automatische Anzeige von Rechtschreibfehlern im Screenreader umständlich zu bedienen ist, muss ein Abschalten der Automatik möglich sein. Eine Autokorrektur, falls verfügbar, muss ebenfalls abschaltbar sein.

Um dem Gebrauch von kundenspezifischen Rechtschreibregeln gerecht zu werden, sollte die Rechtschreibprüfung das Anlegen von Profilen ermöglichen.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, wenn die Anwendung mehrzeilige Texteingaben erwartet.

Begründung

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

Die Rechtschreibung stellt für viele Benutzer ein Problem dar, einschließlich solcher Menschen mit Rechtschreibschwächen wie beispielsweise Legasthenie. Nutzer von Sprachausgaben überhören leicht geringfügige Abweichungen, die auf einen Rechtschreibfehler hinweisen.

Prüfanleitung

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

Erprobung und Sichtprüfung, ob die in den Beispielen genannten Anforderungen an die Rechtschreibhilfe erfüllt 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]

-

Offene Fragen

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

Der Prüfschritt könnte auf die Syntaxprüfung in Programmeditoren übertragen werden. Ein Beispiel: Eclipse zeigt an, wenn man in einer Programmzeile einen Fehler gemacht hat. Dies wird permanent beim Schreiben angezeigt, was sehende Benutzer leicht ignorieren können. Nutzer von Screenreadern müssen die Funktion abschalten können, denn wenn bei noch nicht fertigem Code beim Schreiben permanent Fehler vorgelesen werden, so ist dies sehr störend.

Referenzen

EN301549

-

WCAG

WCAG 3.3.5 kontextsensitive Hilfe

WCAG-Techniques

G194: Providing spell checking and suggestions for text input

ISO9241-171

9.1.5 Systemweite Werkzeuge zur Kontrolle der Rechtschreibung zur Verfügung stellen

Zuletzt bearbeitet

29.08.2016

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Der Name von grafischen Bedienelementen kann durch Maus- und Tastaturbedienung angezeigt werden. Die Anforderung bezieht sich auf grafische Elemente, die nicht zum Betriebssystemstandard gehören und keine Beschriftung haben.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Die Elemente in einer Symbolleiste haben jeweils ein Kontextmenü, das den Namen des Elements enthält. Das Kontextmenü kann entsprechend dem Windows-Standard mit der rechten Maustaste und mit der Funktionstaste F10 abgerufen werden.

Die Funktion „Drucken“ wird durch ein Icon in Form eines Druckers dargestellt. Bei Mausberührung erscheint ein Tooltipp mit dem Namen „Drucken“.  Zusätzlich kann der Name durch einen Tastaturbefehl abgerufen werden.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist anwendbar, wenn die Software grafische Bedienelemente enthält.

Begründung

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

Die Symbole auf grafischen Bedienelementen sind nicht für alle Benutzer selbsterklärend. Bevor ein Benutzer ein Bedienelement auslöst, muss er überprüfen können, ob sich hinter dem Symbol die vermutete Funktion verbirgt. Wenn der Benutzer eine Erläuterung zum Element in der Dokumentation nachschlagen will, benötigt er ebenfalls den Namen des Elements.

Diese Information muss jedem Benutzer zur Verfügung stehen, unabhängig von dem verwendeten Bediengerät. Daher genügt es nicht, wenn bei Mausberührung ein Tooltipp mit dem Namen des Elements erscheint, oder wenn der Name vom Screenreader ausgegeben wird. Ein motorisch behinderter Benutzer, der auf die Tastatur angewiesen ist, muss die Information mit einem Tastaturbefehl abrufen können.

Prüfanleitung

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

Ermitteln Sie das Tastaturkommando zur Anzeige von Namen anhand der Dokumentation.

Praktische Erprobung: Werden die Namen der grafischen Bedienelemente durch eine Mausaktion (Hover, rechte Maustaste) und ebenso durch eine Tastaturaktion (F10, sonstige) am Bildschirm angezeigt? 

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]

Der Prüfschritt könnte aufgeteilt werden, Maus­ und Tastaturbedienung könnten separat untersucht werden. Das wäre interessant, wenn eine Auswertung nach Modalitäten / nach Art der Behinderung eingeführt werden sollte.

Referenzen

EN301549

WCAG

3.3.5 Kontextsensitive Hilfe

WCAG-Techniques

ISO9241-171

8.1.5 Anzeige von Namen

BITV-Test

2.4.6a Title-Attribut für Symbole

Zuletzt bearbeitet

10.11.2016

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Anzeigen, die mit der Maus bedienbar sind, können auch mit der Tastatur bedient werden.

Anzeigen sind Statusanzeigen, Anweisungen, Meldungen etc., die eine rein informative Funktion haben, ebenso nicht editierbare Daten. Solche Anzeigen können mit der Maus selektierbar sein, um Informationen daraus zu kopieren. Wenn dies der Fall ist, muss die Bedienung auch mit der Tastatur möglich sein.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Eine Anwendung zeigt Systemmeldungen mit Fehlercodes in der Statuszeile an. Um den Fehlercode zu kopieren, kann die Statuszeile mit F6 fokussiert, der Inhalt mit strg+a  markiert und mit strg+c in die Zwischenablage kopiert werden.

Ein Buchhaltungsprogramm zieht den Banknamen der Kontoverbindungen aus einem internen Verzeichnis und zeigt ihn in der Liste der Kreditoren an, die nicht editierbar ist. Die einzelnen Listenelemente können mit Tastaturbefehlen selektiert und kopiert werden.

Die Anwendung nimmt Anzeigen in die TAB-Reihe auf, oder sie bietet spezielle Tastaturbefehle für die Fokussierung von Anzeigen an.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist anwendbar, wenn Anzeigen mit der Maus selektierbar sind.

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.

Anzeigen werden häufig nicht in die Tastaturbedienung aufgenommen, da nach einer verbreiteten Bedienphilosophie nur solche Elemente mit der Tastatur erreichbar sein müssen, die eine Benutzereingabe erwarten oder eine Funktion auslösen. Wenn aber eine Anzeige mit der Maus selektiert werden kann, so muss dies auch mit der Tastatur möglich sein.

Die Möglichkeit, Inhalte von Anzeigen in die Zwischenablage zu kopieren, kann Benutzern mit Behinderungen helfen, das missliche, langsame oder fehleranfällige manuelle Eingeben des betreffenden Textes an anderer Stelle zu vermeiden. 

Prüfanleitung

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

Feststellen, welche Anzeigen mit der Maus selektierbar sind.

Tastaturbefehle für die Selektion der betreffenden Anzeigen ermitteln, über die Dokumentation oder über andere Quellen wie kontextsensitive Hilfe, Herstellerinterview, eigene Erprobung.

Praktische Erprobung: Mit Tastaturbefehlen Text aus Anzeigen kopieren.

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]

Referenzen

EN301549

11. 2.1.15 Keyboard

WCAG

2.1.1 Tastatur

WCAG-Techniques

ISO9241-171

8.4.7 Unterstützung der Funktion „Kopieren“ in nicht editierbarem Text

9.3.2 Nutzung aller Funktionen über die Tastatur ermöglichen

Zuletzt bearbeitet

29.08.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Anzeigen können mit der Tastatur bedient werden, um Text daraus zu kopieren.

Anzeigen sind Statusanzeigen, Anweisungen, Meldungen etc., die eine rein informative Funktion haben, ebenso nicht editierbare Daten.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Eine Anwendung zeigt Systemmeldungen mit Fehlercodes in der Statuszeile an. Um den Fehlercode zu kopieren, kann die Statuszeile mit F6 fokussiert, der Inhalt mit strg+a  markiert und mit strg+c in die Zwischenablage kopiert werden.

Ein Buchhaltungsprogramm zieht den Banknamen der Kontoverbindungen aus einem internen Verzeichnis und zeigt ihn in der Liste der Kreditoren an, die nicht editierbar ist. Die einzelnen Listenelemente können mit Tastaturbefehlen selektiert und kopiert werden.

Die Anwendung nimmt Anzeigen in die TAB-Reihe auf, oder sie bietet spezielle Tastaturbefehle für die Fokussierung von Anzeigen an.

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]

Aufgabenrelevante Anzeigen sollen mit der Tastatur fokussierbar sein, um Informationen daraus für die Verwendung an anderer Stelle in die Zwischenablage kopieren zu können. Dies erspart Menschen mit Behinderungen das mühsame und fehleranfällige Abschreiben der Informationen. Darüber hinaus können Nutzer von Screenreadern die Inhalte fokussierbarer Anzeigen leichter adressieren und lesen, ohne hierzu spezifische Screenreaderbefehle kennen zu müssen.

Prüfanleitung

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

Tastaturbefehle für die Selektion der in der Arbeitsaufgabe benötigten Anzeigen ermitteln, über die Dokumentation oder über andere Quellen wie kontextsensitive Hilfe, Herstellerinterview, eigene Erprobung.

Praktische Erprobung: Mit Tastaturbefehlen Text aus Anzeigen kopieren.

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]

Anzeigen, die Mausbedienbar sind, werden im Prüfschritt 3.04.1 „Tastaturbedienung für Anzeigen (wie Mausbedienung)“ geprüft.

Offene Fragen

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

Referenzen

EN301549

WCAG

WCAG-Techniques

ISO9241-171

8.4.7 Unterstützung der Funktion „Kopieren“ in nicht editierbarem Text

Zuletzt bearbeitet

29.08.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Der Tastaturfokus ist deutlich sichtbar, so dass er von Menschen mit leicht eingeschränkter Sehfähigkeit ohne Anstrengung gefunden werden kann.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Im Hauptmenü einer Anwendung wird der Tastaturfokus durch invertierte Farben angezeigt.

In einem E-Mail-Client wird der Tastaturfokus in der Liste der eingegangenen Mails durch einen andersfarbigen Hintergrund und eine Rahmenlinie am linken Rand angezeigt.

Um das Kontrollkästchen, das fokussiert wird, wenn der Benutzer eine Pfeiltaste anschlägt, erscheint ein Rahmen oder ein markierter Bereich.

Um die Schaltfläche, die fokussiert wird, erscheint ein gepunkteter Rahmen.

Ein Text-Indikator (ein blinkender senkrechter Strich) erscheint im Dateneingabefeld an der Stelle, an der die eingegebenen Zeichen eingefügt werden.

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]

Für den Tastaturbenutzer ist es wichtig, zu sehen, wo sich der Tastaturfokus gerade befindet, welche Aktion also ausgelöst wird, wenn er die Enter-Taste drückt, bzw. an welcher Stelle eingegebene Zeichen erscheinen werden. Ohne sichtbaren Tastaturfokus ist eine Anwendung für optisch orientierte Menschen praktisch nicht tastaturbedienbar.

Deutlich sichtbar ist der Tastaturfokus, wenn er von Normalsichtigen ebenso wie von Menschen mit leichter Einschränkung des Sehens, die aus Farbfehlsichtigkeit oder aus normaler Alterung resultiert, bei der durch Tastenanschläge hervorgerufenen Bewegung ohne Anstrengung gefunden werden kann. Die Bedingungen für gute Sichtbarkeit sind definiert in den Prüfschritten 1.01.0 „Ausreichender Kontrast“ und 1.07.1 „Informationen nicht allein durch Farbe übermitteln“.

Prüfanleitung

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

Sichtprüfung im Anschluss an Prüfschritt 3.01.0 „Tastaturbedienung für Bedienelemente“: ist der Fokus sichtbar?

Weitere Prüfung der deutlichen Sichtbarkeit wie in den Prüfschritten 1.01.0 „Ausreichender Kontrast“ und 1.07.1 „Informationen nicht allein durch Farbe übermitteln“.

Bewertungsalternativen

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

Wenn der Tastaturfokus in ganzen Bereichen der Anwendung nicht sichtbar ist, so ist dies eine Blockade.

Wenn der Tastaturfokus für mehr als 3 Tastenanschläge nicht sichtbar ist, so ist dies eine Barriere.

Wenn der Tastaturfokus schwach sichtbar ist, so ist dies eine Einschränkung.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfschritt geht es um die Normalansicht des Tastaturfokus. Die Konfiguration einer stärkeren optischen Hervorhebung für Menschen mit Sehbehinderungen ist Gegenstand des Prüfschritts 6.02.2 „Hilfsmittel zum Auffinden des Zeigers zur Verfügung stellen“.

Offene Fragen

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

Eine strengere Definition von „deutlich sichtbar“ wird in ISO 9241-171 Nr. 9.2.2 „Für deutliche Sichtbarkeit des Tastaturfokus- und Text-Indikators sorgen“ gegeben, die diskussionswürdig erscheint. Denn ein grell gestalteter Tastaturfokus kann auch ablenken, wenn die Arbeitsaufgabe die Konzentration auf Informationen abseits der Tastatureingabe verlangt. Daher sollte der Fokus für Menschen mit Sehbehinderungen konfigurierbar sein.

Referenzen

EN301549

11. 2.1.26 Focus visible

WCAG

2.4.7 Fokus sichtbar: Jede durch Tastatur bedienbare Benutzerschnittstelle hat einen Bedienmodus, bei dem der Tastaturfokus sichtbar ist.

WCAG-Techniques

ISO9241-171

9.2.1 Tastaturfokus- und Text-Indikator zur Verfügung stellen

9.2.2 Für deutliche Sichtbarkeit des Tastaturfokus- und Text-Indikators sorgen

Zuletzt bearbeitet

13.10.2016

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Wenn ein Bedienelement fokussiert wird oder eine Eingabe erhält, so löst dies nicht eine Änderung des Kontextes aus, es sei denn der Benutzer erhält einen Hinweis, wie er das Verhalten auf einfache Weise steuern kann.

Eine Kontextänderung ist eine wesentliche Änderung des Inhalts, oder eine Änderung des Fokus, des Bildausschnitts oder der Bedienmodalität.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Kein Fehler: Eine Kontextänderung wird explizit ausgelöst, z.B. mit der Eingabetaste auf einem Aktionstrigger (Menüpunkt, Button, Link), oder durch das Verlassen eines Eingabefeldes mit TAB.

Fehler: Ein Dialog ist in mehrere Registerkarten aufgeteilt, die durch Karteireiter (Tabs) auswählbar sind. Bei Fokussierung eines Reiters wird automatisch die dazugehörige Karte angezeigt, der Fokus geht auf das erste Bedienelement der Karte. Um den nächsten Reiter auszuwählen, muss der Benutzer zunächst alle Bedienelemente der Karte passieren.
Kein Fehler: Wie zuvor, aber der Fokus geht nicht automatisch in die angezeigte Registerkarte, sondern erst beim Verlassen der Karteireiter mit der TAB-oder der ENTER-Taste, während die Auswahl eines Reiters mit den Pfeiltasten geschieht.

Kein Fehler: Eine Präsentationssoftware bietet die Möglichkeit, Daten aus einer Tabellenkalkulation einzubinden und zu bearbeiten, wobei die Bedienelemente beider Komponenten in demselben Bildschirmbereich angezeigt werden. Die Bedienelemente der Tabellenkalkulation erscheinen erst dann, wenn der Benutzer den „Bearbeiten“-Button betätigt, und nicht bereits beim Fokussieren der Tabelle.

Kein Fehler: In einer Bibliotheksanwendung ist die Eingabe der 8-stelligen ISS-Nummer für Zeitschriften in zwei Felder aufgeteilt, mit einem dazwischen angezeigten Bindestrich. Nach der Eingabe der vierten Ziffer wechselt der Fokus automatisch in das zweite Eingabefeld (Auto-Tab). Die Beschriftung der Eingabefelder lautet „ISS-Nummer (fortlaufende Eingabe)“.
Fehler: Wie zuvor, aber das Auto-Tab-Verhalten ist nicht angekündigt.

Fehler: Ein Formular wird automatisch abgeschickt, sobald der Fokus das letzte Eingabefeld verlässt, ohne dass explizit ein Submit-Button zu betätigen wäre.
Ausnahme: in einem Suchfeld ist dieses Verhalten nicht unerwartet.

Fehler: Bei Fokussierung eines Eingabefeldes erscheint ein Popup mit einem Hilfetext, das erst mit ESC geschlossen werden muss, bevor die Eingabe erfolgen kann.

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 Software muss es den Benutzern ermöglichen, den Tastaturfokus zu bewegen, ohne dadurch bei irgendetwas anderem als der Positionsanzeige eine Wirkung hervorzurufen. Es muss eine bewusste Aktion des Benutzers vorgenommen werden, um jede andere Wirkung auszulösen. Dies ist besonders wichtig für Benutzer, die nicht die gesamte Anzeige auf einmal sehen können und die Benutzungsschnittstelle daher erkunden müssen, indem sie durch alle verfügbaren Bedienelemente navigieren. Wenn hierbei eine unbeabsichtigte Kontextänderung geschieht, können Benutzer desorientiert sein oder die Änderung zunächst gar nicht wahrnehmen, was im späteren Verlauf zu Problemen führt.

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
• wenn eine unerwartete Kontextänderung vorliegt: feststellen, ob sie mit einem einfachen Bedienschritt (ESC, Zurück o.ä.) wieder aufgehoben werden kann

Bewertungsalternativen

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

Wenn mehr als ein Bedienschritt benötigt wird, um die unerwartete Kontextänderung rückgängig zu machen, so ist dies eine Barriere.

Alle weiteren Mängel sind eine Einschränkung.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Dieser Prüfschritt behandelt Störungen der Tastaturbedienung wegen mangelnder Orientierung. Schwerwiegendere Fehlersituationen werden unter anderen Prüfschritten behandelt:

• Fehlersituationen, die dazu führen, dass eine Funktion nicht mit der Tastatur ausgeführt werden kann, werden im Prüfschritt 3.01.0 „Tastaturbedienung für Bedienelemente“ als Mangel gewertet.
• Fehlersituationen, die zu einem Fokusverlust führen, werden im Prüfschritt 3.07.0 „Sinnvolle Fokusreihenfolge“ als Mangel gewertet.

Explizit ausgelöste Kontextänderungen werden im Prüfschritt 4.09.1 "Benachrichtigung über Änderungen" behandelt.

Offene Fragen

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

Referenzen

EN301549

11. 2.1.29 On focus

11. 2.1.30 On input

WCAG

3.2.1 Bei Fokus

3.2.2 Bei Eingabe

WCAG-Techniques

G107: Using "activate" rather than "focus" as a trigger for changes of context

G80: Providing a submit button to initiate a change of context

F36: Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value

ISO9241-171

9.3.14 Tastaturnavigation und Aktivierung voneinander trennen

Zuletzt bearbeitet

25.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Die Anzahl der für jede Arbeitsaufgabe erforderlichen Schritte optimieren.

• Die Software stellt Shortcuts für häufig gebrauchte Funktionen zur Verfügung.
• Kurztasten für Menüpunkte, die unterstrichen angezeigt werden
• Navigieren durch lange Listen erleichtern
• Die Software stellt für alle Funktionen wenigstens zwei verschiedene Bedienwege zur Verfügung.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Der Benutzer kann „Strg-C“ eingeben, um zu kopieren, „Strg-V“, um einzufügen, oder „Strg-P“, um auszudrucken.

Der Benutzer drückt die „Pos 1“-Taste, um zum ersten Element in einer Liste zu gelangen, und die „Ende“-Taste, um zum letzten Element in der Liste zu gelangen, und er verwendet „Bild auf“ und „Bild ab“, um innerhalb der momentan sichtbaren Objekte vorwärts und rückwärts zu gehen.

In einer Liste gibt der Benutzer ein oder mehrere Zeichen ein, um zum nächsten Objekt zu gelangen, das mit diesen Zeichen beginnt.

Die Druckfunktion kann sowohl aus dem Menü als auch mit dem Shortcut „Strg+p“ aufgerufen 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]

Bei der Gestaltung der Software sollte die Anzahl der Schritte optimiert werden, die der Benutzer für eine gegebene Arbeitsaufgabe durchführen muss. Diese Regel wird zumeist nur für die Bedienung mit Zeigegeräten befolgt. Für Menschen, die auf die Tastatur angewiesen sind, ist eine effiziente Bedienung ebenso wichtig,

Effiziente Tastatursteuerung ist besonders wichtig für Benutzer, die langsam eingeben, nur über eine Tastatur interagieren oder die Tastaturemulatoren, wie z. B. Spracherkennungssysteme, verwenden. Behinderte Benutzer profitieren davon, weil sie die Anzahl zeitraubender Schritte verringern können, die anderenfalls erforderlich wären.

Verschiedene Bedienwege erleichtern es Benutzern, ihren an die Arbeitsaufgabe angepassten persönlichen Arbeitsstil zu entwickeln. Hierarchisch aufgebaute Funktionsmenüs sind wichtig, um alle Funktionen der Anwendung systematisch zu präsentieren. Zusätzlich werden Tastenkombinationen für häufig verwendete Funktionen benötigt. Eine Software, die sich allein auf Tastenkombinationen verlässt, wäre nicht effizient bedienbar, denn ein Benutzer kann nicht alle Tastenkombinationen im Kopf haben. Kontextmenüs helfen situativ mit einem ausgewählten Funktionsangebot.

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.

Stichprobenartige praktische Erprobung: Stehen für alle Arbeitsschritte effiziente Tastaturmethoden zur Verfügung?

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]

Referenzen

EN301549

-

WCAG

2.4.5 Verschiedene Methoden

WCAG-Techniques

ISO9241-171

8.4.2 Die Anzahl der für jede Arbeitsaufgabe erforderlichen Schritte optimieren

9.3.10 Beschleunigungs-Tasten zur Verfügung stellen

9.3.16 Das Navigieren durch lange Listen und Menüs erleichtern

Zuletzt bearbeitet

29.08.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Die Software sollte die von der betreffenden Plattformsoftware festgelegten Tastaturzugriffskonventionen befolgen. Die Plattformkonventionen schließen üblicherweise die Zuweisung von impliziten Bezeichnern, Funktionstasten und Beschleunigungs-Tasten ein. Tastaturkonventionen können vom Betriebssystem oder von einer separaten Schicht der grafischen Benutzungsschnittstelle festgelegt werden.

Dies schließt die Festlegung weiterer Tastenkürzel und Verfahren zusätzlich zu denen, die zu den Plattformkonventionen gehören, nicht aus.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Eine Anwendung befolgt die Systemkonventionen, die besagen, dass die „Alt“-Taste, wenn sie gedrückt gehalten wird, dazu dient, die Verwendung von impliziten Bezeichnern anzuzeigen, und dass sie zur Aktivierung des Anwendungshauptmenüs dient, wenn sie gedrückt und dann losgelassen wird.

Eine Anwendung benutzt zum Schließen ihrer kundenspezifischen Dialog- und Meldungsfelder die „Esc“-Taste, weil dies der vom Betriebssystem festgelegten Konvention entspricht.

Eine Anwendung vermeidet es, die vom Betriebssystem zum Aktivieren der Tastaturmaus-Funktion verwendete Tastenkombination erneut zuzuweisen.

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 die Einhaltung der Tastaturkonventionen wird die Gebrauchstauglichkeit neuer Anwendungen verbessert. Dies ist besonders wichtig für Menschen, die nur die Tastatur benutzen können oder kognitive Behinderungen haben.

Prüfanleitung

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

Sichtprüfung, praktische Erprobung.

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]

Referenzen

EN301549

-

WCAG

WCAG-Techniques

ISO9241-171

9.3.15 Die Tastaturkonventionen der Plattform befolgen

Bit-Inklusiv-Synopse

Sonstige

Microsoft Windows Keyboard Design Guide

https://www.microsoft.com/enable/products/keyboard.aspx

Zuletzt bearbeitet

29.08.2016

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Tastaturbefehle sind in der Bedienoberfläche der Anwendung direkt bei den Elementen angezeigt, auf die sie sich beziehen, oder sie sind mit der Tastatur abrufbar.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

In Menüs werden die Tastaturbefehle zum Aufruf der Funktionen direkt neben dem Menübefehl angezeigt.

Bei ALT werden die als Tastenkürzel verwendeten Buchstaben in den Beschriftungen von Bedienelementen unterstrichen.

Bei ALT werden die als Tastenkürzel verwendeten Buchstaben neben den Bedienelementen angezeigt.

Bei Buttons sind die Tastaturbefehle zum Aufruf der Funktion im Kontextmenü vermerkt und mit der Tastatur abrufbar.

Einschränkung: Bei Buttons sind die Tastaturbefehle zum Aufruf der Funktion nur bei Mausberührung als Tooltipp verfügbar.

Fehler: Es gibt keine kontextsensitive Hilfe für Tastaturbefehle.

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]

Für alle Benutzer ist es umständlich, Informationen zur Bedienung einer Software in der Dokumentation nachzuschlagen, dies gilt insbesondere für Menschen mit Behinderungen, die aus verschiedenen Gründen bei der Nutzung von Dokumenten eingeschränkt sind. Eine kontextsensitive Hilfe ist daher für Menschen mit Behinderungen besonders wichtig. Besonders wenn Nutzer auf die Tastatur angewiesen sind, benötigen sie eine kontextsensitive Hilfe für selten gebrauchte Tastaturbefehle, um die Anwendung effizient bedienen zu können.

Damit die kontextsensitive Hilfe den Tastaturnutzern zur Verfügung steht, genügt es nicht, wenn bei Mausberührung ein Tooltipp mit dem Tastaturbefehl erscheint, oder wenn der Tastaturbefehl vom Screenreader ausgegeben wird. Ein motorisch behinderter Benutzer, der auf die Tastatur angewiesen ist, muss die Information mit einem Tastaturbefehl abrufen können. 

Prüfanleitung

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

Sichtprüfung, Erprobung.

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]

Referenzen

EN301549

-

WCAG

WCAG-Techniques

ISO9241-171

9.3.11 Implizite oder explizite Bezeichner zur Verfügung stellen

Zuletzt bearbeitet

28.11.2016

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

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Formularfelder werden vom Screenreader mit ihrem Namen, ihrer Rolle, voreingestellten Werten und erlaubten Wertebereichen wiedergegeben.

Der Name eines Formularfeldes entspricht der sichtbaren Beschriftung (Label). Wenn bei Eingabefeldern anstelle einer Beschriftung eine Vorbelegung des Feldinhalts angezeigt wird, so ist ein Name zusätzlich vorhanden. Wenn als Beschriftung ein angrenzender Schalter verwendet wird, so entspricht der Name des Eingabefeldes der Beschriftung bzw. dem Namen des Schalters.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Ein Eingabefeld hat den Platzhalter-Wert „Ihr Suchbegriff“, der Screenreader gibt zusätzlich den Namen „Suche“ aus.

Einschränkung: Ein Eingabefeld hat keinen Namen, aber der angrenzende Submit-Button hat den Namen „Suche“, der vom Screenreader bei TAB vorgelesen wird.

In einer Zeile mit mehreren inhaltlich zusammenhängenden Eingabefeldern, z.B. Land - Postleitzahl - Ort in einer Adresse, sind die Beschriftungen am Anfang der Zeile zusammengefasst. Der Screenreader sagt zusätzlich die Namen der einzelnen Felder an.

Die Rolle des Feldes wird korrekt wiedergegeben. Rollen sind u.a.: Eingabefeld, Auswahlliste, Kombinationsfeld, Kontrollkästchen (Checkbox), Auswahlschalter (Radiobutton), Schalter (Submit-Button).

Fehler: Eine Auswahlliste wird als Eingabefeld ausgegeben. Ein blinder Benutzer kann das Feld nicht bedienen, da er versucht Text einzutippen, statt mit den Pfeiltasten einen Eintrag auszuwählen.

Der Wert einer Tristate-Checkbox wird als "nicht aktiviert", "aktiviert" oder "teilweise aktiviert" ausgegeben.

Fehler: In einer Mehrfachauswahlliste wird bei Fokuserhalt nur ein Eintrag und nicht alle gewählten Einträge ausgegeben.

Eingabeformate und Wertebereiche, die von der Anwendung geprüft werden, sagt der Screenreader bei Fokussierung des Formularfelds an.

Wenn ein Feld nicht leer bleiben darf (Pflichtfeld), so sagt der Screenreader bei Fokussierung „Eingabe erforderlich“.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, wenn die Anwendung Benutzereingaben erwartet.

Begründung

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

Formularfelder kommen in verschiedener Rolle bzw. Funktion vor, die dem blinden Benutzer bekannt gemacht werden muss, damit er weiß, wie er ein Feld zu bedienen hat.

Beim Ausfüllen von Formularen sollen alle benötigten Informationen von Anfang an bekannt sein, diese Anforderung wird geprüft im Prüfschritt 2.06.1 „Ausreichende Anweisungen für Benutzereingaben“. Der Screenreader soll diese Informationen direkt beim jeweiligen Eingabefeld ausgeben. Denn im Formularmodus übersehen blinde Benutzer leicht Anweisungen, die zwischen den Feldern stehen. In der Programmierung sind die auf korrekte Eingabe zu prüfenden Informationen normalerweise dem jeweiligen Formularfeld zugeordnet, so dass es nur ein kleiner Schritt ist, sie für die Hilfstechnik verfügbar zu machen.

Prüfanleitung

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

Das Formularfeld mit der Tastatur aktivieren und feststellen, ob die in der Beschreibung und den Beispielen spezifizierten Informationen korrekt vom Screenreader ausgegeben werden.

Wenn der Name fehlt, durch Bewegung des Fokus (ein Tastenanschlag) überprüfen, ob im unmittelbaren Kontext ein Hinweis auf den Zweck des Feldes zu finden ist.

Wenn ein Pflichtfeldhinweis oder der Hinweis auf geprüfte Eingabewerte und -formate nicht direkt beim Feld ausgegeben wird, überprüfen, ob eine entsprechende Anweisung neben dem Formularfeld steht oder abgerufen werden kann.

Bewertungsalternativen

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

Wenn der Name des Formularfeldes mit einem Tastendruck ermittelt werden kann, so ist dies eine Einschränkung.

Wenn Informationen über erforderliche Eingaben, Wertebereiche und Formate im Umfeld des Formularfeldes ermittelt werden können, so ist dies eine Einschränkung.

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

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Dieser Prüfschritt bezieht sich auf einzelne Formularfelder. Gruppen von Formularfeldern werden behandelt im Prüfschritt 4.04.0 „Name für Gruppen von Elementen“.

Dieser Prüfschritt bezieht sich nicht auf die sprachliche Gestaltung der Namen von Formularfeldern, diese wird behandelt in den Prüfschritten 1.05.1 „Prägnante Beschriftungen“ und 4.02.0 „Name für grafische Bedienelemente und Anzeigen“

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.2.5 Object information

11.3.2.7 Values

11.3.2.8 Label relationships

WCAG

1.3.1 Info und Beziehungen können durch Software bestimmt werden

3.3.2 Beschriftung (Labels) oder Anweisungen

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

28.11.2016

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Der Name identifiziert das Element und ist eindeutig. Wenn innerhalb eines Kontextes mehrere gleichartige Elemente vorkommen, sollte der Name durch die Umgebung unterscheidbar sein, oder es wird ein unterscheidendes Merkmal hinzugefügt.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Ein Formular ist in mehrere Abschnitte unterteilt, die jeweils durch einen Edit-Button für die Bearbeitung aktiviert werden. Der Screenreader sagt den Namen des Buttons an und kann mit einem Bedienschritt die Überschrift des Abschnitts ausgeben.

In einer Anwendung symbolisiert ein Fragezeichen in einem Kreis die kontextsensitive Hilfe zu bestimmten Bereichen. In der Beschreibung des Buttons (und damit im Tooltipp) wird jeweils das Hilfethema genannt.

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]

Screenreadernutzer lesen jedes  Bedienelement einzeln und sind auf den Namen des Elements angewiesen, um seinen Zweck zu erkennen. Daher sollten die Namen der Elemente innerhalb eines Kontextes eindeutig sein. Wenn eine Bezeichnung mehrfach vorkommt, sollte ein Unterscheidungsmerkmal hinzugefügt werden, oder die erforderlichen Zusatzinformationen sollten aus dem Kontext einfach zu beschaffen sein.

Prüfanleitung

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

Feststellen, ob mehrere gleich benannte Elemente vorkommen. Element im Screenreader aktivieren und feststellen, ob der Name des Elements eindeutig angesagt wird. Falls dies nicht der Fall ist, überprüfen, ob eine Zusatzinformation mit einem Bedienschritt ermittelt werden kann.

Bewertungsalternativen

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

Mängel sind eine Barriere oder eine Einschränkung, je nachdem wie aufwändig es ist, notwendige Zusatzinformationen zu ermitteln.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Der Prüfschritt basiert auf ISO 9241-171 8.1.3 „Innerhalb des Kontextes eindeutige Namen vorsehen“ und ist daher in Konformitätsstufe II eingeordnet. Eine Teilmenge des Prüfumfangs könnte aufgrund von EN 301549 11. 2.1.23 „Link purpose (in context)“ in Konformitätsstufe I eingeordnet werden. Hierbei handelt es sich um Links i.e.S. und ausdrücklich nicht um Buttons und sonstige Bedienelemente. Da Links in Anwendungssoftware relativ marginal sind, wurde auf einen entsprechenden Prüfschritt verzichtet.

Referenzen

EN301549

11. 2.1.23 Link purpose (in context)

WCAG

2.4.4 Linkzweck (im Kontext)

2.4.9 Linkzweck (reiner Link)

WCAG-Techniques

BITV-Test

2.4.4.a Aussagekräftige Linktexte

ISO9241-171

8.1.3 Innerhalb des Kontextes eindeutige Namen vorsehen

Zuletzt bearbeitet

09.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Bei Textinhalten werden die Attribute fett, kursiv und unterstrichen wiedergegeben bzw. sind ermittelbar.

Die Anforderung bezieht sich auf Inhalte einer Anwendung, nicht auf Elemente der Bedienoberfläche.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

In einem Rich-Text-Feld soll ein Satz fett hervorgehoben dargestellt werden. Der entsprechende Bereich wird markiert und dann mit den Funktionen des Editors fett hervorgehoben. Um zu prüfen, ob der Text nun auch wie gewünscht dargestellt wird, setzt der blinde Benutzer die Einfügemarke in diesen Bereich und ruft mit einer Tastenkombination des Screenreaders die Textattribute ab.

Ein Multiple-Choice-Test bietet eine Lösungsversion an, in der die richtige Antwort durch eine Unterstreichung der Antwortnummer gekennzeichnet ist.

Eine Datenbankanwendung gibt einen Report aus, in dem noch nicht abschließend geprüfte Daten kursiv gesetzt sind. Der blinde Benutzer schaltet in seinem Screenreader die Funktion „Textattribute überwachen“ ein und liest so den Report.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, wenn die Anwendung Textinhalte oder Daten enthält, die durch Attribute ausgezeichnet sind.

Begründung

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

Textattribute wie fett, kursiv und unterstrichen heben einzelne Wörter oder Textabschnitte hervor und kennzeichnen sie dadurch als besonders wichtige Teile eines Textes. In der Datenverarbeitung ist es üblich, einzelnen Daten durch ein Textattribut eine bestimmte Bedeutung zuzuweisen. Diese Informationen müssen auch für blinde Benutzer zugänglich sein, da sie das Verständnis der Inhalte wesentlich beeinflussen. Screenreader stellen daher spezielle Funktionen zur Verfügung, um Textattribute je nach der gegebenen Situation gezielt abzufragen oder den Wechsel des Textattributs zu überwachen und automatisch anzusagen.

Prüfanleitung

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

Lesen Sie die Inhalte der Anwendung, und schalten Sie dabei im Screenreader die Funktionen zur Ausgabe von Textattributen ein. Je nach Situation kommen die folgenden Funktionen zum Einsatz (Anleitung für NVDA):

Automatische Ansage: Im NVDA Einstellungsdialog wählen Sie den Bereich "Dokumentformatierungen" aus. Dort aktivieren Sie "Schriftattribute ansagen" und bestätigen mit "OK".

Abfrage: In der Textverarbeitung setzen Sie die Einfügemarke in einen hervorgehobenen Bereich und drücken die Tastenkombination EINF+f.

Übersicht: Wenn Sie die Einfügen-Taste und dazu die Taste f zweimal kurz hintereinander drücken, erhalten Sie ein Meldungsfenster, in welchem alle Attribute zum Nachlesen angezeigt werden.

Bewertungsalternativen

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

Der Prüfschritt ist erfüllt, wenn die Attribute korrekt wiedergegeben werden.

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

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Referenzen

EN301549

11.3.2.10 Text

WCAG

WCAG-Techniques

ISO9241-171

Zuletzt bearbeitet

21.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Inhalte, die am Bildschirm in Blöcken neben- oder nacheinander angeordnet sind, werden vom Screenreader in korrekter, sinnentsprechender Reihenfolge ausgegeben.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Im Windows Explorer liest der Screenreader zunächst alle Zeilen der Baum-Ansicht und dann alle Zeilen der Detailansicht vor.

In einer synoptischen Darstellung von Textinhalten liest der Screenreader die linearisierten Zellinhalte vor, ohne dass logische Zusammenhänge auseinandergerissen werden.

Fehler: Ein Datenauszug ist in zwei nebeneinander stehenden Blöcken angeordnet, wobei links die Rechnungsanschrift und rechts die Lieferanschrift steht. Beim fortlaufenden Lesen gibt der Screenreader abwechselnd eine Zeile des linken und des rechten Blocks aus.

Fehler: Wenn ein Dialogfenster sich über den Inhalt legt, so vermischt der Screenreader den Text des Dialogs mit dem dahinter liegenden Inhalt.

Fehler: Beim fortlaufenden Lesen mit dem Screenreader entsteht eine erratische Reihenfolge, deren Sinn nicht nachvollzogen werden kann.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist anwendbar, wenn die Anwendung Inhalte in Blöcken anordnet.

Begründung

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

In der Programmierung von Anwendungen kann die programmtechnische Reihenfolge der Inhalte unabhängig von der am Bildschirm sichtbaren Anordnung sein, z.B. wenn eine absolute Positionierung durch Bildschirmkoordinaten erfolgt. Wenn eine Tabellenstruktur zum Layout einer synoptischen Darstellung verwendet wird, muss auf die Linearisierbarkeit der Zellinhalte geachtet werden. Wenn Anzeigetechniken verwendet werden, die keinen Gebrauch von den Systemroutinen des Betriebssystems machen, kann der Screenreader nur aus dem Bildschirmspeicher lesen, was eine zeilenweise Abbildung der Inhalte bewirkt. In solchen Fällen kann die Hilfstechnik die sichtbare logische Anordnung der Inhalte nicht nachvollziehen.  

Prüfanleitung 

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

Lesen Sie die Anwendung mit der Screenreaderfunktion „alles lesen“. Prüfen Sie, ob die Blöcke in einer sinnentsprechenden Reihenfolge vorgelesen werden. Falls dies nicht der Fall ist, stellen Sie fest, ob der Screenreader über einen alternativen Lesemodus verfügt, im NVDA wäre dies die Objektnavigation, und wiederholen Sie die Prüfung in diesem Modus.

Bewertungsalternativen

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

Die Anforderung ist erfüllt, wenn wenigstens in einem Screenreader-Modus eine sinnentsprechende Reihenfolge der blockweise angeordneten Inhalte wiedergegeben werden kann.

Mängel werden nach der Bedeutung der gestörten Information für die Arbeitsaufgabe bewertet.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

In diesem Prüfschritt geht es um das Lesen von Inhaltsblöcken. Die sinnvolle Reihenfolge bei Bedienung wird im Prüfschritt 3.07.0 „Sinnvolle Fokus-Reihenfolge“ behandelt.  

Offene Fragen

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

Zu beobachten: Alternativ zum Screenreader könnte auch Inspect als Prüftool verwendet werden. Im Inspect wird die Anordnung der Inhaltsblöcke im Accessiblity-Tree abgebildet, was auf einfachere Weise eine Überprüfung der sinnvollen Reihenfolge erlauben könnte.

Referenzen

EN301549

11. 2.1.8. Meaningful sequence

WCAG

1.3.2 Bedeutungstragende Reihenfolge

WCAG-Techniques

F49 Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized

ISO9241-171

BITV-Test

1.3.2a  Layouttabellen linearisierbar

Zuletzt bearbeitet

28.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

In Datentabellen sagt der Screenreader in jeder Zelle die Zeile und Spalte an, ebenso Zeilen- und Spaltenüberschriften, soweit diese vorhanden sind.

Datentabellen sind einfach strukturiert, so dass der blinde Benutzer den Inhalt nachvollziehen kann. 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

In einer Tabelle sagt der Screenreder in jeder Zelle die Zeilen- und Spaltennummer an, z.B. „Zeile 2 Spalte 3“.

Wenn Überschriften vorhanden sind, sagt der Screenreader die Überschrift vor jedem Zellinhalt an. Beispiel: „Monat: April, Bearbeiter: Meier“. Bei der Bewegung durch die Tabelle dürfen gleichbleibende Überschriften unterdrückt werden.

Fehler: Die Tabelle ist nicht zellenweise navigierbar.

Einschränkung: Der Screenreader behandelt Überschriften wie Daten, sagt sie also nur einmal an und wiederholt sie nicht bei jeder Zelle.

Fehler: Überschriften sind nicht vorhanden, obwohl die Daten nicht aus sich selbst verständlich sind. Beispiel: „Spalte 2: 45“ (=Schuhgröße), „Spalte 3: 49“ (=Alter).

Fehler: Die Daten verändern ihre Bedeutung, ohne dass dies durch neue Überschriften explizit gemacht wird.

Fehler: Ein Bedeutungswandel wird ausschließlich durch leere Tabellenzeilen angedeutet.

Fehler: Die Tabelle ist stark verschachtelt, so dass die Zeilen- und Spaltennummern vom blinden Benutzer nur mit Mühe nachvollzogen werden können.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist anwendbar, wenn die Anwendung Daten in Form von Tabellen präsentiert.

Begründung

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

Für blinde Menschen bedarf es zur Orientierung in Tabellen eines besonderen Abstraktionsvermögens. Zweidimensionale Darstellungen müssen klar in Zeilen und Spalten erfassbar sein. Einfach strukturierte Datentabellen sind für Screenreadernutzer leicht nachvollziehbar. Überschriften sind nicht immer erforderlich, denn oftmals sind die Inhalte der Zellen für sich selbst verständlich. Wenn aber die Bedeutung der Zellinhalte für sich genommen nicht eindeutig ist, sind Überschriften erforderlich. Überschriften helfen auch bei komplexen Tabellen, die mehr als eine logische Ebene abbilden. Diese können durch die Zuordnung der Zellen zu ihren jeweiligen Überschriften für Screenreadernutzer verständlich gemacht werden.

Anders liegt der Fall bei flächigen Darstellungen von Textinhalten, die eigentlich Synopsen sind. Die Tabellenstruktur wird hier zu Layoutzwecken genutzt, es kommen leere und verbundene Zellen vor. Solche Darstellungen können von Screenreadernutzern nur in linearisierter Form nachvollzogen werden, siehe Prüfschritt 4.07.1 „Korrekte Leseabfolge von Inhalten“. Ob eine flächige Darstellung als Tabelle oder als Synopse einzustufen ist, kann anhand einer Faustregel beurteilt werden: Wenn Überschriften erforderlich sind, um den Zellinhalt zu verstehen, muss es als Datentabelle behandelt werden. Wenn die Zellinhalte für sich selbst sprechen, kann es auch eine Synopse sein. Wenn zusätzlich grafische Elemente wie Pfeile etc. enthalten sind, ist es eine multimediale Darstellung, siehe Prüfschritt 1.10.0 „Alternativen für Abbildungen und Multimedia-Inhalte“.

In der Praxis kommen viele Zwischenformen der flächigen Darstellung von Daten vor, die durch eine eingehendere Analyse der Datenstruktur vermieden werden könnten. Von barrierefreien Anwendungen ist zu erwarten, dass sie eine für Screenreadernutzer nachvollziehbare Darstellung finden.

Prüfanleitung

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

Bewegen Sie den Fokus des Screenreaders in die Tabelle, und stellen Sie fest, ob der Tabellenmodus angesagt wird. Die Screenreader-Shortcuts zur Navigation in der Tabelle sind üblicherweise STRG+ALT+Pfeiltasten. Können Sie sich damit zellenweise auf- und abwärts sowie seitwärts durch die Tabelle bewegen? Werden dabei Zeilen- und Spaltennummern angesagt? Falls Überschriften vorhanden sind, werden diese bei jeder Zelle angesagt?

Bewegen Sie sich mit den Screenreader-Shortcuts durch die Tabelle und stellen Sie fest, ob die unter Beispiele dargestellten Gestaltungsregeln eingehalten werden.

Bewertungsalternativen

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

Erfüllt: Datenzellen wie auch Überschriften werden erwartungsgemäß wiedergegeben.

Barriere: Die Daten erfordern eine Tabellenstruktur, der Screenreader gibt aber nur lineare Inhalte aus.

Einschränkung: in einer einfach strukturierten Tabelle sind Überschriften vorhanden, die aber nur in der ersten Zeile bzw. Spalte wiedergegeben werden.

Weitere Mängel werden nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Synopsen werden im Prüfschritt 4.07.1 „Korrekte Leseabfolge von Inhalten“ behandelt.

Offene Fragen

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

Referenzen

EN301549

11.2.1.7 Info and relationships

11.3.2.6 Row, column, and headers

WCAG

1.3.1 Info und Beziehungen

WCAG-Techniques

H43 Using id and headers attributes to associate data cells with header cells in data tables

H63 Using the scope attribute to associate header cells and data cells in data tables

BITV-Test

1.3.1e  Datentabellen richtig aufgebaut

1.3.1f  Zuordnung von Tabellenzellen

ISO9241-171

8.5.10 Angemessene Darstellung von Tabellen ermöglichen

Zuletzt bearbeitet

28.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Bei der Bedienung der Anwendung erhält der Benutzer fortlaufend Rückmeldung über alle von ihm vorgenommenen Änderungen, einschließlich der bearbeiteten Inhalte, der vorgenommenen Selektionen, der aktuellen Position des Fokus und dem Status von Bedienelementen und Anzeigen.

Der Benutzer wird benachrichtigt über Ereignisse, die außerhalb seines aktuellen Fokus und ohne seine unmittelbare Veranlassung geschehen, wie etwa das Erscheinen von Systemmeldungen, die automatische Aktualisierung von Inhalten, etc. Der Benutzer muss nicht benachrichtigt werden über Änderungen, die durch seine explizite Aktion geschehen und sich bei sequentieller Abarbeitung nahe unterhalb seiner aktuellen Position befinden.

Rückmeldungen und Benachrichtigungen sollen für die Benutzerinteraktion relevant sein und den Benutzer nicht stören.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Bei der Auswahl von Einträgen in einer Mailbox erhält der Benutzer die Rückmeldung „ausgewählt“ oder „markiert“.

Beim Formatieren eines Textes erhält der Benutzer ständig Rückmeldung darüber, welche Formatvorlage er gerade ausgewählt hat, welche Formatierung er vorgenommen hat, etc.

In einer Dokumentensuche erscheint in einer Meldungszeile die Warnung, dass zunächst die zu durchsuchenden Datenbanken ausgewählt werden müssen, bevor die Suchanfrage beantwortet werden kann. Der Screenreader liest die Meldung sofort vor.

Während der Bedienung einer Anwendung erscheint eine Sprechblase, die das Eintreffen einer neuen E-Mail bekannt gibt. Der Screenreader liest die Sprechblase vor, sobald die aktuelle Benutzeraktion abgeschlossen ist.

Der fortlaufend sich ändernde Inhalt eines Börsentickers wird vom Screenreader nicht vorgelesen, um die zugleich erforderliche Programmbedienung nicht zu stören.

Einschränkung: Die Anwendung versetzt den Tastaturfokus, aber der Screenreader sagt erst beim nächsten Tastendruck des Benutzers die neue Position an.

Fehler: Eine Systemmeldung erscheint, aber der Screenreader gibt zunächst eine große Menge anderer Informationen aus, die der Benutzer abbricht, so dass er die Systemmeldung nicht bemerkt.

Fehler: In einem Chatprogramm wird beim Erscheinen neuer Beiträge der gesamte Inhalt vorgelesen. Richtig wäre, nur den neu erschienenen Beitrag vorzulesen.

Kein Fehler: Ein Formular blendet zusätzliche Eingabefelder ein, nachdem eine Optionsschaltfläche ausgewählt wurde. Die neuen Eingabefelder erscheinen unterhalb der Optionsschaltflächen, der Tastaturfokus bleibt bei den Optionsschaltflächen stehen. Der Screenreader sagt „[Name der Option] ausgewählt“ und gibt nicht die neu erschienenen Bedienelemente aus.
Fehler: Wie zuvor, aber die neuen Eingabefelder erscheinen oberhalb der Optionsschaltflächen, wo sie bei kleinem Bildausschnitt und sequentieller Bedienung nicht wahrgenommen werden.

Fehler: In einer Bestellfunktion sind die verfügbaren Produkte samt Produktbeschreibung als Tabelle dargestellt. Der Benutzer wählt die gewünschten Produkte durch ein Kontrollkästchen aus und fügt dann alle ausgewählten Produkte durch einen Funktionsbutton zum Warenkorb hinzu. Der Screenreader meldet die Änderung im Warenkorb, indem er den vollständigen Inhalt aller hinzugefügten Produktbeschreibungen vorliest. Die Art der vollzogenen Aktion wird nicht quittiert. Eine sinnvolle Rückmeldung wäre etwa die Benachrichtigung „xx Produkte zum Warenkorb hinzugefügt“.

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]

Alle Änderungen an den Inhalten und der Bedienoberfläche einer Anwendung, egal ob vom Benutzer oder von einer anderen Instanz veranlasst, sollen vom Benutzer wahrgenommen werden können, damit er seine Aktionen kontrollieren und auf Ereignisse angemessen reagieren kann. Der Screenreader hat die nicht triviale Aufgabe, die vom System ausgegebenen Daten entsprechend zu filtern, damit weder zuwenig noch zuviel Information beim Benutzer ankommt. Die Anwendung hat die Aufgabe, angemessene Informationen bereitzustellen, z.B. durch die Ausgabe von Meldungen oder durch die Definition von Überwachungsbereichen.

Ein kritischer Fall ist z.B. die Rückmeldung von Benutzeraktionen, die in einem anderen Funktionsbereich des Bildschirms abgebildet werden. Denn während der vollsichtige Benutzer ohne weiteres sieht, was er getan hat, benötigt der blinde oder hochgradig sehbehinderte Benutzer, der nur einen kleinen Ausschnitt wahrnimmt, ggf. eine Erfolgsmeldung zur Quittierung seiner Aktion. Eine gemeinsame Lösung findet sich u.a. in responsiven Verfahren, die auf verschieden große Displays eingerichtet sind.

Einige Gestaltungsprobleme, die aus der dynamischen Änderung von Inhalten resultieren, können auch durch die Mitführung des Tastaturfokus behoben werden, siehe Prüfschritt 3.07.0 „Sinnvolle Fokus-Reihenfolge“.

Prüfanleitung

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

Beobachten Sie die durch die Arbeitsschritte des Szenarios hervorgerufenen Änderungen, wie geänderte Darstellung, geänderte Inhalte, das Erscheinen von Meldungen aller Art. Werden alle Änderungen angemessen vom Screenreader wiedergegeben?

Ggf. ergänzen Sie das Szenario um Gelegenheit zur Überprüfung von Meldungen, z.B. indem Sie den Empfang einer E-Mail provozieren.

Sofern es keine Rückmeldung gibt, prüfen Sie, ob die Meldung durch eine Bewegung der Pfeiltasten (ein Tastendruck in jede Richtung) gefunden werden kann.

Sofern es gar keine Rückmeldungen gibt, prüfen Sie, ob der Screenreader in den Ausführlichkeitseinstellungen korrekt konfiguriert ist, und wiederholen Sie ggf. die Prüfung.

Bewertungsalternativen

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

Wenn die Rückmeldung durch einen zusätzlichen Tastendruck gesucht werden muss, so ist dies eine Einschränkung. 

Weitere Mängel werden nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.
 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Die generelle Behandlung von Bewegung und dynamischen Änderungen, z.B. das Ausstellen von störenden Änderungen, ist in den Prüfschritten 1.03.0 „Verzicht auf Bewegung, Blinken und Flackern“ und 2.03.1 „Bewegte Inhalte sind steuerbar“ beschrieben.

Änderungen, die durch einen mitgeführten Tastaturfokus auf sich aufmerksam machen, werden im Prüfschritt 3.07.0 „Sinnvolle Fokus-Reihenfolge“ behandelt.

Änderungen, die durch bloße Navigationsbewegungen des Benutzers entstehen, werden im Prüfschritt 3.08.1 „Keine unerwartete Kontextänderung“ behandelt.

Offene Fragen

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

Referenzen

EN301549

11. 2.1.38: Name, role, value

11.3.2.15 Change notification

WCAG

4.1.2 Name, Rolle, Wert

WCAG-Techniques

ISO9241-171

8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen

Sonstige

WAI-ARIA Authoring Practices 1.1 Kapitel 6.2 Implementing Live Regions

Zuletzt bearbeitet

25.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Der Screenreader gibt Bedienoptionen und Tastaturkommandos aus, die in der aktuellen Programmsituation zur Verfügung stehen.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Nach Drücken der Alt-Taste können die Ausklappmenüs der Anwendung genutzt werden. Die Tastaturkommandos für den jeweiligen Befehl stehen rechtsbündig hinter der jeweiligen Menüauswahl. Der Screenreader liest den ausgewählten Punkt wie auch das dazu gehörende Tastaturkommando vor.

Die Multifunktionsleiste der Textverarbeitung wird angesteuert und einzelne Bediensymbole werden mit dem Screenreader fokussiert. Der Hilfetext, der bei Mausnutzung unterhalb des Symbols erscheint, wird vollständig ausgegeben.

Eine Auswahlliste kann mit einer bestimmten Tastenkombination geöffnet und mit den Pfeiltasten navigiert werden. Die Eingabe kann mit Enter bestätigt werden. Die Vorgehensweise wird präzise von der Screenreader-Ausgabe beschrieben, sobald das Element den Fokus erhalt.

Ein Content-Management-System hat ein Seitenverzeichnis, in dem Informationen zum Bearbeitungsstand wie „nicht öffentlich“ und „zum Löschen vorgemerkt“ durch Farbe und Textattribut (grau kursiv, rot durchgestrichen) codiert sind. Diese Informationen sind in der Accessibility-Schnittstelle als „Beschreibung“ dokumentiert und werden vom Screenreader bei Fokussierung des Elements ausgegeben.

Fehler: In der Bedienoberfläche der Anwendung verfügbare kontextsensitive Hilfe wird vom Screenreader nicht ausgegeben.

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]

Für Benutzer von Screenreadern ist es besonders umständlich, Informationen zur Bedienung einer Software in der Dokumentation nachzuschlagen. Zudem fehlen ihnen Kontextinformationen, die sehende Benutzer aus der optischen Gestaltung der Bedienoberfläche gewinnen. Screenreaderbenutzer profitieren besonders von einer kontextsensitiven Hilfe direkt bei der Bedienung.

Der Screenreader muss bei der Fokussierung von Bedienelementen mindestens die in der Bedienoberfläche der Software verfügbaren Erläuterungen zu Tastaturbefehlen und zur Bedeutung von Bedienelementen ausgeben. Weitere Hilfestellungen soll er aus der Rolle des Elements ableiten, wie etwa die Anweisung „Eingabefeld, geben Sie Text ein“. Die Anwendung kann weitere Hilfen speziell für nicht sehende Benutzer zur Verfügung stellen. In der Accessibility-Schnittstelle gibt es eine Vielzahl von Feldern wie Hilfetext, Beschreibung, Standard-Aktion, Tastenkürzel, die für differenzierte Hilfen genutzt werden können.

Prüfanleitung

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

Stellen Sie fest, welche kontextsensitiven Hilfen die Anwendung direkt in der Bedienoberfläche oder durch Tooltipp abrufbar gibt. Werden sie vom Screenreader bei Fokussierung des Elements wiedergegeben?

Werden bei selten eingesetzten Bedienelementen Informationen zur Bedienung gegeben?

Stellen Sie fest, welche weiteren Elemente für nicht sehende Benutzer erklärungsbedürftig sind. Werden Hilfetexte gegeben?

Wenn keine Hilfetexte ausgegeben werden, prüfen Sie, ob der Screenreader in den Ausführlichkeitseinstellungen korrekt konfiguriert ist, und wiederholen Sie ggf. die Prüfung. 

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]

Referenzen

EN301549

11.3.2.5 Object Information

11.3.2.11 List of available actions

WCAG

3.3.5 Hilfe

WCAG-Techniques

ISO9241-171

Zuletzt bearbeitet

28.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Wenn die Anwendung in einer anderen Sprache als die Plattform verfasst ist, spricht die Sprachausgabe automatisch die Sprache der Anwendung.

Der Prüfschritt bezieht sich auf die Sprache der Anwendung, nicht auf den Sprachwechsel bei mehrsprachigen Inhalten.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Ein Benutzer hat sein Betriebssystem in deutscher Sprache konfiguriert. Ein internationaler Newsticker ist in englischer Sprache verfasst. Die Sprachausgabe wechselt in die englische Sprache, sobald der Benutzer den Newsticker öffnet.

Wenn der Benutzer zwischen mehreren offenen Anwendungen wechselt, wechselt die Sprache automatisch, sobald die zu prüfende Anwendung aktiv wird.

Fehler: Der Benutzer muss zunächst im Screenreader die Sprache umstellen, bevor er die Anwendung benutzen kann.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist anwendbar, wenn die Software in einer Fremdsprache verfasst ist.

Begründung

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

Screenreader verwenden verschiedene Sprachausgaben für die jeweiligen natürlichen Sprachen. Die Sprachausgabe bestimmt, ob die Texte einer Software (Beschriftungen, Meldungen, Anleitungen, Inhalte) richtig ausgesprochen werden. Die Sprache der Software soll programmatisch erkennbar sein, so dass der Screenreader automatisch die richtige Sprachausgabe wählen kann. Wenn der Benutzer eingreifen muss, um die Sprachausgabe umzuschalten, so behindert ihn dies in seinen Arbeitsabläufen.

Prüfanleitung

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

Stellen Sie sicher, dass der Screenreader alle benötigten Sprachen installiert hat, und dass in den Einstellungen des Screenreaders die automatische Sprachumschaltung gewählt ist.

Erprobung: Wechselt der Screenreader automatisch die Sprache, wenn die fremdsprachige Anwendung aktiv wird?

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]

Referenzen

EN301549

11. 2.1.27 Language of software

WCAG

3.1.1 Sprache der Seite

WCAG-Techniques

ISO9241-171

-

Zuletzt bearbeitet

28.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Die Reaktionszeit des Systems wird durch den Betrieb eines Screenreaders nicht störend verlängert.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Fehler: Nach Installation und Inbetriebnahme eines Screenreaders kann in einer Textverarbeitung nur noch verzögert Text eingegeben werden. Nach jedem Tastendruck müssen Nutzer mehrere Sekunden warten, bis der gedrückte Buchstabe auf dem Bildschirm erscheint bzw. von der Sprache angesagt wird.

Fehler: Screenreader-Nutzer warten im Vergleich zu Nutzern ohne Hilfsmittel ungewöhnlich lange auf das Erscheinen der Hilfe-Funktion nach Druck auf die Taste F1.

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 direkte Reaktion des Systems auf Benutzereingaben ist eine Anforderung der allgemeinen Software-Ergonomie, die für flüssiges Arbeiten vorausgesetzt wird. Texteingaben sollen unmittelbar angezeigt werden. Für Antwortzeiten bei Dialogen gilt die Faustregel, dass Reaktionszeiten ab ca. 2 sec vom Benutzer als „Warten“ bemerkt werden, wobei ab ca. 4 sec eine Störung vermutet wird, wenn das System nicht explizit eine Wartezeit meldet.

Die Toleranz des Benutzers gegenüber Wartezeiten und allgemeiner Trägheit des Systems ist kontextabhängig. Im Rahmen dieses Prüfschritts geht es darum, dass das Reaktionsverhalten des Systems durch den Einsatz des Screenreaders nicht störend verlängert werden darf. Dies ist auch eine Qualität der Anwendung, denn wenn die Anwendung sehr viel ggf. ungefilterte Information an die Accessibility-Schnittstelle sendet, hat der Screenreader unnötig viel Arbeit.

Prüfanleitung

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

Sichtprüfung: Reagiert das System auf Benutzereingaben bei Dialogen und bei der Anzeige von eingegebenem Text im Vergleich mit der Sichtprüfung störend verzögert?

Die Beurteilung richtet sich nach der subjektiven Wahrnehmung des Testers:

Bei der Installation des Testsystems darauf achten, dass keine Hintergrundprogramme wie Virenscanner etc. installiert sind, die die Rechnerkapazität unnötig beanspruchen.

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 Beurteilung nach der subjektiven Wahrnehmung des Testers erscheint unbefriedigend, ist aber nach bisheriger Diskussion noch das praktikabelste Verfahren. Bisher bekannte Messtechniken sind unausgereift. Beispiele: Akustisches Tracking vom Tastendruck bis zur Screenreader-Ausgabe ist ungenau, da das Messen selber Zeit bzw. Rechnerkapazität braucht und das Ergebnis verfälscht. Auswertung von Log-Dateien: Zeit zwischen Fokuswechseln zu berechnen ist ungeeignet, denn die Anzeige erfolgt erst danach.

Referenzen

EN301549

- 

WCAG

WCAG-Techniques

ISO 9241-171

8.5.8 Der unterstützenden Technik den Zugriff auf Ressourcen ermöglichen

Sonstige

ISO 9241-112 Grundsätze der Informationsdarstellung, Abschnitt 6.1.3 Empfehlungen in Bezug auf die zeitliche Darstellung der Information

Zuletzt bearbeitet

10.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Alle Schriften der Anwendung können mit den Schriftgröße-Einstellungen der Plattform oder der Anwendung auf 200% vergrößert werden, ohne dass dabei Inhalt oder Funktionalität verloren gehen.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Die Anwendung ändert das Layout oder zeigt einen oder mehrere Rollbalken, wenn bei vergrößerter Schrift nicht mehr alle Inhalte in das Anwendungsfenster passen. Der Benutzer kann alle Bedienelemente und Inhalte mit dem Rollbalken lesen. Bei Tastaturbedienung folgt der Bildausschnitt dem Tastaturfokus automatisch in den zuvor nicht sichtbaren Bereich.

Ein Textverarbeitungsprogramm enthält eine Zoomfunktion, die den gesamten Text des Dokumentes auf mindestens 200% gegenüber den im Dokument festgelegten Schriftgrößen vergrößert. Der Benutzer kann mit dem Rollbalken den Text in seiner gesamten Breite lesen. Bei der Eingabe und Korrektur des Textes folgt der Bildausschnitt dem Eingabecursor.

Fehler: Bei vergrößerter Schrift werden die Zeichen der Anwendung am Bildschirm unscharf dargestellt.

Fehler: Bei vergrößerter Schrift sind Bereiche der Anwendung abgeschnitten oder überlagern sich, so dass der Benutzer sie nicht mehr lesen kann.

Fehler: Bei vergrößerter Schrift folgt der Bildausschnitt nicht dem Tastaturfokus, so dass der Anwender mit dem Rollbalken nachsteuern muss, um das fokussierte Element zu sehen.

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]

Benutzer sollen die Schriftgröße nach ihren Bedürfnissen einstellen können. Die Vergrößerung bis zu 200% unterstützt vor allem leicht sehbehinderte Benutzer, die noch keine assistierende Technik benötigen.

Auch im vergrößerten Zustand sollen alle Schriften scharf und gut lesbar sein, alle Inhalte und Funktionen der Anwendung sollen erreichbar und benutzbar sein.

In diesem Prüfschritt wird die grundlegende Vergrößerung geprüft. Hierfür reicht es aus, wenn die Vergrößerung durch eine Zoomfunktion erreicht wird, so dass die Bedienoberfläche der Anwendung das Anwendungsfenster seitlich überragt. Das relativ umständliche Seitwärtsscrollen muss in Kauf genommen werden.

Prüfanleitung

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

Die Schriftgröße und die Fenstergröße einstellen wie für den Standardbildschirm des Testsystems beschrieben.

Alle Schriften (Versalhöhe) sowie die Fenstergröße mit dem Keseling Bildschirmlineal (siehe Werkzeugliste) messen.

Nehmen Sie die im Folgenden genannten Einstellungen der Reihe nach vor und stellen Sie nach jedem Schritt fest, ob alle oder einige Schriften der Anwendung sich hierdurch auf mindestens 200‘%  der Ausgangsgröße einstellen lassen. Im Zweifel messen Sie nach und kalibrieren ggf. zuvor das Bildschirmlineal neu. Berücksichtigen Sie alle Schriften: Menüs, Beschriftungen, Meldungstexte, Daten. Sobald alle Schriften ausreichend vergrößert sind, beenden Sie die Einstellung (es müssen nicht alle Optionen angewandt werden).

• DPI-Einstellung auf das Doppelte erhöhen oder, falls das nicht möglich ist, so hoch wie möglich setzen. Falls die Schriften der Anwendung nun unscharf erscheinen, zuvor aber scharf waren, diese Einstellung rückgängig machen.
• In der Windows-Systemsteuerung im Dialog Fensterfarbe und -darstellung (Win7: Systemsteuerung-Anpassung-Fensterfarben-erweiterte Darstellungseinstellungen) für alle Elemente, die dies erlauben (Menü, Dialogfeld, ausgewählte Elemente etc.), den Schriftgrad einstellen.
• Falls vorhanden, Schriftgröße-Einstellung oder Zoomfunktion der Anwendung benutzen.
• Bildschirmauflösung herabsetzen unter Systemsteuerung-Anzeige-Auflösung anpassen (Win7).

Falls am Ende der Einstellung die Zeichen unscharf sind, so ist dies ein Mangel, der für die weitere Prüfung hingenommen werden muss.

Falls sich Einstellmöglichkeiten kumulieren, so dass einzelne Schriften nun mehrfach vergrößert sind, können soweit möglich zuvor getroffene Einstellungen zurückgenommen werden.

Falls einzelne Schriften zuvor schon groß waren und nach Vergrößerung nun Störungen verursachen, kann versucht werden, die Schriftgröße dieser Elemente gezielt zu vermindern. Große Schrift ist definiert im Prüfschritt 1.01.0 „Ausreichender Kontrast“.

Falls bei einer der vorgenommenen Einstellungen die Fenstergröße verändert worden sein sollte, mit Hilfe des Bildschirmlineals die anfangs gemessene Fenstergröße wiederherstellen.

Hiermit ist die Einstellung der Schriftgröße abgeschlossen. Es sollten alle Schriften auf mindestens 200% vergrößert worden sein.

Sichtprüfung und Erprobung:

• Sind alle Inhalte der Anwendung, Beschriftungen, Meldungstexte und Daten, sichtbar oder können mit dem Rollbalken sichtbar gemacht werden?
• Eingaben vornehmen und feststellen, ob der Bildausschnitt automatisch dem Tastaturfokus in den zuvor nicht sichtbaren Bereich folgt.

Bewertungsalternativen

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

Wenn wichtige Bereiche der Anwendung abgeschnitten sind, so dass der Benutzer sie nicht mehr lesen und bedienen kann, so ist dies eine Blockade. 

Wenn der Bildausschnitt nicht dem Tastaturfokus folgt, so dass der Anwender mit dem Rollbalken nachsteuern muss, um das fokussierte Element zu sehen, so ist dies eine Barriere.

Alle weiteren Mängel sind eine Einschränkung.

Wenn einzelne Schriften besonders unscharf oder pixelig sind, so ist dies ein Hinweis darauf, dass der Text als Bild abgelegt ist. Dies wird nicht hier gewertet, sondern im Prüfschritt 7.03.1 „Text als Text codieren“.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Bilder eines Textes sind Gegenstand des Prüfschritts 7.03.1 Text als Text codieren.

Weitergehende Anforderungen an die Vergrößerung werden im Prüfschritt 5.02.2 „Bei vergrößerter Darstellung Layout anpassen“ geprüft.

Offene Fragen

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

Referenzen

EN301549

11. 2.1.13 Resize text

11. 5. User Preferences

WCAG

1.4.4.Textgröße ändern.

WCAG-Techniques

ISO9241-171

10.3.2 Benutzern die Einstellung einer Mindestschriftgröße ermöglichen

Zuletzt bearbeitet

02.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Bei Schriftvergrößerung auf 200% passt sich das Layout an, so dass der Leser nicht horizontal scrollen muss, um einen Informationsblock im Anwendungsfenster zu lesen.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Menüzeilen brechen bei Schriftvergrößerung am Rande des Anwendungsfensters um und werden zwei- oder mehrzeilig.

Informationsblöcke, die zuvor nebeneinander standen, werden nach Schriftvergrößerung untereinander dargestellt.

Die Größe von Dialogboxen passt sich bei Schriftvergrößerung an, um den gesamten vergrößerten Inhalt anzeigen zu können.

Tabellen passen bei Schriftvergrößerung die Spaltenbreite an und brechen die Zellinhalte neu um, so dass sie in die Breite des Anwendungsfensters passen.

Breite Tabellen können konfiguriert werden, so dass der Benutzer auswählen kann, welche Spalten er sehen will.

Ein Textverarbeitungsprogramm enthält einen „Entwurfsmodus“, der den gesamten Text des Dokumentes in einer einzigen, vom Benutzer auswählbaren Schriftgröße anzeigt, ohne Rücksicht auf die im Dokument festgelegten Formatierungsangaben. In diesem Modus wird der Text auf Bildschirmbreite umgebrochen.

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]

Ein Text oder ein Datenblock ist nur schwer lesbar, wenn er den sichtbaren Bildausschnitt überragt und der Benutzer hin- und herscrollen muss, um den Inhalt vollständig zu erfassen. Wenn Bedienelemente außerhalb des sichtbaren Bildausschnittes angeordnet sind, werden sie von kognitiv beeinträchtigten Benutzern leicht übersehen. Daher soll die Software soweit möglich bei Schriftvergrößerung das Layout anpassen.

Diese Anforderung unterstützt auch Benutzer von Vergrößerungssoftware, die so die Vergrößerung der Anwendung zusätzlich nutzen können. Denn je kleiner der Zoomfaktor in der Vergrößerungssoftware, desto größer die Übersicht über die Anwendung. Wenn jedoch die Anwendung bei Vergrößerung einen waagerechten Rollbalken zeigt, müsste der Benutzer zwei Bildausschnitte steuern, was den gewünschten Effekt zunichte macht.

Prüfanleitung

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

Sichtprüfung im Anschluss an den Prüfschritt 5.01.1 „Schriftvergrößerung auf 200%“. Bei waagerechten Rollbalken ist zu überprüfen, ob es sich um einen überbreiten Inhalt handelt, dessen Layout nicht angepasst werden kann.

Bewertungsalternativen

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

Mängel sind eine Einschränkung.

Wenn überbreite Inhalte (Tabellen, Bilder) gescrollt werden müssen, so ist dies kein Mangel.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Referenzen

EN301549

-

WCAG

1.4.8 Visuelle Präsentation

WCAG-Techniques

ISO9241-171

10.3.3 Bei Änderung der Schriftgröße den Maßstab und das Layout von Benutzungsschnittstellen-Elementen im Verhältnis anpassen

10.5.8 Erneute Einstellung der Fenstergröße ermöglichen

Zuletzt bearbeitet

02.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Die Anwendung kann in dem von der Plattform bereitgestellten Kontrastmodus ohne wesentliche Einschränkungen genutzt werden.

Sofern die Anwendung ein eigenes Farbschema nutzt, ist es mit dem Windows Kontrastmodus gleichwertig. Das Farbschema erlaubt es, Vorder- und Hintergrundfarben für alle textbasierten Elementtypen (Daten, Menüs, Links etc.) separat einzustellen.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Im Kontrastmodus sind alle Elemente der Anwendung erkennbar.

Alle Textelemente übernehmen die voreingestellten Farben für Vorder- und Hintergrund der Zeichen, mit Ausnahme von Logos (Schrift-/Bildmarken). Fehler: Texte sind als Grafik abgelegt, die sich im Kontrastmodus nicht anpassen.

Einfarbige Grafiken werden vermieden. Icons haben eine Hintergrundfarbe oder ein mehrfarbiges Motiv.

Eine Anwendung stellt einen Styleswitcher zur Verfügung, mit dem helle oder dunkle Icons ausgewählt werden können, die mit den im Windows Kontrastmodus eingestellten Hintergrundfarben ausreichend kontrastieren.

Eine Anwendung verwendet farbige Rechtecke als Farbmarkierung für verschiedene Inhalte. Die Farben sind als Grafiken gespeichert, damit sie im Kontrastmodus erhalten bleiben, und mit einem Rahmen umgeben, damit sie gegen jeden Hintergrund erkennbar sind.

Bedienelemente und Daten, soweit sie in der Normalansicht optisch unterscheidbar sind, sind auch im Kontrastmodus unterscheidbar.

Die Anwendung kennzeichnet Bedienelemente mit Rahmenlinien, die auch im Kontrastmodus erscheinen.

Der Status von Bedienelementen (ausgewählt, aktives Element, nicht verfügbar), soweit er in der Normalansicht optisch unterscheidbar ist, ist auch im Kontrastmodus unterscheidbar.

Die Anwendung gestaltet Statusmarkierungen mit Grafiken, Rahmenlinien oder Unterstrichen, die auch im Kontrastmodus erscheinen.

Der Tastaturfokus und der Eingabecursor sind erkennbar. Eine Selektion (Markierung) ist erkennbar.

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]

Menschen mit Sehbehinderungen wie Farbfehlsichtigkeit, erhöhter Blendempfindlichkeit oder erhöhtem Kontrastbedarf profitieren davon, wenn sie sich die Farben am Bildschirm nach ihren individuellen Anforderungen einstellen können. Sie wählen dann z,B. einen dunklen Hintergrund oder spezielle Farbkontraste. So können sie beschwerdefrei arbeiten und oftmals auch die Vergrößerung geringer einstellen, so dass sie einen besseren Überblick über die Anwendung gewinnen.

Im Windows Kontrastmodus können die Vorder- und Hintergrundfarben von textbasierten Elementtypen vom Benutzer frei gewählt werden. Dabei fallen die in der Normalansicht gesetzten Farbunterschiede, Hintergrundfarben und Hintergrundbilder weg, mit denen Hinweise auf die Rolle und den Status  von Bedienelementen gegeben werden. Diese Merkmale müssen in der Programmierung gesetzt sein bzw. dürfen nicht deaktiviert werden, damit der Elementtyp erkannt und im Kontrastmodus wie gewählt dargestellt werden kann. Standardelemente des Betriebssystems erfüllen im Prinzip diese Anforderungen, während bei individuell erstellten UI-Elementen der Programmierer bzw. das verwendete UI-Framework dafür sorgen muss.

Grafiken bleiben im Windows Kontrastmodus unverändert. Sie müssen so gestaltet sein, dass sie mit der individuell gewählten Hintergrundfarbe zusammenpassen. Grafische Schriften, deren Farben sich im Kontrastmodus nicht anpassen, sollten nur für Logos verwendet werden. Kontraproduktiv sind vor allem größere Flächen mit grafischer Schrift, deren Hintergrund gegen die gewählte Hintergrundfarbe kontrastiert und somit einen optischen Störeffekt hervorruft.

Manche Anwendungen nutzen den Windows Kontrastmodus nur für die Menüs und die Statuszeile, während sie für den Dokumentteil eigene Farbschemata anbieten. Hierbei ist zu beachten, dass das anwendungseigene Farbschema dieselben Einstellmöglichkeiten wie der Windows Kontrastmodus bietet. Nicht gleichwertig ist ein Farbfilter, der z.B. alle Farben invertiert oder in Graustufen umwandelt. Hierbei werden zwar die Grafiken und Hintergrundfarben mit einbezogen, jedoch kann nicht immer der gewünschte Effekt erzielt bzw. für alle Elemente ein ausreichender Kontrast eingestellt werden.

Prüfanleitung

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

Den Windows Kontrastmodus einschalten mit SHIFT (links) + ALT (links) +DRUCK. Falls die Anwendung nicht mit einem durchgängigen Farbwechsel darauf reagiert, feststellen, ob die Anwendung eine eigene gleichwertige Einstellmöglichkeit anbietet, und diese nutzen. Andernfalls Abbruch des Prüfschritts.

Sichtprüfung und praktische Erprobung (TAB, Markierung von Daten, Texteingabe): sind die in den Beispielen dargestellten Gestaltungsregeln eingehalten?

Bewertungsalternativen

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

Blockade: Die Anwendung übernimmt nicht die Farben des Windows Kontrastmodus und bietet auch keine eigene Farbwahl. 

Blockade: Im Kontrastmodus ist der Tastaturfokus über mehr als drei TAB-Schritte nicht erkennbar.

Blockade: Im Kontrastmodus sind markierte Daten nicht unterscheidbar oder nicht erkennbar.

Barriere: Wichtige Bereiche der Anwendung übernehmen nur die Vordergrundfarbe oder nur die Hintergrundfarbe des Kontrastmodus, so dass die individuelle Farbwahl nicht frei gestaltet werden kann.

Barriere: Texte von mehr als 8 Wörtern sind eine Grafik, deren Farben sich nicht anpassen.

Barriere: Flächen von mehr als 1/6 des Anwendungsfensters (siehe Testausstattung, Standardbildschirm) sind eine Grafik, deren Farben sich nicht anpassen. Ausnahme: Die Grafik ist eine Infografik und gehört zum Datenbereich der Anwendung.

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. 5. User Preferences

WCAG

1.4.8 Visuelle Präsentation: Vorder- und Hintergrundfarben können vom Benutzer ausgewählt werden.

WCAG-Techniques

ISO9241-171

10.4.2 Für Behinderte entwickelte Farbschemata zur Verfügung stellen

10.4.3 Individualisierung der Farbschemata ermöglichen

10.4.4 Benutzern die Individualisierung der Farbkennzeichnung ermöglichen

Zuletzt bearbeitet

07.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Im Großbildsystem folgt die Anzeige den Aktionen des Benutzers mit Tastatur und Maus, so dass der Tastaturfokus bzw. der Eingabecursor jederzeit im vergrößerten Bildausschnitt zu sehen ist. 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Der Bildausschnitt folgt, wenn der Benutzer

• den Bildausschnitt mit der Maus über den Bildschirm führt, um alle Inhalte zu lesen
• mit TAB durch die Bedienelemente geht
• mit einem Tastenbefehl Funktionsbereiche gezielt anspringt, z.B. das Hauptmenü und den Datenbereich der Anwendung
• Dialoge öffnet und schließt
• lange Inhalte mit den Rollbalken oder mit SEITE AUF/AB über den Bildschirm rollt
• Daten mit Maus oder Tastatur markiert, über den Rand des Bildausschnitts hinweg
• lange Eingaben macht, über den Rand des Bildausschnitts hinweg.

Der Bildausschnitt folgt bei Systemmeldungen, die eine Benutzeraktion erfordern, z.B. Dialogboxen.

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]

Menschen mit Sehbehinderungen, die ein Großbildsystem nutzen, sehen je nach ihrem benötigten Vergrößerungsfaktor nur einen mehr oder weniger kleinen Ausschnitt des Bildschirms. Bei 4-facher Vergrößerung sehen sie nur 1/16 des Originalbildes. Die Vergrößerungssoftware unterstützt den Benutzer durch verschiedene Funktionen dabei, sich in der Anwendung zu orientieren. Hierzu gehört die Fokusverfolgung.

Der Benutzer wechselt zwischen dem Steuern des vergrößerten Bildausschnitts und der Programmbedienung hin und her. Wenn der Benutzer Eingaben macht – Menüs und Buttons aktiviert, Dialoge öffnet und schließt, Inhalte markiert, Daten erfasst – soll die Vergrößerungssoftware die Steuerung des vergrößerten Ausschnitts übernehmen und den Aktionen des Benutzers folgen, so dass der Benutzer jederzeit den Ort des Geschehens sehen kann. Wenn die Vergrößerungssoftware dies nicht kann, muss der Benutzer den Ausschnitt während der Programmbedienung nachsteuern, was den Arbeitsfluss unterbricht und hohe Konzentration erfordert, oder in manchen Fällen auch kaum leistbar sein kann.

Anwendungselemente, die mit Standardroutinen des Betriebssystems erzeugt wurden, übermitteln den Tastaturfokus bzw. die Selektionsmerkmale normalerweise automatisch an die Hilfstechnik. Dagegen muss bei individuell entwickelten Elementen der Programmierer bzw. das eingesetzte Framework dafür sorgen.

In der Prüfung wird ein Vergrößerungsfaktor von 400% eingesetzt. Dieser Wert markiert in etwa die Grenze einer sinnvollen Vergrößerung, wenn Vergrößerung die einzige von einem Benutzer eingesetzte assistierende Technologie ist. In der Praxis kommen stärkere Vergrößerungen vor, die aber mit anderen Hilfen wie Sprachausgabe kombiniert sein sollten. 

Benutzer von Großbildsystemen setzen normalerweise Tastatur und Maus kombiniert zur Programmbedienung ein und entwickeln dabei ihren persönlichen Arbeitsstil. In der Prüfung werden mehrere Aspekte des Abschnitts III Tastaturbedienung wieder aufgegriffen, jedoch abgewandelt durch die Kombination mit Mausbedienung und Ausschnittvergrößerung. Daher werden die Ergebnisse dieses Prüfschritts unabhängig von anderen gewertet.

Prüfanleitung

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

Die Schriftgröße und die Fenstergröße einstellen wie für den Standardbildschirm des Testsystems beschrieben. Das ausgewählte Großbildsystem (siehe Testsystem) starten. Die Vergrößerung auf Faktor 4 einstellen (400%). Die Anwendung starten.

Praktische Erprobung: Folgt die Anzeige den Bedienschritten des Szenarios? Dabei die Bedienung zwischen Maus und Tastatur wechseln. Die unter Beispiele genannten Fälle berücksichtigen.

Im Zweifelsfall die Vergrößerung ausschalten, den Bedienschritt wiederholen und dabei die Fokusreihenfolge feststellen, die Vergrößerung wieder einschalten und die Fokusverfolgung des Großbildsystems erneut überprüfen.

Bewertungsalternativen

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

Mängel sind eine Barriere oder eine Einschränkung, je nachdem wie einfach der Fokus nach dem Abhängen des vergrößerten Ausschnitts wiederzufinden ist. 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Referenzen

EN301549

11.3.2.13 Tracking of focus and selection attributes

11.3.2.15 Change notification

WCAG

WCAG-Techniques

ISO9241-171

8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen

Zuletzt bearbeitet

08.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Im Großbildsystem werden Textzeichen in allen Vergrößerungsstufen mit glatten Konturen angezeigt.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Fehler: Nur schwarze Textzeichen auf weißem Grund haben glatte Konturen. Textzeichen in anderen Farben erscheinen pixelig/stufig.

Fehler: Bei manchen Textzeichen sind die Konturen glatt, aber die Form ist stark verzerrt, so dass der Buchstabe kaum wiederzuerkennen ist.

Fehler: Manche Textzeichen berühren oder überlagern sich.

Fehler: Die vergrößerten Textzeichen werden unscharf dargestellt.

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]

Klare, scharfe Konturen sind wichtig für gute Lesbarkeit von Zeichen. Ein wichtiges Qualitätsmerkmal bei Großbildsystemen ist daher die Kantenglättung der vergrößerten Textzeichen. Hierzu sind heute die folgenden Techniken im Einsatz:

1. Die Font-Substitution ersetzt die Zeichen durch einen größeren Font. Dies ergibt an sich saubere Zeichen. Da aber die Position jedes Zeichens neu berechnet werden muss, können Fehler entstehen, so dass Zeichen sich berühren oder überlagern können.
2. Die Kantenglättung i.e.S. basiert auf der Vektorisierung, ein Verfahren der grafischen Mustererkennung. Aus den Farbkontrasten der Bildpunkte werden Ecken ermittelt und durch interpolierende Konturen verbunden. Dabei wird das zugrundeliegende Zeichen mehr oder weniger gut nachgebildet. Die neu entstandene Vektorgrafik kann ohne Qualitätsverlust vergrößert werden. Das Verfahren wirkt auf Fonts ebenso wie auf grafische Schriften und Symbole. Wegen der Rechenintensität wird die Kantenglättung oftmals auf schwarz-weiße Schriften begrenzt, während farbige Schrift pixelig/stufig erscheint.
3. Das Anti-Aliasing ist ein Kantenglättungsverfahren für Rastergrafiken. Der Treppeneffekt bei schrägen und runden Linien wird abgeschwächt, indem ein Farbübergang zwischen Vorder- und Hintergrundfarbe eingesetzt wird. Als Nebeneffekt muss eine Unschärfe in Kauf genommen werden, die sich je nach Auflösung und Vergrößerungsfaktor mehr oder weniger stark bemerkbar macht.

Aus Anwendersicht sollte das Verfahren der Wahl für die Vergrößerung von Schrift die Font-Substitution sein. Dieses Verfahren ist heute jedoch nicht mehr sehr verbreitet, denn es wird vom Betriebssystem schlecht unterstützt. Die zugrundeliegende Routine, die die Fonts auf den Bildschirm schreibt, ist keine Schnittstelle mit verbindlichem Standard, die Codierung in Windows ist wechselhaft. So muss die Font-Substitution in Großbildsystemen bei jedem Versionssprung der Plattform- bzw. Anwendungssoftware nachgearbeitet werden.

Die heute üblichen grafischen Verfahren der Kantenglättung sind an sich eine Leistung des Großbildsystems und nicht der Plattform oder der Anwendungssoftware. Daher stellt sich die Frage, ob dieser Prüfschritt in einem Verfahren zur Prüfung von Anwendungssoftware unter Windows seinen Platz hat. Ein Argument dafür ist, dass der Status quo nicht befriedigend ist. Die Leistung der Kantenglättung bei Vergrößerung sollte in das Betriebssystem aufgenommen und von der Anwendungssoftware, z.B. durch Auswahl geeigneter Fonts, unterstützt werden.

Die Anforderung „Kantenglättung bei Vergrößerung“ wird allerdings bisher von den Standards nur schwach unterstützt. In ISO 9241-303 „Anforderungen an elektronische optische Anzeigen“ wird auf die Rasterung von Zeichen eingegangen, die für eine gute Lesbarkeit nicht zu grob und jedenfalls nicht sichtbar sein sollte. Gute Lesbarkeit bei Vergrößerung ist in keinem Standard explizit ausgeführt. WCAG 1.4.4. „Vergrößerung auf 200%“ und WCAG 1.4.5 „Bilder eines Textes“ gehen implizit davon aus, dass bei der Vergrößerung von Text klare Konturen entstehen, während Grafiken nur auf Pixelebene vergrößert werden können und entsprechend grob gerastert erscheinen. Wie gezeigt wurde, gilt diese klare Unterscheidung für Großbildsysteme heute nicht mehr. Eine Fortentwicklung der Standards erscheint notwendig, um die Anforderung für die Fortentwicklung der Betriebssysteme relevant zu machen.

Prüfanleitung

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

Die Schriftgröße und die Fenstergröße einstellen wie für den Standardbildschirm des Testsystems beschrieben. Das ausgewählte Großbildsystem (siehe Testsystem) starten. Die Vergrößerung auf Faktor 4 einstellen (400%). Die Anwendung starten.

Sichtprüfung: sind die unter Beschreibung und Beispiele genannten Anforderungen erfüllt?

Wiederholung der Prüfung mit Vergrößerungsfaktor 2 (200%) und 6 (600%).

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]

Angesichts des Stands der Technik wäre zu diskutieren, ob der Prüfschritt bewertet werden soll, oder ob Mängel nur mit beratender Funktion protokolliert werden sollen. 

Referenzen

EN301549

-

WCAG

WCAG-Techniques

ISO9241-171

-

Sonstige

ISO 9241-303 Anforderungen an elektronische optische Anzeigen 

Zuletzt bearbeitet

08.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Die Anwendung übernimmt die in der Plattform eingestellten Eingabehilfen für Tastatur und Maus.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Folgende in der Windows Systemsteuerung eingestellten Eingabehilfen funktionieren in der Anwendung unverändert:

• Verzögerung der Mausbewegung
• Anschlagverzögerung der Tastatur
• Einrastfunktion, um Tastenkombinationen, die normalerweise gleichzeitig einzugeben sind (Strg+Alt+Entf etc.),  nacheinander eingeben zu können

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]

Menschen mit einer Einschränkung der motorischen Fähigkeiten der Hände (Beweglichkeit, Stetigkeit, Genauigkeit, Kraft) können mit den Windows Eingabehilfen die Reaktion von Tastatur und Maus an ihre Bedürfnisse anpassen. Die Windows Eingabehilfen reichen aus für leichte, altersbedingte  Einschränkungen. Diese Einstellungen sollen auch in der Anwendungssoftware funktionieren. Normalerweise verwendet Anwendungssoftware die Tastatur- und Mausschnittstelle des Betriebssystems unverändert, so dass die Benutzereinstellungen automatisch übernommen werden. Wenn dies nicht der Fall ist, muss der Benutzer spezielle Eingabegeräte für motorisch Behinderte verwenden, die für leichte Fälle überdimensioniert sind.

Prüfanleitung

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

Praktische Erprobung der unter Beispiele genannten Einstellungen.

Bewertungsalternativen

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

Wenn die Eingabehilfen in der Anwendung nicht funktionieren, so ist dies eine Barriere.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Referenzen

EN301549

11.4.2 No disruption of accessibility features

WCAG

WCAG-Techniques

ISO9241-171

8.5.3 Nutzung der Standard-Zugänglichkeitsdienste

9.3 Tastatureingabe

9.4 Zeigegeräte

Zuletzt bearbeitet

29.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Der Benutzer kann die Darstellung des Tastatur- und Mauszeigers an seine Bedürfnisse anpassen. Die Anwendung nutzt hierzu die Eingabehilfen der Plattform, oder sie bietet entsprechende eigene Einstellungsmöglichkeiten an.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Der Benutzer kann die Attribute aller Tastaturfokus-Indikatoren, Text-Indikatoren und Mauszeiger anpassen, hierzu gehören u.a. Form, Größe, Strichbreite, Farbe, Blinkgeschwindigkeit und Zeigerspur.

Benutzer mit eingeschränktem Sehvermögen können den Zeiger vergrößern, so dass sie ihn leichter orten können.

Ein Benutzer mit eingeschränktem Sehvermögen verliert den Mauszeiger leicht aus dem Blick. Beim Drücken der Strg-Taste jedoch werden animierte konzentrische Kreise um die Mauszeigerposition herum angezeigt.

Die Software bietet die Option, den Tastaturfokus besonders deutlich als dick umrandetes Rechteck von kontrastierender Farbe darzustellen.

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 Einfügemarke, der Tastaturfokus und der Mauszeiger markieren die aktiven Elemente der Bedienoberfläche, auf die sich die nächste Aktion des Benutzers auswirken wird. Diese Indikatoren sollen einerseits leicht wahrnehmbar sein, damit der Benutzer sich orientieren kann, aber andererseits nicht ablenken. Die Bedürfnisse der Menschen sind in dieser Hinsicht verschieden, daher sind individuelle Einstellmöglichkeiten wichtig. Während ein sehbehinderter Benutzer die Einfügemarke groß und blinkend braucht, um sie wahrnehmen zu können, wird ein Benutzer mit einem Aufmerksamkeitsdefizit die Einfügemarke so einstellen, dass sie nicht blinkt.

Die Windows Eingabehilfen halten eine Vielzahl von Einstellmöglichkeiten bereit, und wenn auch nicht alle Bedürfnisse damit abgedeckt sind, ist es doch wichtig, dass Anwendungen diese Einstellungen übernehmen. Denn dann funktionieren voraussichtlich auch spezielle Tools, die genau die vom Benutzer gesuchte Einstellung bieten.

Eine Anwendung, die die Eingabehilfen der Plattform nicht übernimmt, muss die entsprechenden Einstellmöglichkeiten selber anbieten.

Prüfanleitung

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

Im Windows Center für erleichterte Bedienung aktivieren Sie folgende Optionen:

• Verwenden der Maus erleichtern / Mauseinstellungen / Zeigeroptionen / Zeigerposition beim Drücken der Strg-Taste anzeigen
• Erkennen von Bildschirmobjekten erleichtern / Die Breite des Fokusrechtecks vergrößern
• Erkennen von Bildschirmobjekten erleichtern / Legen Sie die Breite des blinkenden Cursors fest – hier den Wert auf 9 einstellen

Öffnen Sie die Anwendung, und bewegen Sie sich mit Tab und Pfeiltasten durch die Bedienelemente. Geben Sie Text ein. Wird die im Betriebssystem gewählte Darstellung von Fokus und Cursor für alle Elemente übernommen?

Bewegen Sie die Maus über mehrere Funktionsbereiche der Anwendung, und drücken Sie jeweils die Strg-Taste. Wird die Position des Mauszeigers durch animierte konzentrische Kreise verdeutlicht?

Falls die Windows-Eingabehilfen nicht übernommen werden, stellen Sie fest, ob die Anwendung über eigene Einstellmöglichkeiten für Tastatur- und Mauszeiger verfügt, ob diese mindestens den Eingabehilfen der Plattform entsprechen, und ob sie in allen im Szenario vorkommenden Bereichen der Anwendung funktionieren.

Bewertungsalternativen

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

Die Anforderung ist erfüllt, wenn die Eingabehilfen der Plattform in der Anwendung funktionieren.

Die Anforderung ist erfüllt, wenn die Anwendung über eigene Einstellmöglichkeiten verfügt, die nicht schlechter sind als die der Plattform.

Wenn in den Einstellmöglichkeiten der Anwendung wesentliche Optionen fehlen, so ist dies eine Barriere.

Wenn weder die Eingabehilfen der Plattform übernommen werden, noch eigene adäquate Einstellmöglichkeit angeboten werden, so ist dies eine Barriere.

Wenn die gewählte Einstellung in einzelnen Bereichen der Anwendung nicht funktioniert, so ist dies eine Einschränkung.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Software, die nicht die Fokusindikatoren des Betriebssystems übernimmt, müsste eigentlich in ihren eigenen Einstellmöglichkeiten alle vorkommenden Benutzerbedürfnisse abdecken. Es fehlt aber eine vollständige Klassifikation von Benutzerbedürfnissen in Bezug auf die Darstellung von Fokusindikatoren. Daher kann in diesem Prüfschritt nur der in Windows angebotene Stand als Maßstab angelegt werden.

Referenzen

EN301549

11.4.2 No disruption of accessibility features

11. 5. User Preferences

WCAG

WCAG-Techniques

ISO9241-171

8.2.4 Individualisierung der Einfügemarke und des Zeigers ermöglichen

9.4.13 Hilfsmittel zum Auffinden des Zeigers zur Verfügung stellen

Zuletzt bearbeitet

29.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Anwendungen in Auszeichnungssprachen sind mit korrekter Syntax codiert.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Elemente haben komplette Start- und End-Tags.

Elemente werden entsprechend ihrer Spezifikationen verschachtelt.

Elemente haben keine doppelten Attribute.

Attribute haben zueinander passende Anführungszeichen.

Alle IDs sind einzigartig.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist anwendbar, sofern die Anwendung in einem textbasierten Format mit Auszeichnungssprachen wie HTML oder XML codiert ist.

Begründung

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

Die Syntax der Auszeichnungssprachen ist einzuhalten, damit Anzeigetechniken die Inhalte korrekt darstellen und gliedern können. Während Browser oftmals Reparaturtechniken nutzen, um fehlerhaften Code ausgleichen zu können, erzeugen doch diese Reparaturtechniken verschiedene Ergebnisse. Damit assistive Technologien nicht in Fehlerzustände laufen oder Inhalte verpassen, müssen zumindest die formalen Syntaxregeln eingehalten werden, die eine Untermenge des jeweiligen Sprachumfangs sind.

Handcodierte Anwendungen können Flüchtigkeitsfehler enthalten. Von Generatoren produzierter Code kann fehlerhaft sein, wenn Browser-Heuristiken ausgenutzt werden. Daher wird auch der in Webanwendungen oftmals von Javascript generierte HTML-Code der Syntaxanalyse unterzogen.

Prüfanleitung

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

Zur Syntaxanalyse von HTML-Anwendungen verwenden Sie den Nu HTML Checker https://validator.w3.org/nu/ in Verbindung mit dem Bookmarklet „WCAG-Parsing only“ und dem Firebug Add-On für den Firefox Browser (siehe Werkzeugliste).

1. Öffnen Sie die Anwendung im Firefox Browser und warten Sie, bis die Anwendung vollständig geladen ist.
2. Um den generierten Code zu sehen, aktivieren Sie Firebug (Kontextmenü: Element mit Firebug untersuchen). Markieren Sie das body-Element und aktivieren Sie die Bearbeiten-Funktion. Es erscheint der vollständige Code des body-Elements. Kopieren Sie den Code in die Zwischenablage.
3. Überprüfen Sie den Code mit dem Nu HMTL-Checker. Wählen Sie "Check by text input" und fügen Sie den Inhalt der Zwischenablage in das Textfeld ein. Drücken Sie "Check".
4. Filtern Sie die Ergebnisliste mit dem Bookmarklet „WCAG-Parsing-only“. Ignorieren Sie die Meldung "Start tag seen without seeing a doctype first." Stellen Sie fest, ob jetzt noch Fehler angezeigt werden.
5. Wiederholen Sie die Schritte 2 bis 4, nachdem Sie die Anwendung bedient haben. Nehmen Sie etwa 2 bis 3 Stichproben je Szenario.

Für lauffähige XML-Anwendungen erübrigt sich eine Überprüfung der Syntax, da nur wohlgeformter Code von der Anzeigesoftware ausgeführt wird.

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]

Referenzen

EN301549

11. 2.1.37 Parsing

WCAG

4.1.1 Syntaxanalyse

WCAG-Techniques

G134: Validating Web pages

ISO9241-171

-

Zuletzt bearbeitet

11.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Objektinformationen zu Bedienelementen und Anzeigen werden über die Accessibility-Schnittstelle des Betriebssystems für Hilfstechniken verfügbar gemacht.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Windows bietet die Schnittstellen MSAA (Microsoft Active Accessibility) und UIA (User Interface Automation) für die Kommunikation mit unterstützender Technik an. Weitere bekannte Accessibility-Schnittstellen sind IAccessible2 und Java Access Bridge. Die Anwendung stellt in einer dieser Schnittstellen u.a. die folgenden Objektinformationen bereit:

• Name des Elements. Beispiel: der Name eines grafischen Buttons lautet „Kontakt“. 
• Rolle bzw. Funktion des Elements. Beispiel: ein Button hat die Rolle „Button“ oder „Schaltfläche“.
• Wert des Elements. Beispiele: Der angezeigte Inhalt eines Textfeldes lautet „Hochofenstraße“. Der Zustand einer Statusanzeige lautet „Internetzugriff hergestellt“.
• Informationen zum Status des Bedienelements wie „verfügbar“, „markiert“, „fokussiert“.
• Label-Beziehungen, d.h. ein Element wird durch den Wert eines benachbarten Elements benannt. Beispiel: Ein Eingabefeld hat keinen Namen, aber der benachbarte Text „Straße“ ist als Label für das Eingabefeld gekennzeichnet.
• Informationen zur Einordnung des Elements in die Objekthierarchie der Anwendung: Eltern-, Geschwister- und Kind-Elemente.

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 Bereitstellung von Objektinformationen über eine standardisierte Schnittstelle ermöglicht die Kompatibilität mit assistierenden Techniken wie Screenreader, Vergrößerungssoftware und Spracheingabesoftware, die von Menschen mit Behinderungen benutzt werden. Anwendungselemente, die mit Standardroutinen des Betriebssystems erzeugt wurden, übermitteln ihre Objektinformationen defaultmäßig an die Accessibility-Schnittstelle. Sie benötigen ggf. noch einen Namen, um ausreichend deklariert zu sein. Dagegen müssen neuartige oder individuell entwickelte Elemente mit allen Merkmalen gegenüber der Accessibility-Schnittstelle deklariert werden. Wenn dies nicht geschieht, müssen die Hersteller von Hilfstechniken die Objektinformationen aus anderen Quellen erschließen, wie etwa dem DOM (Document Object Model) der Anwendung oder den Ein-/Ausgaberoutinen des Betriebssystems, was sehr aufwändig ist und nicht immer gelingt. Je vollständiger eine Anwendung die Accessibility-Schnittstelle informiert, desto einfacher kann sie für die Benutzung mit assistiven Technologien verfügbar gemacht werden.

Prüfanleitung

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

Stellen Sie zunächst fest, ob die Anwendung mit JAVA programmiert ist oder die Schnittstelle IAccessible2 verwendet (siehe Herstellerfragebogen und Technische Prüfung). Für solche Anwendungen ist diese Prüfanleitung nicht geeignet. Für alle anderen Anwendungen gilt das Folgende:

Verwenden Sie das Tool Inspect (siehe Werkzeugliste), um zu überprüfen, ob die Anwendung ausreichende Objektinformationen an die Accessibility-Schnittstelle übergibt.

Untersuchen Sie diejenigen Bedienelemente und Anzeigen, die in der bisherigen Prüfung auffällig geworden sind, insbesondere in den Prüfschritten

• 3.01.0 Tastaturbedienung für Bedienelemente
• 4.01.0 Wiedergabe von Text
• 4.02.0 Name für grafische Bedienelemente und Anzeigen
• 4.03.1 Name, Rolle, Wert für Formularelemente
• 4.04.0 Name für Gruppen von Elementen
• 4.09.1 Benachrichtigung über Änderungen
• 5.04.1 Fokusverfolgung im Großbildsystem

Untersuchen Sie zusätzlich für jeden Arbeitsschritt des Szenarios 2 weitere, zufällig gewählte UI-Elemente.

Öffnen Sie inspect.exe. Unter „Options“ aktivieren Sie mindestens die folgenden Einstellungen:

• UI Automation Mode – umfasst auch MSAA, hier als „Legacy“-Properties benannt
• Raw View
• SPI_SCREENREADER Flag
• Show Highlight Rectangle
• Watch Focus
• Watch Cursor
• Show Tree

Es gibt auch die Möglichkeit, sich wichtige Elemente direkt am zu prüfenden Element als Tooltipp anzeigen zu lassen. Darauf wird an dieser Stelle jedoch nicht eingegangen.

Zum Prüfen bewegen Sie den Mauszeiger oder den Tastaturfokus zum zu untersuchenden Element, oder wählen Sie das Element im Inspect-Tree aus. Stellen Sie zunächst fest, ob das Element einfach oder zusammengesetzt ist. Bei zusammengesetzten Elementen führen Sie die Untersuchung für jedes Einzelteil durch. Bei Unstimmigkeiten überprüfen Sie auch, ob das Element im fokussierten Zustand andere Properties hat als im nicht fokussierten Zustand.

Sobald sich ein Rahmen um das zu untersuchende Element gebildet hat, drücken Sie die Tastenkombination STRG+SHIFT+4, damit die Ergebnisliste der Property-Werte in die Zwischenablage kopiert wird. Zum Lesen fügen Sie den Inhalt der Zwischenablage in einen Editor ein. Dieses Vorgehen ist etwas umständlich, hilft aber gegen Instabilitäten im Umgang mit Inspect.

Untersuchen Sie die Property-Werte in der Ergebnisliste. Achten Sie insbesondere auf folgende Werte:

• Name oder LegacyIAccessible.Name - der Name des Elements, z.B. "Format übertragen".
• ControlType – die Rolle, die Funktion des Elements, z.B. „UIA_ButtonControlTypeId (0xC350)“
• LocalizedControlType - Übersetzung der Rolle in die Landessprache, z.B. "Schaltfläche".
• LegacyIAccessible.Role - MSAA-Rolle, z.B. „Schaltfläche (0x2B)“.
• Value oder LegacyIAccessible.Value – Der Wert oder Inhalt des Elements, ist bei einer reinen Schaltfläche leer, also "".
• LegacyIAccessible.State – MSAA-Status, z.B. „markierbar,auswählbar,mehrfache Auswahl möglich (0x1300000)“
• IsEnabled - Verfügbar, kann die Werte "true" oder "false" annehmen.
• SelectionItem.IsSelected – Ausgewählt, kann die Werte "true" oder "false" annehmen.
• HasKeyboardFocus -  Fokussiert, kann die Werte "true" oder "false" annehmen.
• IsKeyboardFocusable – Fokussierbar, kann die Werte "true" oder "false" annehmen.
• Next, Previous – benachbarte Elemente
• Children – untergeordnete Elemente
• Ancestors – übergeordnete Elemente

Bitte beachten Sie:

• Der Name des Elements sollte einer sichtbaren Beschriftung, soweit vorhanden, entsprechen.
• Bei zusammengesetzten Elementen kann der Name auch in einem benachbarten, über- oder untergeordneten Element stehen, das zur selben Gruppe gehört.
• Die Rolle des Elements sollte der in der praktischen Erprobung festgestellten Funktion entsprechen.
• Bei zusammengesetzten Elementen sind Name, Rolle und Status der Einzelteile nicht mehrdeutig oder widersprüchlich angegeben.
• Benachbarte Elemente (prev und next) werden, sofern sie eine Label-Beziehung beschreiben, konsistent verwendet.

Bewertungsalternativen

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

Wenn sich kein Rahmen um das Element bildet, oder der Rahmen nicht der visuell wahrnehmbaren Begrenzung des Elements entspricht, so ist dies ein Mangel.

Wenn der Name des Elements nicht vorhanden ist, nicht der sichtbaren Beschriftung entspricht, verschiedene Namen in den Teilen eines zusammengesetzten Elements angegeben sind, verschiedene Namen im fokussierten und nicht fokussierten Zustand angegeben sind, so ist dies ein Mangel.

Wenn der Name des Elements nicht im Feld Name, sondern in einem anderen Feld wie Wert oder Hilfetext steht, und hieraus keine Widersprüche entstehen, so ist dies eine Einschränkung.

Wenn der Name des Elements im Feld Wert steht und der Wert des Elements sich dynamisch ändern kann (Formularfelder, Statusanzeigen), so ist dies ein Mangel.

Wenn die Rolle des Elements unzutreffend angegeben ist, oder in den verschiedenen für die Rolle einsetzbaren Feldern widersprüchliche Angaben stehen, oder in den Teilen eines zusammengesetzten Elements widersprüchliche Rollen angegeben sind, oder im fokussierten und nicht fokussierten Zustand des Elements verschiedene Rollen angegeben sind, so ist dies ein Mangel.

Alle Mängel, soweit nicht bereits gewichtet, werden nach der Bedeutung des gestörten Elements für die Arbeitsaufgabe bewertet.

Für den Bericht an Entwickler notieren Sie das bemängelte Element bitte mit dem Klassen-Namen (ClassName).

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Die folgenden Informationen aus Inspect gehen in den Prüfschritt 4.10.2 „Zusätzliche kontextsensitive Hilfe“ ein:

• HelpText oder LegacyIAccessible.Help
• LegacyIAccessible.Description
• LegacyIAccessible.DefaultAction
• AccessKey oder LegacyIAccessible.KeyboardShortcut

Textattribute werden im Prüfschritt 4.06.1 „Wiedergabe von Textattributen“ überprüft.

Tabellen werden im Prüfschritt 4.08.1 „Orientierung in Tabellen“ überprüft.

Offene Fragen

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

Zur Überprüfung der Rolle eines Elements wäre es hilfreich, ein Verzeichnis der in UIA gebräuchlichen Rollenbezeichnungen zu haben, eine entsprechende Referenz wird noch gesucht.

Die Verwendung des UIA-Attributs labelledby zur Kennzeichnung von Labelbeziehungen ist in der Anwendungsentwicklung bisher anscheinend nicht gebräuchlich. Diese Beobachtung braucht Verifizierung.

Prüftools für JAVA-Anwendungen und für die Schnittstelle IAccessible2 müssen noch benannt werden.

Referenzen

EN301549

11. 2.1.38 Name, Role, Value

11.3 Interoperability with assistive technology

WCAG

4.1.2 Name, Rolle, Wert

WCAG-Techniques

ISO9241-171

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

8.5. Kompatibilität mit unterstützender Technik

Zuletzt  bearbeitet

28.11.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Text soll mit den Systemroutinen des Betriebssystems als Text und nicht als Bild erzeugt werden. Text kann visuell angepasst werden und ist ohne Transformation (OCR) programmatisch zugänglich.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Texte werden bei Vergrößerung auf 200% mit scharfen Konturen dargestellt.

Eine Button-Beschriftung wird im Kontrastmodus mit angepassten Farben dargestellt.

Texte werden vom Screenreader vorgelesen, ohne dass OCR hinzugeschaltet werden muss.

Eine Bildunterschrift, die im Bild dargestellt ist, wird vom Screenreader vorgelesen.

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist nicht anwendbar auf Fälle, in denen eine bestimmte visuelle Präsentation von Text für die vermittelte Information unentbehrlich ist, wie z.B. ein Logo (Wortbildmarke) oder die Darstellung bestimmter Schriftarten.

Begründung

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

Text soll als Text und nicht als Bild erzeugt werden, damit die Darstellung an die Bedürfnisse von Menschen mit Behinderungen angepasst werden kann, und damit assistive Technologien uneingeschränkt darauf zugreifen können. Es genügt nicht, wenn auf die Verfügbarkeit von OCR-fähigen assistiven Technologien hingewiesen wird, denn zum einen ist die Transformation durch OCR fehleranfällig, und zum anderen wird hierdurch nur ein Teil der Anforderungen erfüllt. Solange die visuelle Anpassung von Bildern technisch eng begrenzt ist, soll Text nicht als Bild erzeugt werden.

Diese Anforderung wird verletzt u.a. von Programmiersprachen, die unter Umgehung der Betriebssystemroutinen direkt in den Bildschirmspeicher schreiben. Weiterhin kommt die Verwendung von Schriftgrafiken in Webanwendungen vor, um einen bestimmten optischen Effekt zu erzielen. Dies ist nur akzeptabel, wenn die visuelle Darstellung für die vermittelte Information unentbehrlich ist, wie z.B. bei einem Logo.

Prüfanleitung

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

Der Prüfschritt betrifft alle im Szenario vorkommenden Texte: Beschriftungen, Anweisungen, Meldungen, Hilfetexte und Daten, nicht aber Logos (Wortbildmarken) und Abbildungen von Schrift.

Sichten Sie erneut diejenigen Elemente, die in folgenden vorangegangenen Prüfschritten aufgefallen sind:

• 4.01.0 Wiedergabe von Text
• 5.01.1 Schriftvergrößerung auf 200%
• 5.03.1 Kontrastmodus ist nutzbar
• 7.02.1 Objektinformationen für Hilfstechniken verfügbar machen

Bei textbasierten Anwendungen: Der Prüfschritt ist nicht erfüllt, wenn im Quelltext (HTML/CSS/Javascript) anstelle des bemängelten Textes eine Bilddatei in einem Rasterformat (JPG, GIF, PNG etc.) referenziert ist.

Bei kompilierten Anwendungen: Der Prüfschritt ist nicht erfüllt, wenn wenigstens 2 der folgenden Mängel vorliegen:

• Im Screenreader wird der Text nicht vorgelesen.
• Bei Vergrößerung auf 200% sind die Konturen der Schriftzeichen pixelig oder verschwommen.
• Im Windows Kontrastmodus passen sich die Farben nicht an.
• Die Accessibility-Schnittstelle enthält nicht den angezeigten Text.

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]

Der Standard beschreibt die Eigenschaften von Rastergrafiken. XML-basierte Vektorgrafiken (SVG) verfügen im Prinzip über die geforderte Anpassbarkeit und Zugänglichkeit, allerdings liegen noch keine ausreichenden Daten über das Verhalten im Zusammenspiel mit verschiedenen Anzeigetechniken vor. Daher werden Vektorgrafiken bzw. SVG-Dateien in diesem Prüfschritt nicht behandelt.

Bei kompilierten Anwendungen kann nur indirekt auf die Verwendung von Schriftgrafiken geschlossen werden, wobei die einzelnen Indizien nicht eindeutig sind, da die beschriebenen Effekte entweder auch auf andere Weise erzielt werden können, oder durch Anpassungen ausgeglichen werden können. Daher lässt sich nur aus der Kumulation von Indizien ein Rückschluss auf die Verwendung von Schriftgrafiken treffen. Zu diskutieren wäre, ob der Prüfschritt für kompilierte Anwendungen ausgesetzt werden sollte.

Die Bewertung von Mängeln als Einschränkung ist eine Kompromisslösung: Es stellt sich die Frage, ob dieser Prüfschritt überhaupt bewertet werden soll, oder ob er rein informativ gelten soll. Für eine Bewertung spricht, dass die Verwendung von Schriftgrafiken an sich ein Regelverstoß ist, weil sie eine Anpassung für Menschen mit Behinderungen nicht oder nur mit großem Aufwand ermöglicht. Gegen eine Bewertung spricht, dass bereits in anderen Prüfschritten wegen der Auswirkungen der Schriftgrafik ein Mangel festgestellt und differenziert bewertet wird.

Referenzen

EN301549

11. 2.1.14 Images of text

WCAG

1.4.5 Bilder eines Textes

WCAG-Techniques

-

ISO9241-171

-

Zuletzt bearbeitet

29.08.2016

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Die Tastaturfunktionen der Anwendung funktionieren weiterhin, wenn ein Screenreader aktiv ist. Konflikte zwischen Tastaturbedienung und Screenreader sind in der Dokumentation aufgeführt, ein alternativer Bedienweg wird aufgezeigt.

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Bedienelemente können weiterhin mit TAB oder Pfeiltasten fokussiert und mit EINGABE oder LEER ausgelöst werden.

Tastaturfunktionen zur Bewegung in Daten und zur Selektion von Daten funktionieren weiterhin. 

Die Windows-Standardfunktion STRG+LEER zum Ab- und Hinzuwählen von Daten aus einer Liste, falls in der Anwendung verwendet, funktioniert weiterhin.

Shortcuts der Anwendung funktionieren weiterhin. Bei Konflikten mit den Shortcuts des Screenreaders greift das „Tastatur durchreichen“-Kommando des Screenreaders.

Die Windows-Standardfunktionen F3 (Suchen) bzw. F4 (Suche wiederholen), falls in der Anwendung verwendet, funktionieren weiterhin.

Die Windows-Standardfunktionen STRG+c (Kopieren), STRG+v (Einfügen), STRG+z (Rückgängig), falls in der Anwendung verwendet, funktionieren weiterhin.

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]

Hilfstechnik für Menschen mit Behinderungen soll störungsfrei in das Computersystem eingebunden werden. Screenreader übernehmen i.d.R. die Kontrolle über die Tastatur, um eine erweiterte Tastatursteuerung, z.B. zur Bewegung in Tabellen, anbieten zu können. Die Tastaturbefehle der Anwendung werden vom Screenreader normalerweise unverändert durchgereicht. Wenn nach Zuschaltung des Screenreaders Probleme mit einzelnen Tastaturfunktionen der Anwendung auftreten, so ist dies ein Indiz dafür, dass Programmierstandards des Betriebssystems nicht beachtet wurden. Die Software muss die Kompatibilität mit unterstützender Technik sicherstellen. Hierzu gehört, dass bestehende Konflikte dokumentiert und alternative Bedienwege angeboten werden.

Prüfanleitung

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

Schalten Sie den Screenreader ein. Wiederholen Sie stichprobenartig einzelne Elemente aus den Prüfschritten des Abschnitts „Tastaturbedienung“. Beachten Sie besonders die im Abschnitt „Beispiele“ aufgeführten Tastaturfunktionen. Beachten Sie besonders solche UI-Elemente, die in ihrem Aussehen vom Betriebssystem-Standard abweichen. Beachten Sie besonders solche Arbeitsschritte, in denen ein Wechsel zwischen Bedienoberfläche und Datenbereich (Moduswechsel des Screenreaders) stattfindet.

Bei Ausfällen stellen Sie fest, ob in der Dokumentation darauf hingewiesen wird, und ob ein alternativer Bedienweg aufgezeigt wird.

Bewertungsalternativen

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

Blockade/ Barriere/Einschränkung: Ausfälle in der Tastaturbedienung sind nicht dokumentiert, Bewertung nach der Bedeutung des ausfallenden Elements für die Arbeitsaufgabe.

Bei Ausfällen in der Tastaturbedienung, die dokumentiert sind und für die eine mit Screenreader bedienbare Alternative besteht, gilt der Prüfschritt als erfüllt.

Einordnung

[Abgrenzung zu anderen Prüfschritten]

Offene Fragen

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

Welche Komponente für eine Störung der Tastaturbedienung verantwortlich ist – der Screenreader oder die Anwendung – kann im Rahmen dieser Prüfung nicht zweifelsfrei festgestellt werden. Sofern die Störung durch eine Veränderung in den Funktionen des Screenreaders zu beheben wäre, hat der Software-Hersteller seine Verantwortung durch die Dokumentation der Störung und Bereitstellung eines alternativen Bedienweges erfüllt.

Referenzen

EN 301549

11. 2.1.15 Keyboard

11.3.2.14 Modification of focus and selection attributes

WCAG

2.1.1 Tastatur

Konformitätsbedingung 5: Nicht störend

WCAG-Techniques

ISO 9241-171

8.5.5 Der unterstützenden Technik die Änderung von Fokus und Auswahl ermöglichen

Zuletzt bearbeitet

29.08.2016