https://biti-wiki.de/api.php?action=feedcontributions&user=Maugustin&feedformat=atomBIT inklusiv Wiki und Test-Case-Datenbank - Benutzerbeiträge [de]2024-03-29T07:40:21ZBenutzerbeiträgeMediaWiki 1.31.8https://biti-wiki.de/index.php?title=4.06.1_-_Wiedergabe_von_Textattributen&diff=15804.06.1 - Wiedergabe von Textattributen2021-01-11T12:11:50Z<p>Maugustin: </p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Bei Textinhalten werden zugehörige Attribute wie z. B. fett, kursiv und unterstrichen wiedergegeben bzw. sind ermittelbar.<br />
<br />
Die Anforderung bezieht sich auf Inhalte einer Anwendung, nicht auf Elemente der Bedienoberfläche.<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
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.<br />
<br />
Ein Multiple-Choice-Test bietet eine Lösungsversion an, in der die richtige Antwort durch eine Unterstreichung der Antwortnummer gekennzeichnet ist.<br />
<br />
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.<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Der Prüfschritt ist anwendbar, wenn die Anwendung Textinhalte oder Daten enthält, die durch Attribute ausgezeichnet sind.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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):<br />
<br />
Automatische Ansage: Im NVDA Einstellungsdialog wählen Sie den Bereich "Dokumentformatierungen" aus. Dort aktivieren Sie "Schriftattribute ansagen" und bestätigen mit "OK".<br />
<br />
Abfrage: In der Textverarbeitung setzen Sie die Einfügemarke in einen hervorgehobenen Bereich und drücken die Tastenkombination EINF+f.<br />
<br />
Ü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.<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Der Prüfschritt ist erfüllt, wenn die Attribute korrekt wiedergegeben werden.<br />
<br />
Mängel werden nach der Bedeutung der fehlenden Information für die Arbeitsaufgabe bewertet.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.5.2.10 Text<br />
<br />
==== WCAG ====<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:4.06.1_-_Wiedergabe_von_Textattributen&diff=1579Diskussion:4.06.1 - Wiedergabe von Textattributen2021-01-11T12:11:00Z<p>Maugustin: </p>
<hr />
<div>21.12.2017 Anmerkung Johannes Fischer (DZB):<br/><br />
In der Prüfschrittbeschreibung werden fest die Attribute fett, kursiv und unterstrichen angegeben ("Bei Textinhalten werden die Attribute fett, kursiv und unterstrichen wiedergegeben bzw. sind ermittelbar."). Könnte man dies allgemeiner formulieren, z. B. "Bei Textinhalten werden zugehörige Attribute wie z. B. fett, kursiv und unterstrichen wiedergegeben bzw. sind ermittelbar." ? Denn mir würde als Textattribut auch noch "durchgestrichen" einfallen und vielleicht gibt es auch noch weitere. Mit einer anderen Formulierung würde man den Prüfschritt weniger einschränken.<br />
<br />
Detlef Girke, Dezember 2017<br/><br />
Das halte ich für eine gute Idee. Als weitere Textattribute fallen mir z.B. hochgestellt oder tiefgestellt ein. Die ursprüngliche Idee hinter den festen Formulierungen war, dass man dann keine Priorisierung der Attribute vornehmen muss. Denn fett, kursiv und unterstrichen kommen häufiger vor als die anderen und sind daher rein statistisch gesehen wichtiger. Wie wollen wir damit umgehen? LG Detlef<br />
<br />
Telko 21.12.2020 - Ergebnis: Vorschlag soll übernommen werden.<br />
<br />
11.01.2021: Änderung im Prüfschritt übernommen.</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:4.03.1_-_Name,_Rolle,_Wert_f%C3%BCr_Formularfelder&diff=1578Diskussion:4.03.1 - Name, Rolle, Wert für Formularfelder2021-01-11T12:08:57Z<p>Maugustin: </p>
<hr />
<div>== Schalter zum Aufklappen von Textbereichen ==<br />
22.03.2019 Johannes Fischer (DZB) <br/><br />
Frage: Fallen Aufklappschalter, die z. B. nur einen Text-Bereich aufklappen (auch Disclosure genannt) unter Formularelemente? Also wird deren Status auch in diesem Prüfschritt bewertet? Wenn man den Begriff "Formularfelder" weit auslegt, kann man ihn auf solche Schalter erweitern. Ich würde mir jedoch einen klaren Hinweis darauf in der Anleitung wünschen. Falls so ein Aufklappbereich nicht unter diesen Prüfschritt fallen sollte, besteht die Frage, in welchem anderen Prüfschritt der Status bewertet wird?<br />
<br />
Telko 21.12.2020 - Ergebnis: Aufklappfeld in Navigation oder Akkordeon (siehe WCAG 4.1.2). Bei der Überarbeitung des BITV-Softwaretests auch EN-Kapitel 5 berücksichtigen!</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:4.02.0_-_Name_f%C3%BCr_grafische_Bedienelemente_und_Anzeigen&diff=1577Diskussion:4.02.0 - Name für grafische Bedienelemente und Anzeigen2021-01-11T12:07:09Z<p>Maugustin: </p>
<hr />
<div>21.12.2017 Anmerkung Johannes Fischer (DZB):<br/><br />
Der Prüfschritt bezieht sich u.a. auf das EN-301549-Kriterium 11.2.1.38, welches dem WCAG-Kriterium 4.1.2 (Name, Rolle, Wert für Bedienelemente verfügbar) entspricht. Der Name wird hier auch explizit geprüft. Werte (Zustände/Eigenschaften) werden in den Beispielen nur einmal kurz erwähnt bei dem Icon für den Internetzugriff. Das sollte aus meiner Sicht deutlicher gemacht werden, schon in der Prüfschritt-Bezeichung und auch im ersten Abschnitt "Beschreibung". Die Rolle des Bedienelements fehlt hier in der Prüfung aber noch komplett und sollte vielleicht ergänzt werden? Zumindest für die grafischen Bedienelemente wäre dies relevant. Man kann sich hier am Prüfschritt 4.03.1 orientieren.<br/>Auch in der Bezeichnung des Prüfschritts wird bisher nur der Name erwähnt, nicht Rolle oder Wert.<br />
<br />
21.12.2017 Anmerkung Detlef Girke<br/><br />
Im Bereich 4 geht es ja ausschließlich um die Screenreadernutzung. Außerdem ist es ein Schritt der Stufe 0, also Praxistauglichkeitstest. Dafür sollte der Name reichen. Er wird in Stufe I ergänzt um 4.03.1 - Name, Rolle, Wert für Formularfelder. Frage an die Programmierer: Gibt es eine Liste der Elemente, die unterschiedliche Zustände annehmen können? Für mich sind das in erster Linie Formularelemente sowie Bedienelemente, die verfügbar oder nicht verfügbar (ausgegraut) sind.<br />
<br />
15.01.2018 Johannes Fischer<br/><br />
Ok, Rolle und Wert werden in Prüfschritt 4.03.1 abgeprüft. Das leuchtet ein, genauso dass in Stufe 0 ein Name ausreicht. Bei 4.03.1 hatte ich zunächst Formularfelder und grafische Bedienelemente gedanklich nicht assoziiert. Aber grafische Bedienelemente sind ja in der Regel Buttons und fallen damit unter Formularelemente (wenn auch sprachlich nicht unbedingt "felder"). In Ordnung.<br />
<br />
Telko 21.12.2020 - Ergebnis: Frage ist geklärt (Johannes Fischer). <br />
Bei der Überarbeitung des BITV-Softwaretests "Buttons" mit aufnehmen und Zustände (bisher in Prüfschritt 7.2.1)</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:3.11.0_-_Vollst%C3%A4ndige_Dokumentation_der_Tastaturbefehle&diff=1576Diskussion:3.11.0 - Vollständige Dokumentation der Tastaturbefehle2021-01-11T12:05:22Z<p>Maugustin: </p>
<hr />
<div>21.12.2017 Anmerkung Johannes Fischer (DZB):<br/><br />
Im Abschnitt "Begründung" heißt es: "Selten gebrauchte Tastaturbefehle sind den Benutzern nicht geläufig und müssen nachgeschlagen werden können."<br />
Das heißt, nicht alle Tastaturbefehle müssen dokumentiert sein, nur selten gebrauchte Befehle. Vielleicht sollte man in die Prüfanleitung aufnehmen, welche Befehle nicht dokumentiert werden müssen? Zum Beispiel wäre dies die Tabulatortaste oder vielleicht auch die Pfeiltasten?<br/><br />
Tasten wie Esc, Bild-auf, Bild-ab, F6 (zwischen Bereichen springen) oder Kombinationen mit Strg oder Alt müssen aber wohl schon dokumentiert sein.<br />
Gibt es hierzu Meinungen?<br />
<br />
04.04.2018 Detlef Girke: <br/><br />
Ich finde, dass man hier ein "... wie z.B. TAB oder die Pfeil-Tasten..." einschieben könnte. Außerdem sollte hier mit erwähnt werden, dass alle Befehle, die vom Windows-Standard abweichen, dokumentiert sein müssen, wenn nicht sogar besonders hervorgehoben. Damit meine ich Befehle wie z.B. STRG+C, STRG+V, ALT+F4, UMSCHALT+F10, F6, ...<br />
<br />
Telko 21.12.2020 - Ergebnis: <br />
Gem. EN wird jetzt eine vollständige Dokumentation gefordert.<br />
"Standard-Tasten nicht zu dokumentieren"? Was sind „Standard“-Tasten.<br />
Evtl. auf Windows-Standards verweisen? <br />
In der Überarbeitung des BITV-Softwaretest berücksichtigen!</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:3.08.1_-_Keine_unerwartete_Kontext%C3%A4nderung&diff=1575Diskussion:3.08.1 - Keine unerwartete Kontextänderung2021-01-11T12:04:11Z<p>Maugustin: </p>
<hr />
<div>05.06.2019 Johannes Fischer<br/><br />
Bereich Beispiele: "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."<br/><br />
Frage: Warum ist das in einem Suchfeld nicht unerwartet? Der Nutzer sollte aus meiner Sicht zumindest die Eingabetaste drücken müssen. Nach den WCAG reicht ein Verlassen mit der Tabulatortaste nicht ganz aus.<br />
<br />
Telko 21.12.2020 - Ergebnis: Der Text Ausnahme „in einem Suchfeld ist dieses Verhalten nicht unerwartet.“ = entfernen.<br />
<br />
11.01.2021: Text wurde aus dem Prüfschritt entfernt.</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:1.10.0_-_Alternativen_f%C3%BCr_Abbildungen_und_Multimedia-Inhalte&diff=1574Diskussion:1.10.0 - Alternativen für Abbildungen und Multimedia-Inhalte2021-01-11T12:03:09Z<p>Maugustin: /* Audiodeskription */</p>
<hr />
<div>== Audiodeskription ==<br />
30.08.2018 Johannes Fischer (DZB)<br/><br />
Im Abschnitt Beschreibung steht: "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."<br/><br />
Die EN301549 bzw. WCAG fordern auf Level AA in jedem Fall Audiodeskription ([https://www.w3.org/TR/WCAG/#audio-description-prerecorded WCAG-Kriterium 1.2.5]). Textbeschreibung als Alternative würde nur auf Level A ausreichen. Der zweite Teilsatz in der Prüfbeschreibung müsste aus meiner Sicht entfernt werden.<br />
<br />
Telko 21.12.2020 - Ergebnis: zu überprüfen für die Überarbeitung des BITV-Softwaretests! WCAG Textalternative nur für A erfüllt.</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:3.11.0_-_Vollst%C3%A4ndige_Dokumentation_der_Tastaturbefehle&diff=1573Diskussion:3.11.0 - Vollständige Dokumentation der Tastaturbefehle2021-01-11T11:57:16Z<p>Maugustin: </p>
<hr />
<div>21.12.2017 Anmerkung Johannes Fischer (DZB):<br/><br />
Im Abschnitt "Begründung" heißt es: "Selten gebrauchte Tastaturbefehle sind den Benutzern nicht geläufig und müssen nachgeschlagen werden können."<br />
Das heißt, nicht alle Tastaturbefehle müssen dokumentiert sein, nur selten gebrauchte Befehle. Vielleicht sollte man in die Prüfanleitung aufnehmen, welche Befehle nicht dokumentiert werden müssen? Zum Beispiel wäre dies die Tabulatortaste oder vielleicht auch die Pfeiltasten?<br/><br />
Tasten wie Esc, Bild-auf, Bild-ab, F6 (zwischen Bereichen springen) oder Kombinationen mit Strg oder Alt müssen aber wohl schon dokumentiert sein.<br />
Gibt es hierzu Meinungen?<br />
<br />
04.04.2018 Detlef Girke: <br/><br />
Ich finde, dass man hier ein "... wie z.B. TAB oder die Pfeil-Tasten..." einschieben könnte. Außerdem sollte hier mit erwähnt werden, dass alle Befehle, die vom Windows-Standard abweichen, dokumentiert sein müssen, wenn nicht sogar besonders hervorgehoben. Damit meine ich Befehle wie z.B. STRG+C, STRG+V, ALT+F4, UMSCHALT+F10, F6, ...<br />
<br />
Telko 21.12.2020 - Ergebnis: <br />
Gem. EN wird jetzt eine vollständige Dokumentation gefordert.<br />
"Standard-Tasten nicht zu dokumentieren"? Was sind „Standard“-Tasten.<br />
Evtl. auf Windows-Standards verweisen? <br />
In der Überarbeitung berücksichtigen!</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:3.11.0_-_Vollst%C3%A4ndige_Dokumentation_der_Tastaturbefehle&diff=1572Diskussion:3.11.0 - Vollständige Dokumentation der Tastaturbefehle2021-01-11T11:57:01Z<p>Maugustin: </p>
<hr />
<div>21.12.2017 Anmerkung Johannes Fischer (DZB):<br/><br />
Im Abschnitt "Begründung" heißt es: "Selten gebrauchte Tastaturbefehle sind den Benutzern nicht geläufig und müssen nachgeschlagen werden können."<br />
Das heißt, nicht alle Tastaturbefehle müssen dokumentiert sein, nur selten gebrauchte Befehle. Vielleicht sollte man in die Prüfanleitung aufnehmen, welche Befehle nicht dokumentiert werden müssen? Zum Beispiel wäre dies die Tabulatortaste oder vielleicht auch die Pfeiltasten?<br/><br />
Tasten wie Esc, Bild-auf, Bild-ab, F6 (zwischen Bereichen springen) oder Kombinationen mit Strg oder Alt müssen aber wohl schon dokumentiert sein.<br />
Gibt es hierzu Meinungen?<br />
<br />
04.04.2018 Detlef Girke: <br/><br />
Ich finde, dass man hier ein "... wie z.B. TAB oder die Pfeil-Tasten..." einschieben könnte. Außerdem sollte hier mit erwähnt werden, dass alle Befehle, die vom Windows-Standard abweichen, dokumentiert sein müssen, wenn nicht sogar besonders hervorgehoben. Damit meine ich Befehle wie z.B. STRG+C, STRG+V, ALT+F4, UMSCHALT+F10, F6, ...<br />
<br />
Telko 21.12.2020: <br />
Gem. EN wird jetzt eine vollständige Dokumentation gefordert.<br />
"Standard-Tasten nicht zu dokumentieren"? Was sind „Standard“-Tasten.<br />
Evtl. auf Windows-Standards verweisen? <br />
In der Überarbeitung berücksichtigen!</div>Maugustinhttps://biti-wiki.de/index.php?title=3.08.1_-_Keine_unerwartete_Kontext%C3%A4nderung&diff=15713.08.1 - Keine unerwartete Kontextänderung2021-01-11T11:55:15Z<p>Maugustin: /* Beispiele */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
Eine Kontextänderung ist eine wesentliche Änderung des Inhalts, oder eine Änderung des Fokus, des Bildausschnitts oder der Bedienmodalität.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
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.<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
<br />
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)“.<br />
Fehler: Wie zuvor, aber das Auto-Tab-Verhalten ist nicht angekündigt.<br />
<br />
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.<br />
<br />
Fehler: Bei Fokussierung eines Eingabefeldes erscheint ein Popup mit einem Hilfetext, das erst mit ESC geschlossen werden muss, bevor die Eingabe erfolgen kann.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Praktische Erprobung:<br />
<br />
* die unter Beschreibung und Beispiele genannten Fälle nachvollziehen<br />
* wenn eine unerwartete Kontextänderung vorliegt: feststellen, ob sie mit einem einfachen Bedienschritt (ESC, Zurück o.ä.) wieder aufgehoben werden kann<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Wenn mehr als ein Bedienschritt benötigt wird, um die unerwartete Kontextänderung rückgängig zu machen, so ist dies eine Barriere.<br />
<br />
Alle weiteren Mängel sind eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
Dieser Prüfschritt behandelt Einschränkungen der Tastaturbedienung wegen mangelnder Orientierung. Schwerwiegendere Fehlersituationen werden unter anderen Prüfschritten behandelt:<br />
<br />
- 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.<br />
<br />
- Fehlersituationen, die zu einem Fokusverlust führen, werden im Prüfschritt 3.07.0 „Sinnvolle Fokusreihenfolge“ als Mangel gewertet.<br />
<br />
Explizit ausgelöste Kontextänderungen werden im Prüfschritt 4.09.1 "Benachrichtigung über Änderungen" behandelt. <br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.3.2.1 On focus<br />
<br />
11.3.2.2 On input<br />
<br />
==== WCAG ====<br />
<br />
3.2.1 Bei Fokus<br />
<br />
3.2.2 Bei Eingabe<br />
<br />
==== WCAG-Techniques ====<br />
<br />
G107: Using &quot;activate&quot; rather than &quot;focus&quot; as a trigger for changes of context<br />
<br />
G80: Providing a submit button to initiate a change of context<br />
<br />
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<br />
<br />
==== ISO9241-171 ====<br />
<br />
9.3.14 Tastaturnavigation und Aktivierung voneinander trennen</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:3.08.1_-_Keine_unerwartete_Kontext%C3%A4nderung&diff=1570Diskussion:3.08.1 - Keine unerwartete Kontextänderung2021-01-11T11:54:29Z<p>Maugustin: </p>
<hr />
<div>05.06.2019 Johannes Fischer<br/><br />
Bereich Beispiele: "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."<br/><br />
Frage: Warum ist das in einem Suchfeld nicht unerwartet? Der Nutzer sollte aus meiner Sicht zumindest die Eingabetaste drücken müssen. Nach den WCAG reicht ein Verlassen mit der Tabulatortaste nicht ganz aus.<br />
<br />
Telko 21.12.2020 - Ergebnis: Der Text Ausnahme „in einem Suchfeld ist dieses Verhalten nicht unerwartet.“ = entfernen</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:1.02.2_-_Leserliche_Schrift&diff=1569Diskussion:1.02.2 - Leserliche Schrift2021-01-11T11:53:07Z<p>Maugustin: /* 80 Zeichen pro Zeile */</p>
<hr />
<div>== 80 Zeichen pro Zeile ==<br />
30.08.2018 Johannes Fischer (DZB) <br/><br />
Im Abschnitt Beschreibung ist angegeben, dass Fließtext nicht mehr als 80 Zeichen pro Zeile haben soll. Das zugehörige [https://www.w3.org/TR/WCAG/#visual-presentation WCAG-Kriterium 1.4.8] fordert nicht generell 80 Zeichen pro Zeile. Der Nutzer soll nur über einen Mechanismus die Möglichkeit haben, 80 Zeichen zu erreichen, z. B. durch Verringern der Fensterbreite. Ähnlich sollte es auch hier formuliert werden. In der anderen Quelle, der [https://www.arbeitssicherheit.de/schriften/dokument/0%3A5004837%2C1/#hmap-11 DGUV-Richtlinie 215-410, Abschnitt 7.2], ist nur die Rede davon, dass mindestens 80 Zeichen pro Zeile angezeigt werden können.<br />
<br />
Telko 21.12.2020 - Ergebnis: Komplett rausnehmen aus dem Prüfschritt bzw. nicht in neuen BITV-Softwaretest aufnehmen, da Anforderung aus Level AAA (erhöhte Anforderung).</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:1.02.2_-_Leserliche_Schrift&diff=1568Diskussion:1.02.2 - Leserliche Schrift2021-01-11T11:51:11Z<p>Maugustin: /* 80 Zeichen pro Zeile */</p>
<hr />
<div>== 80 Zeichen pro Zeile ==<br />
30.08.2018 Johannes Fischer (DZB) <br/><br />
Im Abschnitt Beschreibung ist angegeben, dass Fließtext nicht mehr als 80 Zeichen pro Zeile haben soll. Das zugehörige [https://www.w3.org/TR/WCAG/#visual-presentation WCAG-Kriterium 1.4.8] fordert nicht generell 80 Zeichen pro Zeile. Der Nutzer soll nur über einen Mechanismus die Möglichkeit haben, 80 Zeichen zu erreichen, z. B. durch Verringern der Fensterbreite. Ähnlich sollte es auch hier formuliert werden. In der anderen Quelle, der [https://www.arbeitssicherheit.de/schriften/dokument/0%3A5004837%2C1/#hmap-11 DGUV-Richtlinie 215-410, Abschnitt 7.2], ist nur die Rede davon, dass mindestens 80 Zeichen pro Zeile angezeigt werden können.<br />
<br />
Telko 21.12.2020: Ergebnis: Komplett rausnehmen aus dem Prüfschritt.<br />
= Anforderung aus Level AAA (erhöhte Anforderung)</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:2.01.2_-_Ausreichende_Gr%C3%B6%C3%9Fe_von_Schaltfl%C3%A4chen&diff=1567Diskussion:2.01.2 - Ausreichende Größe von Schaltflächen2020-12-21T11:35:53Z<p>Maugustin: </p>
<hr />
<div>21.12.2017 Anmerkungen Johannes Fischer (DZB):<br />
<br />
1. Warum wird die Bewertung "Einschränkung" erst bei weniger als 98% gegeben und nicht bei weniger als 100%?<br />
<br />
2. Ist 12 x 12 pt nicht eine sehr geringe Größe von Schaltflächen, vor allem für Touchbedienung? In der überarbeitetn WCAG 2.1 gibt es das Erfolgskriterium "Target size" (https://www.w3.org/TR/WCAG21/#target-size). Wenn es sich nicht um eine Ausnahme handelt, müssen Schaltflächen auf Webseiten mindestens 44 x 44 CSS-px groß sein. Das entspricht nach Umrechnung (siehe hier: https://www.w3.org/TR/css-values-3/#absolute-lengths) 33 x 33 pt. Man könnte sich hier an der WCAG 2.1 orientieren, meiner Meinung nach.<br />
<br />
04.04.2018 Detlef Girke:<br/><br />
<br />
zu 1.: Darauf hatten Brigitte Bornemann und ich uns verständigt. Das sollten wir in unsserer Telko am 16. oder 17.4. besprechen.<br />
25.04.2018: Protokoll des Netzwerk-Treffens. Äderung auf 100%.<br />
21.12.2020: Monika Augustin: Anweisung wurde geändert. Diskussion geschlossen.<br />
<br />
zu 2.: ja, unbedingt. Die WCAG-2.1-Definition ist meiner Meinung nach viel zeitgemäßer.<br />
21.12.2020: Monika Augustin: Anweisung wurde bereits geändert. Diskussion geschlossen.</div>Maugustinhttps://biti-wiki.de/index.php?title=2.01.2_-_Ausreichende_Gr%C3%B6%C3%9Fe_von_Schaltfl%C3%A4chen&diff=15662.01.2 - Ausreichende Größe von Schaltflächen2020-12-21T11:33:26Z<p>Maugustin: </p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Schaltflächen haben eine Kantenlänge von mindestens 33pt, um sicherzustellen, dass auch Menschen mit eingeschränkter Feinmotorik sie mit Hilfe einer Maus auswählen können.<br />
<br />
Dies betrifft grafische Bedienelemente, aber auch Textlinks und Eingabefelder, deren sensible Fläche ausreichend groß sein muss. <br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
''Keine''<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
Bedienelemente sollen nicht zu klein sein und nicht zu nah beieinander stehen. Dies erleichtert allen Mausbenutzern die Bedienung und ist besonders wichtig für Menschen mit eingeschränkter Feinmotorik der Hände und für Nutzer von alternativen Eingabegeräten wie Kopfmaus etc., damit sie Bedienelemente sicher auswählen können.<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
''Sichtprüfung: sind alle Schaltflächen ausreichend groß? Im Zweifel nach''messen mit dem Keseling Bildschirmlineal (siehe Werkzeugliste). Die Maßangabe 33pt bzw. 1,16cm bezieht sich auf den Standard-Bildschirm (siehe Testsystem). Zu messen ist die Kantenlänge der Schaltfläche bzw. des sensitiven Bereichs. Im Zweifel zunächst den Tastaturfokus auf ein Element setzen und die Kantenlänge des Fokusindikators messen.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
''Kantenlängen von weniger als 100% der Anforderung können bereits als Einschränkung bewertet werden.''<br />
<br />
''Kantenlängen von weniger als 50% der Anforderung (5,08mm) sind eine Barriere.''<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
* <br />
<br />
==== WCAG 2.1 ====<br />
<br />
Success Criterion 2.5.5 Target Size.<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
<br />
9.4.3 Leicht auswählbare Ziele für Zeigegeräte zur Verfügung stellen</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:3.07.0_-_Sinnvolle_Fokus-Reihenfolge&diff=1565Diskussion:3.07.0 - Sinnvolle Fokus-Reihenfolge2020-12-21T11:28:46Z<p>Maugustin: </p>
<hr />
<div>21.12.2017 Anmerkung Johannes Fischer (DZB):<br/><br />
Bei den Bewertungsalternativen sollte es auch die Bewertungsmöglichkeit einer Blockade geben. Falls die Reihenfolge völlig durcheinander ist, könnte diese Bewertung abgegeben werden. Oder wird die Alternative nicht angezeigt, weil eine völlig verwirrende Reihenfolge nur selten auftritt und der Prüfer in diesen Fällen selbst entscheidet, ob doch eine Blockade gegeben ist?<br />
<br />
<br />
05.04.2018 Detlef Girke:<br />
<br />
Im Unterkapitel "Bewertung" zu diesem Prüfschritt steht:<br />
<br />
"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.<br />
<br />
Wenn bei Benutzereingaben die Reihenfolge des Tastaturfokus willkürlich erscheint, und zugleich der Fokusindikator nur schwach sichtbar ist, so ist dies eine Barriere.<br />
<br />
Alle weiteren Mängel sind eine Einschränkung."<br />
<br />
Blockade ist daher tatsächlich nicht vorgesehen. Das hatte ich damals mit Brigitte auch schon diskutiert. Eine Blockade bedeutet ja, dass eine Anwendung ab einer bestimmten Stelle überhaupt nicht mehr nutzbar ist. Das ist in diesem Fall (leider) noch nicht gegeben. Vielleicht bräuchten wir noch eine Stufe zwischen Barriere und Blockade, die die Hilflosigkeit, die eine vollkommen verwirrende Fokus-Reihenfolge verursacht, zum Ausdruck bringt. Vielleicht etwas, das weniger sperrig klingt als "Nutzungshemmnis". Im Sinne von Barriere und Blockade komme ich dabei auf "Schikane", das ist aber zu moralisch. Irgendwelche Ideen?<br />
<br />
<br />
06.04.2018 Johannes Fischer (DZB):<br/><br />
Ok, mit der Erklärung, dass die Anwendung auch mit einer völlig verwirrenden Fokus-Reihenfolge weiterhin nutzbar ist, verstehe ich, warum es keine Möglichkeit der Blockade gibt. Ich hatte zu sehr in den Bewertungsstufen zwischen erfüllt und nicht erfüllt gedacht, nicht in der Art des Fehlers.<br />
<br />
21.12.2020: Monika Augustin: Frage ist geklärt. Diskussion geschlossen.</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:3.02.2_-_Name_von_grafischen_Bedienelementen_abrufen&diff=1564Diskussion:3.02.2 - Name von grafischen Bedienelementen abrufen2020-12-21T11:27:34Z<p>Maugustin: /* Fehler Taste F10 */</p>
<hr />
<div>== Fehler Taste F10 ==<br />
30.08.2018 Johannes Fischer (DZB)<br/><br />
In den Bereichen Beispiele und Prüfanleitung wird von der Taste F10 für das Kontextmenü gesprochen. Richtig wäre jedoch Umschalt+F10, siehe hier: https://support.microsoft.com/en-us/help/12445/windows-keyboard-shortcuts<br />
<br />
21.12.2020: Monika Augustin: Prüfanleitung wurde bereits geändert. Diskussion geschlossen.</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:1.01.0_-_Ausreichender_Kontrast&diff=1563Diskussion:1.01.0 - Ausreichender Kontrast2020-12-21T11:26:10Z<p>Maugustin: </p>
<hr />
<div>21.12.2017 Frage Johannes Fischer (DZB):<br/><br />
Bewertung: Warum ist eine Einschränkung erst bei einem Kontrast von weniger als 4,41:1 bzw. 2,94:1 gegeben? Dann ist die Anforderung ja gar nicht 4,5:1 oder 3:1, sondern geringer.<br />
<br />
21.12.2020: Monika Augustin: Anforderung wurde bereits geändert. Diskussion geschlossen.</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:2.06.1_-_Ausreichende_Anweisungen_f%C3%BCr_Benutzereingaben&diff=1562Diskussion:2.06.1 - Ausreichende Anweisungen für Benutzereingaben2020-12-21T11:21:23Z<p>Maugustin: </p>
<hr />
<div>= Pflichtfeld-Kennzeichnung =<br />
21.12.2017 Johannes Fischer (DZB)<br><br />
Im Bereich "Beispiele" steht, dass ein Zeichen für Pflichtfelder (z. B. das Stern-Zeichen (*)) vor oder auch hinter dem Formular erklärt werden soll. Der Prüfschritt bezieht sich in der EN 301 549 auf das Kriterium 11.2.1.34, welches identisch zum WCAG 2.0 Kriterium 3.3.2 ist. In der WCAG gibt es dabei die Technik H90 (https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H90), welche im Example 2 fordert, dass ein Zeichen zur Anzeige eines Pflichtfelds vor dem zugehörigen Formular erklärt werden muss. Die Erklärung erst hinter dem Formular ist nicht ausreichend.<br />
<br>Monika Augustin: Hinweis wurde bereits übernommen. Diskussion beendet 21.12.2020<br />
<br />
<br />
= Einordnung bzw. Beschreibung =<br />
20.02.2018 Thomas Ernst (Stiftung Pfennigparade)<br><br />
Die Abgrenzung zum Erfolgskriterium "1.05.1 Prägnante Beschriftungen" müsste bei Beschriftungen von Eingabefeldern klarer formuliert werden.<br />
<br />
20.02.2018 Johannes Fischer (DZB)<br><br />
Herr Ernst, wie meinen Sie das genau? Sollte man den Begriff "Verständlichkeit" durch "Aussagekraft" ersetzen oder meinen Sie etwas anderes?<br />
<br />
22.02.2018 Thomas Ernst (Stiftung Pfennigparade)<br><br />
In 2.06.1 Absatz "Einordnung" wird von „formalen Gestaltungsregeln" gesprochen. Im Absatz „Beschreibung" steht dagegen: „Wenn ein Element Benutzereingaben erwartet, werden Beschriftungen, Anweisungen oder Hilfetexte bereitgestellt, die dem Benutzer ausreichend Information geben, um Fehler zu vermeiden." Darunter verstehe ich eher die inhaltliche Aussagekraft, die aber im Prüfkriterium 1.05.1 behandelt wird.<br />
Die Abgrenzung der beiden Prüfkriterien 1.05.1 und 2.06.1 ist nur im Absatz „Einordnung" klar beschrieben. Vielleicht könnte man es bereits im Absatz „Beschreibung" deutlicher formulieren.<br />
<br />
22.02.2018 Johannes Fischer (DZB)<br><br />
Ok, ich habe es jetzt verstanden und kann Ihren Hinweis auch nachvollziehen. Mein Vorschlag dazu: Vielleicht könnte man im Bereich "Beschreibung" nach dem ersten Satz etwas hinzufügen. Man könnte zum Beispiel so formulieren:<br />
<br />
Wenn ein Element Benutzereingaben erwartet, werden Beschriftungen, Anweisungen oder Hilfetexte bereitgestellt, die dem Benutzer ausreichend Information geben, um Fehler zu vermeiden. Darunter versteht man z. B., dass Symbole für Pflichtfelder erklärt werden, dass Label für Dialogelemente vorhanden sind und dass erforderliche Eingabeformate erklärt werden. Die Aussagekraft des Labels an sich wird in diesem Prüfschritt nicht beurteilt, siehe Einordnung.<br><br />
Dialogelemente, die Benutzereingaben erwarten, sind u.a. Eingabefelder, Auswahllisten, Optionsschaltflächen, Absenden-Schaltflächen.<br />
<br />
04.04.2018, Detlef Girke:<br/><br />
Ich fand den Satz so gut, dass ich ihn direkt und ohne Absprache eingefügt habe. Ich werde in der nächsten Telefonkonferenz noch einmal nachfragen, ob die anderen diesen Satz auch in Ordnung finden.<br />
<br>Monika Augustin: Hinweis wurde bereits übernommen. Diskussion beendet 21.12.2020<br />
<br />
= Vorbelegung Eingabefeld =<br />
21.12.2017 Johannes Fischer (DZB)<br><br />
Im Bereich "Beispiele" wird auf Vorbelegungen (Placeholder) von Formularfeldern eingegangen: "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."<br />
Im WCAG-Kriterium 3.3.2 steht zwar nicht direkt etwas zu Vorbelegungen. Aber in den Tutorials zu barrierefreien Webseiten des World Wide Web Consortiums gibt es auch einen Teil zu Placeholdern (https://www.w3.org/WAI/tutorials/forms/instructions/#placeholder-text). Dort steht, dass Placeholder nicht Labels ersetzen. Erlaubt wird zwar, die Labels unsichtbar darzustellen und nur assistiven Technologien zugänglich zu machen. Empfohlen wird aber auch das nicht, weil es z. B. für kognitiv eingeschränkte Menschen gut ist, wenn das Label auch während der Eingabe in das Eingabefeld sichtbar bleibt. Aus meiner Sicht sollten wir die Prüfanleitung ähnlich dazu formulieren.</div>Maugustinhttps://biti-wiki.de/index.php?title=Diskussion:2.06.1_-_Ausreichende_Anweisungen_f%C3%BCr_Benutzereingaben&diff=1561Diskussion:2.06.1 - Ausreichende Anweisungen für Benutzereingaben2020-12-21T11:19:08Z<p>Maugustin: </p>
<hr />
<div>= Pflichtfeld-Kennzeichnung =<br />
21.12.2017 Johannes Fischer (DZB)<br><br />
Im Bereich "Beispiele" steht, dass ein Zeichen für Pflichtfelder (z. B. das Stern-Zeichen (*)) vor oder auch hinter dem Formular erklärt werden soll. Der Prüfschritt bezieht sich in der EN 301 549 auf das Kriterium 11.2.1.34, welches identisch zum WCAG 2.0 Kriterium 3.3.2 ist. In der WCAG gibt es dabei die Technik H90 (https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/H90), welche im Example 2 fordert, dass ein Zeichen zur Anzeige eines Pflichtfelds vor dem zugehörigen Formular erklärt werden muss. Die Erklärung erst hinter dem Formular ist nicht ausreichend.<br />
- Monika Augustin: Hinweis wurde bereits übernommen. Diskussion beendet 21.12.2020<br />
<br />
<br />
= Einordnung bzw. Beschreibung =<br />
20.02.2018 Thomas Ernst (Stiftung Pfennigparade)<br><br />
Die Abgrenzung zum Erfolgskriterium "1.05.1 Prägnante Beschriftungen" müsste bei Beschriftungen von Eingabefeldern klarer formuliert werden.<br />
<br />
20.02.2018 Johannes Fischer (DZB)<br><br />
Herr Ernst, wie meinen Sie das genau? Sollte man den Begriff "Verständlichkeit" durch "Aussagekraft" ersetzen oder meinen Sie etwas anderes?<br />
<br />
22.02.2018 Thomas Ernst (Stiftung Pfennigparade)<br><br />
In 2.06.1 Absatz "Einordnung" wird von „formalen Gestaltungsregeln" gesprochen. Im Absatz „Beschreibung" steht dagegen: „Wenn ein Element Benutzereingaben erwartet, werden Beschriftungen, Anweisungen oder Hilfetexte bereitgestellt, die dem Benutzer ausreichend Information geben, um Fehler zu vermeiden." Darunter verstehe ich eher die inhaltliche Aussagekraft, die aber im Prüfkriterium 1.05.1 behandelt wird.<br />
Die Abgrenzung der beiden Prüfkriterien 1.05.1 und 2.06.1 ist nur im Absatz „Einordnung" klar beschrieben. Vielleicht könnte man es bereits im Absatz „Beschreibung" deutlicher formulieren.<br />
<br />
22.02.2018 Johannes Fischer (DZB)<br><br />
Ok, ich habe es jetzt verstanden und kann Ihren Hinweis auch nachvollziehen. Mein Vorschlag dazu: Vielleicht könnte man im Bereich "Beschreibung" nach dem ersten Satz etwas hinzufügen. Man könnte zum Beispiel so formulieren:<br />
<br />
Wenn ein Element Benutzereingaben erwartet, werden Beschriftungen, Anweisungen oder Hilfetexte bereitgestellt, die dem Benutzer ausreichend Information geben, um Fehler zu vermeiden. Darunter versteht man z. B., dass Symbole für Pflichtfelder erklärt werden, dass Label für Dialogelemente vorhanden sind und dass erforderliche Eingabeformate erklärt werden. Die Aussagekraft des Labels an sich wird in diesem Prüfschritt nicht beurteilt, siehe Einordnung.<br><br />
Dialogelemente, die Benutzereingaben erwarten, sind u.a. Eingabefelder, Auswahllisten, Optionsschaltflächen, Absenden-Schaltflächen.<br />
<br />
04.04.2018, Detlef Girke:<br/><br />
Ich fand den Satz so gut, dass ich ihn direkt und ohne Absprache eingefügt habe. Ich werde in der nächsten Telefonkonferenz noch einmal nachfragen, ob die anderen diesen Satz auch in Ordnung finden.<br />
- Monika Augustin: Hinweis wurde bereits übernommen. Diskussion beendet 21.12.2020<br />
<br />
= Vorbelegung Eingabefeld =<br />
21.12.2017 Johannes Fischer (DZB)<br><br />
Im Bereich "Beispiele" wird auf Vorbelegungen (Placeholder) von Formularfeldern eingegangen: "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."<br />
Im WCAG-Kriterium 3.3.2 steht zwar nicht direkt etwas zu Vorbelegungen. Aber in den Tutorials zu barrierefreien Webseiten des World Wide Web Consortiums gibt es auch einen Teil zu Placeholdern (https://www.w3.org/WAI/tutorials/forms/instructions/#placeholder-text). Dort steht, dass Placeholder nicht Labels ersetzen. Erlaubt wird zwar, die Labels unsichtbar darzustellen und nur assistiven Technologien zugänglich zu machen. Empfohlen wird aber auch das nicht, weil es z. B. für kognitiv eingeschränkte Menschen gut ist, wenn das Label auch während der Eingabe in das Eingabefeld sichtbar bleibt. Aus meiner Sicht sollten wir die Prüfanleitung ähnlich dazu formulieren.</div>Maugustinhttps://biti-wiki.de/index.php?title=3.02.2_-_Name_von_grafischen_Bedienelementen_abrufen&diff=15603.02.2 - Name von grafischen Bedienelementen abrufen2020-12-18T09:13:18Z<p>Maugustin: /* Beispiele */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Der Name von grafischen Bedienelementen kann durch Maus- und Tastaturbedienung angezeigt werden. Die Anforderung bezieht sich auf grafische Elemente, die nicht zum Betriebssystemstandard gehören und keine Beschriftung haben.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Die Elemente in einer Symbolleiste haben jeweils ein Kontextmenü, das den Namen des Elements enthält. Das Kontextmenü kann entsprechend dem Windows-Standard mit der rechten Maustaste und mit der Tastenkombination UMSCHALT + F10 abgerufen werden.<br />
<br />
Die Funktion „Drucken“ wird durch ein Icon in Form eines Druckers dargestellt. Bei Mausberührung erscheint ein Tooltipp mit dem Namen „Drucken“. Zusätzlich kann der Name durch einen Tastaturbefehl abgerufen werden.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist anwendbar, wenn die Software grafische Bedienelemente enthält.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
Die Symbole auf grafischen Bedienelementen sind nicht für alle Benutzer selbsterklärend. Bevor ein Benutzer ein Bedienelement auslöst, muss er überprüfen können, ob sich hinter dem Symbol die vermutete Funktion verbirgt. Wenn der Benutzer eine Erläuterung zum Element in der Dokumentation nachschlagen will, benötigt er ebenfalls den Namen des Elements.<br />
<br />
Diese Information muss jedem Benutzer zur Verfügung stehen, unabhängig von dem verwendeten Bediengerät. Daher genügt es nicht, wenn bei Mausberührung ein Tooltipp mit dem Namen des Elements erscheint, oder wenn der Name vom Screenreader ausgegeben wird. Ein motorisch behinderter Benutzer, der auf die Tastatur angewiesen ist, muss die Information mit einem Tastaturbefehl abrufen können.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Ermitteln Sie das Tastaturkommando zur Anzeige von Namen anhand der Dokumentation.<br />
<br />
Praktische Erprobung: Werden die Namen der grafischen Bedienelemente durch eine Mausaktion (Hover, rechte Maustaste) und ebenso durch eine Tastaturaktion (F10, sonstige) am Bildschirm angezeigt? <br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
Der Prüfschritt könnte aufgeteilt werden, Maus und Tastaturbedienung könnten separat untersucht werden. Das wäre interessant, die Auswertung nach Modalitäten / nach Art der Behinderung eingeführt werden sollte.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
==== WCAG ====<br />
<br />
3.3.5 Kontextsensitive Hilfe<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
<br />
8.1.5 Anzeige von Namen<br />
<br />
==== BITV-Test ====<br />
<br />
2.4.6a Title-Attribut für Symbole</div>Maugustinhttps://biti-wiki.de/index.php?title=1.02.2_-_Leserliche_Schrift&diff=15481.02.2 - Leserliche Schrift2020-08-31T10:31:13Z<p>Maugustin: /* - */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Die Anwendung verwendet gut lesbare Schriften. Die auf dem Bildschirm dargestellten Zeichen müssen scharf, deutlich und ausreichend groß sein sowie einen angemessenen Zeichen- und Zeilenabstand haben. Es gelten die folgenden Spezifikationen:<br />
<br />
* Die Anwendung wird auf dem ausgewählten Bildschirm (siehe Testsystem) mit scharfen Zeichen dargestellt.<br />
* Lateinische Schriftzeichen erscheinen in einem Sehwinkel von mindestens 16 Bogenminuten, dies entspricht einer Versalhöhe von 2,9 mm bei einem Leseabstand von 50 cm (= Standard-Bildschirm des Testsystems).<br />
* Der Zeichensatz hat eine Zeichenbreite der Großbuchstaben (ausgenommen Buchstabe „I“) von 70 Prozent bis 100 Prozent der Versalhöhe, sowie eine Mittelhöhe der Kleinbuchstaben von etwa 70 Prozent der Versalhöhe.<br />
* Sehr feine Schriften werden vermieden.<br />
* Großschreibung sowie die Textattribute fett, kursiv und unterstrichen werden nur in geringem Umfang zur Hervorhebung weniger Worte verwendet.<br />
* Der horizontale Zeichenabstand beträgt mindestens ein Bildelement (Pixel).<br />
* Bei Beschriftungen beträgt der vertikale Zeichenabstand (Zeilenabstand) mindestens ein Bildelement (Pixel).<br />
* Bei Fließtext beträgt der vertikale Zeichenabstand (Zeilenabstand) mindestens 25 Prozent der Versalhöhe.<br />
* Fließtext kann auf 80 Zeichen pro Zeile angepasst werden (z.B. durch Verringern der Fensterbreite).<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Keine<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
Die Anwendung soll mindestens die Anforderungen der Bildschirmarbeitsverordnung für gut lesbare Schriften einhalten, die auf normalsichtige Benutzer ausgerichtet sind. Gut lesbare Schriften sind für alle Benutzer wichtig, um eine Anwendung effizient zu nutzen, insbesondere aber für Menschen mit einer leichten Beeinträchtigung des Sehens aufgrund normaler Alterung.<br />
<br />
Als Mindest-Sehwinkel wird der in ISO 9241-303 für lateinische Schriftzeichen gesetzte Wert von 16 Bogenminuten angenommen. Die meisten Arbeitsaufgaben erfordern einen Sehwinkel von 20-22 Bogenminuten, bis hin zu 31 Bogenminuten. Die für den Standard-Bildschirm berechnete Schriftgröße von 2,9 mm Versalhöhe gilt somit als Mindestgröße für alle Schriften.<br />
<br />
Die Möglichkeit einer vergrößerten Darstellung kann nur dann gegen die Anforderung einer ausreichenden Schriftgröße aufgerechnet werden, wenn die Vergrößerung mängelfrei funktioniert. Grundsätzlich aber darf die Möglichkeit einer Individualisierung nicht dazu führen, dass die Anwendung in der Normalansicht nicht mehr gut lesbar ist. Denn Benutzer mit geringen Einschränkungen wollen in der Regel die Normalansicht verwenden, um sich leichter mit anderen Benutzern austauschen zu können.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Die Anwendung auf dem Standard-Bildschirm oder auf einem Bildschirm nach Herstellerempfehlung (siehe Testsystem) darstellen.<br />
<br />
Sichtprüfung: Werden die Spezifikationen der Anforderung eingehalten? Im Zweifelsfall Zeichengrößen und Abstände nachmessen mit dem Keseling Bildschirmlineal (siehe Werkzeugliste).<br />
<br />
Die Versalhöhe entspricht der Höhe der Großbuchstaben E oder Z. Die Breite der Großbuchstaben ist zu messen an den Buchstaben H und M. Die Mittelhöhe der Kleinbuchstaben entspricht der Höhe der Buchstaben z oder x. Es gelten jeweils die Außenmaße. Der vertikale Zeichenabstand (Zeilenabstand) ist zu messen zwischen Kleinbuchstaben mit Unterlänge und Großbuchstaben mit Oberlänge – zum Beispiel erste Zeile der Kleinbuchstabe q, zweite Zeile der Großbuchstabe Ü. Pixel sind zu erkennen in der Lupe des Bildschirmlineals.<br />
<br />
Sehr feine Schriften sind in der Lupe des Bildschirmlineals daran zu erkennen, dass sie keine durchgehenden Linien in der Schriftfarbe bilden. Diese Schriften sollten bereits im Prüfschritt 1.01.0 „Ausreichender Kontrast“ aufgefallen sein.<br />
<br />
Bei Mängeln im Anschluss die Prüfschritte 5.01.1 „Schriftvergrößerung auf 200%“ und 5.02.2 „Bei vergrößerter Darstellung Layout anpassen“ durchführen.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Einschränkung.<br />
<br />
Schriftgrößen von weniger als 2,9 mm sind eine Einschränkung.<br />
<br />
Sofern zugleich Mängel bei der Vergrößerung vorliegen, siehe Prüfschritte 5.01.1 „Schriftvergrößerung auf 200%“ und 5.02.2 „Bei vergrößerter Darstellung Layout anpassen“, gilt das Folgende: <br />Schriftgrößen von weniger als 80% der Anforderung (2,3 mm) sind eine Barriere.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.4.12 Text spacing<br />
<br />
==== WCAG ====<br />
<br />
==== 1.4.8 Visuelle Präsentation ====<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
<br />
==== - ====<br />
<br />
==== Sonstige ====<br />
<br />
ISO 9241-303 Anforderungen an elektronische optische Anzeigen<br />
<br />
DGUV-Richtlinie 215-410 Bildschirm- und Büroarbeitsplätze</div>Maugustinhttps://biti-wiki.de/index.php?title=1.01.0_-_Ausreichender_Kontrast&diff=15471.01.0 - Ausreichender Kontrast2020-08-31T10:29:40Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Die Kombination von gesättigtem Rot mit Schwarz ist trotz ausreichenden Helligkeitskontrasts als Vorder- und Hintergrundfarbe von Zeichen zu vermeiden.<br />
<br />
Die Anforderung gilt nicht<br />
<br />
* für Bedienelemente, die aktuell nicht zur Verfügung stehen und „ausgegraut“ dargestellt sind<br />
* für Symbole, die mit ausreichendem Kontrast beschriftet sind<br />
* für Symbole, bei denen eine bestimmte Farbgestaltung wesentlich ist, z.B. für Logos<br />
* für Bilder<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
keine<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Der Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Von diesem Erfolgskriterium profitieren auch Benutzer von Schwarzweiß-Monitoren und in Umgebungen mit starkem Lichteinfall.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
* Die Anwendung mit dem Standard-Farbschema verwenden.<br />
* Sichtprüfung: haben die Schriften und Symbole der Anwendung einen ausreichenden Helligkeitskontrast? Wird gesättigtes Rot in Kombination mit Schwarz vermieden?<br />
* 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.<br />
* 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. <br />
* Bei konturierten Zeichen die Farbe der Kontur als Vordergrund auswählen.<br />
* 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.<br />
* 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.<br />
<br />
<br />
<br />
* 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.<br />Anmerkung: Der Prüfer muss nicht selbst ermitteln, welches Windows-Design für die Anwendung geeignet ist.<br />
* 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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Kontrastwerte von weniger als 4,5:1 bzw. 3:1 sind eine Einschränkung.<br />
<br />
Kontrastwerte von weniger als 80% der Anforderung (3,6:1 bzw. 2.4:1) sind eine Barriere.<br />
<br />
Kontrastwerte von weniger als 66,6% der Anforderung (3:1 bzw. 2:1) sind eine Blockade, sofern Elemente betroffen sind, die für die Arbeitsaufgabe wesentlich sind.<br />
<br />
Gesättigtes Rot mit Schwarz als Zeichenfarbe wird nicht bewertet, eine entsprechende Beobachtung wird als Empfehlung mitgeteilt.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
Der Bewertungsmaßstab benötigt Verifizierung.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.4.3 Non-text contrast<br />
<br />
11.2.1.12 Contrast (minimum)<br />
<br />
==== WCAG ====<br />
<br />
1.4.3 Kontrast (Minimum)<br />
<br />
1.4.11 Nicht-Text Kontrast (neu)<br />
<br />
==== WCAG-Techniques ====<br />
<br />
G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text<br />
<br />
==== ISO9241-171 ====<br />
<br />
10.4.5 Für Kontrast zwischen Vordergrund und Hintergrund sorgen<br />
<br />
==== Sonstige ====<br />
<br />
ISO 9241-303 Anforderungen an elektronische optische Anzeigen<br />
<br />
ISO 9241-125 Anleitung zur visuellen Informationsdarstellung </div>Maugustinhttps://biti-wiki.de/index.php?title=4.09.1_-_Benachrichtigung_%C3%BCber_%C3%84nderungen&diff=15464.09.1 - Benachrichtigung über Änderungen2020-08-27T14:41:20Z<p>Maugustin: /* WCAG */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Rückmeldungen und Benachrichtigungen sollen für die Benutzerinteraktion relevant sein und den Benutzer nicht stören.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Bei der Auswahl von Einträgen in einer Mailbox erhält der Benutzer die Rückmeldung „ausgewählt“ oder „markiert“.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Der fortlaufend sich ändernde Inhalt eines Börsentickers wird vom Screenreader nicht vorgelesen, um die zugleich erforderliche Programmbedienung nicht zu stören.<br />
<br />
Einschränkung: Die Anwendung versetzt den Tastaturfokus, aber der Screenreader sagt erst beim nächsten Tastendruck des Benutzers die neue Position an.<br />
<br />
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.<br />
<br />
Fehler: In einem Chatprogramm wird beim Erscheinen neuer Beiträge der gesamte Inhalt vorgelesen. Richtig wäre, nur den neu erschienenen Beitrag vorzulesen.<br />
<br />
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.<br />
Fehler: Wie zuvor, aber die neuen Eingabefelder erscheinen oberhalb der Optionsschaltflächen, wo sie bei kleinem Bildausschnitt und sequentieller Bedienung nicht wahrgenommen werden.<br />
<br />
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“.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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“.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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?<br />
<br />
Ggf. ergänzen Sie das Szenario um Gelegenheit zur Überprüfung von Meldungen, z.B. indem Sie den Empfang einer E-Mail provozieren.<br />
<br />
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. <br />
<br />
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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Wenn die Rückmeldung durch einen zusätzlichen Tastendruck gesucht werden muss, so ist dies eine Einschränkung. <br />
<br />
Weitere Mängel werden nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
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.<br />
<br />
Änderungen, die durch einen mitgeführten Tastaturfokus auf sich aufmerksam machen, werden im Prüfschritt 3.07.0 „Sinnvolle Fokus-Reihenfolge“ behandelt.<br />
<br />
Änderungen, die durch bloße Navigationsbewegungen des Benutzers entstehen, werden im Prüfschritt 3.08.1 „Keine unerwartete Kontextänderung“ behandelt.<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.4.1.2 Name, role, value<br />
<br />
11.4.1.3 Status messages<br />
<br />
11.5.2.15 Change notification<br />
<br />
==== WCAG ====<br />
4.1.2 Name, Rolle, Wert<br />
<br />
4.1.3 Statusmeldunge<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen<br />
<br />
==== Sonstige ====<br />
WAI-ARIA Authoring Practices 1.1 Kapitel 6.2 Implementing Live Regions</div>Maugustinhttps://biti-wiki.de/index.php?title=4.09.1_-_Benachrichtigung_%C3%BCber_%C3%84nderungen&diff=15454.09.1 - Benachrichtigung über Änderungen2020-08-27T14:40:53Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Rückmeldungen und Benachrichtigungen sollen für die Benutzerinteraktion relevant sein und den Benutzer nicht stören.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Bei der Auswahl von Einträgen in einer Mailbox erhält der Benutzer die Rückmeldung „ausgewählt“ oder „markiert“.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Der fortlaufend sich ändernde Inhalt eines Börsentickers wird vom Screenreader nicht vorgelesen, um die zugleich erforderliche Programmbedienung nicht zu stören.<br />
<br />
Einschränkung: Die Anwendung versetzt den Tastaturfokus, aber der Screenreader sagt erst beim nächsten Tastendruck des Benutzers die neue Position an.<br />
<br />
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.<br />
<br />
Fehler: In einem Chatprogramm wird beim Erscheinen neuer Beiträge der gesamte Inhalt vorgelesen. Richtig wäre, nur den neu erschienenen Beitrag vorzulesen.<br />
<br />
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.<br />
Fehler: Wie zuvor, aber die neuen Eingabefelder erscheinen oberhalb der Optionsschaltflächen, wo sie bei kleinem Bildausschnitt und sequentieller Bedienung nicht wahrgenommen werden.<br />
<br />
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“.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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“.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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?<br />
<br />
Ggf. ergänzen Sie das Szenario um Gelegenheit zur Überprüfung von Meldungen, z.B. indem Sie den Empfang einer E-Mail provozieren.<br />
<br />
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. <br />
<br />
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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Wenn die Rückmeldung durch einen zusätzlichen Tastendruck gesucht werden muss, so ist dies eine Einschränkung. <br />
<br />
Weitere Mängel werden nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
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.<br />
<br />
Änderungen, die durch einen mitgeführten Tastaturfokus auf sich aufmerksam machen, werden im Prüfschritt 3.07.0 „Sinnvolle Fokus-Reihenfolge“ behandelt.<br />
<br />
Änderungen, die durch bloße Navigationsbewegungen des Benutzers entstehen, werden im Prüfschritt 3.08.1 „Keine unerwartete Kontextänderung“ behandelt.<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.4.1.2 Name, role, value<br />
<br />
11.4.1.3 Status messages<br />
<br />
11.5.2.15 Change notification<br />
<br />
==== WCAG ====<br />
4.1.2 Name, Rolle, Wert<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen<br />
<br />
==== Sonstige ====<br />
WAI-ARIA Authoring Practices 1.1 Kapitel 6.2 Implementing Live Regions</div>Maugustinhttps://biti-wiki.de/index.php?title=7.03.1_-_Text_als_Text_codieren&diff=15447.03.1 - Text als Text codieren2020-08-27T14:38:30Z<p>Maugustin: /* WCAG */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Texte werden bei Vergrößerung auf 200% mit scharfen Konturen dargestellt.<br />
<br />
Eine Button-Beschriftung wird im Kontrastmodus mit angepassten Farben dargestellt.<br />
<br />
Texte werden vom Screenreader vorgelesen, ohne dass OCR hinzugeschaltet werden muss.<br />
<br />
Eine Bildunterschrift, die im Bild dargestellt ist, wird vom Screenreader vorgelesen.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Der Prüfschritt betrifft alle im Szenario vorkommenden Texte: Beschriftungen, Anweisungen, Meldungen, Hilfetexte und Daten, nicht aber Logos (Wortbildmarken) und Abbildungen von Schrift.<br />
<br />
Sichten Sie erneut diejenigen Elemente, die in folgenden vorangegangenen Prüfschritten aufgefallen sind:<br />
<br />
* 4.01.0 Wiedergabe von Text<br />
* 5.01.1 Schriftvergrößerung auf 200%<br />
* 5.03.1 Kontrastmodus ist nutzbar<br />
* 7.02.1 Objektinformationen für Hilfstechniken verfügbar machen<br />
<br />
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.<br />
<br />
Bei kompilierten Anwendungen: Der Prüfschritt ist nicht erfüllt, wenn wenigstens 2 der folgenden Mängel vorliegen:<br />
<br />
* Im Screenreader wird der Text nicht vorgelesen.<br />
* Bei Vergrößerung auf 200% sind die Konturen der Schriftzeichen pixelig oder verschwommen.<br />
* Im Windows Kontrastmodus passen sich die Farben nicht an.<br />
* Die Accessibility-Schnittstelle enthält nicht den angezeigten Text.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.4.5 Images of text<br />
<br />
==== WCAG ====<br />
<br />
1.4.5 Schriftgrafiken<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== - ====<br />
<br />
==== ISO9241-171 ====</div>Maugustinhttps://biti-wiki.de/index.php?title=4.11.1_-_Automatischer_Sprachwechsel&diff=15434.11.1 - Automatischer Sprachwechsel2020-08-27T14:37:39Z<p>Maugustin: /* WCAG */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Wenn die Anwendung in einer anderen Sprache als die Plattform verfasst ist, spricht die Sprachausgabe automatisch die Sprache der Anwendung.<br />
<br />
Der Prüfschritt bezieht sich auf die Sprache der Anwendung, nicht auf den Sprachwechsel bei mehrsprachigen Inhalten.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
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. <br />
<br />
Wenn der Benutzer zwischen mehreren offenen Anwendungen wechselt, wechselt die Sprache automatisch, sobald die zu prüfende Anwendung aktiv wird. <br />
<br />
Fehler: Der Benutzer muss zunächst im Screenreader die Sprache umstellen, bevor er die Anwendung benutzen kann.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist anwendbar, wenn die Software in einer Fremdsprache verfasst ist. <br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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. <br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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.<br />
<br />
Erprobung: Wechselt der Screenreader automatisch die Sprache, wenn die fremdsprachige Anwendung aktiv wird? <br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung[Abgrenzung zu anderen Prüfschritten] ===<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.3.1.1 Language of software<br />
<br />
==== WCAG ====<br />
<br />
3.1.1 Sprache der Software<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====</div>Maugustinhttps://biti-wiki.de/index.php?title=4.10.2_-_Zus%C3%A4tzliche_kontextsensitive_Hilfe&diff=15424.10.2 - Zusätzliche kontextsensitive Hilfe2020-08-27T14:36:54Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Der Screenreader gibt Bedienoptionen und Tastaturkommandos aus, die in der aktuellen Programmsituation zur Verfügung stehen.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Nach Drücken der Alt-Taste können die Ausklappmenüs der Anwendung genutzt werden. Die Tastaturkommandos für den jeweiligen Befehl stehen rechtsbündig hinter der jeweiligen Menüauswahl. Der Screenreader liest den ausgewählten Punkt wie auch das dazu gehörende Tastaturkommando vor.<br />
<br />
Die Multifunktionsleiste der Textverarbeitung wird angesteuert und einzelne Bediensymbole werden mit dem Screenreader fokussiert. Der Hilfetext, der bei Mausnutzung unterhalb des Symbols erscheint, wird vollständig ausgegeben.<br />
<br />
Eine Auswahlliste kann mit einer bestimmten Tastenkombination geöffnet und mit den Pfeiltasten navigiert werden. Die Eingabe kann mit Enter bestätigt werden. Die Vorgehensweise wird präzise von der Screenreader-Ausgabe beschrieben, sobald das Element den Fokus erhalt.<br />
<br />
Ein Content-Management-System hat ein Seitenverzeichnis, in dem Informationen zum Bearbeitungsstand wie „nicht öffentlich“ und „zum Löschen vorgemerkt“ durch Farbe und Textattribut (grau kursiv, rot durchgestrichen) codiert sind. Diese Informationen sind in der Accessibility-Schnittstelle als „Beschreibung“ dokumentiert und werden vom Screenreader bei Fokussierung des Elements ausgegeben.<br />
<br />
Fehler: In der Bedienoberfläche der Anwendung verfügbare kontextsensitive Hilfe wird vom Screenreader nicht ausgegeben.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
Für Benutzer von Screenreadern ist es besonders umständlich, Informationen zur Bedienung einer Software in der Dokumentation nachzuschlagen. Zudem fehlen ihnen Kontextinformationen, die sehende Benutzer aus der optischen Gestaltung der Bedienoberfläche gewinnen. Screenreaderbenutzer profitieren besonders von einer kontextsensitiven Hilfe direkt bei der Bedienung.<br />
<br />
Der Screenreader muss bei der Fokussierung von Bedienelementen mindestens die in der Bedienoberfläche der Software verfügbaren Erläuterungen zu Tastaturbefehlen und zur Bedeutung von Bedienelementen ausgeben. Weitere Hilfestellungen soll er aus der Rolle des Elements ableiten, wie etwa die Anweisung „Eingabefeld, geben Sie Text ein“. Die Anwendung kann weitere Hilfen speziell für nicht sehende Benutzer zur Verfügung stellen. In der Accessibility-Schnittstelle gibt es eine Vielzahl von Feldern wie Hilfetext, Beschreibung, Standard-Aktion, Tastenkürzel, die für differenzierte Hilfen genutzt werden können.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests}''<br />
<br />
Stellen Sie fest, welche kontextsensitiven Hilfen die Anwendung direkt in der Bedienoberfläche oder durch Tooltipp abrufbar gibt. Werden sie vom Screenreader bei Fokussierung des Elements wiedergegeben?<br />
<br />
Werden bei selten eingesetzten Bedienelementen Informationen zur Bedienung gegeben?<br />
<br />
Stellen Sie fest, welche weiteren Elemente für nicht sehende Benutzer erklärungsbedürftig sind. Werden Hilfetexte gegeben?<br />
<br />
Wenn keine Hilfetexte ausgegeben werden, prüfen Sie, ob der Screenreader in den Ausführlichkeitseinstellungen korrekt konfiguriert ist, und wiederholen Sie ggf. die Prüfung. <br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.5.2.5 Object Information<br />
<br />
11.5.2.11 List of available actions<br />
<br />
==== WCAG ====<br />
<br />
3.3.5 Hilfe<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====</div>Maugustinhttps://biti-wiki.de/index.php?title=4.08.1_-_Orientierung_in_Tabellen&diff=15414.08.1 - Orientierung in Tabellen2020-08-27T14:36:12Z<p>Maugustin: /* WCAG */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
In Datentabellen sagt der Screenreader in jeder Zelle die Zeile und Spalte an, ebenso Zeilen- und Spaltenüberschriften, soweit diese vorhanden sind.<br />
<br />
Datentabellen sind einfach strukturiert, so dass der blinde Benutzer den Inhalt nachvollziehen kann. <br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
In einer Tabelle sagt der Screenreder in jeder Zelle die Zeilen- und Spaltennummer an, z.B. „Zeile 2 Spalte 3“.<br />
<br />
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.<br />
<br />
Fehler: Die Tabelle ist nicht zellenweise navigierbar.<br />
<br />
Einschränkung: Der Screenreader behandelt Überschriften wie Daten, sagt sie also nur einmal an und wiederholt sie nicht bei jeder Zelle.<br />
<br />
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).<br />
<br />
Fehler: Die Daten verändern ihre Bedeutung, ohne dass dies durch neue Überschriften explizit gemacht wird.<br />
<br />
Fehler: Ein Bedeutungswandel wird ausschließlich durch leere Tabellenzeilen angedeutet.<br />
<br />
Fehler: Die Tabelle ist stark verschachtelt, so dass die Zeilen- und Spaltennummern vom blinden Benutzer nur mit Mühe nachvollzogen werden können.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist anwendbar, wenn die Anwendung Daten in Form von Tabellen präsentiert.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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“.<br />
<br />
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.<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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?<br />
<br />
Bewegen Sie sich mit den Screenreader-Shortcuts durch die Tabelle und stellen Sie fest, ob die unter Beispiele dargestellten Gestaltungsregeln eingehalten werden.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Erfüllt: Datenzellen wie auch Überschriften werden erwartungsgemäß wiedergegeben.<br />
<br />
Barriere: Die Daten erfordern eine Tabellenstruktur, der Screenreader gibt aber nur lineare Inhalte aus.<br />
<br />
Einschränkung: in einer einfach strukturierten Tabelle sind Überschriften vorhanden, die aber nur in der ersten Zeile bzw. Spalte wiedergegeben werden.<br />
<br />
Weitere Mängel werden nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
Synopsen werden im Prüfschritt 4.07.1 „Korrekte Leseabfolge von Inhalten“ behandelt.<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.3.1 Info and relationships<br />
<br />
11.5.2.6 Row, column, and headers<br />
<br />
==== WCAG ====<br />
<br />
1.3.1 Informationen und Beziehungen<br />
<br />
==== WCAG-Techniques ====<br />
<br />
H43 Using id and headers attributes to associate data cells with header cells in data tables<br />
<br />
H63 Using the scope attribute to associate header cells and data cells in data tables<br />
<br />
==== BITV-Test ====<br />
<br />
1.3.1e Datentabellen richtig aufgebaut<br />
<br />
1.3.1f Zuordnung von Tabellenzellen<br />
<br />
==== ISO9241-171 ====<br />
<br />
8.5.10 Angemessene Darstellung von Tabellen ermöglichen</div>Maugustinhttps://biti-wiki.de/index.php?title=4.07.1_-_Korrekte_Leseabfolge_von_Inhalten&diff=15404.07.1 - Korrekte Leseabfolge von Inhalten2020-08-27T14:35:49Z<p>Maugustin: /* WCAG */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Inhalte, die am Bildschirm in Blöcken neben- oder nacheinander angeordnet sind, werden vom Screenreader in korrekter, sinnentsprechender Reihenfolge ausgegeben.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Im Windows Explorer liest der Screenreader zunächst alle Zeilen der Baum-Ansicht und dann alle Zeilen der Detailansicht vor.<br />
<br />
In einer synoptischen Darstellung von Textinhalten liest der Screenreader die linearisierten Zellinhalte vor, ohne dass logische Zusammenhänge auseinandergerissen werden.<br />
<br />
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.<br />
<br />
Fehler: Wenn ein Dialogfenster sich über den Inhalt legt, so vermischt der Screenreader den Text des Dialogs mit dem dahinter liegenden Inhalt.<br />
<br />
Fehler: Beim fortlaufenden Lesen mit dem Screenreader entsteht eine erratische Reihenfolge, deren Sinn nicht nachvollzogen werden kann.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist anwendbar, wenn die Anwendung Inhalte in Blöcken anordnet.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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. <br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Die Anforderung ist erfüllt, wenn wenigstens in einem Screenreader-Modus eine sinnentsprechende Reihenfolge der blockweise angeordneten Inhalte wiedergegeben werden kann.<br />
<br />
Mängel werden nach der Bedeutung der gestörten Information für die Arbeitsaufgabe bewertet.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
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. <br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
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 sinnvolle Reihenfolge erlauben könnte. <br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.3.2 Meaningful sequence<br />
<br />
==== WCAG ====<br />
<br />
1.3.2 Aussagekräftige Reihenfolge<br />
<br />
==== WCAG-Techniques ====<br />
<br />
F49 Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized<br />
<br />
==== ISO9241-171 ====<br />
<br />
==== BITV-Test ====<br />
<br />
1.3.2a Layouttabellen linearisierbar</div>Maugustinhttps://biti-wiki.de/index.php?title=4.05.2_-_Eindeutige_Namen&diff=15394.05.2 - Eindeutige Namen2020-08-27T14:35:01Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Der Name identifiziert das Element und ist eindeutig. Wenn innerhalb eines Kontextes mehrere gleichartige Elemente vorkommen, sollte der Name durch die Umgebung unterscheidbar sein, oder es wird ein unterscheidendes Merkmal hinzugefügt.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Ein Formular ist in mehrere Abschnitte unterteilt, die jeweils durch einen Edit-Button für die Bearbeitung aktiviert werden. Der Screenreader sagt den Namen des Buttons an und kann mit einem Bedienschritt die Überschrift des Abschnitts ausgeben.<br />
<br />
In einer Anwendung symbolisiert ein Fragezeichen in einem Kreis die kontextsensitive Hilfe zu bestimmten Bereichen. In der Beschreibung des Buttons (und damit im Tooltipp) wird jeweils das Hilfethema genannt.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar. <br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
Screenreadernutzer lesen jedes Bedienelement einzeln und sind auf den Namen des Elements angewiesen, um seinen Zweck zu erkennen. Daher sollten die Namen der Elemente innerhalb eines Kontextes eindeutig sein. Wenn eine Bezeichnung mehrfach vorkommt, sollte ein Unterscheidungsmerkmal hinzugefügt werden, oder die erforderlichen Zusatzinformationen sollten aus dem Kontext einfach zu beschaffen sein.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Feststellen, ob mehrere gleich benannte Elemente vorkommen. Element im Screenreader aktivieren und feststellen, ob der Name des Elements eindeutig angesagt wird. Falls dies nicht der Fall ist, überprüfen, ob eine Zusatzinformation mit einem Bedienschritt ermittelt werden kann.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Barriere oder eine Einschränkung, je nachdem wie aufwändig es ist, notwendige Zusatzinformationen zu ermitteln.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
Der Prüfschritt basiert auf ISO 9241-171 8.1.3 „Innerhalb des Kontextes eindeutige Namen vorsehen“ und ist daher in Konformitätsstufe II eingeordnet. Eine Teilmenge des Prüfumfangs könnte aufgrund von EN 301549 11. 2.1.23 „Link purpose (in context)“ in Konformitätsstufe I eingeordnet werden. Hierbei handelt es sich um Links i.e.S. und ausdrücklich nicht um Buttons und sonstige Bedienelemente. Da Links in Anwendungssoftware relativ marginal sind, wurde auf einen entsprechenden Prüfschritt verzichtet.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.2.4.4 Link purpose (in context)<br />
<br />
==== WCAG ====<br />
<br />
2.4.4 Linkzweck (im Kontext)<br />
<br />
2.4.9 Linkzweck (reiner Link)<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== BITV-Test ====<br />
<br />
==== 2.4.4.a Aussagekräftige Linktexte ====<br />
<br />
==== ISO9241-171 ====<br />
<br />
8.1.3 Innerhalb des Kontextes eindeutige Namen vorsehen</div>Maugustinhttps://biti-wiki.de/index.php?title=2.02.2_-_Sichtbare_R%C3%BCckmeldung&diff=15382.02.2 - Sichtbare Rückmeldung2020-08-27T14:32:57Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Bedienelemente unterscheiden sich von anderen Anzeigen, indem sie bei Berührung eine deutlich sichtbare Rückmeldung geben. Wenn der Mauszeiger auf ein Bedienelement zeigt, verändern der Mauszeiger und/oder das Bedienelement ihr Aussehen. Wenn ein Bedienelement ausgewählt wurde, ist der veränderte Status sichtbar.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Wenn der Mauszeiger auf ein Feld zeigt, in dem eine Texteingabe möglich ist (Formular, Textbearbeitungsprogramm), so wird er zum Caret.<br />
<br />
Zeigt der Mauszeiger auf einen Link, so wird er zur zeigenden Hand.<br />
<br />
Eine Schaltfläche, auf die der Mauszeiger zeigt, ändert ihr Aussehen (Farbe, Schrift, Umrandung o.ä.).<br />
<br />
In einem E-Mail-Client wird das vom Mauszeiger berührte Element in der Liste der eingegangenen Mails durch einen andersfarbigen Hintergrund und eine Rahmenlinie am linken Rand angezeigt.<br />
<br />
Ein aktivierter Menüpunkt oder Button ändert sein Aussehen, solange die Aktivierung andauert. <br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
Die sichtbare Rückmeldung ist wichtig, damit ein Benutzer erkennen kann, ob ein Bildschirmelement bedienbar ist, und ob er es mit dem Zeigegerät erfolgreich fokussiert hat. Die Rückmeldung gibt auch Information darüber, ob eine angewählte Funktion verfügbar ist oder vorübergehend nicht funktioniert, und ob eine beabsichtigte Aktivierung erfolgreich war.<br />
<br />
Eine verlässliche Rückmeldung von Bedienelementen gibt Sicherheit in der Bedienung. Wichtig ist dies für jedermann vor allem bei selten genutzten Funktionen. Kognitiv beeinträchtige Benutzer sind auf die verlässliche Rückmeldung von Bedienelementen angewiesen.<br />
<br />
Auch Menschen mit leichter Einschränkung des Sehens, die aus Farbfehlsichtigkeit oder aus normaler Alterung resultiert, sind Mausnutzer. Die Bedingungen für gute Sichtbarkeit von Hervorhebungen sind definiert in den Prüfschritten 1.01.0 „Ausreichender Kontrast“ und 1.07.1 „Informationen nicht allein durch Farbe übermitteln“.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Erprobung: Bedienelemente mit der Maus berühren und aktivieren. Feststellen, ob eine sichtbare Rückmeldung erfolgt.<br />
<br />
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“.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
* <br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
Die Rückmeldung bei Bedienung ist offenbar so selbstverständlich, dass sie in keiner der herangezogenen Richtlinien explizit formuliert wird. Daher wurde als Referenz die Anforderung an einen sichtbaren Tastaturfokus herangezogen und auf die Bedienung mit Zeigegeräten übertragen.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== BITV-Test ====<br />
<br />
2.4.7a Aktuelle Position des Fokus deutlich<br />
<br />
==== EN301549 ====<br />
<br />
11.2.4.7 Focus visible<br />
<br />
==== WCAG ====<br />
<br />
2.4.7 Fokus sichtbar (bezieht sich allerdings nur auf Tastatur)<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====</div>Maugustinhttps://biti-wiki.de/index.php?title=1.07.1_-_Informationen_nicht_allein_durch_Farbe_%C3%BCbermitteln&diff=15371.07.1 - Informationen nicht allein durch Farbe übermitteln2020-08-27T14:30:43Z<p>Maugustin: /* WCAG */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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 werden zusätzlich durch Text oder durch andere visuelle Mittel wie Symbole, Fettung, Unterstreichung, Kontrast, Einrückung etc. vermittelt.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
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.<br />
<br />
Als Markierung wird eine Invertierung von Vorder- und Hintergrundfarbe verwendet.<br />
<br />
Als Markierung wird eine Textfarbe verwendet, deren Helligkeitskontrast im Verhältnis 3:1 von der Textfarbe der umgebenden Elemente abweicht. Zusätzlich erscheint bei hover, active und focus ein Unterscheidungsmerkmal wie z.B ein Haken, Rahmen, eine Unterstreichung etc.<br />
<br />
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.<br />
<br />
Grün wird verwendet, um eine erfolgreiche Aktion zu bestätigen. Die Farbe wird durch ein grafisches Symbol (OK-Haken) ergänzt.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist anwendbar, wenn die Anwendung nicht monochrom gestaltet ist, sondern mehr als eine Farbe für Vordergrund und Hintergrund verwendet.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
Farbunterschiede dürfen nur dann ohne ein zusätzliches grafisches Merkmal zur Übermittlung von Bedeutungsunterschieden verwendet werden, wenn der Helligkeitskontrast ausreicht. Textfarben müssen mindestens im Verhältnis 3:1 gegen die Textfarbe der umgebenden Elemente kontrastieren. Farbflächen müssen ebenfalls mindestens im Verhältnis 3:1 gegen die Umgebungsfarbe kontrastieren.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Sichtprüfung: Haben farblich gekennzeichnete Elemente zusätzliche Kennzeichnungen wie sichtbare Beschriftungen/Beschreibungen, Symbole, Einrückungen, Fettungen?<br />
<br />
Falls nein, haben sie einen ausreichenden Kontrast zu den Elementen bzw. zum Hintergrund der Umgebung? Textfarben müssen mindestens im Verhältnis 3:1 gegen die Textfarbe der umgebenden Elemente kontrastieren. Farbflächen müssen ebenfalls mindestens im Verhältnis 3:1 gegen die Umgebungsfarbe kontrastieren. Das Messen eines Kontrastunterschieds wird im Prüfschritt 1.01.0 „Ausreichender Kontrast“ behandelt. Der Kontrast der markierten Texte in sich (Textfarbe gegen Hintergrundfarbe) muss ebenfalls ausreichend sein.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Einschränkung oder eine Barriere, je nach der Bedeutung des Elements für den geprüften Arbeitsschritt.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
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 &quot;Kontrastmodus ist nutzbar&quot;.<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.4.1 Use of colour<br />
<br />
==== WCAG ====<br />
<br />
1.4.1 Verwendung von Farben<br />
<br />
==== WCAG-Techniques ====<br />
<br />
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<br />
<br />
ISO9241-171<br />
<br />
10.4.1 Informationen nicht allein durch Farbe übermitteln<br />
<br />
==== BITV-Test ====<br />
<br />
1.4.1a Ohne Farben nutzbar<br />
==== Sonstige ====<br />
<br />
ISO 9241-303 Anforderungen an elektronische optische Anzeigen<br />
<br />
DIN 32975 Gestaltung visueller Informationen im öffentlichen Raum zur barrierefreien Nutzung </div>Maugustinhttps://biti-wiki.de/index.php?title=1.01.0_-_Ausreichender_Kontrast&diff=15361.01.0 - Ausreichender Kontrast2020-08-27T14:25:18Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Die Kombination von gesättigtem Rot mit Schwarz ist trotz ausreichenden Helligkeitskontrasts als Vorder- und Hintergrundfarbe von Zeichen zu vermeiden.<br />
<br />
Die Anforderung gilt nicht<br />
<br />
* für Bedienelemente, die aktuell nicht zur Verfügung stehen und „ausgegraut“ dargestellt sind<br />
* für Symbole, die mit ausreichendem Kontrast beschriftet sind<br />
* für Symbole, bei denen eine bestimmte Farbgestaltung wesentlich ist, z.B. für Logos<br />
* für Bilder<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
keine<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Der Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Von diesem Erfolgskriterium profitieren auch Benutzer von Schwarzweiß-Monitoren und in Umgebungen mit starkem Lichteinfall.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
* Die Anwendung mit dem Standard-Farbschema verwenden.<br />
* Sichtprüfung: haben die Schriften und Symbole der Anwendung einen ausreichenden Helligkeitskontrast? Wird gesättigtes Rot in Kombination mit Schwarz vermieden?<br />
* 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.<br />
* 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. <br />
* Bei konturierten Zeichen die Farbe der Kontur als Vordergrund auswählen.<br />
* 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.<br />
* 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.<br />
<br />
<br />
<br />
* 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.<br />Anmerkung: Der Prüfer muss nicht selbst ermitteln, welches Windows-Design für die Anwendung geeignet ist.<br />
* 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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Kontrastwerte von weniger als 4,5:1 bzw. 3:1 sind eine Einschränkung.<br />
<br />
Kontrastwerte von weniger als 80% der Anforderung (3,6:1 bzw. 2.4:1) sind eine Barriere.<br />
<br />
Kontrastwerte von weniger als 66,6% der Anforderung (3:1 bzw. 2:1) sind eine Blockade, sofern Elemente betroffen sind, die für die Arbeitsaufgabe wesentlich sind.<br />
<br />
Gesättigtes Rot mit Schwarz als Zeichenfarbe wird nicht bewertet, eine entsprechende Beobachtung wird als Empfehlung mitgeteilt.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
Der Bewertungsmaßstab benötigt Verifizierung.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.4.11 Non-text contrast<br />
<br />
11.2.1.12 Contrast (minimum)<br />
<br />
==== WCAG ====<br />
<br />
1.4.3 Kontrast (Minimum)<br />
<br />
1.4.11 Nicht-Text Kontrast (neu)<br />
<br />
==== WCAG-Techniques ====<br />
<br />
G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text<br />
<br />
==== ISO9241-171 ====<br />
<br />
10.4.5 Für Kontrast zwischen Vordergrund und Hintergrund sorgen<br />
<br />
==== Sonstige ====<br />
<br />
ISO 9241-303 Anforderungen an elektronische optische Anzeigen<br />
<br />
ISO 9241-125 Anleitung zur visuellen Informationsdarstellung </div>Maugustinhttps://biti-wiki.de/index.php?title=1.01.0_-_Ausreichender_Kontrast&diff=15351.01.0 - Ausreichender Kontrast2020-08-27T14:25:09Z<p>Maugustin: /* WCAG */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Die Kombination von gesättigtem Rot mit Schwarz ist trotz ausreichenden Helligkeitskontrasts als Vorder- und Hintergrundfarbe von Zeichen zu vermeiden.<br />
<br />
Die Anforderung gilt nicht<br />
<br />
* für Bedienelemente, die aktuell nicht zur Verfügung stehen und „ausgegraut“ dargestellt sind<br />
* für Symbole, die mit ausreichendem Kontrast beschriftet sind<br />
* für Symbole, bei denen eine bestimmte Farbgestaltung wesentlich ist, z.B. für Logos<br />
* für Bilder<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
keine<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Der Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Von diesem Erfolgskriterium profitieren auch Benutzer von Schwarzweiß-Monitoren und in Umgebungen mit starkem Lichteinfall.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
* Die Anwendung mit dem Standard-Farbschema verwenden.<br />
* Sichtprüfung: haben die Schriften und Symbole der Anwendung einen ausreichenden Helligkeitskontrast? Wird gesättigtes Rot in Kombination mit Schwarz vermieden?<br />
* 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.<br />
* 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. <br />
* Bei konturierten Zeichen die Farbe der Kontur als Vordergrund auswählen.<br />
* 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.<br />
* 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.<br />
<br />
<br />
<br />
* 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.<br />Anmerkung: Der Prüfer muss nicht selbst ermitteln, welches Windows-Design für die Anwendung geeignet ist.<br />
* 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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Kontrastwerte von weniger als 4,5:1 bzw. 3:1 sind eine Einschränkung.<br />
<br />
Kontrastwerte von weniger als 80% der Anforderung (3,6:1 bzw. 2.4:1) sind eine Barriere.<br />
<br />
Kontrastwerte von weniger als 66,6% der Anforderung (3:1 bzw. 2:1) sind eine Blockade, sofern Elemente betroffen sind, die für die Arbeitsaufgabe wesentlich sind.<br />
<br />
Gesättigtes Rot mit Schwarz als Zeichenfarbe wird nicht bewertet, eine entsprechende Beobachtung wird als Empfehlung mitgeteilt.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
Der Bewertungsmaßstab benötigt Verifizierung.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.4.11 Non-text contrast<br />
11.2.1.12 Contrast (minimum)<br />
<br />
==== WCAG ====<br />
<br />
1.4.3 Kontrast (Minimum)<br />
<br />
1.4.11 Nicht-Text Kontrast (neu)<br />
<br />
==== WCAG-Techniques ====<br />
<br />
G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text<br />
<br />
==== ISO9241-171 ====<br />
<br />
10.4.5 Für Kontrast zwischen Vordergrund und Hintergrund sorgen<br />
<br />
==== Sonstige ====<br />
<br />
ISO 9241-303 Anforderungen an elektronische optische Anzeigen<br />
<br />
ISO 9241-125 Anleitung zur visuellen Informationsdarstellung </div>Maugustinhttps://biti-wiki.de/index.php?title=1.01.0_-_Ausreichender_Kontrast&diff=15341.01.0 - Ausreichender Kontrast2020-08-27T14:24:56Z<p>Maugustin: /* WCAG */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Die Kombination von gesättigtem Rot mit Schwarz ist trotz ausreichenden Helligkeitskontrasts als Vorder- und Hintergrundfarbe von Zeichen zu vermeiden.<br />
<br />
Die Anforderung gilt nicht<br />
<br />
* für Bedienelemente, die aktuell nicht zur Verfügung stehen und „ausgegraut“ dargestellt sind<br />
* für Symbole, die mit ausreichendem Kontrast beschriftet sind<br />
* für Symbole, bei denen eine bestimmte Farbgestaltung wesentlich ist, z.B. für Logos<br />
* für Bilder<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
keine<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Der Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Von diesem Erfolgskriterium profitieren auch Benutzer von Schwarzweiß-Monitoren und in Umgebungen mit starkem Lichteinfall.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
* Die Anwendung mit dem Standard-Farbschema verwenden.<br />
* Sichtprüfung: haben die Schriften und Symbole der Anwendung einen ausreichenden Helligkeitskontrast? Wird gesättigtes Rot in Kombination mit Schwarz vermieden?<br />
* 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.<br />
* 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. <br />
* Bei konturierten Zeichen die Farbe der Kontur als Vordergrund auswählen.<br />
* 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.<br />
* 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.<br />
<br />
<br />
<br />
* 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.<br />Anmerkung: Der Prüfer muss nicht selbst ermitteln, welches Windows-Design für die Anwendung geeignet ist.<br />
* 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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Kontrastwerte von weniger als 4,5:1 bzw. 3:1 sind eine Einschränkung.<br />
<br />
Kontrastwerte von weniger als 80% der Anforderung (3,6:1 bzw. 2.4:1) sind eine Barriere.<br />
<br />
Kontrastwerte von weniger als 66,6% der Anforderung (3:1 bzw. 2:1) sind eine Blockade, sofern Elemente betroffen sind, die für die Arbeitsaufgabe wesentlich sind.<br />
<br />
Gesättigtes Rot mit Schwarz als Zeichenfarbe wird nicht bewertet, eine entsprechende Beobachtung wird als Empfehlung mitgeteilt.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
Der Bewertungsmaßstab benötigt Verifizierung.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.4.11 Non-text contrast<br />
11.2.1.12 Contrast (minimum)<br />
<br />
==== WCAG ====<br />
<br />
1.4.3 Kontrast (Minimum)<br />
1.4.11 Nicht-Text Kontrast (neu)<br />
<br />
==== WCAG-Techniques ====<br />
<br />
G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text<br />
<br />
==== ISO9241-171 ====<br />
<br />
10.4.5 Für Kontrast zwischen Vordergrund und Hintergrund sorgen<br />
<br />
==== Sonstige ====<br />
<br />
ISO 9241-303 Anforderungen an elektronische optische Anzeigen<br />
<br />
ISO 9241-125 Anleitung zur visuellen Informationsdarstellung </div>Maugustinhttps://biti-wiki.de/index.php?title=1.01.0_-_Ausreichender_Kontrast&diff=15331.01.0 - Ausreichender Kontrast2020-08-27T14:24:40Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Die Kombination von gesättigtem Rot mit Schwarz ist trotz ausreichenden Helligkeitskontrasts als Vorder- und Hintergrundfarbe von Zeichen zu vermeiden.<br />
<br />
Die Anforderung gilt nicht<br />
<br />
* für Bedienelemente, die aktuell nicht zur Verfügung stehen und „ausgegraut“ dargestellt sind<br />
* für Symbole, die mit ausreichendem Kontrast beschriftet sind<br />
* für Symbole, bei denen eine bestimmte Farbgestaltung wesentlich ist, z.B. für Logos<br />
* für Bilder<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
keine<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Der Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Von diesem Erfolgskriterium profitieren auch Benutzer von Schwarzweiß-Monitoren und in Umgebungen mit starkem Lichteinfall.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
* Die Anwendung mit dem Standard-Farbschema verwenden.<br />
* Sichtprüfung: haben die Schriften und Symbole der Anwendung einen ausreichenden Helligkeitskontrast? Wird gesättigtes Rot in Kombination mit Schwarz vermieden?<br />
* 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.<br />
* 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. <br />
* Bei konturierten Zeichen die Farbe der Kontur als Vordergrund auswählen.<br />
* 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.<br />
* 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.<br />
<br />
<br />
<br />
* 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.<br />Anmerkung: Der Prüfer muss nicht selbst ermitteln, welches Windows-Design für die Anwendung geeignet ist.<br />
* 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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Kontrastwerte von weniger als 4,5:1 bzw. 3:1 sind eine Einschränkung.<br />
<br />
Kontrastwerte von weniger als 80% der Anforderung (3,6:1 bzw. 2.4:1) sind eine Barriere.<br />
<br />
Kontrastwerte von weniger als 66,6% der Anforderung (3:1 bzw. 2:1) sind eine Blockade, sofern Elemente betroffen sind, die für die Arbeitsaufgabe wesentlich sind.<br />
<br />
Gesättigtes Rot mit Schwarz als Zeichenfarbe wird nicht bewertet, eine entsprechende Beobachtung wird als Empfehlung mitgeteilt.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
Der Bewertungsmaßstab benötigt Verifizierung.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.4.11 Non-text contrast<br />
11.2.1.12 Contrast (minimum)<br />
<br />
==== WCAG ====<br />
<br />
1.4.3 Kontrast (Minimum)<br />
<br />
==== WCAG-Techniques ====<br />
<br />
G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text<br />
<br />
==== ISO9241-171 ====<br />
<br />
10.4.5 Für Kontrast zwischen Vordergrund und Hintergrund sorgen<br />
<br />
==== Sonstige ====<br />
<br />
ISO 9241-303 Anforderungen an elektronische optische Anzeigen<br />
<br />
ISO 9241-125 Anleitung zur visuellen Informationsdarstellung </div>Maugustinhttps://biti-wiki.de/index.php?title=7.04.1_-_Tastaturbedienung_im_Screenreader&diff=15327.04.1 - Tastaturbedienung im Screenreader2020-08-24T12:47:08Z<p>Maugustin: /* EN 301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Bedienelemente können weiterhin mit TAB oder Pfeiltasten fokussiert und mit EINGABE oder LEER ausgelöst werden.<br />
<br />
Tastaturfunktionen zur Bewegung in Daten und zur Selektion von Daten funktionieren weiterhin. <br />
<br />
Die Windows-Standardfunktion STRG+LEER zum Ab- und Hinzuwählen von Daten aus einer Liste, falls in der Anwendung verwendet, funktioniert weiterhin.<br />
<br />
Shortcuts der Anwendung funktionieren weiterhin. Bei Konflikten mit den Shortcuts des Screenreaders greift das „Tastatur durchreichen“-Kommando des Screenreaders.<br />
<br />
Die Windows-Standardfunktionen F3 (Suchen) bzw. F4 (Suche wiederholen), falls in der Anwendung verwendet, funktionieren weiterhin.<br />
<br />
Die Windows-Standardfunktionen STRG+c (Kopieren), STRG+v (Einfügen), STRG+z (Rückgängig), falls in der Anwendung verwendet, funktionieren weiterhin.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Der Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests}''<br />
<br />
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 [https://www.biti-test.de/intern/pruefplaene/pruefplan-details-vollstaendig.xhtml?pp=8#Betriebssystem-Standards Betriebssystem-Standard] abweichen. Beachten Sie besonders solche Arbeitsschritte, in denen ein Wechsel zwischen Bedienoberfläche und Datenbereich (Moduswechsel des Screenreaders) stattfindet.<br />
<br />
Bei Ausfällen stellen Sie fest, ob in der Dokumentation darauf hingewiesen wird, und ob ein alternativer Bedienweg aufgezeigt wird.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Blockade/ Barriere/Einschränkung: Ausfälle in der Tastaturbedienung sind nicht dokumentiert, Bewertung nach der Bedeutung des ausfallenden Elements für die Arbeitsaufgabe.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN 301549 ====<br />
<br />
11.2.1.1 Keyboard<br />
<br />
11.5.2.14 Modification of focus and selection attributes<br />
<br />
==== WCAG ====<br />
<br />
2.1.1 Tastatur<br />
<br />
Konformitätsbedingung 5: Nicht störend<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO 9241-171 ====<br />
<br />
8.5.5 Der unterstützenden Technik die Änderung von Fokus und Auswahl ermöglichen</div>Maugustinhttps://biti-wiki.de/index.php?title=7.03.1_-_Text_als_Text_codieren&diff=15317.03.1 - Text als Text codieren2020-08-24T12:46:44Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Texte werden bei Vergrößerung auf 200% mit scharfen Konturen dargestellt.<br />
<br />
Eine Button-Beschriftung wird im Kontrastmodus mit angepassten Farben dargestellt.<br />
<br />
Texte werden vom Screenreader vorgelesen, ohne dass OCR hinzugeschaltet werden muss.<br />
<br />
Eine Bildunterschrift, die im Bild dargestellt ist, wird vom Screenreader vorgelesen.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Der Prüfschritt betrifft alle im Szenario vorkommenden Texte: Beschriftungen, Anweisungen, Meldungen, Hilfetexte und Daten, nicht aber Logos (Wortbildmarken) und Abbildungen von Schrift.<br />
<br />
Sichten Sie erneut diejenigen Elemente, die in folgenden vorangegangenen Prüfschritten aufgefallen sind:<br />
<br />
* 4.01.0 Wiedergabe von Text<br />
* 5.01.1 Schriftvergrößerung auf 200%<br />
* 5.03.1 Kontrastmodus ist nutzbar<br />
* 7.02.1 Objektinformationen für Hilfstechniken verfügbar machen<br />
<br />
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.<br />
<br />
Bei kompilierten Anwendungen: Der Prüfschritt ist nicht erfüllt, wenn wenigstens 2 der folgenden Mängel vorliegen:<br />
<br />
* Im Screenreader wird der Text nicht vorgelesen.<br />
* Bei Vergrößerung auf 200% sind die Konturen der Schriftzeichen pixelig oder verschwommen.<br />
* Im Windows Kontrastmodus passen sich die Farben nicht an.<br />
* Die Accessibility-Schnittstelle enthält nicht den angezeigten Text.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.4.5 Images of text<br />
<br />
==== WCAG ====<br />
<br />
1.4.5 Bilder eines Textes<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== - ====<br />
<br />
==== ISO9241-171 ====</div>Maugustinhttps://biti-wiki.de/index.php?title=7.02.1_-_Objektinformationen_f%C3%BCr_Hilfstechniken_verf%C3%BCgbar_machen&diff=15307.02.1 - Objektinformationen für Hilfstechniken verfügbar machen2020-08-24T12:46:26Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Objektinformationen zu Bedienelementen und Anzeigen werden über die Accessibility-Schnittstelle des Betriebssystems für Hilfstechniken verfügbar gemacht.<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
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:<br />
<br />
* Name des Elements. Beispiel: der Name eines grafischen Buttons lautet „Kontakt“. <br />
* Rolle bzw. Funktion des Elements. Beispiel: ein Button hat die Rolle „Button“ oder „Schaltfläche“.<br />
* Wert des Elements. Beispiele: Der angezeigte Inhalt eines Textfeldes lautet „Hochofenstraße“. Der Zustand einer Statusanzeige lautet „Internetzugriff hergestellt“.<br />
* Informationen zum Status des Bedienelements wie „verfügbar“, „markiert“, „fokussiert“.<br />
* 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.<br />
* Informationen zur Einordnung des Elements in die Objekthierarchie der Anwendung: Eltern-, Geschwister- und Kind-Elemente.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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:<br />
<br />
Verwenden Sie das Tool Inspect (siehe Werkzeugliste), um zu überprüfen, ob die Anwendung ausreichende Objektinformationen an die Accessibility-Schnittstelle übergibt.<br />
<br />
Untersuchen Sie diejenigen Bedienelemente und Anzeigen, die in der bisherigen Prüfung auffällig geworden sind, insbesondere in den Prüfschritten<br />
<br />
* 3.01.0 Tastaturbedienung für Bedienelemente<br />
* 4.01.0 Wiedergabe von Text<br />
* 4.02.0 Name für grafische Bedienelemente und Anzeigen<br />
* 4.03.1 Name, Rolle, Wert für Formularelemente<br />
* 4.04.0 Name für Gruppen von Elementen<br />
* 4.09.1 Benachrichtigung über Änderungen<br />
* 5.04.1 Fokusverfolgung im Großbildsystem<br />
<br />
Untersuchen Sie zusätzlich für jeden Arbeitsschritt des Szenarios 2 weitere, zufällig gewählte UI-Elemente.<br />
<br />
Öffnen Sie inspect.exe. Unter „Options“ aktivieren Sie mindestens die folgenden Einstellungen:<br />
<br />
* UI Automation Mode – umfasst auch MSAA, hier als „Legacy“-Properties benannt<br />
* Raw View<br />
* SPI_SCREENREADER Flag<br />
* Show Highlight Rectangle<br />
* Watch Focus<br />
* Watch Cursor<br />
* Show Tree<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Untersuchen Sie die Property-Werte in der Ergebnisliste. Achten Sie insbesondere auf folgende Werte:<br />
<br />
* Name oder LegacyIAccessible.Name - der Name des Elements, z.B. &quot;Format übertragen&quot;.<br />
* ControlType – die Rolle, die Funktion des Elements, z.B. „UIA_ButtonControlTypeId (0xC350)“<br />
* LocalizedControlType - Übersetzung der Rolle in die Landessprache, z.B. &quot;Schaltfläche&quot;.<br />
* LegacyIAccessible.Role - MSAA-Rolle, z.B. „Schaltfläche (0x2B)“.<br />
* Value.Value oder LegacyIAccessible.Value – Der Wert oder Inhalt des Elements, ist bei einer reinen Schaltfläche leer, also &quot;&quot;.<br />
* LegacyIAccessible.State – MSAA-Status, z.B. „markierbar,auswählbar,mehrfache Auswahl möglich (0x1300000)“<br />
* IsEnabled - Verfügbar, kann die Werte &quot;true&quot; oder &quot;false&quot; annehmen.<br />
* SelectionItem.IsSelected – Ausgewählt, kann die Werte &quot;true&quot; oder &quot;false&quot; annehmen.<br />
* HasKeyboardFocus - Fokussiert, kann die Werte &quot;true&quot; oder &quot;false&quot; annehmen.<br />
* IsKeyboardFocusable – Fokussierbar, kann die Werte &quot;true&quot; oder &quot;false&quot; annehmen.<br />
* Next, Previous – benachbarte Elemente<br />
* Children – untergeordnete Elemente<br />
* Ancestors – übergeordnete Elemente<br />
<br />
Bitte beachten Sie:<br />
<br />
* Der Name des Elements sollte einer sichtbaren Beschriftung, soweit vorhanden, entsprechen.<br />
* Bei zusammengesetzten Elementen kann der Name auch in einem benachbarten, über- oder untergeordneten Element stehen, das zur selben Gruppe gehört.<br />
* Die Rolle des Elements sollte der in der praktischen Erprobung festgestellten Funktion entsprechen.<br />
* Bei zusammengesetzten Elementen sind Name, Rolle und Status der Einzelteile nicht mehrdeutig oder widersprüchlich angegeben.<br />
* Benachbarte Elemente (prev und next) werden, sofern sie eine Label-Beziehung beschreiben, konsistent verwendet.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Wenn sich kein Rahmen um das Element bildet, oder der Rahmen nicht der visuell wahrnehmbaren Begrenzung des Elements entspricht, so ist dies ein Mangel.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Alle Mängel, soweit nicht bereits gewichtet, werden nach der Bedeutung des gestörten Elements für die Arbeitsaufgabe bewertet.<br />
<br />
Für den Bericht an Entwickler notieren Sie das bemängelte Element bitte mit dem Klassen-Namen (ClassName).<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
Die folgenden Informationen aus Inspect gehen in den Prüfschritt 4.10.2 „Zusätzliche kontextsensitive Hilfe“ ein:<br />
<br />
* HelpText oder LegacyIAccessible.Help<br />
* LegacyIAccessible.Description<br />
* LegacyIAccessible.DefaultAction<br />
* AccessKey oder LegacyIAccessible.KeyboardShortcut<br />
<br />
Textattribute werden im Prüfschritt 4.06.1 „Wiedergabe von Textattributen“ überprüft.<br />
<br />
Tabellen werden im Prüfschritt 4.08.1 „Orientierung in Tabellen“ überprüft.<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
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.<br />
<br />
Die Verwendung des UIA-Attributs labelledby zur Kennzeichnung von Labelbeziehungen ist in der Anwendungsentwicklung bisher anscheinend nicht gebräuchlich. Diese Beobachtung braucht Verifizierung.<br />
<br />
Prüftools für JAVA-Anwendungen und für die Schnittstelle IAccessible2 müssen noch benannt werden.<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.4.1.2 Name, role, value<br />
<br />
11.5 Interoperability with assistive technology<br />
<br />
==== WCAG ====<br />
<br />
4.1.2 Name, Rolle, Wert<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
<br />
8.1.4 Namen für unterstützende Technik verfügbar machen<br />
<br />
8.5. Kompatibilität mit unterstützender Technik</div>Maugustinhttps://biti-wiki.de/index.php?title=7.01.1_-_Korrekte_Syntax&diff=15297.01.1 - Korrekte Syntax2020-08-24T12:46:02Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div><br />
=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Anwendungen in Auszeichnungssprachen sind mit korrekter Syntax codiert.<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Elemente haben komplette Start- und End-Tags.<br />
<br />
Elemente werden entsprechend ihrer Spezifikationen verschachtelt.<br />
<br />
Elemente haben keine doppelten Attribute.<br />
<br />
Attribute haben zueinander passende Anführungszeichen.<br />
<br />
Alle IDs sind einzigartig.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Der Prüfschritt ist anwendbar, sofern die Anwendung in einem textbasierten Format mit Auszeichnungssprachen wie HTML oder XML codiert ist.<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Zur Syntaxanalyse von HTML-Anwendungen verwenden Sie den Nu HTML Checker in Verbindung mit dem Bookmarklet „WCAG-Parsing only“ und dem Firebug Add-On für den Firefox Browser (siehe Werkzeugliste).<br />
<br />
# Öffnen Sie die Anwendung im Firefox Browser und warten Sie, bis die Anwendung vollständig geladen ist.<br />
# 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.<br />
# Ü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".<br />
# 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.<br />
# Wiederholen Sie die Schritte 2 bis 4, nachdem Sie die Anwendung bedient haben. Nehmen Sie etwa 2 bis 3 Stichproben je Szenario.<br />
<br />
<br />
Für lauffähige XML-Anwendungen erübrigt sich eine Überprüfung der Syntax, da nur wohlgeformter Code von der Anzeigesoftware ausgeführt wird.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.4.1.1 Parsing<br />
<br />
==== WCAG ====<br />
<br />
4.1.1 Syntaxanalyse<br />
<br />
==== WCAG-Techniques ====<br />
<br />
G134: Validating Web pages<br />
<br />
==== ISO9241-171 ====</div>Maugustinhttps://biti-wiki.de/index.php?title=6.02.1_-_Hilfen_zum_Auffinden_des_Zeigers&diff=15286.02.1 - Hilfen zum Auffinden des Zeigers2020-08-24T12:45:43Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
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.<br />
<br />
Benutzer mit eingeschränktem Sehvermögen können den Zeiger vergrößern, so dass sie ihn leichter orten können.<br />
<br />
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.<br />
<br />
Die Software bietet die Option, den Tastaturfokus besonders deutlich als dick umrandetes Rechteck von kontrastierender Farbe darzustellen.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Eine Anwendung, die die Eingabehilfen der Plattform nicht übernimmt, muss die entsprechenden Einstellmöglichkeiten selber anbieten.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Im Windows Center für erleichterte Bedienung aktivieren Sie folgende Optionen:<br />
<br />
* Verwenden der Maus erleichtern / Mauseinstellungen / Zeigeroptionen / Zeigerposition beim Drücken der Strg-Taste anzeigen<br />
<br />
* Erkennen von Bildschirmobjekten erleichtern / Die Breite des Fokusrechtecks vergrößern<br />
<br />
* Erkennen von Bildschirmobjekten erleichtern / Legen Sie die Breite des blinkenden Cursors fest – hier den Wert auf 9 einstellen<br />
<br />
Ö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?<br />
<br />
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?<br />
<br />
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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Die Anforderung ist erfüllt, wenn die Eingabehilfen der Plattform in der Anwendung funktionieren.<br />
<br />
Die Anforderung ist erfüllt, wenn die Anwendung über eigene Einstellmöglichkeiten verfügt, die nicht schlechter sind als die der Plattform.<br />
<br />
Wenn in den Einstellmöglichkeiten der Anwendung wesentliche Optionen fehlen, so ist dies eine Barriere.<br />
<br />
Wenn weder die Eingabehilfen der Plattform übernommen werden, noch eigene adäquate Einstellmöglichkeit angeboten werden, so ist dies eine Barriere.<br />
<br />
Wenn die gewählte Einstellung in einzelnen Bereichen der Anwendung nicht funktioniert, so ist dies eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
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. <br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.6.2 No disruption of accessibility features<br />
<br />
11.7 User preferences<br />
<br />
==== WCAG ====<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
<br />
8.2.4 Individualisierung der Einfügemarke und des Zeigers ermöglichen<br />
<br />
9.4.13 Hilfsmittel zum Auffinden des Zeigers zur Verfügung stellen</div>Maugustinhttps://biti-wiki.de/index.php?title=6.01.1_-_Eingabehilfen_f%C3%BCr_Tastatur_und_Maus&diff=15276.01.1 - Eingabehilfen für Tastatur und Maus2020-08-24T12:45:22Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>==== Prüfschritt 6.01.1 - Eingabehilfen für Tastatur und Maus ====<br />
<br />
Gewichtung:<br />
<br />
1<br />
<br />
Anwendung:<br />
<br />
Anwendung auf Seite/Szenario<br />
<br />
Bewertungen:<br />
<br />
[https://www.biti-test.de/intern/pruefplaene/pruefschritt-bewertungen.xhtml?ps=78 Bisherige Bewertungen für diesen Prüfschritt anzeigen]<br />
<br />
Beschreibung:<br />
<br />
=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Die Anwendung übernimmt die in der Plattform eingestellten Eingabehilfen für Tastatur und Maus.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Folgende in der Windows Systemsteuerung eingestellten Eingabehilfen funktionieren in der Anwendung unverändert:<br />
<br />
* Verzögerung der Mausbewegung<br />
<br />
* Anschlagverzögerung der Tastatur<br />
<br />
* Einrastfunktion, um Tastenkombinationen, die normalerweise gleichzeitig einzugeben sind (Strg+Alt+Entf etc.), nacheinander eingeben zu können<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Praktische Erprobung der unter Beispiele genannten Einstellungen.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Wenn die Eingabehilfen in der Anwendung nicht funktionieren, so ist dies eine Barriere.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.6.2 No disruption of accessibility features<br />
<br />
==== WCAG ====<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
<br />
8.5.3 Nutzung der Standard-Zugänglichkeitsdienste<br />
<br />
9.3 Tastatureingabe<br />
<br />
9.4 Zeigegeräte</div>Maugustinhttps://biti-wiki.de/index.php?title=5.04.1_-_Fokusverfolgung_im_Gro%C3%9Fbildsystem&diff=15265.04.1 - Fokusverfolgung im Großbildsystem2020-08-24T12:44:28Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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. <br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Der Bildausschnitt folgt, wenn der Benutzer<br />
<br />
* den Bildausschnitt mit der Maus über den Bildschirm führt, um alle Inhalte zu lesen<br />
* mit TAB durch die Bedienelemente geht<br />
* mit einem Tastenbefehl Funktionsbereiche gezielt anspringt, z.B. das Hauptmenü und den Datenbereich der Anwendung<br />
* Dialoge öffnet und schließt<br />
* lange Inhalte mit den Rollbalken oder mit SEITE AUF/AB über den Bildschirm rollt<br />
* Daten mit Maus oder Tastatur markiert, über den Rand des Bildausschnitts hinweg<br />
* lange Eingaben macht, über den Rand des Bildausschnitts hinweg.<br />
<br />
Der Bildausschnitt folgt bei Systemmeldungen, die eine Benutzeraktion erfordern, z.B. Dialogboxen.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
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. <br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.5.2.13 Tracking of focus and selection attributes<br />
<br />
11.5.2.15 Change notification<br />
<br />
==== WCAG ====<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
<br />
8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen</div>Maugustinhttps://biti-wiki.de/index.php?title=5.03.1_-_Kontrastmodus_ist_nutzbar&diff=15255.03.1 - Kontrastmodus ist nutzbar2020-08-24T12:44:02Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Die Anwendung kann in dem von der Plattform bereitgestellten Kontrastmodus ohne wesentliche Einschränkungen genutzt werden.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Im Kontrastmodus sind alle Elemente der Anwendung erkennbar.<br />
<br />
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.<br />
<br />
Einfarbige Grafiken werden vermieden. Icons haben eine Hintergrundfarbe oder ein mehrfarbiges Motiv.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Bedienelemente und Daten, soweit sie in der Normalansicht optisch unterscheidbar sind, sind auch im Kontrastmodus unterscheidbar.<br />
<br />
Die Anwendung kennzeichnet Bedienelemente mit Rahmenlinien, die auch im Kontrastmodus erscheinen.<br />
<br />
Der Status von Bedienelementen (ausgewählt, aktives Element, nicht verfügbar), soweit er in der Normalansicht optisch unterscheidbar ist, ist auch im Kontrastmodus unterscheidbar.<br />
<br />
Die Anwendung gestaltet Statusmarkierungen mit Grafiken, Rahmenlinien oder Unterstrichen, die auch im Kontrastmodus erscheinen.<br />
<br />
Der Tastaturfokus und der Eingabecursor sind erkennbar. Eine Selektion (Markierung) ist erkennbar.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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.<br />
<br />
Sichtprüfung und praktische Erprobung (TAB, Markierung von Daten, Texteingabe): sind die in den Beispielen dargestellten Gestaltungsregeln eingehalten?<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Blockade: Die Anwendung übernimmt nicht die Farben des Windows Kontrastmodus und bietet auch keine eigene Farbwahl. <br />
<br />
Blockade: Im Kontrastmodus ist der Tastaturfokus über mehr als drei TAB-Schritte nicht erkennbar.<br />
<br />
Blockade: Im Kontrastmodus sind markierte Daten nicht unterscheidbar oder nicht erkennbar.<br />
<br />
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.<br />
<br />
Barriere: Texte von mehr als 8 Wörtern sind eine Grafik, deren Farben sich nicht anpassen.<br />
<br />
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.<br />
<br />
Alle weiteren Mängel sind eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.7 User preferences<br />
<br />
==== WCAG ====<br />
<br />
1.4.8 Visuelle Präsentation: Vorder- und Hintergrundfarben können vom Benutzer ausgewählt werden.<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
<br />
10.4.2 Für Behinderte entwickelte Farbschemata zur Verfügung stellen<br />
<br />
10.4.3 Individualisierung der Farbschemata ermöglichen<br />
<br />
10.4.4 Benutzern die Individualisierung der Farbkennzeichnung ermöglichen</div>Maugustinhttps://biti-wiki.de/index.php?title=5.01.1_-_Schriftvergr%C3%B6%C3%9Ferung_auf_200%25&diff=15245.01.1 - Schriftvergrößerung auf 200%2020-08-24T12:43:45Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Fehler: Bei vergrößerter Schrift werden die Zeichen der Anwendung am Bildschirm unscharf dargestellt.<br />
<br />
Fehler: Bei vergrößerter Schrift sind Bereiche der Anwendung abgeschnitten oder überlagern sich, so dass der Benutzer sie nicht mehr lesen kann.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
Auch im vergrößerten Zustand sollen alle Schriften scharf und gut lesbar sein, alle Inhalte und Funktionen der Anwendung sollen erreichbar und benutzbar sein.<br />
<br />
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.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
Die Schriftgröße und die Fenstergröße einstellen wie für den Standardbildschirm des Testsystems beschrieben.<br />
<br />
Alle Schriften (Versalhöhe) sowie die Fenstergröße mit dem Keseling Bildschirmlineal (siehe Werkzeugliste) messen.<br />
<br />
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).<br />
<br />
* 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.<br />
* 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.<br />
* Falls vorhanden, Schriftgröße-Einstellung oder Zoomfunktion der Anwendung benutzen.<br />
* Bildschirmauflösung herabsetzen unter Systemsteuerung-Anzeige-Auflösung anpassen (Win7).<br />
<br />
Falls am Ende der Einstellung die Zeichen unscharf sind, so ist dies ein Mangel, der für die weitere Prüfung hingenommen werden muss.<br />
<br />
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.<br />
<br />
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“.<br />
<br />
Falls bei einer der vorgenommenen Einstellungen die Fenstergröße verändert worden sein sollte, mit Hilfe des Bildschirmlineals die anfangs gemessene Fenstergröße wiederherstellen.<br />
<br />
Hiermit ist die Einstellung der Schriftgröße abgeschlossen. Es sollten alle Schriften auf mindestens 200% vergrößert worden sein.<br />
<br />
Sichtprüfung und Erprobung:<br />
<br />
* Sind alle Inhalte der Anwendung, Beschriftungen, Meldungstexte und Daten, sichtbar oder können mit dem Rollbalken sichtbar gemacht werden?<br />
* Eingaben vornehmen und feststellen, ob der Bildausschnitt automatisch dem Tastaturfokus in den zuvor nicht sichtbaren Bereich folgt.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Wenn wichtige Bereiche der Anwendung abgeschnitten sind, so dass der Benutzer sie nicht mehr lesen und bedienen kann, so ist dies eine Blockade. <br />
<br />
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.<br />
<br />
Alle weiteren Mängel sind eine Einschränkung.<br />
<br />
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“.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
Bilder eines Textes sind Gegenstand des Prüfschritts 7.03.1 Text als Text codieren.<br />
<br />
Weitergehende Anforderungen an die Vergrößerung werden im Prüfschritt 5.02.2 „Bei vergrößerter Darstellung Layout anpassen“ geprüft.<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.4.4 Resize text<br />
<br />
11.7 User preferences<br />
<br />
==== WCAG ====<br />
<br />
1.4.4.Textgröße ändern.<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
<br />
10.3.2 Benutzern die Einstellung einer Mindestschriftgröße ermöglichen</div>Maugustinhttps://biti-wiki.de/index.php?title=4.11.1_-_Automatischer_Sprachwechsel&diff=15234.11.1 - Automatischer Sprachwechsel2020-08-24T12:43:02Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Wenn die Anwendung in einer anderen Sprache als die Plattform verfasst ist, spricht die Sprachausgabe automatisch die Sprache der Anwendung.<br />
<br />
Der Prüfschritt bezieht sich auf die Sprache der Anwendung, nicht auf den Sprachwechsel bei mehrsprachigen Inhalten.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
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. <br />
<br />
Wenn der Benutzer zwischen mehreren offenen Anwendungen wechselt, wechselt die Sprache automatisch, sobald die zu prüfende Anwendung aktiv wird. <br />
<br />
Fehler: Der Benutzer muss zunächst im Screenreader die Sprache umstellen, bevor er die Anwendung benutzen kann.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist anwendbar, wenn die Software in einer Fremdsprache verfasst ist. <br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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. <br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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.<br />
<br />
Erprobung: Wechselt der Screenreader automatisch die Sprache, wenn die fremdsprachige Anwendung aktiv wird? <br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Mängel sind eine Einschränkung.<br />
<br />
<br />
<br />
=== Einordnung[Abgrenzung zu anderen Prüfschritten] ===<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.3.1.1 Language of software<br />
<br />
==== WCAG ====<br />
<br />
3.1.1 Sprache der Seite<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====</div>Maugustinhttps://biti-wiki.de/index.php?title=4.09.1_-_Benachrichtigung_%C3%BCber_%C3%84nderungen&diff=15224.09.1 - Benachrichtigung über Änderungen2020-08-24T12:42:44Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
Rückmeldungen und Benachrichtigungen sollen für die Benutzerinteraktion relevant sein und den Benutzer nicht stören.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Bei der Auswahl von Einträgen in einer Mailbox erhält der Benutzer die Rückmeldung „ausgewählt“ oder „markiert“.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Der fortlaufend sich ändernde Inhalt eines Börsentickers wird vom Screenreader nicht vorgelesen, um die zugleich erforderliche Programmbedienung nicht zu stören.<br />
<br />
Einschränkung: Die Anwendung versetzt den Tastaturfokus, aber der Screenreader sagt erst beim nächsten Tastendruck des Benutzers die neue Position an.<br />
<br />
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.<br />
<br />
Fehler: In einem Chatprogramm wird beim Erscheinen neuer Beiträge der gesamte Inhalt vorgelesen. Richtig wäre, nur den neu erschienenen Beitrag vorzulesen.<br />
<br />
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.<br />
Fehler: Wie zuvor, aber die neuen Eingabefelder erscheinen oberhalb der Optionsschaltflächen, wo sie bei kleinem Bildausschnitt und sequentieller Bedienung nicht wahrgenommen werden.<br />
<br />
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“.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist immer anwendbar.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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.<br />
<br />
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“.<br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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?<br />
<br />
Ggf. ergänzen Sie das Szenario um Gelegenheit zur Überprüfung von Meldungen, z.B. indem Sie den Empfang einer E-Mail provozieren.<br />
<br />
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. <br />
<br />
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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Wenn die Rückmeldung durch einen zusätzlichen Tastendruck gesucht werden muss, so ist dies eine Einschränkung. <br />
<br />
Weitere Mängel werden nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
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.<br />
<br />
Änderungen, die durch einen mitgeführten Tastaturfokus auf sich aufmerksam machen, werden im Prüfschritt 3.07.0 „Sinnvolle Fokus-Reihenfolge“ behandelt.<br />
<br />
Änderungen, die durch bloße Navigationsbewegungen des Benutzers entstehen, werden im Prüfschritt 3.08.1 „Keine unerwartete Kontextänderung“ behandelt.<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.4.1.2 Name, role, value<br />
<br />
11.5.2.15 Change notification<br />
<br />
==== WCAG ====<br />
4.1.2 Name, Rolle, Wert<br />
<br />
==== WCAG-Techniques ====<br />
<br />
==== ISO9241-171 ====<br />
8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen<br />
<br />
==== Sonstige ====<br />
WAI-ARIA Authoring Practices 1.1 Kapitel 6.2 Implementing Live Regions</div>Maugustinhttps://biti-wiki.de/index.php?title=4.08.1_-_Orientierung_in_Tabellen&diff=15214.08.1 - Orientierung in Tabellen2020-08-24T12:42:19Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
In Datentabellen sagt der Screenreader in jeder Zelle die Zeile und Spalte an, ebenso Zeilen- und Spaltenüberschriften, soweit diese vorhanden sind.<br />
<br />
Datentabellen sind einfach strukturiert, so dass der blinde Benutzer den Inhalt nachvollziehen kann. <br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
In einer Tabelle sagt der Screenreder in jeder Zelle die Zeilen- und Spaltennummer an, z.B. „Zeile 2 Spalte 3“.<br />
<br />
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.<br />
<br />
Fehler: Die Tabelle ist nicht zellenweise navigierbar.<br />
<br />
Einschränkung: Der Screenreader behandelt Überschriften wie Daten, sagt sie also nur einmal an und wiederholt sie nicht bei jeder Zelle.<br />
<br />
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).<br />
<br />
Fehler: Die Daten verändern ihre Bedeutung, ohne dass dies durch neue Überschriften explizit gemacht wird.<br />
<br />
Fehler: Ein Bedeutungswandel wird ausschließlich durch leere Tabellenzeilen angedeutet.<br />
<br />
Fehler: Die Tabelle ist stark verschachtelt, so dass die Zeilen- und Spaltennummern vom blinden Benutzer nur mit Mühe nachvollzogen werden können.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist anwendbar, wenn die Anwendung Daten in Form von Tabellen präsentiert.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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.<br />
<br />
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“.<br />
<br />
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.<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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?<br />
<br />
Bewegen Sie sich mit den Screenreader-Shortcuts durch die Tabelle und stellen Sie fest, ob die unter Beispiele dargestellten Gestaltungsregeln eingehalten werden.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Erfüllt: Datenzellen wie auch Überschriften werden erwartungsgemäß wiedergegeben.<br />
<br />
Barriere: Die Daten erfordern eine Tabellenstruktur, der Screenreader gibt aber nur lineare Inhalte aus.<br />
<br />
Einschränkung: in einer einfach strukturierten Tabelle sind Überschriften vorhanden, die aber nur in der ersten Zeile bzw. Spalte wiedergegeben werden.<br />
<br />
Weitere Mängel werden nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
Synopsen werden im Prüfschritt 4.07.1 „Korrekte Leseabfolge von Inhalten“ behandelt.<br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
<br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.3.1 Info and relationships<br />
<br />
11.5.2.6 Row, column, and headers<br />
<br />
==== WCAG ====<br />
<br />
1.3.1 Info und Beziehungen<br />
<br />
==== WCAG-Techniques ====<br />
<br />
H43 Using id and headers attributes to associate data cells with header cells in data tables<br />
<br />
H63 Using the scope attribute to associate header cells and data cells in data tables<br />
<br />
==== BITV-Test ====<br />
<br />
1.3.1e Datentabellen richtig aufgebaut<br />
<br />
1.3.1f Zuordnung von Tabellenzellen<br />
<br />
==== ISO9241-171 ====<br />
<br />
8.5.10 Angemessene Darstellung von Tabellen ermöglichen</div>Maugustinhttps://biti-wiki.de/index.php?title=4.07.1_-_Korrekte_Leseabfolge_von_Inhalten&diff=15204.07.1 - Korrekte Leseabfolge von Inhalten2020-08-24T12:41:51Z<p>Maugustin: /* EN301549 */</p>
<hr />
<div>=== Beschreibung ===<br />
<br />
''[Technikneutrale Beschreibung des Erfolgskriteriums]''<br />
<br />
Inhalte, die am Bildschirm in Blöcken neben- oder nacheinander angeordnet sind, werden vom Screenreader in korrekter, sinnentsprechender Reihenfolge ausgegeben.<br />
<br />
<br />
<br />
=== Beispiele ===<br />
<br />
''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''<br />
<br />
Im Windows Explorer liest der Screenreader zunächst alle Zeilen der Baum-Ansicht und dann alle Zeilen der Detailansicht vor.<br />
<br />
In einer synoptischen Darstellung von Textinhalten liest der Screenreader die linearisierten Zellinhalte vor, ohne dass logische Zusammenhänge auseinandergerissen werden.<br />
<br />
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.<br />
<br />
Fehler: Wenn ein Dialogfenster sich über den Inhalt legt, so vermischt der Screenreader den Text des Dialogs mit dem dahinter liegenden Inhalt.<br />
<br />
Fehler: Beim fortlaufenden Lesen mit dem Screenreader entsteht eine erratische Reihenfolge, deren Sinn nicht nachvollzogen werden kann.<br />
<br />
<br />
<br />
=== Anwendbarkeit ===<br />
<br />
''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''<br />
<br />
Dieser Prüfschritt ist anwendbar, wenn die Anwendung Inhalte in Blöcken anordnet.<br />
<br />
<br />
<br />
=== Begründung ===<br />
<br />
''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''<br />
<br />
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. <br />
<br />
<br />
<br />
=== Prüfanleitung ===<br />
<br />
''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''<br />
<br />
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.<br />
<br />
<br />
<br />
=== Bewertungsalternativen ===<br />
<br />
''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''<br />
<br />
Die Anforderung ist erfüllt, wenn wenigstens in einem Screenreader-Modus eine sinnentsprechende Reihenfolge der blockweise angeordneten Inhalte wiedergegeben werden kann.<br />
<br />
Mängel werden nach der Bedeutung der gestörten Information für die Arbeitsaufgabe bewertet.<br />
<br />
<br />
<br />
=== Einordnung ===<br />
<br />
''[Abgrenzung zu anderen Prüfschritten]''<br />
<br />
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. <br />
<br />
<br />
<br />
=== Offene Fragen ===<br />
<br />
''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''<br />
<br />
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 sinnvolle Reihenfolge erlauben könnte. <br />
<br />
=== Referenzen ===<br />
<br />
==== EN301549 ====<br />
<br />
11.1.3.2 Meaningful sequence<br />
<br />
==== WCAG ====<br />
<br />
1.3.2 Bedeutungstragende Reihenfolge<br />
<br />
==== WCAG-Techniques ====<br />
<br />
F49 Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized<br />
<br />
==== ISO9241-171 ====<br />
<br />
==== BITV-Test ====<br />
<br />
1.3.2a Layouttabellen linearisierbar</div>Maugustin