Enhanced Accessibility Gestures for Custom Components on Android
Article Summary
Nicolas Mayer Weiler from leboncoin shows why your 'accessible' Android component might still be failing users. Three stepper implementations, wildly different user experiences.
When building custom Android components, basic accessibility compliance isn't enough. This deep dive compares three approaches to making a stepper component work with TalkBack, each with different tradeoffs for navigation complexity and gesture requirements. The article evaluates solutions against Europe's RAAM accessibility standard with 107 criteria.
Key Takeaways
- Basic approach requires 3+ swipes per stepper interaction, problematic for multi-component screens
- Custom actions reduce navigation but require complex three-finger gestures (fails RAAM 11.10)
- Progress semantics enables simple up/down swipes, best UX but conflicts with heading navigation
- LiveRegionMode.Polite announces value changes without requiring user navigation back
The Progress Stepper approach delivers the smoothest accessible experience by treating the component as a slider, enabling single-swipe value changes while maintaining easy navigation between components.
About This Article
Nicolas Mayer Weiler found that basic Stepper implementations require users to swipe multiple times across screens with multiple steppers. This creates navigation friction for accessibility tool users like TalkBack.
leboncoin built three progressive solutions using Compose semantics. They added contentDescription with LiveRegionMode.Polite for state updates, customActions for merged semantics, and progressSemantics that treats the component as a slider for simple gestures.
The Progress Stepper approach resolved RAAM criterion 11.10. Users can now change values through simple up/down swipes instead of complex three-finger gestures, while navigation between components on the same screen stays smooth.