A11y Element Focus Box

Waar We Op Controleren

Het toegankelijkheidspad van een element, of VoiceOver-focusbox, moet zijn eigen visuele schermkader volledig omsluiten.

Deze regel handhaaft een Deque Best Practice. U kunt deze regel uitschakelen vanaf het Mobiele Dashboard of door de regel te negeren in tests geschreven voor iOS.

Leer hoe u regels kunt uitschakelen vanuit het Mobiele Dashboard.

Foutief Voorbeeld ❌

VoiceOver is gericht op een knop, maar de focus box appears offset - gedeeltelijk buiten de zichtbare grenzen van de knop

Het gemarkeerde gebied komt niet overeen met het element dat wordt aangekondigd, wat het voor ziende VoiceOver-gebruikers moeilijk maakt om te volgen

Correct Voorbeeld ✅

VoiceOver is gericht op dezelfde knop en de focus box fully contains the element's visual frame

Het gemarkeerde gebied komt nauwkeurig overeen met wat de gebruiker op het scherm ziet, waardoor ziende VoiceOver-gebruikers een duidelijke visuele indicator krijgen van wat gefocust is

In één Oogopslag

• Deze regel heeft een gematigde impact op ziende gebruikers die ook VoiceOver gebruiken
• De VoiceOver-focusbox moet overeenkomen met de visuele schermgrenzen van het element dat hij aankondigt
• Vermijd het gebruik van accessibilityPath of accessibilityFrame indien mogelijk - VoiceOver berekent automatisch het juiste kader
• Als u het kader moet overschrijven, herbereken dan de coördinaten elke keer dat het element beweegt (zoals bij scrollen)

Impact op Gebruikers

Ziende gebruikers die ook VoiceOver gebruiken zijn het meest getroffen. VoiceOver zal de details van een scherm-element aankondigen, maar de focusbox zal gedeeltelijk of volledig buiten het aangekondigde element verschijnen. Deze discrepantie tussen de gesproken inhoud en de zichtbare markering maakt het moeilijk om te volgen wat er wordt gefocust en te begrijpen.

Bevestig A11y Element Focus Box Probleem

1. Schakel VoiceOver in
2. Focus op het element
3. Een van de volgende dingen gebeurt:
   • Ontoegankelijk: de VoiceOver-focusbox zal het element gedeeltelijk bevatten
   • Ontoegankelijk: de VoiceOver-focusbox zal het element helemaal niet bevatten
   • Toegankelijk: de VoiceOver-focusbox zal het element volledig bevatten

Los Problemen op

Problemen gevonden door deze regel worden bijna altijd veroorzaakt door onjuist gebruik van accessibilityPath of accessibilityFrame. De veiligste benadering is om ze te verwijderen en VoiceOver automatisch de focusbox te laten berekenen. Als er een aangepast kader nodig is, moeten de coördinaten telkens opnieuw worden berekend ten opzichte van het hoofdelement wanneer de positie ervan verandert.

UIKit

Onjuist gebruik van de accessibilityPath of accessibilityFrame op een element zal resulteren in een probleem dat door deze regel wordt gevonden. Corrigeer dit op een van de volgende manieren:

• Verwijder accessibilityPath of accessibilityFrame als ze niet nodig zijn. VoiceOver berekent automatisch de coördinaten op het scherm en tekent de juiste focusbox.
• Als u het kader moet overschrijven, converteer het kader van het element naar hoofdweergavecoördinaten en wijs het pad opnieuw toe telkens wanneer het element beweegt (zoals in een 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

Dit type toegankelijkheidsprobleem wordt niet verwacht voor te komen binnen SwiftUI-weergaven.

React Native

Dit type toegankelijkheidsprobleem wordt niet verwacht voor te komen bij standaard Touchable- of Pressable-elementen.

Wanneer u focus toevoegt aan een ander type element, stel de accessible- en accessibilityElementsHidden-eigenschappen direct in op dat element:

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

Wanneer elementen zijn gegroepeerd binnen een bevattende View, stelt u de accessible- en accessibilityElementsHidden-eigenschappen in op de omgevende weergave:

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

Kan ik deze Regel Negeren?

A11y Element Focus Box heeft een gematigde impact voor gebruikers. Omdat dit een Best Practice-regel is, kan deze worden uitgeschakeld vanaf het Mobiele Dashboard of onderdrukt in individuele tests. Echter, een niet-uitgelijnde focusbox creëert een verwarrende ervaring voor ziende VoiceOver-gebruikers en het is de moeite waard om dit te corrigeren als de oorzaak een verkeerd geconfigureerde accessibilityPath of accessibilityFrame is. Lees meer over regels negeren.

Middelen

Deque University Cursuspagina's

• Succescriterium 2.4.7 - Focus Zichtbaar (AA)
• 2.4.7a - Focus Zichtbaar

Opmerking: Volledige toegang tot Deque University bronnen vereist een abonnement.

Andere Bronnen

• Richtlijnen voor Toegankelijkheid van Webinhoud (WCAG) 2.1, W3C-aanbeveling
  • Succescriterium 2.4.7 - Focus Zichtbaar
• Apple Developer Documentatie
  • accessibilityFrame
  • accessibilityPath