Реализация поддержки 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», кастомные жесты не работают, динамический контент пропускается. Мы на практике исправляем эти проблемы. Закажите аудит доступности — получите приложение, которое смогут использовать все. Свяжитесь с нами для консультации.

Почему 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 ₽, экономия бюджета до 50 000 ₽ при комплексном заказе. Свяжитесь с нами — оценим ваш проект.

Как мы тестируем доступность на практике?

Включаем 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 таких проектов. Обращайтесь за консультацией — оценим ваш проект бесплатно.

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

TalkBack — встроенный screen reader Android. Свяжитесь с нами, чтобы получить консультацию по доступности вашего приложения.

Доступность мобильных приложений: VoiceOver, TalkBack и WCAG на практике

Приложение отклонили в App Store по гайдлайну 1.1, или пришёл запрос от корпоративного клиента с требованием WCAG 2.1 AA — обе ситуации означают одно: accessibility не был заложен в архитектуру с самого начала, а теперь его нужно встраивать в готовый продукт. Это больно.

Почему «добавить доступность потом» не работает

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

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

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

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 для мобильных стали де-факто стандартом при корпоративных тендерах и госзакупках.

Критичные критерии применительно к мобилу:

  • 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

Как строим процесс

Аудит начинается с 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

Сроки

Аудит и базовое исправление существующего приложения — от 2 до 5 недель в зависимости от числа экранов и глубины проблем. Внедрение accessibility с нуля в новый проект практически не влияет на сроки при правильном дизайне компонентной системы — закладываем 10-15% overhead на разработку UI-слоя.