Cuadro de Enfoque de Elemento A11y
El cuadro de enfoque de VoiceOver debe encapsular completamente el elemento que está anunciando
Qué Verificamos
La ruta de accesibilidad de un elemento, o el cuadro de enfoque de VoiceOver, debe encapsular completamente su propio marco visual en pantalla.
Esta regla refuerza una Mejor Práctica de Deque. Puedes desactivar esta regla desde el Tablero Móvil o ignorando la regla en pruebas escritas para iOS.
Aprende a desactivar reglas desde el Tablero Móvil.
Ejemplo Fallido ❌
VoiceOver está enfocado en un botón, pero el focus box appears offset - parcialmente fuera de los límites visibles del botón
El área resaltada no coincide con el elemento que se está anunciando, lo que dificulta a los usuarios videntes de VoiceOver seguir el enfoque
Ejemplo Correcto ✅
VoiceOver está enfocado en el mismo botón y el focus box fully contains the element's visual frame
El área resaltada coincide con lo que el usuario ve en pantalla, brindando a los usuarios videntes de VoiceOver un indicador visual claro de lo que está enfocado
En Resumen
- Esta regla tiene un impacto moderado para los usuarios videntes que también utilizan VoiceOver
- El cuadro de enfoque de VoiceOver debe coincidir con los límites visuales en pantalla del elemento que está anunciando
- Evita usar
accessibilityPathoaccessibilityFramesi es posible - VoiceOver calcula automáticamente el marco correcto - Si debes anular el marco, recalcula las coordenadas cada vez que el elemento se mueva (como al desplazarse)
Impacto para los Usuarios
Los usuarios videntes que también utilizan VoiceOver son los más afectados. VoiceOver anunciará los detalles de un elemento en pantalla, pero el cuadro de enfoque aparecerá parcialmente o completamente fuera del elemento anunciado. Esta desconexión entre el contenido hablado y el destaque visible dificulta seguir el enfoque y entender qué está siendo enfocado.
Confirmar Problema de Cuadro de Enfoque de Elemento A11y
- Activa VoiceOver
- Enfoca el elemento
- Ocurrirá una de las siguientes situaciones:
- Inaccesible: El cuadro de enfoque de VoiceOver contendrá parcialmente el elemento
- Inaccesible: El cuadro de enfoque de VoiceOver no contendrá el elemento en absoluto
- Accesible: El cuadro de enfoque de VoiceOver contendrá completamente el elemento
Corregir Problemas
Los problemas encontrados por esta regla son casi siempre causados por un uso incorrecto de accessibilityPath o accessibilityFrame. El enfoque más seguro es eliminarlos y dejar que VoiceOver calcule el cuadro de enfoque automáticamente. Si se requiere un marco personalizado, las coordenadas deben recalcularse respecto al elemento raíz cada vez que su posición cambie.
UIKit
El uso incorrecto de accessibilityPath o accessibilityFrame en un elemento resultará en que esta regla encuentre un problema. Corrige de una de las dos formas:
- Elimina
accessibilityPathoaccessibilityFramesi no son necesarios. VoiceOver calcula automáticamente las coordenadas en pantalla y dibuja el cuadro de enfoque correcto. - Si debes anular el marco, convierte el marco del elemento a coordenadas de vista raíz y reasigna la ruta cada vez que el elemento se mueva (como en un
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
No se espera que este tipo de problema de accesibilidad ocurra dentro de vistas de SwiftUI.
React Native
No se espera que este tipo de problema de accesibilidad ocurra con elementos Touchable o Pressable por defecto.
Al agregar enfoque a otro tipo de elemento, establece las props accessible y accessibilityElementsHidden directamente en ese elemento:
<Image
source={DequeLogo}
accessible={true}
accessibilityElementsHidden={false}
accessibilityLabel="Deque Systems Logo"
accessibilityRole="image"
style={{ width: 100, height: 60 }}
resizeMode='center'
/>Cuando los elementos están agrupados dentro de un View contenedor, establece las props accessible y accessibilityElementsHidden en la vista contenedora:
<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>¿Puedo Ignorar Esta Regla?
El cuadro de enfoque de Elemento A11y tiene un impacto moderado para los usuarios. Debido a que esta es una regla de Mejor Práctica, puede desactivarse desde el Tablero Móvil o suprimirse en pruebas individuales. Sin embargo, un cuadro de enfoque desalineado crea una experiencia confusa para los usuarios videntes de VoiceOver y vale la pena corregirlo cuando la causa es un accessibilityPath o accessibilityFrame mal configurado. Aprende más sobre ignorando reglas.
Recursos
Páginas del Curso de Deque University
Nota: El acceso completo a los recursos de Deque University requiere una suscripción.
Otros recursos
- Pautas de Accesibilidad para el Contenido Web (WCAG) 2.1, Recomendación del W3C
- Documentación para Desarrolladores de Apple