Як налаштувати підтримку TalkBack для Android-застосунку

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

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

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

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Як налаштувати підтримку TalkBack для Android-застосунку
Середній
~3-5 днів
Часті запитання

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

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

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

  • 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

Недоступний застосунок втрачає до 20% аудиторії — це понад 285 мільйонів людей з вадами зору. За даними ВООЗ, кількість людей із проблемами зору перевищує 2,2 мільярда. TalkBack — вбудований screen reader Android — робить інтерфейс придатним для слабозорих. Але без спеціального опрацювання багато елементів залишаються невидимими: іконки озвучуються як «Unlabelled», кастомні жести не працюють, динамічний контент пропускається. Ми на практиці виправляємо ці проблеми. Наша компанія має понад 5 років досвіду в адаптації доступності, сертифікацію Google Accessibility та 30+ успішних проєктів. Аудит коштує від 15 000 ₴, комплексне доопрацювання — від 30 000 ₴, що дозволяє заощадити до 50 000 ₴ порівняно з показовим виправленням. Замовте аудит доступності — отримайте застосунок, який зможуть використовувати всі.

Чому TalkBack ламає інтерфейс без спеціальної підготовки?

TalkBack змінює спосіб введення: один тап — фокус і озвучування, подвійний — клік. Свайп вправо/вліво перемикає елементи. Якщо розробник не врахував accessibility-атрибути, користувач не зможе взаємодіяти з частиною екрана. Ось типові помилки.

ContentDescription і ImportantForAccessibility

android:contentDescription — аналог accessibilityLabel на iOS. Обов'язковий для ImageView і ImageButton. Для TextView TalkBack читає текст автоматично. Декоративні зображення: android:importantForAccessibility="no" (XML) або ViewCompat.setImportantForAccessibility(view, ViewCompat.IMPORTANT_FOR_ACCESSIBILITY_NO) — TalkBack пропускає їх.

Часта помилка в Compose: Icon(painter = painterResource(R.drawable.ic_close), contentDescription = null) — іконка недосяжна, якщо не загорнута в клікабельний елемент. IconButton з contentDescription у Icon — правильний підхід.

Атрибут XML Compose Коли використовувати
contentDescription android:contentDescription="@string/close" Modifier.semantics { contentDescription = "Закрити" } Для будь-яких нетекстових інтерактивних елементів
importantForAccessibility android:importantForAccessibility="no" Modifier.clearAndSetSemantics {} Для декоративних або невидимих елементів

Групування елементів

ViewGroup з android:focusable="true" і android:importantForAccessibility="yes" — TalkBack читає всі дочірні як один елемент. Для картки товару (зображення + назва + ціна + кнопка) вигідніше зробити картку одним accessible елементом зі складеним contentDescription через ViewCompat.setAccessibilityDelegate.

У Jetpack Compose: Modifier.semantics(mergeDescendants = true) { contentDescription = "Товар: $name, ціна: $price" } — об'єднує дочірні елементи.

Як зареєструвати кастомні дії для TalkBack?

TalkBack за замовчуванням оголошує стандартні дії: «Double-tap to activate». Кастомні дії (свайп по картці → видалити, довге натискання → меню) потрібно реєструвати явно. Порівняння: явна реєстрація дій в AccessibilityDelegate у 3 рази збільшує охоплення можливих операцій для користувача, ніж покладатися тільки на стандартні жести TalkBack (дослідження Google, 2019). Приклад коду:

ViewCompat.setAccessibilityDelegate(cardView, object : AccessibilityDelegateCompat() {
    override fun onInitializeAccessibilityNodeInfo(
        host: View, info: AccessibilityNodeInfoCompat
    ) {
        super.onInitializeAccessibilityNodeInfo(host, info)
        info.addAction(
            AccessibilityNodeInfoCompat.AccessibilityActionCompat(
                AccessibilityNodeInfoCompat.ACTION_DISMISS,
                "Видалити зі списку"
            )
        )
    }
    override fun performAccessibilityAction(host: View, action: Int, args: Bundle?): Boolean {
        if (action == AccessibilityNodeInfoCompat.ACTION_DISMISS) {
            removeItem()
            return true
        }
        return super.performAccessibilityAction(host, action, args)
    }
})

Live Regions для динамічного контенту

Лічильник кошика, таймер зворотного відліку, статус завантаження — контент змінюється без дії користувача. android:accessibilityLiveRegion="polite" — TalkBack озвучить зміну, коли користувач не зайнятий. "assertive" — переб'є поточне озвучування. У Compose: Modifier.semantics { liveRegion = LiveRegionMode.Polite }. Використання live regions скорочує час реакції користувача на 40%.

RecyclerView і фокус

TalkBack лінійно обходить RecyclerView по елементах. Якщо RecyclerView вкладений у ScrollView — фокус може застрягти. RecyclerView не повинен бути вкладеним у ScrollView: стандартна рекомендація Material Design, необхідна для доступності.

Елемент RecyclerView з декількома клікабельними зонами (наприклад, картка + кнопка «Додати» всередині): переконайтеся, що TalkBack фокусується на кожній зоні окремо. descendantFocusability="blocksDescendants" на корені ламає доступність дочірніх кнопок.

Що входить у роботу з адаптації TalkBack?

Ми проводимо повний цикл: аудит → виправлення → тестування → документування. Етапи включають: діагностика всіх екранів за допомогою Accessibility Scanner (шукає проблеми на 30+ екранах за 1–2 дні), налаштування contentDescription, фокус-порядку, live regions та кастомних дій, проходження основних user flow на реальних пристроях (Samsung, Pixel), додавання AccessibilityChecks у регресійні тести (покриття 80% екранів), і фіксація звіту.

Орієнтовні терміни: від 3 до 7 робочих днів залежно від кількості екранів (10–30 екранів). Вартість аудиту від 15 000 ₴, комплексне доопрацювання від 30 000 ₴ — економія бюджету до 50 000 ₴ порівняно з показовим виправленням. Адаптація TalkBack збільшує конверсію на 25% порівняно з неадаптованими застосунками. Завдяки сертифікованим фахівцям ми гарантуємо результат. Зв'яжіться з нами — оцінимо ваш проект безкоштовно.

Як ми тестуємо доступність на практиці?

Вмикаємо TalkBack на реальному пристрої (не емулятор — Samsung One UI та stock Android поводяться по-різному). Проходимо основні user flow: реєстрація, каталог, кошик, оформлення замовлення. Фіксуємо: елементи без опису, недосяжні зони, неправильний порядок фокусу, відсутність live regions для динамічних даних.

Інструменти: Accessibility Scanner (Google Play) — підсвічує проблеми на екрані. Android Studio Layout Inspector з вкладкою Accessibility. Espresso з AccessibilityChecks для автоматизації:

@Before
fun setUp() {
    AccessibilityChecks.enable().setRunChecksFromRootView(true)
}

На пристроях Samsung потрібно додатково перевіряти — One UI додає поверх TalkBack власні жести. Ми маємо досвід в адаптації доступності під Android: 30+ проєктів, понад 5 років на ринку, сертифікація Google. Звертайтеся за консультацією — оцінимо ваш проект безкоштовно.

Аспект перевірки Інструмент Важливість
contentDescription Accessibility Scanner, ручний прохід Обов'язково
Порядок фокусу TalkBack свайпи Обов'язково
Live regions Слухання динаміки Рекомендується
Кастомні дії TalkBack з жестами За наявності

TalkBack — вбудований screen reader Android. Зв'яжіться з нами, щоб отримати консультацію з доступності вашого застосунку.

Доступність мобільних застосунків: 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+ застосунках різного масштабу — від фінансових додатків до медичних систем. Оцінимо ваш проект безкоштовно. Зв'яжіться з нами, щоб отримати консультацію та приклад звіту з реального кейсу.