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

В этой статье разберём, как внедрять доступность мобильных приложений в продуктовый процесс: что требует WCAG, как работают iOS VoiceOver и Android TalkBack, какие ошибки ломают UX для людей с ОВЗ и как быстро проверить продукт по чек‑листу.

Почему доступность мобильных приложений — это продуктовый must-have

Доступность — это не «добровольная опция», а показатель зрелости UX и качества кода. Она снижает отказоустойчивость интерфейса, расширяет аудиторию (временные травмы, плохое освещение, малые экраны), улучшает метрики вовлеченности и повышает рейтинг в сторах за счёт лучших отзывов. Плюс требования соответствия WCAG часто фигурируют в тендерах и корпоративных SLA.

WCAG для мобильных: как читать и применять

WCAG не привязан к платформе, но принципы POUR (Perceivable, Operable, Understandable, Robust) полностью применимы к iOS и Android. Основные зоны внедрения:

• Воспринимаемость: контраст, масштаб, альтернативный текст, озвучиваемая семантика.
• Управляемость: фокус, порядок навигации, жесты и доступные цели касания.
• Понятность: предсказуемая навигация, понятные состояния, явные ошибки и подсказки.
• Надёжность: корректное формирование accessibility tree, доступность для скринридеров и вспомогательных технологий.

Практически: привязывайте критерии WCAG 2.2 к пользовательским историям, пишите «Definition of Done» с a11y-акцепт‑критериями и покрывайте критические флоу авто- и мануальными тестами доступности.

iOS: VoiceOver, Dynamic Type и семантика

На iOS фундамент — корректная семантика и поддержка системных настроек:

• Accessibility labels и traits: у каждого интерактивного элемента должен быть label, hint, правильный trait (button, header, selected, link). Комбинируйте элементы в UIAccessibilityElement, если визуально это одна интеракция.
• Focus order: порядок должен соответствовать визуальной и логической структуре. Используйте accessibilityElements и accessibilityViewIsModal, чтобы не «утекать» фокусом под модалку.
• Dynamic Type: включайте масштабирование текста через UIFontMetrics, проверяйте на Extra Large / Accessibility sizes, не обрезайте строки.
• VoiceOver rotor: поддерживайте заголовки и landmarks для быстрой навигации.
• Hit targets: минимум 44×44 pt; следите, чтобы касания не перекрывались.
• Анимации: уважайте Reduce Motion; создавайте альтернативу жестам «свайп–холд» кнопками.

Инструменты: Accessibility Inspector (Xcode), VoiceOver Practice, Audit в Simulator, снимки иерархии для accessibility tree.

Android: TalkBack, масштаб и доступные паттерны

На Android ключевые моменты схожи, но API и названия иные:

• ContentDescription: обязателен для декоративных иконок-кнопок; не дублируйте текст, если он уже видим и читаем скринридером.
• Accessibility heading и role: помечайте заголовки, используйте semantic roles, stateDescription для нестандартных контролов.
• Focus navigation: управляемый порядок через importantForAccessibility, объединение view в контейнер, исключение декоративных.
• Scalable text: соблюдайте SP, поддерживайте масштаб шрифта 200% без потери функциональности.
• Touch target: минимум 48×48 dp; учитывайте safe areas и системные жесты.
• Motion/animation: уважайте настройку Remove animations; предоставляйте альтернативы жестам.

Инструменты: Accessibility Scanner, Layout Inspector, TalkBack в «Для разработчиков», Espresso‑тесты с проверкой contentDescription и состояний.

Контраст и шрифты в app: что реально работает

Контраст — частая причина отказов в аудитах. Минимум: 4.5:1 для основного текста и 3:1 для крупного (>= 18 pt regular или 14 pt bold). Обратите внимание:

• Не используйте «серый по серому» для вторичных действий — сделайте их контрастными, но менее заметными за счёт иерархии и размеров.
• Не полагайтесь на цвет как единственный носитель смысла: добавляйте иконку, паттерн, текст.
• Проверьте контраст в состояниях (disabled, pressed, selected, error) и на фоне медиа.
• Шрифты: соблюдайте минимум 15–16 pt (iOS) / 14–16 sp (Android) для основного текста, следите за межстрочными интервалами и длиной строк.

Инструменты: встроенные инспекторы контраста в Figma, плагин Stark, тестирование на реальных устройствах при разном True Tone/Adaptive Brightness.

Semantic labels app: роли, состояния, ошибки

Семантика — это не только label. Важны:

• Role/trait: кнопка должна быть «кнопкой», заголовок — «заголовком»; переключатель — switch с состоянием on/off.
• State: сообщайте скринридеру о selected, expanded/collapsed, busy/processing.
• Errors: чёткое текстовое сообщение, фокус на ошибочном поле, озвучивание, ссылка «к ошибке» над формой. Не прячьте ошибки под клавиатурой.
• Grouping: объединяйте составные элементы карт в один доступный объект, если взаимодействие единое.
• Media: у видео — субтитры/кэпшены; у изображений — осмысленные alt/description (или пометка как декоративное).

Навигация, жесты и альтернативы взаимодействий

• Порядок фокуса и логическая прогрессия шагов — предсказуемость важнее визуальных эффектов.
• Для жестов «свайп влево/вправо» добавляйте явные кнопки действий.
• Долгое нажатие и drag-n-drop должны иметь альтернативу: меню действий, кнопки перемещения по шагам.
• Хаптика и звук — дополнение, не единственный источник информации. Добавляйте текстовые подтверждения.
• Состояния загрузки и пустые экраны озвучивайте и делайте доступными для фокуса.

Тестирование доступности: процесс, инструменты, покрытие

Стратегия:

1) Unit/UI‑тесты на семантику: проверка наличия label/contentDescription, валидности ролей и состояний.

2) Инструментальные сканы: Accessibility Inspector (iOS), Accessibility Scanner (Android) — быстрый triage.

3) Мануал с VoiceOver/TalkBack: прохождение ключевых сценариев, проверка порядка фокуса, озвучивания, жестов.

4) Тест на масштаб текста 200%, контраст, поворот экрана, клавиатуру/экранную лупу.

5) Тесты с внешними устройствами: переключатели, Bluetooth‑клавиатура, аппаратная навигация.

6) Пользовательские сессии с участниками с разными типами доступности.

Автоматизация: линтеры accessibility для Swift/Kotlin, скрипты для поиска «пустых» кнопок, снапшоты экранов в разных размерах шрифта.

Интеграция доступности в продуктовый цикл

• Discovery: учитывайте людей с ОВЗ в персонажах и сценариях.
• Дизайн: заложите a11y в компоненты дизайн‑системы, проверьте контраст и роле‑модель. Если нужна помощь — подключайте нашу услугу
  и отдельно —
  .
• Разработка: договорённости по naming/ID, единая схема accessibilityProps для кроссплатформы (React Native, Flutter, Kotlin Multiplatform).
• QA: чек‑лист, device‑farm с разными настройками доступности, bug templates с полями для VoiceOver/TalkBack.
• Релиз: changelog с пометкой accessibility fixes повышает доверие и рейтинг.

Если планируете запуск нативного приложения под iOS/Android с акцентом на a11y — смотрите услугу Мобильные приложения.

Доступность кроссплатформенных фреймворков

• React Native: используйте accessibilityLabel, accessibilityRole, accessibilityState; следите за поддержкой платформенных ролей в версиях RN, избегайте «view‑обёрток» без роли.
• Flutter: Semantics, excludeSemantics/mergeSemantics; проверяйте, что CustomPainter элементы имеют описание; тестируйте semantics tree через flutter_driver/integration_test.
• SwiftUI/Jetpack Compose: встроенная семантика сильнее, но кастомные модификаторы могут ломать дерево; используйте .accessibilityLabel/.semantics, проверяйте talkback/voiceover поведение.

a11y чеклист mobile

• Контраст текста и иконок соответствует 4.5:1 (обычный) и 3:1 (крупный).
• Текст масштабируется до 200% без потери контента и функций.
• Минимальный размер интерактивных целей: 44×44 pt (iOS) / 48×48 dp (Android).
• Правильные labels/hints и roles/traits/semantics у всех интерактивных элементов.
• Порядок фокуса соответствует визуальной и логической структуре.
• Есть альтернативы жестам: кнопки для свайпов, long press, drag.
• Ошибки форм озвучиваются, фокус переводится к первому проблемному полю.
• Состояния (selected, expanded, disabled, busy) озвучиваются корректно.
• Медиа имеют субтитры/альтернативы; декоративная графика помечена как декоративная.
• Учитываются системные настройки: Reduce/Remove Motion, инверсия, цветовые фильтры.
• Навигационные заголовки размечены и доступны в rotor/быстрой навигации.
• Тесты пройдены в VoiceOver и TalkBack на ключевых флоу.

Полезные материалы

• О том, как системно выстраивать UX‑процессы и дизайн компонентов, читайте в статье «
  ».
• Если развиваете мобильный продукт, смотрите обзор «
  » — полезно для понимания ожиданий пользователей к UX и производительности.

Вывод: доступность — это скорость, качество и доверие

Доступность не замедляет разработку — она экономит время на багфиксы и поддерживает масштабируемость дизайна. Начните с критичных сценариев, закрепите практики в дизайн‑системе и CI, а затем расширяйте покрытие. Нужна экспертиза и ресурсы — подключайте LightsOn: поможем встроить WCAG‑требования в процесс и выпустить продукт, которым удобно пользоваться всем.