Merge branch 'main' into detlevhfischer-patch-14

Prüfschritte/de/11.1.3.5 Eingabezweck bestimmen.adoc

@@ -64,6 +64,7 @@ Hier sind die Eingabefelder für den Nutzer nicht von den Feldern für Mitreisen
 * Eingabefelder beziehen sich nicht eindeutig auf die Nutzenden selbst.
 
 == Quellen
+In der https://github.com/w3c/matf/issues/2[Mobile Accessibility Taskforce wird 11.1.3.5 diskutiert], ob und in welcher Form die Anforderung bei nativen Apps Anwendung finden kann.
 
 === Android
 * Appt.org: https://appt.org/en/docs/android/samples/input-keyboard-type[Input keyboard type on Android]

Prüfschritte/de/11.2.1.1 Tastatur.adoc

@@ -26,7 +26,8 @@ Dies trifft auf die meisten Apps auf den gängigen mobilen Plattformen wie Apple
 . Mit der Tabulatortaste die Links und Formularelemente durchgehen. Wo sich Elemente nicht mit dem Tabulator erreichen lassen, prüfen, ob sie über die Pfeiltasten erreichbar sind.
 . Prüfen, ob alle wesentlichen Funktionen über die Tastatur erreicht und aktiviert werden können. In der Regel heißt das, das Elemente fokussiert und dann über die Eingabe- oder Leertaste aktiviert werden können. Wo Elemente nicht erreichbar oder aktivierbar sind, stehen äquivalente Wege zum Auslösen der Funktion über die Tastatur zur Verfügung.
 . Falls die Ansicht Elemente enthält, die wie Bedienelemente aussehen, jedoch nicht über Tabulatortaste oder Pfeiltasten angesteuert werden, prüfen, ob diese Elemente auf Touch-Eingaben reagieren (zum Beispiel Navigation zu anderen Ansichten, Funktionsaufrufe, Vergrößerung, Einblenden von weiteren Inhalten). Wenn ja, müssen sie auch mit der Tastatur fokussier- und aktivierbar sein.
-. Falls die Ansicht scrollbare Bereiche enthält, sollen nicht sichtbare Inhalte dieser Bereiche auch über die Tastatur erreichbar sein.
+. Falls die Ansicht scrollbare Bereiche enthält, sollen nicht sichtbare Inhalte dieser Bereiche auch über die Tastatur erreichbar sein, ohne das dazu der Bildschirm berührt werden muss.
+.. iOS: Falls Seitenbereiche mit Textinhalten ohne interaktive Elemente nicht erreicht werden: Prüfen, ob nach Aktivieren von Tastaturgesten (Tab + G) alle Textinhalte über die vertikalen Pfeiltasten erreichbar sind.
 
 === 3. Hinweise
 

Prüfschritte/de/11.2.4.7 Fokus sichtbar.adoc

@@ -110,6 +110,8 @@ endif::env_embedded[]
 
 === Android
 * Appt.org: https://appt.org/en/docs/android/samples/accessibility-focus-indicator[Accessibility focus indicator on Android]
+* Android ViewUI: https://github.com/cvs-health/android-view-accessibility-techniques/blob/0ffd2aad8f8eada9893295ac47cc9ee9bf21372d/doc/dynamicbehaviors/CustomFocusIndicators.md#L4[Custom Focus Indicators]
+* Android Compose: https://github.com/cvs-health/android-compose-accessibility-techniques/blob/main/doc/interactions/CustomFocusIndicators.md[Custom Focus Indicators]
 
 == Einordnung des Prüfschritts
 

Prüfschritte/de/11.2.5.3 Beschriftung (Label) im Namen.adoc

@@ -47,6 +47,7 @@ aber die Zeichenkette der Beschriftung sollte in der gleichen Form in der Zeiche
 * Grenzfälle sind Hinzufügungen bei visuellen Beschriftungen, 
 die nicht eigentlich als Teil des zugänglichen Namens zu werten sind, 
 etwa wenn in einer Logo-Grafik ein zusätzlicher werbender Text enthalten ist. 
+Ein weiteres Beispiel wären Hinzufügungen zu Beschriftungen wie (erforderlich) oder (falls abweichend).
 Für Sprachsteuerungs-Nutzende ist die Einbeziehung solcher Texte nicht hilfreich. 
 * In anderen Fällen sind Teile der Beschriftung, 
 wie etwa der Text "(erforderlich)" nach Eingabefeld-Beschriftungen, 
@@ -60,6 +61,7 @@ Bei Schriftgrafiken, deren Text nicht direkt vom Screenreader erfasst werden kan
 
 ==== Erfüllt:
 * Der Text der Beschriftung ist im zugänglichen Namen enthalten.
+* Sind im Label klar abgesetzte zusätzliche Textbestandteile vorhanden, ist der erste Teil im zugänglichen Label enthalten.
 
 == Quellen
 
@@ -70,6 +72,9 @@ Bei Schriftgrafiken, deren Text nicht direkt vom Screenreader erfasst werden kan
   Accessible Name and Description Computation]
   (zur Zeit nur auf Englisch verfügbar)
 
+=== iOS
+* Der `accessibilityInputLabels()` Modifier  kann dazu verwendet werden, bei Bedienelementen weitere Labels zu hinterlegen, die Nutzenden der Funktion Sprachsteuerung as Aktivieren von Elementen erleichtern - z.B. Synonyme oder kürzere Ausdrücke bei längeren sichtbaren Labeln. Siehe _Hacking with Swift_: https://www.hackingwithswift.com/quick-start/swiftui/how-to-add-custom-activation-commands-for-voice-control[How to add custom activation commands for Voice Control]
+
 == Einordnung des Prüfschritts
 
 === Einordnung des Prüfschritts nach WCAG 2.1

Prüfschritte/de/5.5.1 Möglichkeiten der Bedienung.adoc

@@ -14,10 +14,20 @@ Menschen mit motorischen Einschränkungen sollen physische Informations- und Kom
 
 === 1. Anwendbarkeit des Prüfschritts
 
-Der Prüfschritt ist anwendbar, wenn die zu prüfende App zusammen mit physischem Zubehör genutzt wird und dieses Szenario geprüft wird. Beispiele für physisches Zubehör wären etwa ein Handscanner oder ein Kartenlesegerät zur Authentifizierung.
+Der Prüfschritt ist vor allem anwendbar, 
+wenn die zu prüfende App zusammen mit physischem Zubehör genutzt wird
+und dieses Szenario geprüft wird. 
+Beispiele für physisches Zubehör wären etwa ein Handscanner 
+oder ein Kartenlesegerät zur Authentifizierung.
+
+Der Prüfschritt ist auch anwendbar, wenn die Nutzung der App 
+die Bedienung physischer Tasten oder Regler am Gerät (etwa Smartphone oder Tablet) einschließt 
+oder das Gerät selbst für bestimmte Formen der Eingabe gegriffen, gedreht, geschüttelt oder anders ausgerichtet werden kann.
 
 === 2. Prüfung
-. Prüfen, ob während der Nutzung des Zubehörs  bei der Bedienung phyischer Teile (etwa Schalter, Regler oder Drehknöpfe) ein physisches Greifen, ein Zusammendrücken, oder eine Drehung des Handgelenks erforderlich sind.
+. Prüfen, ob bei die Nutzung der App, z.B. für bestimmte Eingaben, die Bedienung physischer Tasten oder Regler am Gerät oder die Manipulation des Geräts selbst vorgesehen ist, und dabei ein physisches Greifen, ein Zusammendrücken, oder eine Drehung des Handgelenks erforderlich ist.
+. Prüfen, ob bei der Nutzung von Zubehör, z.B. bei der Bedienung physischer Bestandteile wie Schalter, Regler oder Drehknöpfe, ein physisches Greifen, ein Zusammendrücken, 
+oder eine Drehung des Handgelenks erforderlich sind.
 . Falls ja: Gibt es für den Prozess eine alternative Bedienmethode ohne diese Aktionen?
 
 === 3. Hinweise
@@ -28,18 +38,19 @@ Der Prüfschritt ist anwendbar, wenn die zu prüfende App zusammen mit physische
 === 4. Bewertung
 
 ==== Erfüllt:
-* Zur Nutzung des Zubehörs sind physisches Greifen, Zusammendrücken, und eine Drehung des Handgelenks nicht erforderlich.
-*  Es gibt eine barrierefreie Alternative, alle erforderliche Aktionen zur Nutzung der App mit Zubehör ohne die physischen Aktionen (Greifen, Zusammendrückenm Drehung des Handgelenks) auszuführen.
+* Zur Nutzung der App bzw. des Zubehörs sind physisches Greifen, Zusammendrücken, oder eine Drehung des Handgelenks nicht erforderlich.
+*  Es gibt eine barrierefreie Alternative, alle für die Nutzung der App oder des Zubehörs erforderlichen Funktionen lassen sich ohne die genannten physischen Aktionen (Greifen, Zusammendrücken, Drehung des Handgelenks) ausführen.
 
 == Einordnung des Prüfschritts
 
 === Abgrenzung von anderen Prüfschritten
-In diesem Prüfschritt geht es um die Bedienbarkeit von zusätzlichem Zubehör durch Menschen mit motorischen Einschränkungen, wenn dieses zusammen mit der App genutzt wird. Wenn die Anforderung so interpretiert wird, dass auch virtuelle Bedienelemente gemeint sind, so ist die Prüfung der Bedienbarkeit von diesen schon über verschiedene andere Prüfschritte der En abgedeckt, besonders durch:
+In diesem Prüfschritt geht es um die Bedienbarkeit von physischen Geräten und zusätzlichem Zubehör mit physischen Bedienelementen durch Menschen mit motorischen Einschränkungen. Wenn die Anforderung so interpretiert wird, dass auch virtuelle Bedienelemente gemeint sind, so ist die Prüfung der Bedienbarkeit von diesen schon über verschiedene andere Prüfschritte abgedeckt, besonders durch:
 
 * 11.2.1.1 Tastatur
 * 11.2.1.4 Tastatur-Kurzbefehle abschaltbar oder anpassbar
 * 11.2.5.1 Alternativen für komplexe Zeigergesten
 * 11.2.5.2 Zeigergesten-Eingaben können abgebrochen oder widerrufen werden
+* 11.2.5.4 Betätigung durch Bewegung
 
 === Einordnung des Prüfschritts nach EN 301 549 V3.2.1
 

Prüfschritte/de/5.5.2 Unterscheidbarkeit der bedienbaren Elemente.adoc

@@ -4,40 +4,49 @@ include::include/attributes.adoc[]
 
 == Was wird geprüft?
 
-Wenn die IKT physisch bedienbare Teile hat, müssen die physisch bedienbaren Elemente als solche erkennbar sein, ohne dass Sehvermögen zwingend erforderlich ist.
-Um das physische Bedienelement als solches zu erkennen, darf es außerdem nicht erforderlich sein, dass Element auszulösen bzw. zu bedienen.
+Wenn die Nutzung der App die Bedienung physischer Bedienelemente wie Tasten, Regler o.ä. einschließt, müssen diese als solche identifizierbar und unterscheidbar sein, ohne dass Sehvermögen zwingend erforderlich ist.
+Um das physische Bedienelement zu identifizieren, darf es außerdem nicht erforderlich sein, dass Element auszulösen bzw. zu bedienen.
 
 == Warum wird das geprüft?
 
-Physische Bedienelemente eines Informations- und Kommunikationssystems sollen auch durch Menschen mit Sehbehinderung als solche erkennbar sein.
+Wenn physische Bedienelemente am Gerät oder an gekoppeltem Zubehör taktil identifiziert und unterschieden werden können, sind sie auch für Menschen mit Sehbehinderung nutzbar.
 
 == Wie wird das geprüft?
 
 === 1. Anwendbarkeit des Prüfschritts
 
-Der Prüfschritt ist für die Prüfung von mobilen Apps für iOS und Android im Regelfall nicht anwendbar.
-Ist die zu prüfende App für die Nutzung zusammen mit physischem Spezialzubehör gedacht, findet der Prüfschritt jedoch ggf. Anwendung.
+Der Prüfschritt ist bei der Prüfung von mobilen Apps für iOS und Android im Regelfall nicht anwendbar, es sei denn, die Nutzung der App setzt die Bedienung physischer Tasten oder Regler am Gerät oder die Nutzung von Bedienelementen an gekoppeltem Zubehör voraus.
 
 === 2. Prüfung
-(folgt)
+Prüfen, ob physische Bedienelemente, etwa Tasten oder Regler, über taktile Unterscheidung oder Positionierung am Gerät identifizierbar und unterscheidbar sind. 
 
 === 3. Hinweise
 
-Eine Möglichkeit, diese Anforderung zu erfüllen, besteht darin, die physisch bedienbaren Teile taktil wahrnehmbar zu machen.
+. Wenn Apps die Bedienung von Tasten am Gerät vorsehen, ist bei Smartphones der Prüfschritt in der Regel über die haptische Unterscheidbarkeit und/oder Positionierung dieser Tasten gegeben. So ist der Unterschied von Laut- und Leisetaste schon über die Position am Gerät (lauter = oben, leiser = unten) gegeben. Bei Zubehör mit mehreren Tasten kann die Anforderung erfüllt werden, wenn Tasten taktil wahrnehmbar und ggf. durch erhabene Beschriftung auch taktil unterscheidbar sind. 
+. Bei Nummernblocks ermöglicht die taktile Hervorhebung der zentralen Taste Nummer 5 gleichzeitig die taktile Erkennung der umgebenden Tasten.
 
 === 4. Bewertung
 
 ==== Erfüllt:
+Für die Nutzung der App (ggf. mit Zubehör) erforderliche Bedienelemente sind taktil identifizierbar und ggf. unterscheidbar, etwa durch abweichende Form, erhabene Beschriftung, oder auf anderem Wege (etwa durch Positionierung).
+
+==== Nicht erfüllt:
+Bedienelemente beim Zubehör sind nicht-visuell nicht wahrnehmbar oder unterscheidbar. Das ist z.B. bei virtuellen Tasten auf Touch-Displays der Fall.
 
 == Einordnung des Prüfschritts
 
 === Abgrenzung von anderen Prüfschritten
 
-In diesem Prüfschritt geht es um die Bedienbarkeit von zusätzlichem Zubehör durch Menschen mit motorischen Einschränkungen, wenn dieses zusammen mit der App genutzt wird. Wenn die Anforderung so interpretiert wird, dass auch virtuelle Bedienelemente gemeint sind, so ist die Prüfung der Bedienbarkeit von diesen schon über verschiedene andere Prüfschritte der En abgedeckt, besonders durch:
+In diesem Prüfschritt geht es um die Bedienbarkeit von zusätzlichem Zubehör 
+durch Menschen mit motorischen Einschränkungen, wenn dieses zusammen mit der App genutzt wird. 
+Wenn die Anforderung so interpretiert wird, dass auch virtuelle Bedienelemente gemeint sind, 
+so ist die Prüfung der Bedienbarkeit von diesen schon über verschiedene andere Prüfschritte abgedeckt, besonders durch:
 
-* 11.4.1.2 Name, Rolle, Wert verfügbar
-* 11.5.2.15 Änderungsbenachrichtigung
-* 11.5.2.16 Änderungen von Zuständen und Eigenschaften
+. 11.2.1.1 Tastatur
+. 11.2.1.4 Tastatur-Kurzbefehle abschaltbar oder anpassbar
+. 11.2.5.1 Alternativen für komplexe Zeigergesten
+. 11.2.5.2 Zeigergesten-Eingaben können abgebrochen oder widerrufen werden
+. 11.2.5.4 Betätigung durch Bewegung
 
 === Einordnung des Prüfschritts nach EN 301 549 V3.2.1
 

Prüfschritte/de/5.7 Tastenwiederholung.adoc

@@ -13,7 +13,7 @@ bevor die Tastenwiederholung einsetzt
 (der Standard ist etwa eine halbe Sekunde). 
 Dies sind üblicherweise Einstellungen des Betriebssystems, 
 auf die Entwickler in der Regel keinen Einfluss haben. 
-Apps sollten diese betriebssystemseitigen Einstellungen für Texteingaben übernehmen.
+Apps sollten diese betriebssystemseitigen Einstellungen, wo vorhanden, für Texteingaben übernehmen.
 
 == Warum wird das geprüft?
 Menschen mit motorischen Einschränkungen haben manchmal das Problem, 
@@ -31,7 +31,7 @@ Der Prüfschritt wird nur geprüft,
 wenn die Tastenwiederholung nicht abstellbar ist 
 und die Funktion in der App unterstützt wird. 
 Bei iOS-Apps ist der Prüfschritt generell nicht anwendbar, 
-da die Tastenwiederholfunktion absgeschaltet werden kann.
+da die Tastenwiederholfunktion abgeschaltet werden kann.
 Bei Android-Apps ist der Prüfschritt nur anwendbar, 
 wenn die Ansicht Texteingabefelder für Tastatureingaben enthält.
 Geprüft wird nicht die systemseitige Einstellung selbst, 
@@ -42,7 +42,7 @@ Die Funktion Tastenwiederholung ist, soweit vorhanden,
 eine generelle Einstellung auf Betriebssystem-Ebene. 
 Für die App selbst kann also nur geprüft werden, 
 ob Einstellungen wie von Nutzenden intendiert 
-bei Texteingaben auf der Anicht greifen. 
+bei Texteingaben auf der Ansicht greifen. 
 
 ==== iOS
 * Unter iOS und iPadOS (iPad mit Magic Keyboard) 
@@ -109,7 +109,7 @@ und diese Einstellungen bei Texteingabefeldern der App greifen.
 
 ==== Nicht erfüllt (Android)
 * Für Android-Apps ist der Prüfschritt nicht erfüllt, 
-wenn eingestellte höhere Werte bei Anschlageschwindigkeit und Tastenanschlagfunktion
+wenn eingestellte höhere Werte bei Anschlaggeschwindigkeit und Tastenanschlagfunktion
 bei Texteingabefeldern der App nicht greifen.
 
 == Quellen

Prüfschritte/de/5.9 Gleichzeitige Benutzerhandlungen.adoc

@@ -3,17 +3,17 @@ include::include/author.adoc[]
 include::include/attributes.adoc[]
 
 == Was wird geprüft?
-Für die Nutzung der App soll es einen Modus der Bedienung geben, der für die Bedienung keine simultanen Aktivitäten bzw. Eingaben von Nutzenden verlangt. Die Einfingerbedienung wird üblicherweise über Einstellungen des Betriebssystems festgelegt, auf die Entwickler keinen Einfluss haben, bzw. keinen Einfluss nehmen sollten. Für Toucheingaben wird ein Teil der Anforderung in Prüfschritt 11.2.5.1 geprüft.
+Für die Nutzung der App soll es einen Modus der Bedienung geben, der keine simultanen Aktivitäten bzw. gleichzeitige Eingaben von Nutzenden erfordert. Die Einfingerbedienung wird üblicherweise über Einstellungen des Betriebssystems festgelegt, auf die Entwickler keinen Einfluss haben, bzw. keinen Einfluss nehmen sollten. Für Toucheingaben wird ein Teil der Anforderung in Prüfschritt 11.2.5.1 geprüft.
 
 Beispiele für simultane Aktionen:
 
 * das gleichzeitige Drücken zweier Tasten auf der Tastatur 
 * das Halten eines Bedienelements auf einem Touchscreen, während ein weiteres Bedienelement über Touch bedient wird.
 * Das Halten einer Gerätetaste, während eine Spracheingabe erfolgt.
 
-Notwendige simultane Aktionen bei der Bedienung der App in einem bestimmten Modus sind kein Fehler im Sinne dieses Prüfschritts, solange es einen anderen Bedienungsmodus gibt, der die Bedienung ohne simulatane Aktionen erlaubt. Dies ist bei der Vielzahl der Eingabemöglichkeiten und Kombinationen unter diesen nur schwer vollständig zu prüfen.
+Notwendige simultane Aktionen bei der Bedienung der App in einem bestimmten Modus sind kein Fehler im Sinne dieses Prüfschritts, solange es einen anderen Bedienungsmodus gibt, der die Bedienung ohne simultane Aktionen erlaubt. Dies ist bei der Vielzahl der Eingabemöglichkeiten und Kombinationen unter diesen nur schwer vollständig zu prüfen.
 
-Die Situation ist unterscheidlich für verschiedene Bedienungsmodi:
+Die Situation ist unterschiedlich für verschiedene Bedienungsmodi:
 
 * *Tastaturbedienung:* iOS hat unter Einstellungen > Bedienungshilfen > Tastaturen > Einfingerbedienung die Möglichkeit, simultane Tasteneingaben so aufzulösen, dass Sondertasten gesetzt werden können, ohne gleichzeitig andere Tasten gedrückt halten zu müssen ("sticky keys"). In manchen Umgebungen (Android mit Tastatur) ist zur Zeit keine Einfingerbedienung einstellbar. Auf die Einstellungsmöglichkeiten für Einfingerbedienung haben Entwickler keinen Einfluss.
 
@@ -24,21 +24,26 @@ Die Situation ist unterscheidlich für verschiedene Bedienungsmodi:
 * *Sprachsteuerung:* Diese funktioniert in der Regel ohne simultane physische Eingaben.
 
 == Warum wird das geprüft?
-Menschen mit motorischen Einschränkungen haben oft Probleme, mehrere Aktionen zur gleichen Zeit auszuführen. Deshalb sollten alle Funktionen über einfache Eingaben (ohne simultane Aktionen) möglich sein.
+Menschen mit motorischen Einschränkungen haben oft Probleme, mehrere Aktionen zur gleichen Zeit auszuführen. Deshalb sollten alle Funktionen auch über einfache Eingaben (ohne simultane Aktionen) ausführbar sein.
 
 == Wie wird das geprüft?
 
 === 1. Anwendbarkeit des Prüfschritts
 Der Prüfschritt ist immer anwendbar. Bezüglich Tastasturbedienung wir dieser Prüfschritt nicht geprüft, da Einstellungsmöglichkeiten für Einfingerbedienung (etwa Microsofts Einrastfunktion) Aufgabe des Betriebssystems sind und nicht auf der Ebene der App implementiert werden sollten. Lücken in der Unterstützung sind als Mangel der Betriebssytemumgebung zu bewerten, die App-Entwickler nicht kompensieren können.
 
+Komplexe Aktionen, die vom Betriebssystem oder einer Hilfsmittelfunktionen definiert sind (etwa der VoiceOver-Rotor, der über eine gegenläufige Drehbewegung mit zwei Fingern aufgerufen wird) fallen nicht unter diesen Prüfschritt.
+
 === 2. Prüfung
 Wenn die Accessibility Baseline Umgebungen einschließt, die bei Tastaturnutzung keine Einfingerbedienung anbietet (Android):
 
 . Bezüglich der Prüfung von Aktionen bei der Toucheingabe wird das Ergebnis von 11.2.5.1 "Alternativen für komplexe Zeiger-Gesten" hierhin übertragen, wenn es Fehler durch den Einsatz von Mehrfingergesten ohne Einfinger-bedienbare Alternativen gibt.
 . Bedienung mit Toucheingabe überprüfen. Sind alle Funktionen mit Einfinger-Gesten aktivierbar, ohne das gleichzeitig Gerätetasten gedrückt oder das Gerät bewegt bzw. ausgerichtet werden muss?
 
 === 3. Hinweise
-Ggf. sind bei Touchbedienung außer dem gleichzeitigen Drücken von Gerätetasten oder der Ausrichtung des Geräts andere, hier nicht näher spezifizierte simultane Aktionen denkbar, die für die erfolgreiche Bedienuung ausgeführt werden müssten, etwa die Auswertung von Handbewegungen über dem Gerät, der Auswertung des Kamera-Bildes, wofür das Gerät gehalten bzw. bewegt werden müsste, usw.
+
+Ggf. sind bei Touchbedienung außer dem gleichzeitigen Drücken von Gerätetasten oder der Ausrichtung des Geräts andere, 
+hier nicht näher spezifizierte simultane Aktionen denkbar, die für die erfolgreiche Bedienuung ausgeführt werden müssten, 
+etwa die Auswertung von Handbewegungen über dem Gerät, die Auswertung des Kamera-Bildes, wofür das Gerät gehalten bzw. bewegt werden müsste, usw.
 
 === 4. Bewertung
 

Prüfschritte/de/6.5.2 Auflösung.adoc

@@ -38,6 +38,8 @@ ____
 Where ICT that provides two-way voice communication includes real-time video
 functionality, the ICT:
 
-* shall support at least QVGA resolution
+* a) shall support at least QVGA resolution
+* b) should preferably support at least VGA resolution.
+
 --
 ____