Anwendungssoftware, Stufe I

Schließen

Der BIT inklusiv-Anwendungssoftware-Test der Stufe I basiert auf der europäischen Norm für die Vergabe von Informationstechnik EN 301 549. Ausführliche Informationen zum Prüfverfahren finden Sie unter http://wiki.bit-inklusiv.de/index.php?title=Pr%C3%BCfverfahren_Anwendungssoftware.

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

Testausstattung

Befragung zu technischen Voraussetzungen

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

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

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

Werkzeugliste

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

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

Testsystem

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

Technische Prüfung

= Testverfahren Teil I

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

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

Dokumentenprüfung

= Testverfahren Teil II

Dokumentation der Tastaturkommandos

EN 301549 Nr. 12.1.1 Accessibility and compatibility features

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

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

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

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

Beschreibung der Accessibility-Features

EN 301549 Nr. 12.1.1 Accessibility and compatibility features

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

Barrierefreiheit von Dokumentation und Dienstleistungen

EN 301549 Nr. 12.1.2 Accessible documentation

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

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

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

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

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

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

Praktische Prüfung

= Testverfahren Teil III

Generelles Vorgehen

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

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

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

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

Sample / Szenario / Drehbuch

= Testverfahren Teil III A

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

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

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

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

Regeln für die Erstellung eines Drehbuchs

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

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

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

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

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

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

Prüfkatalog / Erfolgskriterien / Prüfschritte

= Testverfahren Teil III B

Zugrundeliegende Standards / Konformitätsstufen

Die Erfolgskriterien sind unterteilt in 3 aufeinander aufbauende Stufen.

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

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

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

Gliederung des Prüfkatalogs

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

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

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

Bearbeitungsmodalitäten

Abschnitte des Prüfkatalogs:

  1. Sichtprüfung bei normaler Darstellung

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

  3. Bedienung mit Tastatur

  4. Darstellung im Screenreader

  5. Personalisierte visuelle Darstellung

  6. Personalisierte Eingabe

  7. Standardkonforme Programmierung

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

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

Nummerierung

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

Aufbau eines Prüfpunktes

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

Aufbau in Anlehnung an den BITV-Test.

Bewertung

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

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

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

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

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

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

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

Prüfprotokoll / Reporting-Tool

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

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

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

Prüfbericht

Der Prüfbericht umfasst

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

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

Literatur

Prüfschritte zum Prüfplan

I. Sichtprüfung bei normaler Darstellung

Prüfschritt 1.01.0 - Ausreichender Kontrast

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

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

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

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

Die Anforderung gilt nicht

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

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

keine

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Der Prüfschritt ist immer anwendbar.

 

Begründung

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

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

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

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

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

 

Prüfanleitung

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

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

 

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

 

Bewertungsalternativen

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

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

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

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

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

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

 

Offene Fragen

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

Der Bewertungsmaßstab benötigt Verifizierung.

 

Referenzen

EN301549

11. 2.1.12 Contrast (minimum)

WCAG

1.4.3 Kontrast (Minimum)

WCAG-Techniques

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

ISO9241-171

10.4.5 Für Kontrast zwischen Vordergrund und Hintergrund sorgen

Sonstige

ISO 9241-303 Anforderungen an elektronische optische Anzeigen

ISO 9241-125 Anleitung zur visuellen Informationsdarstellung 

Zuletzt bearbeitet

31.10.2016

 

 

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

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

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

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

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

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

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

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

Fehler: Ein in eine Anwendung eingebundenes Video startet unaufgefordert.

Fehler: Ein blinkender Warnhinweis flackert grell.

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

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

 

Begründung

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

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

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

 

Prüfanleitung

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

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

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

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

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

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

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

 

Bewertungsalternativen

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

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

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

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

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

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

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

 

Offene Fragen

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

Prüftool für Flackern suchen.

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

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

 

Referenzen

EN301549

11. 2.1.18 Pause, stop, hide

11. 2.1.19 Three flashes or below threshold

WCAG

2.2.2 Pausieren, beenden, ausblenden

2.3.1 Grenzwert von dreimaligem Blitzen oder weniger

K5 Nicht störend

WCAG-Techniques

G176: Den blitzenden Bereich klein genug halten

ISO9241-171

10.1.1 Anfälle verursachende Blinkraten vermeiden

 

Zuletzt bearbeitet

29.09.2016

 

 

Prüfschritt 1.04.0 - Ton ist steuerbar

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

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

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

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

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

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

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

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

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

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

Begründung

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

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

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

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

 

Prüfanleitung

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

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

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

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

Bewertungsalternativen

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

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

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

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

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

Einordnung

[Abgrenzung zu anderen Prüfschritten]

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

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

Offene Fragen

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

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

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

Referenzen

EN301549

11. 2.1.11 Audio control

WCAG

1.4.2 Audio-Steuerelement

1.4.7 Leiser oder kein Hintergrund-Audioinhalt

K5 Nicht störend

WCAG-Techniques

ISO9241-171

10.6.2 Lautstärkeregelung ermöglichen

10.6.5 Einstellbarkeit des Hintergrundgeräuschs und anderer Audiokanäle

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

Prüfschritt 1.05.1 - Prägnante Beschriftungen

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

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

Prüfschritt 1.07.1 - Informationen nicht allein durch Farbe übermitteln

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

Beschreibung

[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. 

Als Markierung wird eine Hintergrundfarbe verwendet, deren Helligkeitskontrast im Verhältnis 1,5:1 von der Umgebungsfarbe abweicht, vorausgesetzt die Markierung bildet eine Fläche, die mindestens der Größe eines Bedienelements entspricht. 

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 mindestens im Verhältnis 1,5:1 gegen die Umgebungsfarbe kontrastieren.

Der Kontrastwert 1,5:1 zur Erkennbarkeit von markierten Farbflächen ist abgeleitet von dem Kontrastwert 3:1 zur Erkennbarkeit von markierten Zeichen. In Anlehnung an DIN 32975 wird für Flächen die Hälfte des zur Unterscheidbarkeit von Zeichen angesetzten Kontrastwertes angenommen.

 

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 mindestens im Verhältnis 1,5: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]

Der Kontrastwert 1,5:1 zur Erkennbarkeit von markierten Farbflächen ist theoretisch abgeleitet und muss empirisch verifiziert werden.

 

Referenzen

EN301549

11. 2.1.10 Use of colour

WCAG

1.4.1 Benutzung von Farbe

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

ISO9241-171

10.4.1 Informationen nicht allein durch Farbe übermitteln

BITV-Test

1.3.3a Ohne Bezug auf sensorische Merkmale nutzbar

Sonstige

ISO 9241-303 Anforderungen an elektronische optische Anzeigen

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

Zuletzt  bearbeitet

07.11.2016

 

 

Prüfschritt 1.08.1 - Nicht nur sensorische Merkmale in Anweisungen

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

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

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

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

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

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

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

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

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

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

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

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

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

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

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

 

Begründung

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

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

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

 

Prüfanleitung

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

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

 

Bewertungsalternativen

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

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

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

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

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

 

Offene Fragen

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

-

Referenzen

EN301549

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

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

11. 2.1.3 Captions (pre-recorded)

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

11. 2.1.5 Captions (live)

11. 2.1.6 Audio description (pre-recorded)

WCAG

1.1.1 Nicht-Text-Inhalte

1.2.1 Reine Audio- und Videoinhalte (aufgezeichnet)

1.2.2 Untertitel (aufgezeichnet)

1.2.3 Audiodeskription oder Medienalternative (aufgezeichnet)

1.2.4 Untertitel (Live)

1.2.5 Audiodeskription (aufgezeichnet)

WCAG-Techniques

BITV-Test

1.1.1b Alternativtexte für Grafiken und Objekte

1.2.1a Alternativen für Audiodateien und stumme Videos

1.2.2a Videos mit Untertiteln

1.2.3a Audiodeskription für Videos

ISO9241-171

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

 

Zuletzt bearbeitet

28.11.2016

 

II Bedienung mit Zeigegeräten (Maus, Touch)

Prüfschritt 2.03.1 - Bewegte Inhalte sind steuerbar

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

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

 

Prüfschritt 2.04.1 - Zeitbegrenzungen sind anpassbar

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

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

Prüfschritt 2.06.1 - Ausreichende Anweisungen für Benutzereingaben

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

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.

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

 

 

Prüfschritt 2.07.1 - Hilfen bei Fehleingaben

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

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

III Bedienung mit Tastatur

Prüfschritt 3.01.0 - Tastaturbedienung für Bedienelemente

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

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

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

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

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

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

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

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

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

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

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

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist immer anwendbar.

 

Begründung

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

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

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

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

 

Prüfanleitung

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

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

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

 

Bewertungsalternativen

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

Eine Tastaturfalle ist eine Blockade.

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

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

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

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

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

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

 

Offene Fragen

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

 

Referenzen

EN301549

11. 2.1.15 Keyboard

11. 2.1.16 No keyboard trap

WCAG

2.1.1 Tastatur

2.1.2 Keine Tastaturfalle

K5 Nicht störend

WCAG-Techniques

ISO9241-171

9.3.2 Nutzung aller Funktionen über die Tastatur ermöglichen

 

Zuletzt bearbeitet

31.10.2016

 

 

Prüfschritt 3.03.0 - Direktzugriff auf Funktionsbereiche

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

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

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

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

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

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

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

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

 

Begründung

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

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

 

Prüfanleitung

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

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

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

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

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

 

Bewertungsalternativen

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

Mängel sind eine Einschränkung.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

 

Offene Fragen

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

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

 

Referenzen

EN301549

11. 2.1.7 Info and relationships

WCAG

1.3.1 Info und Beziehungen

2.4.1 Blöcke umgehen

WCAG-Techniques

ISO9241-171

9.3.17 Die Navigation von Steuerungselementen durch Gruppierung erleichtern

 

Zuletzt bearbeitet

29.09.2016

 

 

Prüfschritt 3.04.1 - Tastaturbedienung für Anzeigen (wie Mausbedienung)

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

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

Prüfschritt 3.06.1 - Deutlich sichtbarer Tastaturfokus

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

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

 

 

Prüfschritt 3.07.0 - Sinnvolle Fokus-Reihenfolge

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

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

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

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

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

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

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

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

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

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

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

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist immer anwendbar.

 

Begründung

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

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

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

 

Prüfanleitung

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

Praktische Erprobung:

-         die unter Beschreibung und Beispiele genannten Fälle nachvollziehen

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

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

 

Bewertungsalternativen

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

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

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

Alle weiteren Mängel sind eine Einschränkung.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

 

Offene Fragen

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

 

Referenzen

EN301549

11. 2.1.22 Focus order

WCAG

2.4.3 Fokus-Reihenfolge

WCAG-Techniques

ISO9241-171

9.2.3 Bei Wiedererhalten des Tastaturfokus den letzten Stand bereitstellen

9.3.18 Steuerungselemente in Gruppen anordnen, die der Navigationsreihenfolge entsprechen

 

Zuletzt bearbeitet

24.11..2016

 

Prüfschritt 3.08.1 - Keine unerwartete Kontextänderung

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

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

 

Prüfschritt 3.11.0 - Vollständige Dokumentation der Tastaturbefehle

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

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

Keine

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist immer anwendbar.

 

Begründung

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

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

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

 

Prüfanleitung

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

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

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

 

Bewertungsalternativen

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

Mängel sind eine Einschränkung.

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

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

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

 

Offene Fragen

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

 

Referenzen

EN301549

12.1.1. Accessibility and compatibility features

WCAG

-

WCAG-Techniques

ISO9241-171

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

Weitere Standards

DIN EN 82079 Erstellen von Gebrauchsanleitungen

 

Zuletzt bearbeitet

29.09.2016

 

IV Darstellung im Screenreader

Prüfschritt 4.01.0 - Wiedergabe von Text

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

Alle sichtbaren Texte der Anwendung werden vom Screenreader vorgelesen.

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

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

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

Dieser Prüfschritt ist immer anwendbar.

 

Begründung

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

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

 

Prüfanleitung

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

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

Werden alle sichtbaren Texte der Anwendung vom Screenreader vorgelesen?

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

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

 

Bewertungsalternativen

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

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

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

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

 

Offene Fragen

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

 

Referenzen

EN301549

11. 2.1.14 Images of text

11. 2.1.38 Name, role, value

11. 3.3.2.7 Values

11. 3.3.2.10 Text

 

WCAG

1.4.5 Bilder eines Textes

4.1.2 Name, Rolle, Wert

WCAG-Techniques

ISO9241-171

 

Zuletzt bearbeitet

29.08.2016

 

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

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

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

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

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

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

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

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

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

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

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

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

 

Begründung

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

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

 

Prüfanleitung

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

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

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

 

Bewertungsalternativen

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

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

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

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

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

 

Offene Fragen

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

 

Referenzen

EN301549

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

11. 2.1.38 Name, role, value

11. 3.3.2.5 Object information

WCAG

1.1.1 Nicht-Text-Inhalt

4.1.2 Name, Rolle, Wert

WCAG-Techniques

ISO9241-171

8.1.1 Für jedes Benutzungsschnittstellen-Element einen Namen vorsehen

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

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

 

Zuletzt bearbeitet

29.08.2016

 

 

Prüfschritt 4.03.1 - Name, Rolle, Wert für Formularfelder

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

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

 

 

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

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

Beschreibung

[Technikneutrale Beschreibung des Erfolgskriteriums]

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

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

 

Beispiele

[Typische Anwendungsbeispiele aus verschiedenen Plattformen]

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

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

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

 

Anwendbarkeit

[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]

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

 

Begründung

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

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

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

 

Prüfanleitung

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

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

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

 

Bewertungsalternativen

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

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

 

Einordnung

[Abgrenzung zu anderen Prüfschritten]

 

Offene Fragen

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

 

Referenzen

EN301549

11. 2.1.7 Info and relationships

11. 2.1.34 Labels or instructions

11. 2.1.38 Name, role, value

11. 3.3.2.5 Object information

3.2.9 Parent-child relationships

WCAG

1.3.1 Info und Beziehungen

3.3.2 Beschriftungen oder Anweisungen

4.1.2 Name, Rolle, Wert

WCAG-Techniques

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

ISO9241-171

8.1.1 Für jedes Benutzungsschnittstellen-Element einen Namen vorsehen

9.3.17 Die Navigation von Steuerungselementen durch Gruppierung erleichtern

10.5.1 Eindeutige und verständliche Fenstertitel vorsehen

 

Zuletzt bearbeitet

29.09.2016

 

 

Prüfschritt 4.06.1 - Wiedergabe von Textattributen

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

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

 

 

Prüfschritt 4.07.1 - Korrekte Leseabfolge von Inhalten

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

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

 

Prüfschritt 4.08.1 - Orientierung in Tabellen

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

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

 

Prüfschritt 4.09.1 - Benachrichtigung über Änderungen

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

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

 

 

Prüfschritt 4.11.1 - Automatischer Sprachwechsel

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

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

 

 

V Personalisierte visuelle Darstellung

Prüfschritt 5.01.1 - Schriftvergrößerung auf 200%

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

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

 

 

Prüfschritt 5.03.1 - Kontrastmodus ist nutzbar

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

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

 

 

Prüfschritt 5.04.1 - Fokusverfolgung im Großbildsystem

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

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

 

 

Prüfschritt 5.05.1 - Kantenglättung im Großbildsystem

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

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

 

 

VI Personalisierte Eingabe

Prüfschritt 6.01.1 - Eingabehilfen für Tastatur und Maus

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

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

 

Prüfschritt 6.02.1 - Hilfen zum Auffinden des Zeigers

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

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

VII Standardkonforme Programmierung

Prüfschritt 7.01.1 - Korrekte Syntax

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

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

 

Prüfschritt 7.02.1 - Objektinformationen für Hilfstechniken verfügbar machen

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

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

 

 

Prüfschritt 7.03.1 - Text als Text codieren

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

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

Prüfschritt 7.04.1 - Tastaturbedienung im Screenreader

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

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


Schließen