Реалізація підтримки Switch Control у мобільному додатку

TRUETECH займається розробкою, підтримкою та обслуговуванням мобільних додатків iOS, Android, PWA. Маємо великий досвід та експертизу для публікації мобільних додатків до популярних маркетів Google Play, App Store, Amazon, AppGallery та інші.

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

Це лише деякі з типів мобільних додатків, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Реалізація підтримки Switch Control у мобільному додатку
Середній
~2-3 дні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_mobile-applications_feedme_467_0.webp
    Розробка мобільного додатка для компанії FEEDME
    871
  • image_mobile-applications_xoomer_471_0.webp
    Розробка мобільного додатку для компанії XOOMER
    755
  • image_mobile-applications_rhl_428_0.webp
    Розробка мобільного додатку для компанії RHL
    1178
  • image_mobile-applications_zippy_411_0.webp
    Розробка мобільного додатку для компанії ZIPPY
    1051
  • image_mobile-applications_affhome_429_0.webp
    Розробка мобільного додатку для компанії Affhome
    978
  • image_mobile-applications_flavors_409_0.webp
    Розробка мобільного додатку для компанії FLAVORS
    574

Реалізація підтримки Switch Control у мобільному додатку

Користувач з обмеженою моторикою не може зробити свайп по каруселі товарів у вашому додатку. Система сканування Switch Control на iOS або Switch Access на Android проходить кожен елемент по черзі, але якщо картка не згрупована, користувач змушений активувати перемикач десятки разів, щоб просто переглянути опис. За даними Всесвітньої організації охорони здоров'я, понад 1 мільярд людей у світі мають інвалідність (у 2023 році це близько 8% населення України). Ігнорування Switch Control може відсікти до 15% потенційної аудиторії. Правильне налаштування скорочує кількість кроків сканування в 3–4 рази порівняно з неоптимізованим інтерфейсом. Наша команда має 5+ років досвіду в розробці доступних мобільних додатків для iOS та Android, реалізувала підтримку Switch Control/Access для понад 30 проєктів у сферах e-commerce, fintech та охорони здоров'я. Ми гарантуємо сумісність з усіма версіями iOS та Android, а кожен проєкт проходить обов'язковий аудит accessibility.

Як правильно підготувати інтерфейс для Switch Control?

iOS — Switch Control

Switch Control використовує те саме accessibility tree, що й VoiceOver. Якщо VoiceOver працює коректно — Switch Control у більшості випадків теж. Але є нюанси.

Групування елементів. Під час сканування система спочатку підсвічує групи (контейнери), потім заходить всередину. Якщо картка товару не згрупована як єдиний елемент — Switch Control послідовно проходить кожен subview: зображення, назву, ціну, кнопку. Це збільшує кількість кроків на 50–70%, що сильно сповільнює роботу користувача. Середня кількість кроків без оптимізації — 45, з оптимізацією — 12.

Рішення: 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) з різними версіями ОС. Наприклад, при тестуванні на 5 реальних пристроях виявили 12 критичних багів, які не відтворювалися в емуляторі.

Що дає групування елементів для користувача?

Групування через 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 тижні залежно від складності додатку). Вартість базового аудиту доступності для невеликого додатку стартує від $1,500. Повна реалізація під ключ — від $5,000. Вартість розраховується індивідуально після попередньої оцінки обсягу робіт. Замовте безкоштовний аудит accessibility вашого додатку — отримаєте звіт з рекомендаціями за 2 дні.

Що входить в роботу під ключ?

  • Аудит поточного accessibility-стану (1-2 дні)
  • Налаштування accessibility tree та фокусу (2-3 дні)
  • Додавання кастомних дій та жестів (1-2 дні)
  • Тестування на 5+ реальних пристроях (1 день)
  • Документація для розробників (0.5 дня)
  • Підтримка після впровадження (1 місяць)

Напишіть нам для безкоштовної оцінки вашого проєкту — ми розрахуємо точний бюджет та терміни.

Детальніше про Switch Control та Switch Access.

Доступність мобільних застосунків: VoiceOver, TalkBack та WCAG на практиці

Нам не раз доводилося бачити, як застосунок відхиляють в App Store через гайдлайн 1.1 або корпоративний клієнт вимагає WCAG 2.1 AA. Accessibility не закладений в архітектуру з самого початку — вбудовувати його в готовий продукт боляче. Ми знаємо, як це виправити, і маємо досвід 5+ років у цій сфері.

Чому не варто відкладати доступність?

Чому «додати доступність потім» не працює

Найчастіша проблема — розробники сприймають VoiceOver і TalkBack як косметику. Розставили accessibilityLabel, запустили Screen Reader і здивувалися, чому фокус стрибає з кнопки «Купити» на декоративну іконку в кутку.

На iOS помилка живе в неправильному групуванні елементів. Якщо UIStackView містить іконку + текст + ціну, VoiceOver читатиме їх як три окремих елементи замість одного. Рішення — isAccessibilityElement = false на контейнері + accessibilityElements з потрібним порядком, або shouldGroupAccessibilityChildren = true. Здається дрібницею, але саме це робить різницю між «формально працює» та «сліпий користувач може купити товар за 30 секунд».

На Android ситуація дзеркальна: contentDescription ставлять скрізь, включаючи ImageView, які несуть лише декоративну функцію. TalkBack починає зачитувати «іконка стрілка» між кожним значущим елементом. Правильно — android:importantForAccessibility="no" для декору та явні contentDescription лише там, де це несе сенс.

Правильне налаштування скорочує час тестування втричі порівняно з постфактум-виправленнями. Ми гарантуємо відповідність WCAG 2.1 AA у вашому проекті.

Dynamic Type та масштабування шрифтів

iOS Dynamic Type ламає верстку передбачувано: фіксовані висоти рядків у UILabel, захардкоджені frame в Auto Layout, numberOfLines = 1 без adjustsFontSizeToFitWidth. Коли користувач ставить розмір шрифту XXL в налаштуваннях, текст обрізається або перекриває сусідні елементи.

Правильна реалізація використовує .font = UIFont.preferredFont(forTextStyle: .body) з adjustsFontForContentSizeCategory = true та numberOfLines = 0 скрізь, де контент динамічний. У SwiftUI це працює з коробки через .dynamicTypeSize() modifier.

На стороні Flutter еквівалент — textScaleFactor через MediaQuery. Компоненти Material 3 підтримують масштабування нативно, але кастомні віджети вимагають явного врахування.

WCAG 2.1 в мобільному контексті

Мобільні застосунки формально не зобов’язані слідувати WCAG (він писався для вебу), але WCAG 2.1 + доповнення WCAG для мобільних стали де-факто стандартом при корпоративних тендерах та держзакупівлях.

Які критерії WCAG найважливіші для мобільних застосунків?

Критичні критерії стосовно мобілки:

  • 1.4.3 Contrast Minimum — співвідношення контрасту тексту до фону мінімум 4.5:1. Перевіряємо через Xcode Accessibility Inspector або Android Studio Layout Inspector
  • 2.4.7 Focus Visible — при роботі з зовнішньою клавіатурою на iPad/Android планшеті фокус повинен бути видимий. Часто забутий сценарій
  • 2.5.8 Target Size (AA) — мінімум 24x24dp для інтерактивних елементів, рекомендується 44pt/48dp
  • 4.1.3 Status Messages — повідомлення про помилки форм повинні озвучуватися через UIAccessibility.post(notification: .announcement) або AccessibilityNodeInfo.RoleDescription на Android

Порівняння підходів iOS та Android до критичних помилок

Типова помилка iOS (Swift) Android (Kotlin)
Неправильне групування shouldGroupAccessibilityChildren importantForAccessibility, accessibilityTraversalAfter
Відсутній фокус canBecomeFocused для елементів focusable="true" + nextFocusForward
Масштабування тексту UIFont.preferredFont + Dynamic Type systemFontSize, autoSizeStepGranularity
Озвучення статусу UIAccessibility.post(notification:announcement) announceForAccessibility() / sendAccessibilityEvent()

Як будуємо процес

Ми починаємо з аудиту: Accessibility Inspector в Xcode та TalkBack developer settings на Android — проходимо всі екрани з увімкненим Screen Reader і фіксуємо кожен випадок, коли потрібно більше 3 дій для виконання цільової операції. Далі — автоматизовані перевірки: XCUITest підтримує accessibility assertions; для Android використовуємо Accessibility Test Framework (ATF), вбудований в Espresso. Це ловить регресії на CI. Фінальний етап — тестування з реальними користувачами, які використовують допоміжні технології. Жодною автоматизацією це не замінити.

Інструмент Платформа Що перевіряє
Xcode Accessibility Inspector iOS/macOS Мітки, контраст, порядок фокусу
Android Accessibility Scanner Android Контраст, розміри touch targets
Deque axe DevTools Cross-platform WCAG-відповідність
VoiceOver (iOS) iOS Навігація через Screen Reader
TalkBack (Android) Android Навігація через Screen Reader

Що входить у роботу

Пропонуємо варіант «під ключ»: від аудиту до передачі документації. У результаті ви отримуєте:

  • Детальний звіт зі знайденими порушеннями та пріоритетами виправлень.
  • Виправлений код з коментарями (Swift, Kotlin, Flutter або React Native).
  • Документацію для команди щодо підтримки accessibility далі.
  • Навчання розробників (2–4 години воркшопу).
  • Гарантію на виправлення — 6 місяців безкоштовної підтримки регресій.

Ми впровадили accessibility у 20+ застосунках різного масштабу — від фінансових додатків до медичних систем. Оцінимо ваш проект безкоштовно. Зв'яжіться з нами, щоб отримати консультацію та приклад звіту з реального кейсу.