Implementing Switch Control Support in a Mobile Application

Implementing Switch Control Support in a Mobile Application

A user with limited motor skills cannot swipe through the product carousel in your app. Switch Control on iOS or Switch Access on Android scans each element sequentially, but if a card is not grouped, the user must tap the switch dozens of times just to see the description. Over 1 billion people worldwide have a disability World Health Organization. Ignoring this scanning technology can cut off up to 15% of potential audiences. According to a WebAIM survey, 74% of screen reader users also rely on switch-like inputs. Proper grouping reduces scanning steps by 3–4 times compared to an unoptimized interface. Our team has 5+ years of experience developing accessible mobile apps for iOS and Android, and has implemented Switch Access support for over 35 projects in e-commerce, fintech, and healthcare. We are certified WCAG 2.1 specialists. We offer turnkey implementation in 2–3 days after a preliminary audit. Contact us for a free project assessment.

How to Properly Prepare the Interface for Scanning?

iOS — Switch Control

Scanning uses the same accessibility tree as VoiceOver. If VoiceOver works correctly, Switch Control usually does too. But there are nuances.

Grouping elements. During scanning, the system first highlights groups (containers), then enters them. If a product card is not grouped as a single element, Switch Control sequentially goes through each subview: image, title, price, rating, add to cart, wishlist. This increases the number of steps by 50–70%, significantly slowing down the user.

Solution: accessibilityElements on the container + accessibilityActivate() override for custom activation. Such clustering reduces scanning time by 2–3 times.

Custom gestures. A swipe to delete on a card—standard UIKit UISwipeGestureRecognizer will not be triggered. You need to add a UIAccessibilityCustomAction:

let deleteAction = UIAccessibilityCustomAction( name: "Delete", target: self, selector: #selector(deleteItem) ) accessibilityCustomActions = [deleteAction] 

Custom actions appear in the Switch Control menu when the element is activated.

Scanning style. By default, auto-scanning (elements are highlighted automatically). The user can switch to manual scanning. Ensure that the focus does not get stuck in an infinite loop inside a single container.

Android — Switch Access

Switch Access is configured via Settings → Accessibility → Switch Access. Two main modes: Linear Scanning (sequential traversal) and Row-Column Scanning (first rows, then columns).

android:focusable="true" and correct android:nextFocusDown/Up/Left/Right define navigation order. Without explicit nextFocus attributes, the system builds the order based on screen position—which can be illogical for complex layouts.

In Compose: Modifier.focusRequester() and Modifier.focusOrder { down = nextFocusRequester }—programmatic control of focus order for Switch Access.

Custom actions similar to iOS: ViewCompat.setAccessibilityDelegate with overriding onInitializeAccessibilityNodeInfo—add AccessibilityActionCompat for non-standard operations.

Why Testing on a Real Device is Critical

Emulators do not fully support Switch Access. On iOS: Settings → Accessibility → Switch Control → Add New Switch → Screen → Full Screen. Now tap on the screen equals switch activation. You can check the scanning flow yourself.

On Android: Settings → Accessibility → Switch Access → Use Volume Keys as Switches. Volume Up = next item, Volume Down = select.

However, emulation does not replace real scenarios: different scanning speeds, behavior with group actions, dynamic content. Therefore, we always test on physical devices (iPhone, iPad, Galaxy, Pixel) with various OS versions.

What Grouping Gives to the User

Grouping via accessibilityElements (iOS) or nextFocus* (Android) reduces scanning steps by 2–3 times. For example, a product card with six subviews without grouping requires 12 activations, but with grouping only 4. The user spends three times less time on navigation—critical for prolonged use.

Comparison of iOS and Android for Scanning Technologies

iOS setup is 50% faster than Android due to simpler group configuration.

Typical Mistakes and Their Consequences

Implementation Steps

1. Ensure VoiceOver/TalkBack works correctly.
2. Group elements using accessibilityElements (iOS) or focusable + nextFocus (Android).
3. Add custom actions with UIAccessibilityCustomAction or AccessibilityActionCompat.
4. Test on real devices with Switch Control enabled.
5. Validate scanning order and fix any infinite loops.

What's Included in the Work

• Detailed accessibility audit report.
• Code adjustments for efficient grouping and custom actions.
• Real device testing on 5+ models (iPhone, iPad, Galaxy, Pixel, etc.).
• Documentation of all accessibility changes.
• Post-implementation support for 30 days.

How Long Does Implementation Take?

If VoiceOver/TalkBack are already implemented, scanning usually works automatically. The main work is adding UIAccessibilityCustomAction/AccessibilityActionCompat for gesture actions and verifying scanning order. Estimate: 2-3 days. If the accessibility tree is not built, you need to start with a VoiceOver/TalkBack audit (1-2 weeks depending on app complexity). Cost is calculated individually after a preliminary assessment. We'll assess your project for free and provide a fixed-price quote.

Learn more about Apple's official documentation on scanning and Google's help page for accessibility.