A11y Element Fokusrahmen

Was wir überprüfen

Der Barrierefreiheitsweg eines Elements oder der VoiceOver-Fokusrahmen muss seinen eigenen visuellen Rahmen auf dem Bildschirm vollständig umschließen.

Diese Regel setzt eine beste Praxis von Deque um. Sie können diese Regel im Mobile Dashboard oder durch die Regel in Tests ignorieren, die für iOS geschrieben wurden deaktivieren.

Erfahren Sie, wie Sie Regeln im Mobile Dashboard deaktivieren.

Fehlerhaftes Beispiel ❌

VoiceOver fokussiert sich auf eine Schaltfläche, aber der focus box appears offset - teilweise außerhalb der sichtbaren Grenzen der Schaltfläche

Der hervorgehobene Bereich entspricht nicht dem angekündigten Element, was es für sehende VoiceOver-Nutzer schwierig macht, zu folgen

Erfolgreiches Beispiel ✅

VoiceOver fokussiert sich auf dieselbe Schaltfläche und der focus box fully contains the element's visual frame

Der hervorgehobene Bereich entspricht genau dem, was der Nutzer auf dem Bildschirm sieht, was sehenden VoiceOver-Nutzern einen klaren visuellen Indikator dafür gibt, was fokussiert wird

Auf einen Blick

• Diese Regel hat einen moderaten Einfluss auf sehende Nutzer, die ebenfalls VoiceOver verwenden
• Der Fokusrahmen von VoiceOver muss den visuellen Bildschirmrahmen des Elements, das es ankündigt, widerspiegeln
• Vermeiden Sie nach Möglichkeit die Verwendung von accessibilityPath oder accessibilityFrame - VoiceOver berechnet den korrekten Rahmen automatisch
• Wenn Sie den Rahmen überschreiben müssen, berechnen Sie die Koordinaten jedes Mal neu, wenn sich das Element bewegt (z. B. beim Scrollen)

Auswirkungen auf die Nutzer

Sehende Nutzer, die auch VoiceOver nutzen, sind am stärksten betroffen. VoiceOver wird die Details eines Bildschirmelements ankündigen, aber der Fokusrahmen wird sich teilweise oder vollständig außerhalb des angekündigten Elements befinden. Diese Diskrepanz zwischen dem gesprochenen Inhalt und der sichtbaren Hervorhebung macht es schwierig, zu folgen und zu verstehen, was fokussiert wird.

A11y Element Fokusrahmen Problem bestätigen

1. VoiceOver einschalten
2. Element fokussieren
3. Eines der folgenden Dinge wird passieren:
   • Unzugänglich: Der Fokusrahmen von VoiceOver enthält das Element teilweise
   • Unzugänglich: Der Fokusrahmen von VoiceOver enthält das Element überhaupt nicht
   • Zugänglich: Der Fokusrahmen von VoiceOver enthält das Element vollständig

Probleme beheben

Probleme, die durch diese Regel gefunden werden, werden fast immer durch die falsche Verwendung von accessibilityPath oder accessibilityFrame verursacht. Der sicherste Ansatz ist, diese zu entfernen und VoiceOver den Fokusrahmen automatisch berechnen zu lassen. Wenn ein benutzerdefinierter Rahmen erforderlich ist, müssen die Koordinaten jedes Mal relativ zum Hauptelement neu berechnet werden, wenn sich seine Position ändert.

UIKit

Falsche Anwendung von accessibilityPath oder accessibilityFrame auf einem Element führt dazu, dass diese Regel ein Problem findet. Beheben Sie dies auf eine von zwei Arten:

• Entfernen Sie accessibilityPath oder accessibilityFrame, wenn sie nicht benötigt werden. VoiceOver berechnet automatisch die Bildschirmkoordinaten und zeichnet den korrekten Fokusrahmen.
• Wenn Sie den Rahmen überschreiben müssen, konvertieren Sie den Rahmen des Elements in die Koordinaten der Wurzelansicht und weisen Sie den Pfad erneut zu, wann immer sich das Element bewegt (z. B. in einem UIScrollview):

// Assuming we are in a ViewController
let button = UIButton()

// If not within a ViewController, self.view should be replaced with the rootView of the screen
let rootview = self.view
let onScreenFrame = button.superview!.convert(button.frame, to: rootview)
button.accessibilityPath = UIBezierPath(rect: onScreenFrame)

SwiftUI

Dieser Typ von Barrierefreiheitsproblem wird in SwiftUI-Ansichten nicht erwartet.

React Native

Dieser Typ von Barrierefreiheitsproblem wird bei Standard-Touchable- oder Pressable-Elementen nicht erwartet.

Wenn Sie den Fokus auf einen anderen Elementtyp setzen, legen Sie die accessible und accessibilityElementsHidden-Eigenschaften direkt auf diesem Element fest:

<Image
   source={DequeLogo}
   accessible={true}
   accessibilityElementsHidden={false}
   accessibilityLabel="Deque Systems Logo"
   accessibilityRole="image"
   style={{ width: 100, height: 60 }}
   resizeMode='center'
/>

Wenn Elemente innerhalb eines enthaltenen View gruppiert sind, setzen Sie die accessible und accessibilityElementsHidden-Eigenschaften auf die enthaltene Ansicht:

<View
  style={styles.rowContainer}
  accessible={true}
  accessibilityElementsHidden={false}
  accessibilityLabel="Dark Mode"
  accessibilityValue={{ text: "" + secondSwitchIsEnabled }}
  accessibilityRole="switch"
  onTouchStart={() => {
    setSecondSwitchIsEnabled(!secondSwitchIsEnabled)
  }}>
    <Text style={{ fontSize: 18 }}>Dark Mode</Text>
    <Switch
        style={styles.standardSwitch}
        importantForAccessibility='no-hide-descendants'
        value={secondSwitchIsEnabled}
        onValueChange={() => {
          setSecondSwitchIsEnabled(!secondSwitchIsEnabled);
        }}
    />
</View>

Kann ich diese Regel ignorieren?

A11y Element Fokusrahmen hat eine Moderater Einfluss für Benutzer. Da dies eine Best-Practice-Regel ist, kann sie über das Mobile Dashboard deaktiviert oder in einzelnen Tests unterdrückt werden. Ein falsch ausgerichteter Fokusrahmen schafft jedoch eine verwirrende Erfahrung für sehende VoiceOver-Nutzer und sollte behoben werden, wenn die Ursache ein falsch konfigurierter accessibilityPath oder accessibilityFrame ist. Erfahren Sie mehr über Regeln ignorieren.

Ressourcen

Deque University Kurs-Seiten

• Erfolgskriterium 2.4.7 - Fokus Sichtbar (AA)
• 2.4.7a - Fokus Sichtbar

Hinweis: Der volle Zugang zu den Ressourcen der Deque University erfordert ein Abonnement.

Weitere Ressourcen

• Web Content Accessibility Guidelines (WCAG) 2.1, W3C-Empfehlung
  • Erfolgskriterium 2.4.7 - Fokus sichtbar
• Apple Developer Dokumentation
  • accessibilityFrame
  • accessibilityPath