BIT inklusiv Wiki und Test-Case-Datenbank - Benutzerbeiträge [de]

Benutzer:JFischer

2019-11-15T10:46:37Z

JFischer:

Johannes Fischer, Deutsches Zentrum für barrierefreies Lesen (dzb lesen)
E-Mail: j.fischer@dzblesen.de

Diskussion:3.08.1 - Keine unerwartete Kontextänderung

2019-06-05T20:09:31Z

JFischer: Die Seite wurde neu angelegt: „05.06.2019 Johannes Fischer Bereich Beispiele: "Fehler: Ein Formular wird automatisch abgeschickt, sobald der Fokus das letzte Eingabefeld verlässt, ohne…“

05.06.2019 Johannes Fischer 
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." 
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.

Diskussion:1.07.1 - Informationen nicht allein durch Farbe übermitteln

2019-06-05T20:07:13Z

JFischer:

== Farbflächen als Markierkung ==
21.12.2017 Anmerkung Johannes Fischer (DZB): 
Der Kontrast für Farbflächen als Markierung zum Hintergrund von 1,5:1 ist sehr gering und meiner Meinung nach nicht barrierefrei. Ein Kontrast von 3:1 sollte das Minimum darstellen, denn dieser Kontrast ist von Normalsichtigen geradeso wahrnehmbar, vergleiche Erklärung in Prüfschritt 1.01.0. 
Und falls wirklich wie im Abschnitt "Begründung" die Hälfte des zur Unterscheidbarkeit von Zeichen angesetzten Kontrastwertes verwendet werden sollte, müsste das wohl eher 2:1 sein. Denn 1:1 ist das Kontrastminimum, nicht 0:1. Von 1:1 bis 3:1 ist der Abstand 2, sodass der Abstand 1 die Hälfte darstellen würde. Von 1:1 auf 2:1 ist der Abstand 1, daher müsste 2:1 angesetzt werden.

05.04.2018 Detlef Girke: 
In der ISO 32975 findet man folgendes:
Hier stehen auf Seite 8 die Kontrastwerte für Schrift etc. = 0,7 bis 0,8 und für flächige Bodenindikatoren = 0,4. Die Messung und die Messwerte sind hier ganz anders als am Bildschirm, aber das Verhältnis - der Kontrast von Flächen wird halb so stark angesetzt als der von Zeichen - ist m.E. übertragbar.
Das mit 2:1 stimmt aber. Das sollten wir korrigieren.

10.04.2018 Johannes Fischer (DZB): 
Ok, von den Kontrastwerten 0,8 bzw. 0,4 für Bodenindikatoren wusste ich bisher nichts. Danke für die Information. Die Werte scheinen mir der Formel des Michelson-Kontrasts zu entstammen. Es stimmt, wenn man hier allein das Verhältnis verwendet, um den Kontrast für markierende Farbflächen zum Hintergrund zu bestimmen, würde für einen Ausgangswert für Zeichen von 3:1 als Ergebnis ein Wert von 2:1 stehen. Aber für mich stehen zwei Dinge in Frage:

#Der Kontrast von Zeichen ist in der WCAG eigentlich 4,5:1. Nur großer oder fetter Text darf den verringerten Kontrast von 3:1 verwenden. Wenn man nun also nicht 3:1, sondern 4,5:1 als Ausgangswert nimmt, wäre die Hälfte des Kontrastwertes 2,75:1 und damit deutlich höher als 2:1.
#Statt sich auf den WCAG-Wert von 4,5:1 für Text zu beziehen, könnte man versuchen, die Kontrastwerte 0,8 und 0,4 auf WCAG-Werte umzurechnen. Dazu habe zunächst einen Link von Leserlich.info gefunden, wo steht, dass 0,6 nach Michelson dem WCAG-Wert 4,5:1 entspricht (0,8 -> 7:1): http://www.leserlich.info/kapitel/farben.php 
#:Ich habe noch eine Seite gefunden, auf der im Bereich "Common Metrics" für den Verhältniswert 3:1 ein Wert 0,5 nach Michelson angegeben wird: http://www.stonesc.com/pubs/Contrast%20Metrics.htm
#:Unter einer weiteren Seite von Leserlich (http://www.leserlich.info/werkzeuge/kontrastrechner/) im Bereich "Hintergründe zur Berechnung" sind die Formeln von WCAG und Michelson hinterlegt. Wenn ich hier z. B. den WCAG-Kontrast von 2:1 umrechne, komme ich nur auf 0,33 oder 0,34 nach Michelson, bei WCAG 2,3:1 dagegen auf etwa 0,4 nach Michelson, siehe folgendes Beispiel:
#:WCAG-Formel: 2,3:1 = (2,25 + 0,05) / (0,95 + 0,05)
#:-> Ymax = 2,25; Ymin = 0,95
#:Dies setze ich in die Michelson-Formel ein:
#:(2,25 - 0,95) / (2,25 + 0,95) = 1,3 / 3,2 = 0,406
Wenn ich falsch gerechnet haben sollte bzw. ich einem Irrtum bezüglich der Umrechnung unterlegen sein sollte, bitte korrigieren. Ich bin kein Experte für Kontrastformeln und habe nur etwas dazu recherchiert.

Fazit: 
Aus meiner Sicht könnte man sich für Kontrastwerte zwischen 2,3:1 und 2,75:1 entscheiden, je nachdem, anhand welcher Alternative man es begründet. Oder man nimmt als Mitte zwischen beiden Alternativen 2,5:1 als Mindestkontrast.

=== Versuchsanordnung ===

11.06.2018 Brigitte Bornemann

Die theoretische Diskussion um Kontrastformeln lässt sich ggf. leichter entscheiden, wenn wir etwas empirisches Material zur Anschauung haben. Anbei ein Beispiel aus meiner aktuellen Beratungspraxis (Namen sind geschwärzt).

[[Datei:kontrast_flaechen_checkbox_eingabefeld.png | 750px | Screenshot: Kontraste von Checkbox und Eingabefeld]]

In Frage stehen die leeren Checkboxen und Eingabefelder, die im Screenshot farblich markiert sind.

Die Checkbox ist ein Zeichen, denn sie muss von vergleichbaren Formularfeldern, z.B. Radiobutton, unterscheidbar sein. Sie ist auch so groß wie ein Textzeichen, nicht extra groß wie heute oft zu sehen. Es gilt also die Kontrastanforderung von 3:1 wie für große bzw. fette Zeichen. Das Eingabefeld ist dagegen eine Fläche, es kommt darauf an, ob es gegen den Hintergrund wahrnehmbar ist. Der ausreichende Kontrast von Flächen steht hier zur Diskussion.

Im abgebildeten Beispiel sind die Kontraste zu schwach (bitte nicht nachmessen - in der Abbildung kommen die Farben nicht original heraus).
Die Checkbox im Beispiel hat einen Kontrast von 2:1.
Das Eingabefeld im Beispiel hat einen Kontrast von 1,1:1.

'''Versuchsanordnung'''

Das Eingabefeld im Beispiel ist kaum wahrnehmbar, soviel ist klar. Aber welcher Wert wäre ausreichend, um das Eingabefeld zu erkennen? - In unserer Diskussion wurden Werte von 1,5:1, 2:1, 2,3:1, 2,5:1, 2,8:1 genannt.

Diese verschiedenen Grenzwerte für den Kontrast von Flächen habe ich in einer Versuchsanordnung mit Formularfeldern dargestellt. Meine Bitte: schaut Euch die [http://www.bitsite.de/testen/kontraste.html Versuchsanordnung auf dem Testserver] an und gebt Rückmeldung, bei welchem Wert für Euch persönlich "gut sichtbar" anfängt.

[[Datei: kontrast_flaechen_versuch.png | 560px | Screenshot Versuchsanordnung ]]

Diese Abbildung ist ein Screenshot, bitte nicht für den Test verwenden.
Bitte die [http://www.bitsite.de/testen/kontraste.html Versuchsanordnung auf dem Testserver] verwenden.

Meine persönlichen Werte - ich bin leicht alterssichtig:
Checkbox und Radiobutton kann ich deutlich unterscheiden bei einem Kontrast von 2,3:1.
Das Eingabefeld kann ich deutlich erkennen bei einem Kontrast von 1,5:1.

Ich freue mich auf Rückmeldungen von normalsichtigen und von mehr oder weniger stark sehbehinderten Lesern. Bitte meldet mir Euer Ergebnis in einer Mail an bb@bit-informationsdesign.de mit Betreff "Kontrast von Flächen".

Danke :-)

30.07.2018 Johannes Fischer

Frau Bornemann, hier ist mein Ergebnis, das ich Ihnen auch per Mail geschickt habe: Sowohl das Eingabefeld als auch Checkbox und Radiobutton kann als Normalsichtiger in allen Fällen erkennen. Bei dem niedrigsten Kontrast 1,5:1 bereitet es etwas Schwierigkeiten, ist aber möglich. Den Kontrast von 2:1 finde ich auch noch nicht komfortabel zu erkennen. Ohne leichte Anstrengung komfortabel zu erkennen finde ich erst Werte von 2,3:1 bis 2,5:1.

Ich bin mir daneben unsicher, ob der Kontrast von Formularfeldern überhaupt unter den Prüfschritt der Informationsvermittlung mit Farbe bzw. Farbflächen als Markierung zum Hintergrund fällt. Ich würde den Fall der Farbflächen als Markierung eher bei besonders markierten Worten sehen. Für die Kennzeichnung von Eingabefeldern gibt es in den neuen WCAG 2.1 das Kriterium 1.4.11 Non-Text-Contrast. Im [https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#active-user-interface-component-examples zugehörigen Understanding-Dokument] sind auch Beispiele zu sehen, wie ein Eingabefeld gekennzeichnet wird (Beispiel Text input using background colour). Sobald die EN 301549 die neuen WCAG-Kriterien für die Software übernommen haben, müssten wir dies perspektivisch wohl in einem eigenen Prüfschritt unterbringen. Der von den WCAG geforderte Mindest-Kontrast wäre hier übrigens 3:1.

== Kontrast 3:1 zum Fließtext und Fokus mit zusätzlichem Merkmal ==
05.06.2019 Johannes Fischer 
Bereich Beispiele: "Als Markierung wird eine Textfarbe verwendet, deren Helligkeitskontrast im Verhältnis 3:1 von der Textfarbe der umgebenden Elemente abweicht." 
Hier fehlt der Zusatz, dass bei Fokus bzw. Hover neben der Farbe ein zusätzliches Unterscheidungsmerkmal hinzukommen muss. So ist es nach den WCAG vorgeschrieben, siehe Technik [https://www.w3.org/TR/WCAG20-TECHS/G183.html G183].

Diskussion:1.07.1 - Informationen nicht allein durch Farbe übermitteln

2019-06-05T20:05:49Z

JFischer:

= Farbflächen als Markierkung =
21.12.2017 Anmerkung Johannes Fischer (DZB): 
Der Kontrast für Farbflächen als Markierung zum Hintergrund von 1,5:1 ist sehr gering und meiner Meinung nach nicht barrierefrei. Ein Kontrast von 3:1 sollte das Minimum darstellen, denn dieser Kontrast ist von Normalsichtigen geradeso wahrnehmbar, vergleiche Erklärung in Prüfschritt 1.01.0. 
Und falls wirklich wie im Abschnitt "Begründung" die Hälfte des zur Unterscheidbarkeit von Zeichen angesetzten Kontrastwertes verwendet werden sollte, müsste das wohl eher 2:1 sein. Denn 1:1 ist das Kontrastminimum, nicht 0:1. Von 1:1 bis 3:1 ist der Abstand 2, sodass der Abstand 1 die Hälfte darstellen würde. Von 1:1 auf 2:1 ist der Abstand 1, daher müsste 2:1 angesetzt werden.

05.04.2018 Detlef Girke: 
In der ISO 32975 findet man folgendes:
Hier stehen auf Seite 8 die Kontrastwerte für Schrift etc. = 0,7 bis 0,8 und für flächige Bodenindikatoren = 0,4. Die Messung und die Messwerte sind hier ganz anders als am Bildschirm, aber das Verhältnis - der Kontrast von Flächen wird halb so stark angesetzt als der von Zeichen - ist m.E. übertragbar.
Das mit 2:1 stimmt aber. Das sollten wir korrigieren.

10.04.2018 Johannes Fischer (DZB): 
Ok, von den Kontrastwerten 0,8 bzw. 0,4 für Bodenindikatoren wusste ich bisher nichts. Danke für die Information. Die Werte scheinen mir der Formel des Michelson-Kontrasts zu entstammen. Es stimmt, wenn man hier allein das Verhältnis verwendet, um den Kontrast für markierende Farbflächen zum Hintergrund zu bestimmen, würde für einen Ausgangswert für Zeichen von 3:1 als Ergebnis ein Wert von 2:1 stehen. Aber für mich stehen zwei Dinge in Frage:

#Der Kontrast von Zeichen ist in der WCAG eigentlich 4,5:1. Nur großer oder fetter Text darf den verringerten Kontrast von 3:1 verwenden. Wenn man nun also nicht 3:1, sondern 4,5:1 als Ausgangswert nimmt, wäre die Hälfte des Kontrastwertes 2,75:1 und damit deutlich höher als 2:1.
#Statt sich auf den WCAG-Wert von 4,5:1 für Text zu beziehen, könnte man versuchen, die Kontrastwerte 0,8 und 0,4 auf WCAG-Werte umzurechnen. Dazu habe zunächst einen Link von Leserlich.info gefunden, wo steht, dass 0,6 nach Michelson dem WCAG-Wert 4,5:1 entspricht (0,8 -> 7:1): http://www.leserlich.info/kapitel/farben.php 
#:Ich habe noch eine Seite gefunden, auf der im Bereich "Common Metrics" für den Verhältniswert 3:1 ein Wert 0,5 nach Michelson angegeben wird: http://www.stonesc.com/pubs/Contrast%20Metrics.htm
#:Unter einer weiteren Seite von Leserlich (http://www.leserlich.info/werkzeuge/kontrastrechner/) im Bereich "Hintergründe zur Berechnung" sind die Formeln von WCAG und Michelson hinterlegt. Wenn ich hier z. B. den WCAG-Kontrast von 2:1 umrechne, komme ich nur auf 0,33 oder 0,34 nach Michelson, bei WCAG 2,3:1 dagegen auf etwa 0,4 nach Michelson, siehe folgendes Beispiel:
#:WCAG-Formel: 2,3:1 = (2,25 + 0,05) / (0,95 + 0,05)
#:-> Ymax = 2,25; Ymin = 0,95
#:Dies setze ich in die Michelson-Formel ein:
#:(2,25 - 0,95) / (2,25 + 0,95) = 1,3 / 3,2 = 0,406
Wenn ich falsch gerechnet haben sollte bzw. ich einem Irrtum bezüglich der Umrechnung unterlegen sein sollte, bitte korrigieren. Ich bin kein Experte für Kontrastformeln und habe nur etwas dazu recherchiert.

Fazit: 
Aus meiner Sicht könnte man sich für Kontrastwerte zwischen 2,3:1 und 2,75:1 entscheiden, je nachdem, anhand welcher Alternative man es begründet. Oder man nimmt als Mitte zwischen beiden Alternativen 2,5:1 als Mindestkontrast.

== Versuchsanordnung ==

11.06.2018 Brigitte Bornemann

Die theoretische Diskussion um Kontrastformeln lässt sich ggf. leichter entscheiden, wenn wir etwas empirisches Material zur Anschauung haben. Anbei ein Beispiel aus meiner aktuellen Beratungspraxis (Namen sind geschwärzt).

[[Datei:kontrast_flaechen_checkbox_eingabefeld.png | 750px | Screenshot: Kontraste von Checkbox und Eingabefeld]]

In Frage stehen die leeren Checkboxen und Eingabefelder, die im Screenshot farblich markiert sind.

Die Checkbox ist ein Zeichen, denn sie muss von vergleichbaren Formularfeldern, z.B. Radiobutton, unterscheidbar sein. Sie ist auch so groß wie ein Textzeichen, nicht extra groß wie heute oft zu sehen. Es gilt also die Kontrastanforderung von 3:1 wie für große bzw. fette Zeichen. Das Eingabefeld ist dagegen eine Fläche, es kommt darauf an, ob es gegen den Hintergrund wahrnehmbar ist. Der ausreichende Kontrast von Flächen steht hier zur Diskussion.

Im abgebildeten Beispiel sind die Kontraste zu schwach (bitte nicht nachmessen - in der Abbildung kommen die Farben nicht original heraus).
Die Checkbox im Beispiel hat einen Kontrast von 2:1.
Das Eingabefeld im Beispiel hat einen Kontrast von 1,1:1.

'''Versuchsanordnung'''

Das Eingabefeld im Beispiel ist kaum wahrnehmbar, soviel ist klar. Aber welcher Wert wäre ausreichend, um das Eingabefeld zu erkennen? - In unserer Diskussion wurden Werte von 1,5:1, 2:1, 2,3:1, 2,5:1, 2,8:1 genannt.

Diese verschiedenen Grenzwerte für den Kontrast von Flächen habe ich in einer Versuchsanordnung mit Formularfeldern dargestellt. Meine Bitte: schaut Euch die [http://www.bitsite.de/testen/kontraste.html Versuchsanordnung auf dem Testserver] an und gebt Rückmeldung, bei welchem Wert für Euch persönlich "gut sichtbar" anfängt.

[[Datei: kontrast_flaechen_versuch.png | 560px | Screenshot Versuchsanordnung ]]

Diese Abbildung ist ein Screenshot, bitte nicht für den Test verwenden.
Bitte die [http://www.bitsite.de/testen/kontraste.html Versuchsanordnung auf dem Testserver] verwenden.

Meine persönlichen Werte - ich bin leicht alterssichtig:
Checkbox und Radiobutton kann ich deutlich unterscheiden bei einem Kontrast von 2,3:1.
Das Eingabefeld kann ich deutlich erkennen bei einem Kontrast von 1,5:1.

Ich freue mich auf Rückmeldungen von normalsichtigen und von mehr oder weniger stark sehbehinderten Lesern. Bitte meldet mir Euer Ergebnis in einer Mail an bb@bit-informationsdesign.de mit Betreff "Kontrast von Flächen".

Danke :-)

30.07.2018 Johannes Fischer

Frau Bornemann, hier ist mein Ergebnis, das ich Ihnen auch per Mail geschickt habe: Sowohl das Eingabefeld als auch Checkbox und Radiobutton kann als Normalsichtiger in allen Fällen erkennen. Bei dem niedrigsten Kontrast 1,5:1 bereitet es etwas Schwierigkeiten, ist aber möglich. Den Kontrast von 2:1 finde ich auch noch nicht komfortabel zu erkennen. Ohne leichte Anstrengung komfortabel zu erkennen finde ich erst Werte von 2,3:1 bis 2,5:1.

Ich bin mir daneben unsicher, ob der Kontrast von Formularfeldern überhaupt unter den Prüfschritt der Informationsvermittlung mit Farbe bzw. Farbflächen als Markierung zum Hintergrund fällt. Ich würde den Fall der Farbflächen als Markierung eher bei besonders markierten Worten sehen. Für die Kennzeichnung von Eingabefeldern gibt es in den neuen WCAG 2.1 das Kriterium 1.4.11 Non-Text-Contrast. Im [https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#active-user-interface-component-examples zugehörigen Understanding-Dokument] sind auch Beispiele zu sehen, wie ein Eingabefeld gekennzeichnet wird (Beispiel Text input using background colour). Sobald die EN 301549 die neuen WCAG-Kriterien für die Software übernommen haben, müssten wir dies perspektivisch wohl in einem eigenen Prüfschritt unterbringen. Der von den WCAG geforderte Mindest-Kontrast wäre hier übrigens 3:1.

= Kontrast 3:1 zum Fließtext und Fokus mit zusätzlichem Merkmal =
05.06.2019 Johannes Fischer 
Bereich Beispiele: "Als Markierung wird eine Textfarbe verwendet, deren Helligkeitskontrast im Verhältnis 3:1 von der Textfarbe der umgebenden Elemente abweicht." 
Hier fehlt der Zusatz, dass bei Fokus bzw. Hover neben der Farbe ein zusätzliches Unterscheidungsmerkmal hinzukommen muss. So ist es nach den WCAG vorgeschrieben, siehe Technik [https://www.w3.org/TR/WCAG20-TECHS/G183.html G183].

Diskussion:7.02.1 - Objektinformationen für Hilfstechniken verfügbar machen

2019-03-25T06:58:27Z

JFischer: /* Benachrichtigung über Änderungen in inspect */

== Referenz für gebräuchliche Rollenbezeichnungen in UI-Automation ==

Zur Überprüfung der Rolle mit Inspect: uns fehlt eine Referenz für gebräuchliche Rollenbezeichnungen in UIA/MSAA. Unter „ControlType“ werden oft sehr spezifische Bezeichnungen genannt, daher vermute ich, dass LocalizedControlType und LegacyIAccessible.Role ein Mapping auf eine UIA-interne Liste erlaubter Rollen enthalten. Ich finde nur einen Verweis im Rahmen von .net: [https://msdn.microsoft.com/en-us/library/system.windows.automation.controltype(v=vs.110).aspx - https://msdn.microsoft.com/en-us/library/system.windows.automation.controltype(v=vs.110).aspx] – kann jemand bestätigen, dass dies eine von Anwendungssoftware generell genutzte Liste ist?
--[[Benutzer:Brigitte|Brigitte]] ([[Benutzer Diskussion:Brigitte|Diskussion]]) 16:06, 27. Nov. 2016 (CET)

05.04.2018 Detlef Girke: 
Wir sollten es uns mit diesem Prüfschritt nicht zu kompliziert machen. Nach Aussage von Herrn Kochanek und Herrn Friehoff genügt es, wenn in der Liste, die inspect ausgibt, es einen irgendwie gearteten Hinweis auf Name, Rolle, Wert gibt. Dann sind Screenreader schon sehr "dankbar". Die Prüfanleitung ist ja schon lang genug. Aber sofern es eine Liste der Rollen gibt, können wir die gern referenzieren. Je mehr potenzielle Fragen wir in der Prüfschrittbeschreibung beantworten, desto besser.

== Benachrichtigung über Änderungen in inspect ==
30.08.2018 Johannes Fischer (DZB) 
Frage: In diesem Prüfschritt sollen Inhalte nochmals untersucht werden, die u. a. im Prüfschritt 4.09.1 (Benachrichtigung über Änderung) auffällig geworden sind. Gibt es hier Erfahrungen von anderen Prüfern, in welchem Parameter oder in welchen Parametern bei inspect etwas stehen müsste, damit es vorgelesen wird? 
Beispiel Excel 2010 Statusleiste: Es gibt die Plus-/Minus-Schalter zum Zoomen des Tabellenblatts, links neben den Schaltern die Angabe des aktuellen Zooms, z. B. 100%. Wenn ich nun einmal den Plus-Schalter betätige, ist der Zoom 110% und das sollte der Screenreader mir eigentlich vorlesen, um mich von der Änderung zu benachrichtigen. Es wird aber nichts vorgelesen. Über welchen Parameter in Inspect könnte hier die Anzeige des Prozentwerts mit dem Plus-Schalter verknüpft sein? Ist das einfach nur der Name (Name oder LegacyIAccessible.Name), der sich adhoc ändern müsste oder wäre ein anderer Parameter besser geeignet?

24.03.2019 Detlef Girke 
Das Problem kenne ich auch. Ich habe es sogar in einigen meiner Präsentationen drin, um zu demonstrieren, dass auch in MS Office nicht an alles gedacht wurde. Ich glaube, wir sollten uns hier weniger Gedanken um die Technik machen als darum, dass wir einen solchen Fehler dokumentieren müssten. Andere Änderungen des Status werden ja korrekt ausgegeben. Und dann machen wir uns ja auch keine weiteren Gedanken darum, wie das implementiert wurde. Hier ist die Schwierigkeit, dass das nicht unbedingt ein Fall für diesen Prüfschritt ist, sondern für 4.09.1 - Benachrichtigung über Änderungen. Denn die Information über die Zoomstufe lässt sich über das rechts daneben liegende Element auslesen. Und selbst der Slider ist über die Objektnavigation von NVDA erreichbar und gibt dann auch Informationen über die Zoomstufe aus.

25.03.2019 Johannes Fischer 
Den Fehler dokumentieren würde ich in jedem Fall. Ich hatte mich nur gefragt, ob man dem Entwickler einen konkreten Lösungsvorschlag machen könnte, wo er ansetzen sollte.

Diskussion:4.03.1 - Name, Rolle, Wert für Formularfelder

2019-03-22T08:21:39Z

JFischer: Die Seite wurde neu angelegt: „== Schalter zum Aufklappen von Textbereichen == 22.03.2019 Johannes Fischer (DZB) Frage: Fallen Aufklappschalter, die z. B. nur einen Text-Bereich aufkla…“

== Schalter zum Aufklappen von Textbereichen ==
22.03.2019 Johannes Fischer (DZB) 
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?

Diskussion:2.09.2 - Rechtschreibkontrolle für Texteingaben

2019-03-22T08:20:28Z

JFischer: Die Seite wurde neu angelegt: „== Fehler als solche sollen vom Screenreader vorgelesen werden == 22.03.2019 Johannes Fischer (DZB) Fehler in der Rechtschreibung sollten auch vom Screenr…“

== Fehler als solche sollen vom Screenreader vorgelesen werden ==
22.03.2019 Johannes Fischer (DZB) 
Fehler in der Rechtschreibung sollten auch vom Screenreader als Fehler vorgelesen werden. Mir fehlt ein klarer Hinweis, dass auch mit dem Screenreader zu prüfen ist. Bei diesem Prüfschritt handelt es sich um einen Prüfschritt der Bedienmodalität "Bedienung mit Zeigegeräten", sodass man auch selbst nicht unbedingt darauf kommt, dass mit Screenreader zusätzlich zu prüfen ist. Mein Vorschlag: Entweder man integriert im Prüfanleitung-Abschnitt einen Hinweis auf zusätzliche Erprobung mit dem Screenreader. Alternativ könnte man auch in den Prüfschritten 4.03.1 (Wert für Formularfelder) oder in 7.02.1 (Objektinformationen für Hilfstechniken verfügbar machen) einen Hinweis integrieren, dass Fehler der Rechtschreibung bei Prüfung auf Stufe II als solche vorgelesen werden müssen.

Diskussion:7.02.1 - Objektinformationen für Hilfstechniken verfügbar machen

2018-08-30T12:42:08Z

JFischer:

Diskussion:6.02.1 - Hilfen zum Auffinden des Zeigers

2018-08-30T12:39:11Z

JFischer: /* Einstellung "Breite des Fokusrechtecks vergrößern" hat kaum Auswirkungen */

== Bewertung ==
21.12.2017 Johannes Fischer (DZB) 
Warum ist die Bewertungsmöglichkeit "Blockade" hier nicht möglich? Wenn keine Übernahme der Plattformeinstellungen erfolgt und keine eigenen Einstellmöglichkeiten vorhanden sind, ist dies nur eine Barriere. Ist der Grund, dass der Nutzer auch assistive Technologien dafür verwenden könnte und somit die Nutzung nicht blockiert ist? Oder gibt es einen anderen Grund?

05.04.2018 Detlef Girke 
auch wenn das Auffinden des Zeigers nicht unterstützt wird, ist eine Nutzung der Anwendung in der Regel noch möglich, wenn auch erschwert. Daher nur Barriere.

== Prüfung nur bestimmter Attribute oder Erweiterung der Prüfanleitung ==
21.12.2017 Johannes Fischer (DZB) 
Im Bereich "Beispiele" ist von der Anpassung einiger Attribute die Rede, und diese werden mit "u. a." benannt: "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."
Im Bereich "Prüfanleitung" werden dann aber nur drei von diesen Attributen geprüft. Wäre es sinnvoll, die Prüfanleitung hier zu erweitern oder allgemeiner zu halten?

05.04.2018 Detlef Girke 
Guter Vorschlag. Sollten wir in der nächsten Telko besprechen.

== Einstellung "Breite des Fokusrechtecks vergrößern" hat kaum Auswirkungen ==
30.08.2018 Johannes Fischer (DZB) 
Frage: Bei mir hat die Einstellung der Vergrößerung des Fokusrechtecks nur geringe Verbesserungen gezeigt. Bei den Desktop-Icons merkt man es noch am meisten, in Dialogfeldern ein wenig, im Windows-Startmenü oder im Windows Explorer gar nicht. Laut einer Hilfeseite soll es sich auch am ehesten auf Dialogfelder auswirken: https://support.microsoft.com/de-ch/help/14207/windows-7-make-computer-easier-to-see 
Empfinden dies andere Prüfer auch so, dass die Option für Nutzer keine große Verbesserungen bringt? Prüfen kann man die Option natürlich, aber für wirklichen Nutzen der Einstellung ist man hier wohl auf eine Verbesserung durch Microsoft angewiesen.

Diskussion:6.02.1 - Hilfen zum Auffinden des Zeigers

2018-08-30T12:37:39Z

JFischer:

== Bewertung ==
21.12.2017 Johannes Fischer (DZB) 
Warum ist die Bewertungsmöglichkeit "Blockade" hier nicht möglich? Wenn keine Übernahme der Plattformeinstellungen erfolgt und keine eigenen Einstellmöglichkeiten vorhanden sind, ist dies nur eine Barriere. Ist der Grund, dass der Nutzer auch assistive Technologien dafür verwenden könnte und somit die Nutzung nicht blockiert ist? Oder gibt es einen anderen Grund?

05.04.2018 Detlef Girke 
auch wenn das Auffinden des Zeigers nicht unterstützt wird, ist eine Nutzung der Anwendung in der Regel noch möglich, wenn auch erschwert. Daher nur Barriere.

== Prüfung nur bestimmter Attribute oder Erweiterung der Prüfanleitung ==
21.12.2017 Johannes Fischer (DZB) 
Im Bereich "Beispiele" ist von der Anpassung einiger Attribute die Rede, und diese werden mit "u. a." benannt: "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."
Im Bereich "Prüfanleitung" werden dann aber nur drei von diesen Attributen geprüft. Wäre es sinnvoll, die Prüfanleitung hier zu erweitern oder allgemeiner zu halten?

05.04.2018 Detlef Girke 
Guter Vorschlag. Sollten wir in der nächsten Telko besprechen.

== Einstellung "Breite des Fokusrechtecks vergrößern" hat kaum Auswirkungen ==
30.08.2018 Johannes Fischer (DZB) 
Bei mir hat die Einstellugn der Vergrößerung des Fokusrechtecks nur geringe Verbesserungen gezeigt. Bei den Desktop-Icons merkt man es noch am meisten, in Dialogfeldern ein wenig, im Windows-Startmenü oder im Windows Explorer gar nicht. Laut einer Hilfeseite soll es sich auch am ehesten auf Dialogfelder auswirken: https://support.microsoft.com/de-ch/help/14207/windows-7-make-computer-easier-to-see 
Empfinden dies andere Prüfer auch so, dass die Option für Nutzer keine große Verbesserungen bringt? Prüfen kann man die Option natürlich, aber für wirklichen Nutzen der Einstellung ist man hier wohl auf eine Verbesserung durch Microsoft angewiesen.

Diskussion:5.05.1 - Kantenglättung im Großbildsystem

2018-08-30T12:26:07Z

JFischer: Die Seite wurde neu angelegt: „== Bildschirmlupe und Pixel/Stufen == 30.08.2018 Johannes Fischer (DZB) Frage: Wenn ich die Windows Bildschirmlupe als Großbildsystem (wie in der Werkzeu…“

== Bildschirmlupe und Pixel/Stufen ==
30.08.2018 Johannes Fischer (DZB) 
Frage: Wenn ich die Windows Bildschirmlupe als Großbildsystem (wie in der Werkzeugliste angegeben) verwende, wird bei mir die Schrift generell pixelig bzw. stufig, das heißt, an den Rändern der Buchstaben erscheinen Pixel in anderen Farben. Dies tritt umso mehr auf, je weiter ich vergrößere. Außerdem nehme ich es nicht nur in Anwendungen wahr, sondern auch in Windows selbst, z. B. auf dem Desktop oder im Startmenü. Dies scheint mir ein normales Verhalten der Bildschirmlupe zu sein, egal ob ClearType in der Systemsteuerung ein- oder ausgeschaltet ist. In ZoomText ist die Schrift dagegen völlig glatt. Mit der Bildschirmlupe dürfte man also nicht sofort Abzug geben, sondern man muss beurteilen, ob es einen Unterschied der Stufigkeit/Pixel bei Buchstaben gibt. Sehen das andere Prüfer auch so?

Diskussion:3.12.2 - Kontextsensitive Hilfe für Tastaturbefehle

2018-08-30T12:21:39Z

JFischer: Die Seite wurde neu angelegt: „== Bewertung - Zugriffstasten, aber nicht Tastenkombinationen in kontexts. Hilfe == 30.08.2018 Johannes Fischer (DZB) Frage: Wie bewertet man es, wenn kon…“

== Bewertung - Zugriffstasten, aber nicht Tastenkombinationen in kontexts. Hilfe ==
30.08.2018 Johannes Fischer (DZB) 
Frage: Wie bewertet man es, wenn kontextsensitive Hilfe zwar Zugriffstasten enthält, aber nicht die Tastenkombinationen. Beispiel Excel (wohl ab 2007) - Menüband: Durch Drücken der Alt-Taste werden Zugriffstasten angezeigt. Die Tastenkombinationen, z. B. Strg+Umschalt+F für Fett-Formatierung, werden aber nur im Tooltip bereitgestellt. Streng nach Prüfanleitung würde es keinen Abzug geben, denn kontextsensitive Hilfe ist gegeben. Aber eine Tastenkombination ist vielleicht noch effizienter. Ich würde es wohl auch bei einem Hinweis belassen und keinen Abzug geben. Wie bewerten hier andere Prüfer?

Diskussion:3.02.2 - Name von grafischen Bedienelementen abrufen

2018-08-30T12:16:17Z

JFischer: Die Seite wurde neu angelegt: „== Fehler Taste F10 == 30.08.2018 Johannes Fischer (DZB) In den Bereichen Beispiele und Prüfanleitung wird von der Taste F10 für das Kontextmenü gespro…“

== Fehler Taste F10 ==
30.08.2018 Johannes Fischer (DZB) 
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

Diskussion:1.10.0 - Alternativen für Abbildungen und Multimedia-Inhalte

2018-08-30T12:14:43Z

JFischer: Die Seite wurde neu angelegt: „== Audiodeskription == 30.08.2018 Johannes Fischer (DZB) Im Abschnitt Beschreibung steht: "Für bedeutungstragende stumme Sequenzen in Videos werden gespr…“

== Audiodeskription ==
30.08.2018 Johannes Fischer (DZB) 
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." 
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.

Diskussion:Einführung BIT inklusiv Anwendungssoftware-Test

2018-08-30T12:11:15Z

JFischer:

== Bewertung eines Szenarios ==
30.08.2018 Johannes Fischer (DZB) 
Frage: Werden die Einschränkungen, Barrieren, Blockaden im Prüfbericht für das Szenario als Ganzes aufgelistet oder wird das Szenario in Teilschritte bzw. Teilansichten zerlegt, wofür dann gesondert die Einschränkungen usw. aufgeführt werden? Aus meiner Sicht ist die Aufteilung in Teilschritte sinnvoll. Zum Beispiel könnte bei einer Excel-Prüfung die Orientierung auf dem Bildschirm nach dem Start (Menüband, Statuszeile, Dokumentinhalt) getrennt werden von einer bestimmten Aufgabe (Daten eintragen und formatieren). Wie handhaben dies andere Prüfer?
Besonders, wenn ein Scoring verwendet werden sollte, wird die Frage wohl relevant.

Diskussion:1.02.2 - Leserliche Schrift

2018-08-30T12:10:39Z

JFischer:

== 80 Zeichen pro Zeile ==
30.08.2018 Johannes Fischer (DZB) 
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.

Diskussion:1.02.2 - Leserliche Schrift

2018-08-30T12:09:23Z

JFischer: Die Seite wurde neu angelegt: „= 80 Zeichen pro Zeile = 30.08.2018 Johannes Fischer (DZB) Im Abschnitt Beschreibung ist angegeben, dass Fließtext nicht mehr als 80 Zeichen pro Zeile h…“

= 80 Zeichen pro Zeile =
30.08.2018 Johannes Fischer (DZB) 
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.

Diskussion:Einführung BIT inklusiv Anwendungssoftware-Test

2018-08-30T12:02:12Z

JFischer: Die Seite wurde neu angelegt: „= Bewertung eines Szenarios = 30.08.2018 Johannes Fischer (DZB) Frage: Werden die Einschränkungen, Barrieren, Blockaden im Prüfbericht für das Szenario…“

= Bewertung eines Szenarios =
30.08.2018 Johannes Fischer (DZB) 
Frage: Werden die Einschränkungen, Barrieren, Blockaden im Prüfbericht für das Szenario als Ganzes aufgelistet oder wird das Szenario in Teilschritte bzw. Teilansichten zerlegt, wofür dann gesondert die Einschränkungen usw. aufgeführt werden? Aus meiner Sicht ist die Aufteilung in Teilschritte sinnvoll. Zum Beispiel könnte bei einer Excel-Prüfung die Orientierung auf dem Bildschirm nach dem Start (Menüband, Statuszeile, Dokumentinhalt) getrennt werden von einer bestimmten Aufgabe (Daten eintragen und formatieren). Wie handhaben dies andere Prüfer?
Besonders, wenn ein Scoring verwendet werden sollte, wird die Frage wohl relevant.

Diskussion:1.07.1 - Informationen nicht allein durch Farbe übermitteln

2018-07-30T12:38:25Z

JFischer:

21.12.2017 Anmerkung Johannes Fischer (DZB): 
Der Kontrast für Farbflächen als Markierung zum Hintergrund von 1,5:1 ist sehr gering und meiner Meinung nach nicht barrierefrei. Ein Kontrast von 3:1 sollte das Minimum darstellen, denn dieser Kontrast ist von Normalsichtigen geradeso wahrnehmbar, vergleiche Erklärung in Prüfschritt 1.01.0. 
Und falls wirklich wie im Abschnitt "Begründung" die Hälfte des zur Unterscheidbarkeit von Zeichen angesetzten Kontrastwertes verwendet werden sollte, müsste das wohl eher 2:1 sein. Denn 1:1 ist das Kontrastminimum, nicht 0:1. Von 1:1 bis 3:1 ist der Abstand 2, sodass der Abstand 1 die Hälfte darstellen würde. Von 1:1 auf 2:1 ist der Abstand 1, daher müsste 2:1 angesetzt werden.

05.04.2018 Detlef Girke: 
In der ISO 32975 findet man folgendes:
Hier stehen auf Seite 8 die Kontrastwerte für Schrift etc. = 0,7 bis 0,8 und für flächige Bodenindikatoren = 0,4. Die Messung und die Messwerte sind hier ganz anders als am Bildschirm, aber das Verhältnis - der Kontrast von Flächen wird halb so stark angesetzt als der von Zeichen - ist m.E. übertragbar.
Das mit 2:1 stimmt aber. Das sollten wir korrigieren.

10.04.2018 Johannes Fischer (DZB): 
Ok, von den Kontrastwerten 0,8 bzw. 0,4 für Bodenindikatoren wusste ich bisher nichts. Danke für die Information. Die Werte scheinen mir der Formel des Michelson-Kontrasts zu entstammen. Es stimmt, wenn man hier allein das Verhältnis verwendet, um den Kontrast für markierende Farbflächen zum Hintergrund zu bestimmen, würde für einen Ausgangswert für Zeichen von 3:1 als Ergebnis ein Wert von 2:1 stehen. Aber für mich stehen zwei Dinge in Frage:

#Der Kontrast von Zeichen ist in der WCAG eigentlich 4,5:1. Nur großer oder fetter Text darf den verringerten Kontrast von 3:1 verwenden. Wenn man nun also nicht 3:1, sondern 4,5:1 als Ausgangswert nimmt, wäre die Hälfte des Kontrastwertes 2,75:1 und damit deutlich höher als 2:1.
#Statt sich auf den WCAG-Wert von 4,5:1 für Text zu beziehen, könnte man versuchen, die Kontrastwerte 0,8 und 0,4 auf WCAG-Werte umzurechnen. Dazu habe zunächst einen Link von Leserlich.info gefunden, wo steht, dass 0,6 nach Michelson dem WCAG-Wert 4,5:1 entspricht (0,8 -> 7:1): http://www.leserlich.info/kapitel/farben.php 
#:Ich habe noch eine Seite gefunden, auf der im Bereich "Common Metrics" für den Verhältniswert 3:1 ein Wert 0,5 nach Michelson angegeben wird: http://www.stonesc.com/pubs/Contrast%20Metrics.htm
#:Unter einer weiteren Seite von Leserlich (http://www.leserlich.info/werkzeuge/kontrastrechner/) im Bereich "Hintergründe zur Berechnung" sind die Formeln von WCAG und Michelson hinterlegt. Wenn ich hier z. B. den WCAG-Kontrast von 2:1 umrechne, komme ich nur auf 0,33 oder 0,34 nach Michelson, bei WCAG 2,3:1 dagegen auf etwa 0,4 nach Michelson, siehe folgendes Beispiel:
#:WCAG-Formel: 2,3:1 = (2,25 + 0,05) / (0,95 + 0,05)
#:-> Ymax = 2,25; Ymin = 0,95
#:Dies setze ich in die Michelson-Formel ein:
#:(2,25 - 0,95) / (2,25 + 0,95) = 1,3 / 3,2 = 0,406
Wenn ich falsch gerechnet haben sollte bzw. ich einem Irrtum bezüglich der Umrechnung unterlegen sein sollte, bitte korrigieren. Ich bin kein Experte für Kontrastformeln und habe nur etwas dazu recherchiert.

Fazit: 
Aus meiner Sicht könnte man sich für Kontrastwerte zwischen 2,3:1 und 2,75:1 entscheiden, je nachdem, anhand welcher Alternative man es begründet. Oder man nimmt als Mitte zwischen beiden Alternativen 2,5:1 als Mindestkontrast.

== Versuchsanordnung ==

11.06.2018 Brigitte Bornemann

Die theoretische Diskussion um Kontrastformeln lässt sich ggf. leichter entscheiden, wenn wir etwas empirisches Material zur Anschauung haben. Anbei ein Beispiel aus meiner aktuellen Beratungspraxis (Namen sind geschwärzt).

[[Datei:kontrast_flaechen_checkbox_eingabefeld.png | 750px | Screenshot: Kontraste von Checkbox und Eingabefeld]]

In Frage stehen die leeren Checkboxen und Eingabefelder, die im Screenshot farblich markiert sind.

Die Checkbox ist ein Zeichen, denn sie muss von vergleichbaren Formularfeldern, z.B. Radiobutton, unterscheidbar sein. Sie ist auch so groß wie ein Textzeichen, nicht extra groß wie heute oft zu sehen. Es gilt also die Kontrastanforderung von 3:1 wie für große bzw. fette Zeichen. Das Eingabefeld ist dagegen eine Fläche, es kommt darauf an, ob es gegen den Hintergrund wahrnehmbar ist. Der ausreichende Kontrast von Flächen steht hier zur Diskussion.

Im abgebildeten Beispiel sind die Kontraste zu schwach (bitte nicht nachmessen - in der Abbildung kommen die Farben nicht original heraus).
Die Checkbox im Beispiel hat einen Kontrast von 2:1.
Das Eingabefeld im Beispiel hat einen Kontrast von 1,1:1.

'''Versuchsanordnung'''

Das Eingabefeld im Beispiel ist kaum wahrnehmbar, soviel ist klar. Aber welcher Wert wäre ausreichend, um das Eingabefeld zu erkennen? - In unserer Diskussion wurden Werte von 1,5:1, 2:1, 2,3:1, 2,5:1, 2,8:1 genannt.

Diese verschiedenen Grenzwerte für den Kontrast von Flächen habe ich in einer Versuchsanordnung mit Formularfeldern dargestellt. Meine Bitte: schaut Euch die [http://www.bitsite.de/testen/kontraste.html Versuchsanordnung auf dem Testserver] an und gebt Rückmeldung, bei welchem Wert für Euch persönlich "gut sichtbar" anfängt.

[[Datei: kontrast_flaechen_versuch.png | 560px | Screenshot Versuchsanordnung ]]

Diese Abbildung ist ein Screenshot, bitte nicht für den Test verwenden.
Bitte die [http://www.bitsite.de/testen/kontraste.html Versuchsanordnung auf dem Testserver] verwenden.

Meine persönlichen Werte - ich bin leicht alterssichtig:
Checkbox und Radiobutton kann ich deutlich unterscheiden bei einem Kontrast von 2,3:1.
Das Eingabefeld kann ich deutlich erkennen bei einem Kontrast von 1,5:1.

Ich freue mich auf Rückmeldungen von normalsichtigen und von mehr oder weniger stark sehbehinderten Lesern. Bitte meldet mir Euer Ergebnis in einer Mail an bb@bit-informationsdesign.de mit Betreff "Kontrast von Flächen".

Danke :-)

30.07.2018 Johannes Fischer

Frau Bornemann, hier ist mein Ergebnis, das ich Ihnen auch per Mail geschickt habe: Sowohl das Eingabefeld als auch Checkbox und Radiobutton kann als Normalsichtiger in allen Fällen erkennen. Bei dem niedrigsten Kontrast 1,5:1 bereitet es etwas Schwierigkeiten, ist aber möglich. Den Kontrast von 2:1 finde ich auch noch nicht komfortabel zu erkennen. Ohne leichte Anstrengung komfortabel zu erkennen finde ich erst Werte von 2,3:1 bis 2,5:1.

Ich bin mir daneben unsicher, ob der Kontrast von Formularfeldern überhaupt unter den Prüfschritt der Informationsvermittlung mit Farbe bzw. Farbflächen als Markierung zum Hintergrund fällt. Ich würde den Fall der Farbflächen als Markierung eher bei besonders markierten Worten sehen. Für die Kennzeichnung von Eingabefeldern gibt es in den neuen WCAG 2.1 das Kriterium 1.4.11 Non-Text-Contrast. Im [https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#active-user-interface-component-examples zugehörigen Understanding-Dokument] sind auch Beispiele zu sehen, wie ein Eingabefeld gekennzeichnet wird (Beispiel Text input using background colour). Sobald die EN 301549 die neuen WCAG-Kriterien für die Software übernommen haben, müssten wir dies perspektivisch wohl in einem eigenen Prüfschritt unterbringen. Der von den WCAG geforderte Mindest-Kontrast wäre hier übrigens 3:1.

Diskussion:2.04.1 - Zeitbegrenzungen sind anpassbar

2018-04-17T09:53:05Z

JFischer:

Thomas Ernst, 20.02.18: Die Zeitangabe „diese Anforderung gilt nicht für alle Fälle, in denen die zeitliche Begrenzung länger als 20 Stunden beträgt" muss laut Absprache mit Detlef Girke „20 Minuten" lauten.

Johannes Fischer, 20.02.2018: Im BITV-/WCAG-Test wird der Prüfschritt (2.2.1a) tatsächlich bei einem Time Out später als nach 20 Minuten Inaktivität mit erfüllt bewertet. Ich halte dies allerdings für problematisch, da die [https://www.w3.org/Translations/WCAG20-de/#time-limits-required-behaviors WCAG 2.0] 20 Stunden fordern. Der Software-Test hat die EN 301549, Kriterium 11.2.1.17 als Basis, welche identisch zum genannten WCAG-Kriterium 2.2.1 ist. Natürlich vereinfachen 20 Minuten den Test, ich finde persönlich aber 20 Minuten eigentlich zu kurz.

23.02.18, Thomas Ernst (Stiftung Pfennigparade): 20 Minuten mögen zu kurz sein. 20 Stunden sind aber nicht prüfbar.

09.03.18, Thomas Ernst (Stiftung Pfennigparade): Detlef Girke antwortete mit folgender Mail auf meine Anfrage:

''„in der EN 301 549, Kapitel 11.17, steht übersetzt:''

''Für jede zeitliche Begrenzung, die von der Software festgelegt wird, gilt mindestens eines der folgenden: ''
''- Abschalten: Der Benutzer darf die zeitliche Begrenzung abschalten, bevor er darauf trifft; oder ''
''- Anpassen: Der Benutzer darf die zeitliche Begrenzung anpassen, bevor er darauf trifft, und zwar so weitreichend, dass es sich um die mindestens zehnfache Zeit der Standardeinstellung handelt; oder ''
''- Ausweiten: Der Benutzer wird gewarnt, bevor die Zeit abläuft und bekommt mindestens 20 Sekunden Zeit, um die zeitliche Begrenzung mit einer einfachen Handlung auszuweiten (zum Beispiel: „Drücken Sie die Leertaste“) und der Benutzer darf die zeitliche Begrenzung mindestens 10 Mal ausweiten; oder ''
''- Echtzeit-Ausnahme: Die zeitliche Begrenzung ist ein erforderlicher Bestandteil eines Echtzeit- Ereignisses (zum Beispiel einer Auktion) und es gibt keine Alternative zur zeitlichen Begrenzung; oder ''
''- Unentbehrliche Ausnahme: Die zeitliche Begrenzung ist unentbehrlich und eine Ausweitung dieser würde die Handlung ungültig machen; oder ''
''- 20-Stunden-Ausnahme: Die zeitliche Begrenzung beträgt mehr als 20 Stunden.''

''Das sollte man pragmatisch sehen: Es geht hier um zeitlich begrenzte Anzeigen und Eingabaufforderungen. ''
''Man könnte das so deuten: Wenn eine Anzeige oder Eingabaufforderung einem 20 Stunden Zeit lässt, zu reagieren, dann ist das keine Barriere. Solch ein Szenario kann hier aber nicht gemeint sein. Denn selbst, wenn eine Eingabaufforderung einem nur 20 Sekunden Zeit lässt, sie zu verlängern, dann ist das schon in Ordnung. Es muss also um etwas anderes gehen. Das einzige, das mir in diesem Zusammenhang einfällt, sind Server-Timeouts. ''
''Die Formulierung ist ja aus den WCAG 2.0 (siehe https://www.w3.org/Translations/WCAG20-de/#time-limits). Auch im BITV-Test steht
das: http://testen.bitv-test.de/index.php?a=di&iid=19''

''Das mit den 20 Stunden hat in den letzten zehn Jahren ganz offenbar niemanden interessiert. Das Internet liefert keinerlei Hinweise darauf, wie man das prüfen kann. Selbst die Techniques liefern keinen Hinweis darauf, wie man das prüfen könnte. Aber weil für die Prüfung eigentlich kein Unterschied zum BITV-Test besteht, würde ich mir um die 20 Stunden in Zukunft einfach keine Gedanken machen. Oder beim W3C anklopfen :-)"''

17.04.2018 Johannes Fischer (DZB): 
Stimmt, für die Verlängerung eines Zeitlimits mit einer kurzen Anweisung sind 20 Sekunden schon in Ordnung. Dieser Zeitraum wird im Understanding-Dokument der WCAG so begründet, dass es sonst eventuell auch zu Sicherheitsrisiken kommen könnte. Es wird dort nicht behauptet, dass alle Nutzer mit 20 Sekunden klarkommen würden.
Aber bei einem deutlich längerem Zeitlimit pro Anweisung von 1 oder 2 Minuten reichen für die meisten Nutzer wahrscheinlich die 20 Minuten als TimeOut-Begrenzung aus und man benötigt nicht 20 Stunden. Bei längeren bzw. komplexeren Formularen in einer Ansicht muss man vielleicht als Prüfer auch im Einzelfall entscheiden, ob mehr als 20 Minuten als Begrenzung erforderlich sind oder nicht. Für alle denkbaren Fälle kann eine bestimmte Minutenzahl wohl nicht fest definiert werden, sie kann aber als Vorschlag dienen.

Diskussion:1.07.1 - Informationen nicht allein durch Farbe übermitteln

2018-04-12T08:00:25Z

JFischer:

Diskussion:1.07.1 - Informationen nicht allein durch Farbe übermitteln

2018-04-10T08:39:55Z

JFischer:

Diskussion:4.10.2 - Zusätzliche kontextsensitive Hilfe

2018-04-06T10:15:13Z

JFischer:

21.12.2017 Frage Johannes Fischer (DZB): 
Warum wurde der Prüfschritt in Stufe II eingeordnet und nicht in Stufe I? Stufe I prüft die Konformität der EN 301 549 und in dieser Norm ist die Prüfung ja enthalten. Oder ist der Grund, dass die kontextsensitive Hilfe in der WCAG in Level AAA fällt und man in Stufe I keine Prüfung aus Level AAA haben möchte?

05.04.2018 Detlef Girke 
Hilfe und Fehlererkennung sind doch drin. Kontextsensitive Hilfe ist meines Erachtens nicht Bestandteil der EN 301 549. Welches Kriterium meinst Du? Wir haben bez. dieses Schrittes in unserem Verfahren:

* 2.06.1 - Ausreichende Anweisungen für Benutzereingaben
* 2.07.1 - Hilfen bei Fehleingaben

06.04.2018 Johannes Fischer (DZB): 
In den Referenzen des Prüfschritts ist aus den EN 301549 der Punkt 11.3.2.11 (List of available actions) angegeben und dies ist auch der einzige Prüfschritt, wo dieser Punkt der europäischen Norm referenziert wird. Nach diesem Punkt soll die Software eine Liste von ausführbaren Aktionen für ein Bedienelement erstellen und sie für assistive Technologien auslesbar machen. Wenn Tastaturkommandos in einem Tooltip oder in einem Menü angezeigt werden und der Screenreader diese Information ansagt, müsste das doch dem Punkt 11.3.2.11 der EN entsprechen, oder?

2.06.1 (Ausreichende Anweisungen für Benutzereingaben) sagt zwar, dass Label vorhanden sein müssen und Eingabeformate erklärt werden. Aber der Schritt sagt nicht aus, dass auch Tastenkombinationen angezeigt werden müssen bzw. dass der Screenreader diese ausgeben muss oder dass die Möglichkeit der Pfeiltastennavigation für eine Auswahlliste vom Screenreader angesagt werden muss.

Vielleicht könnte man den Prüfschritt auch auftrennen. Alles, was konkrete Funktionen kurz beschreibt (z. B. Tastenkombinationen, Pfeiltastennavigation bei Auswahllisten usw.) gehört zum EN-Punkt 11.3.2.11 und muss daher zusätzlich in Stufe I (vielleicht auch Prüfschritt 2.06.1) geprüft werden. Richtige kontextsensitive Hilfe entsprechend WCAG-Kriterium 3.3.5 würde weiterhin in 4.10.2 geprüft. Dazu würden dann richtige Hilfetexte zu Eingabefeldern gehören. Ein mir bekanntes Beispiel wären Eingabefelder für eine Steuererklärung, zu denen Informationstexte eingeblendet werden, was in welches Feld genau einzutragen ist. Man würde dann aber nur fordern, dass es solche Texte gibt, nicht dass der Screenreader sie sofort komplett ausgibt (da evtl. sehr lange Texte).

Diskussion:3.07.0 - Sinnvolle Fokus-Reihenfolge

2018-04-06T09:38:27Z

JFischer:

21.12.2017 Anmerkung Johannes Fischer (DZB): 
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?

05.04.2018 Detlef Girke:

Im Unterkapitel "Bewertung" zu diesem Prüfschritt steht:

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

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

Alle weiteren Mängel sind eine Einschränkung."

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?

06.04.2018 Johannes Fischer (DZB): 
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.

Diskussion:2.06.1 - Ausreichende Anweisungen für Benutzereingaben

2018-02-22T16:18:57Z

JFischer:

= Pflichtfeld-Kennzeichnung =
21.12.2017 Johannes Fischer (DZB) 
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.

= Vorbelegung Eingabefeld =
21.12.2017 Johannes Fischer (DZB) 
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."
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.

= Einordnung bzw. Beschreibung =
20.02.2018 Thomas Ernst (Stiftung Pfennigparade) 
Die Abgrenzung zum Erfolgskriterium "1.05.1 Prägnante Beschriftungen" müsste bei Beschriftungen von Eingabefeldern klarer formuliert werden.

20.02.2018 Johannes Fischer (DZB) 
Herr Ernst, wie meinen Sie das genau? Sollte man den Begriff "Verständlichkeit" durch "Aussagekraft" ersetzen oder meinen Sie etwas anderes?

22.02.2018 Thomas Ernst (Stiftung Pfennigparade) 
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.
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.

22.02.2018 Johannes Fischer (DZB) 
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:

Wenn ein Element Benutzereingaben erwartet, werden Beschriftungen, Anweisungen oder Hilfetexte bereitgestellt, die dem Benutzer ausreichend Information geben, um Fehler zu vermeiden. Darunter versteht man z. B., dass Symbole für Pflichtfelder erklärt werden, dass Label für Dialogelemente vorhanden sind und dass erforderliche Eingabeformate erklärt werden. Die Aussagekraft des Labels an sich wird in diesem Prüfschritt nicht beurteilt, siehe Einordnung. 
Dialogelemente, die Benutzereingaben erwarten, sind u.a. Eingabefelder, Auswahllisten, Optionsschaltflächen, Absenden-Schaltflächen.

Benutzer:JFischer

2018-02-20T14:25:40Z

JFischer:

Johannes Fischer, Deutsche Zentralbücherei für Blinde (DZB)
E-Mail: johannes.fischer@dzb.de

Diskussion:2.04.1 - Zeitbegrenzungen sind anpassbar

2018-02-20T14:18:08Z

JFischer:

Diskussion:2.06.1 - Ausreichende Anweisungen für Benutzereingaben

2018-02-20T14:03:37Z

JFischer:

Diskussion:4.02.0 - Name für grafische Bedienelemente und Anzeigen

2018-01-15T13:30:06Z

JFischer:

21.12.2017 Anmerkung Johannes Fischer (DZB): 
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. Auch in der Bezeichnung des Prüfschritts wird bisher nur der Name erwähnt, nicht Rolle oder Wert.

21.12.2017 Anmerkung Detlef Girke 
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.

15.01.2018 Johannes Fischer 
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.

Diskussion:6.02.1 - Hilfen zum Auffinden des Zeigers

2017-12-21T13:29:42Z

JFischer: Die Seite wurde neu angelegt: „21.12.2017 Anmerkungen Johannes Fischer (DZB): 1. Warum ist die Bewertungsmöglichkeit "Blockade" hier nicht möglich? Wenn keine Übernahme der Plattformeins…“

21.12.2017 Anmerkungen Johannes Fischer (DZB):

1. Warum ist die Bewertungsmöglichkeit "Blockade" hier nicht möglich? Wenn keine Übernahme der Plattformeinstellungen erfolgt und keine eigenen Einstellmöglichkeiten vorhanden sind, ist dies nur eine Barriere. Ist der Grund, dass der Nutzer auch assistive Technologien dafür verwenden könnte und somit die Nutzung nicht blockiert ist? Oder gibt es einen anderen Grund?

2. Im Bereich "Beispiele" ist von der Anpassung einiger Attribute die Rede, und diese werden mit "u. a." benannt: "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."
Im Bereich "Prüfanleitung" werden dann aber nur drei von diesen Attributen geprüft. Wäre es sinnvoll, die Prüfanleitung hier zu erweitern oder allgemeiner zu halten?

Diskussion:6.01.1 - Eingabehilfen für Tastatur und Maus

2017-12-21T13:23:03Z

JFischer: Die Seite wurde neu angelegt: „21.12.2017 Anmerkung Johannes Fischer (DZB): Es gibt in der Systemsteuerung noch mehr Eingabehilfen, z. B. die Einstellbarkeit der Doppelklick-Geschwindig…“

21.12.2017 Anmerkung Johannes Fischer (DZB): 
Es gibt in der Systemsteuerung noch mehr Eingabehilfen, z. B. die Einstellbarkeit der Doppelklick-Geschwindigkeit mit der Maus. Diese wird auch in der ISO 9241-171 unter 9.4.9 gefordert. Könnte man den Prüfschritt noch ergänzen? Oder gibt es einen Grund, warum das hier nicht enthalten ist? Generell bin ich mir nicht ganz sicher, ob alle Anforderungen der ISO-Norm aus 9.3 und 9.4 (auf die sich dieser Prüfschritt bezieht) in diesem oder anderen Prüfschritten des Prüfverfahrens alle berücksichtigt sind. Ich habe dies im Detail aber nicht nachgeprüft, es ist mehr eine Frage.

Diskussion:5.04.1 - Fokusverfolgung im Großbildsystem

2017-12-21T13:21:34Z

JFischer: Die Seite wurde neu angelegt: „21.12.2017 Anmerkung Johannes Fischer (DZB): Eventuell könnte man in der Prüfanleitung ergänzen, dass in den Einstellungen der Bildschirmlupe das Häkc…“

21.12.2017 Anmerkung Johannes Fischer (DZB): 
Eventuell könnte man in der Prüfanleitung ergänzen, dass in den Einstellungen der Bildschirmlupe das Häkchen "Dem Tastaturfokus folgen" aktiviert sein muss.

Diskussion:4.10.2 - Zusätzliche kontextsensitive Hilfe

2017-12-21T13:18:21Z

JFischer: Die Seite wurde neu angelegt: „21.12.2017 Frage Johannes Fischer (DZB): Warum wurde der Prüfschritt in Stufe II eingeordnet und nicht in Stufe I? Stufe I prüft die Konformität der EN…“

Diskussion:1.01.0 - Ausreichender Kontrast

2017-12-21T13:16:35Z

JFischer:

21.12.2017 Frage Johannes Fischer (DZB): 
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.

Diskussion:1.07.1 - Informationen nicht allein durch Farbe übermitteln

2017-12-21T13:16:15Z

JFischer:

Diskussion:3.07.0 - Sinnvolle Fokus-Reihenfolge

2017-12-21T13:15:47Z

JFischer:

Diskussion:3.11.0 - Vollständige Dokumentation der Tastaturbefehle

2017-12-21T13:15:18Z

JFischer:

21.12.2017 Anmerkung Johannes Fischer (DZB): 
Im Abschnitt "Begründung" heißt es: "Selten gebrauchte Tastaturbefehle sind den Benutzern nicht geläufig und müssen nachgeschlagen werden können."
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? 
Tasten wie Esc, Bild-auf, Bild-ab, F6 (zwischen Bereichen springen) oder Kombinationen mit Strg oder Alt müssen aber wohl schon dokumentiert sein.
Gibt es hierzu Meinungen?

Diskussion:2.01.2 - Ausreichende Größe von Schaltflächen

2017-12-21T13:14:54Z

JFischer:

21.12.2017 Anmerkungen Johannes Fischer (DZB):

1. Warum wird die Bewertung "Einschränkung" erst bei weniger als 98% gegeben und nicht bei weniger als 100%?

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.

Diskussion:2.06.1 - Ausreichende Anweisungen für Benutzereingaben

2017-12-21T13:14:24Z

JFischer:

21.12.2017 Anmerkungen Johannes Fischer (DZB):

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

2. 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."
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.

Diskussion:4.02.0 - Name für grafische Bedienelemente und Anzeigen

2017-12-21T13:13:51Z

JFischer:

Diskussion:4.06.1 - Wiedergabe von Textattributen

2017-12-21T13:13:24Z

JFischer:

21.12.2017 Anmerkung Johannes Fischer (DZB): 
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.

Diskussion:4.06.1 - Wiedergabe von Textattributen

2017-12-21T13:12:37Z

JFischer: Die Seite wurde neu angelegt: „Anmerkung Johannes Fischer (DZB): In der Prüfschrittbeschreibung werden fest die Attribute fett, kursiv und unterstrichen angegeben ("Bei Textinhalten we…“

Anmerkung Johannes Fischer (DZB): 
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.

Diskussion:4.02.0 - Name für grafische Bedienelemente und Anzeigen

2017-12-21T13:11:19Z

JFischer:

Anmerkung Johannes Fischer (DZB): 
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. Auch in der Bezeichnung des Prüfschritts wird bisher nur der Name erwähnt, nicht Rolle oder Wert.

Diskussion:4.02.0 - Name für grafische Bedienelemente und Anzeigen

2017-12-21T13:10:48Z

JFischer: Die Seite wurde neu angelegt: „Anmerkung Johannes Fischer (DZB): 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,…“

Anmerkung Johannes Fischer (DZB): 
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. Auch in der Bezeichnung des Prüfschritts wird bisher nur der Name erwähnt, nicht Rolle oder Wert.

Diskussion:2.06.1 - Ausreichende Anweisungen für Benutzereingaben

2017-12-21T13:07:30Z

JFischer: Die Seite wurde neu angelegt: „Anmerkungen Johannes Fischer (DZB): 1. Im Bereich "Beispiele" steht, dass ein Zeichen für Pflichtfelder (z. B. das Stern-Zeichen (*)) vor oder auch hinter de…“

Anmerkungen Johannes Fischer (DZB):

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

2. 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."
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.

Diskussion:2.01.2 - Ausreichende Größe von Schaltflächen

2017-12-21T13:03:50Z

JFischer: Die Seite wurde neu angelegt: „Anmerkungen Johannes Fischer (DZB): 1. Warum wird die Bewertung "Einschränkung" erst bei weniger als 98% gegeben und nicht bei weniger als 100%? 2. Ist 12 x…“

Anmerkungen Johannes Fischer (DZB):

1. Warum wird die Bewertung "Einschränkung" erst bei weniger als 98% gegeben und nicht bei weniger als 100%?

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.

Diskussion:3.11.0 - Vollständige Dokumentation der Tastaturbefehle

2017-12-21T13:01:17Z

JFischer: Die Seite wurde neu angelegt: „Anmerkung Johannes Fischer (DZB): Im Abschnitt "Begründung" heißt es: "Selten gebrauchte Tastaturbefehle sind den Benutzern nicht geläufig und müssen…“

Anmerkung Johannes Fischer (DZB): 
Im Abschnitt "Begründung" heißt es: "Selten gebrauchte Tastaturbefehle sind den Benutzern nicht geläufig und müssen nachgeschlagen werden können."
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? 
Tasten wie Esc, Bild-auf, Bild-ab, F6 (zwischen Bereichen springen) oder Kombinationen mit Strg oder Alt müssen aber wohl schon dokumentiert sein.
Gibt es hierzu Meinungen?

Diskussion:3.07.0 - Sinnvolle Fokus-Reihenfolge

2017-12-21T12:59:16Z

JFischer: Die Seite wurde neu angelegt: „Anmerkung Johannes Fischer (DZB): Bei den Bewertungsalternativen sollte es auch die Bewertungsmöglichkeit einer Blockade geben. Falls die Reihenfolge vö…“

Anmerkung Johannes Fischer (DZB): 
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?

Diskussion:1.01.0 - Ausreichender Kontrast

2017-12-21T12:58:08Z

JFischer:

Frage Johannes Fischer (DZB): 
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.

Diskussion:1.07.1 - Informationen nicht allein durch Farbe übermitteln

2017-12-21T12:57:11Z

JFischer: Die Seite wurde neu angelegt: „Anmerkung Johannes Fischer (DZB): Der Kontrast für Farbflächen als Markierung zum Hintergrund von 1,5:1 ist sehr gering und meiner Meinung nach nicht ba…“

Anmerkung Johannes Fischer (DZB): 
Der Kontrast für Farbflächen als Markierung zum Hintergrund von 1,5:1 ist sehr gering und meiner Meinung nach nicht barrierefrei. Ein Kontrast von 3:1 sollte das Minimum darstellen, denn dieser Kontrast ist von Normalsichtigen geradeso wahrnehmbar, vergleiche Erklärung in Prüfschritt 1.01.0. 
Und falls wirklich wie im Abschnitt "Begründung" die Hälfte des zur Unterscheidbarkeit von Zeichen angesetzten Kontrastwertes verwendet werden sollte, müsste das wohl eher 2:1 sein. Denn 1:1 ist das Kontrastminimum, nicht 0:1. Von 1:1 bis 3:1 ist der Abstand 2, sodass der Abstand 1 die Hälfte darstellen würde. Von 1:1 auf 2:1 ist der Abstand 1, daher müsste 2:1 angesetzt werden.