Реализация поддержки Switch Control в мобильном приложении
Пользователь с ограниченной моторикой не может сделать свайп по карусели товаров в вашем приложении. Система сканирования Switch Control на iOS или Switch Access на Android проходит каждый элемент по очереди, но если карточка не сгруппирована, пользователь вынужден активировать переключатель десятки раз, чтобы просто посмотреть описание. По данным ВОЗ, более 1 миллиарда человек в мире имеют инвалидность. Игнорирование Switch Control может отсечь до 15% потенциальной аудитории. Правильная настройка сокращает количество шагов сканирования в 3–4 раза по сравнению с неоптимизированным интерфейсом. Наша команда имеет 5+ лет опыта в разработке доступных мобильных приложений для iOS и Android, реализовала поддержку Switch Control/Access для более чем 30 проектов в сферах e-commerce, fintech и здравоохранения.
Как правильно подготовить интерфейс для Switch Control?
iOS — Switch Control
Switch Control использует тот же accessibility tree, что и VoiceOver. Если VoiceOver работает корректно — Switch Control в большинстве случаев тоже. Но есть нюансы.
Группировка элементов. При сканировании система сначала подсвечивает группы (контейнеры), потом входит внутрь. Если карточка товара не сгруппирована как единый элемент — Switch Control последовательно проходит каждый subview: изображение, название, цену, кнопку. Это увеличивает количество шагов на 50–70%, что сильно замедляет пользователя.
Решение: accessibilityElements на контейнере + accessibilityActivate() override для кастомного действия по активации. Такая группировка сокращает время сканирования в 2–3 раза.
Кастомные жесты. Свайп по карточке для удаления — стандартный UIKit UISwipeGestureRecognizer Switch Control не вызовет. Нужно добавить UIAccessibilityCustomAction:
let deleteAction = UIAccessibilityCustomAction(
name: "Удалить",
target: self,
selector: #selector(deleteItem)
)
accessibilityCustomActions = [deleteAction]
Custom Actions появляются в меню Switch Control при активации элемента.
Scanning style. По умолчанию — автосканирование (элементы подсвечиваются автоматически). Пользователь может включить ручное сканирование. Убедиться, что фокус не «застревает» в бесконечном цикле внутри одного контейнера.
Android — Switch Access
Switch Access настраивается через Settings → Accessibility → Switch Access. Два основных режима: Linear Scanning (последовательный обход) и Row-Column Scanning (сначала строки, потом столбцы).
android:focusable="true" и корректные android:nextFocusDown/Up/Left/Right — определяют порядок навигации. Без явных nextFocus атрибутов система строит порядок по позиции на экране — может быть нелогичным для сложных layout.
В Compose: Modifier.focusRequester() и Modifier.focusOrder { down = nextFocusRequester } — программный контроль порядка фокуса для Switch Access.
Кастомные действия аналогично iOS: ViewCompat.setAccessibilityDelegate с переопределением onInitializeAccessibilityNodeInfo — добавляем AccessibilityActionCompat для нестандартных операций.
Почему тестирование на реальном устройстве критично?
Эмуляторы не поддерживают Switch Control/Access в полном объёме. На iOS: Settings → Accessibility → Switch Control → Add New Switch → Screen → Full Screen. Теперь тап по экрану = активация переключателя. Можно проверить поток сканирования самостоятельно.
На Android: Settings → Accessibility → Switch Access → Use Volume Keys as Switches. Volume Up = переключиться к следующему элементу, Volume Down = выбрать.
Однако эмуляция не заменяет реальный сценарий: различная скорость сканирования, поведение при групповых действиях, работа с динамическим контентом. Поэтому мы в обязательном порядке тестируем на физических устройствах (iPhone, iPad, Galaxy, Pixel) с разными версиями ОС.
Что даёт группировка элементов для пользователя?
Группировка через accessibilityElements (iOS) или nextFocus* (Android) уменьшает количество шагов сканирования в 2–3 раза. Например, карточка товара из шести subview без группировки требует 12 активаций, а с группировкой — всего 4. Пользователь тратит на навигацию в три раза меньше времени — это критично при длительном использовании.
Сравнение iOS и Android для Switch Control
| Параметр | iOS (Switch Control) | Android (Switch Access) |
|---|---|---|
| Базовая настройка | Использует тот же accessibility tree, что VoiceOver | Требует явных nextFocus атрибутов |
| Кастомные действия | UIAccessibilityCustomAction |
AccessibilityActionCompat |
| Группировка | accessibilityElements + accessibilityActivate() |
focusable="true" + nextFocus* |
| Время внедрения (при готовом VoiceOver/TalkBack) | 1-2 дня | 2-3 дня |
| Сложность отладки | Низкая (инструменты Inspector) | Средняя (Layout Inspector + switchLog) |
Типичные ошибки и их последствия
| Ошибка | Последствие | Решение |
|---|---|---|
| Отсутствие группировки | Сканирование 50+ шагов на экране | Группировка через accessibilityElements или nextFocus |
| Игнорирование кастомных жестов | Невозможность выполнить свайп | UIAccessibilityCustomAction / AccessibilityActionCompat |
| Неправильный порядок навигации после модалки | Зацикливание фокуса | Тестирование всех переходов |
| Только эмулятор | Пропуск багов реального устройства | Обязательное тестирование на физике |
Сколько времени занимает реализация?
Если VoiceOver/TalkBack уже реализованы — Switch Control в большинстве случаев работает автоматически. Основная работа — добавить UIAccessibilityCustomAction/AccessibilityActionCompat для жестовых действий и проверить порядок сканирования. Оценка: 2-3 дня. Если accessibility tree не проработан — нужно начинать с VoiceOver/TalkBack аудита (1-2 недели в зависимости от сложности приложения). Стоимость рассчитывается индивидуально после предварительной оценки объёма работ. Закажите бесплатный аудит accessibility вашего приложения — получите отчёт с рекомендациями за 2 дня. Свяжитесь с нами для консультации.
Подробнее о Switch Control и Switch Access.