Caixa de Foco do Elemento A11y

O Que Verificamos

O caminho de acessibilidade de um elemento, ou a caixa de foco do VoiceOver, deve encapsular totalmente sua própria estrutura visual na tela.

Esta regra impõe uma Boa Prática do Deque. Você pode desativar esta regra no Mobile Dashboard ou por ignorar a regra em testes escritos para iOS.

Aprenda como desativar regras no Mobile Dashboard.

Exemplo de Falha ❌

O VoiceOver está focado em um botão, mas o focus box appears offset - parcialmente fora dos limites visíveis do botão

A área destacada não corresponde ao elemento que está sendo anunciado, dificultando para os usuários com visão que utilizam o VoiceOver acompanharem

Exemplo de Sucesso ✅

O VoiceOver está focado no mesmo botão e o focus box fully contains the element's visual frame

A área destacada corresponde com precisão ao que o usuário vê na tela, fornecendo aos usuários com visão que utilizam o VoiceOver um indicador visual claro do que está sendo focado

Visão Geral

• Esta regra tem um impacto moderado para usuários videntes que também usam o VoiceOver
• A caixa de foco do VoiceOver deve corresponder aos limites visuais na tela do elemento que está anunciando
• Evite usar accessibilityPath ou accessibilityFrame se possível - o VoiceOver calcula automaticamente o quadro correto
• Se precisar substituir o quadro, recalcule as coordenadas toda vez que o elemento se mover (como ao rolar a tela)

Impacto para os Usuários

Os usuários videntes que também utilizam o VoiceOver são os mais impactados. O VoiceOver anunciará os detalhes de um elemento na tela, mas a caixa de foco aparecerá parcial ou totalmente fora do elemento sendo anunciado. Esse descompasso entre o conteúdo falado e o destaque visível dificulta o acompanhamento e a compreensão do que está sendo focalizado.

Confirmar Problema de Caixa de Foco do Elemento A11y

1. Ative o VoiceOver
2. Focalize o elemento
3. Um dos seguintes ocorrerá:
   • Inacessível: a caixa de foco do VoiceOver conterá parcialmente o elemento
   • Inacessível: a caixa de foco do VoiceOver não conterá o elemento de forma alguma
   • Acessível: a caixa de foco do VoiceOver conterá totalmente o elemento

Corrigir Problemas

Os problemas encontrados por esta regra são quase sempre causados por uso incorreto de accessibilityPath ou accessibilityFrame. A abordagem mais segura é removê-los e deixar o VoiceOver calcular a caixa de foco automaticamente. Se for necessário um quadro personalizado, as coordenadas devem ser recalculadas em relação ao elemento raiz sempre que a posição mudar.

UIKit

O uso incorreto de accessibilityPath ou accessibilityFrame em um elemento resultará em um problema encontrado por esta regra. Corrija de uma das duas maneiras:

• Remova accessibilityPath ou accessibilityFrame se não forem necessários. O VoiceOver calcula automaticamente as coordenadas na tela e desenha a caixa de foco correta.
• Se você precisar substituir o quadro, converta o quadro do elemento para coordenadas de visualização raiz e reatribua o caminho sempre que o elemento se mover (como em um 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

Este tipo de problema de acessibilidade não é esperado em visualizações SwiftUI.

React Native

Este tipo de problema de acessibilidade não é esperado com elementos Touchable ou Pressable padrões.

Ao adicionar foco a outro tipo de elemento, configure as propriedades accessible e accessibilityElementsHidden diretamente nesse elemento:

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

Quando os elementos são agrupados dentro de um View contido, configure as propriedades accessible e accessibilityElementsHidden na visualização contida:

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

Posso Ignorar Esta Regra?

A Caixa de Foco do Elemento A11y tem um impacto moderado para os usuários. Como esta é uma regra de Boa Prática, pode ser desativada no Mobile Dashboard ou suprimida em testes individuais. No entanto, uma caixa de foco desalinhada cria uma experiência confusa para os usuários com visão que utilizam o VoiceOver e vale a pena ser corrigida quando a causa for um accessibilityPath ou accessibilityFrame mal configurado. Saiba mais sobre ignorar regras.

Recursos

Páginas do Curso da Deque University

• Critério de Sucesso 2.4.7 - Foco Visível (AA)
• 2.4.7a - Foco Visível

Nota: O acesso completo aos recursos da Deque University requer uma assinatura.

Outros Recursos

• Diretrizes de Acessibilidade para Conteúdo da Web (WCAG) 2.1, Recomendação W3C
  • Critério de Sucesso 2.4.7 - Foco Visível
• Documentação do Desenvolvedor Apple
  • accessibilityFrame
  • accessibilityPath