Реализация высококонтрастного режима в мобильном приложении

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

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Реализация высококонтрастного режима в мобильном приложении
Средний
от 1 дня до 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

При разработке мобильного приложения мы столкнулись с реальной проблемой: пользователи со слабым зрением не могли читать текст даже при включённой тёмной теме. Контрастность 4.5:1, требуемая WCAG 2.1, оказалась недостаточной. Штрафы за недоступность могут достигать 500 000 рублей, а экономия на переделках после внедрения HC — до 200 000 рублей. High Contrast Mode обеспечивает контрастность 7:1 — это на 55% выше стандартного уровня, а по сравнению с тёмной темой контраст выше в 1.5 раза. На iOS — Increase Contrast, на Android — High Contrast Text или High Contrast Mode у Samsung. Требования раздела 4.2 App Store Review Guidelines обязывают адаптировать интерфейс для людей с ограничениями. Мы реализуем такой режим под ключ за 1–3 дня.

Почему высококонтрастный режим отличается от тёмной темы?

Тёмная тема меняет цветовую палитру, но контраст остаётся средним. HC-режим принудительно делает фон максимально светлым, текст — максимально тёмным, убирает декоративные элементы, градиенты и тени. Это необходимо для пользователей со слабым зрением, когда даже тёмная тема не обеспечивает читаемость. Тестирование читаемости на реальных устройствах подтверждает: при HC текст остаётся читаемым даже на ярком солнце.

Как iOS обрабатывает Increase Contrast?

Система автоматически адаптирует системные цвета (UIColor.label, UIColor.secondaryLabel) под HC. Кастомные цвета из Asset Catalog поддерживают High Contrast вариант: добавляем HC-вариант — и цвет переключается без кода. Для SwiftUI используем @Environment(\.colorSchemeContrast):

@Environment(\.colorSchemeContrast) var contrast

var textColor: Color {
    contrast == .increased ? .black : .secondary
}

Также подписываемся на UIAccessibility.darkerSystemColorsStatusDidChangeNotification для динамического обновления.

Как проверить High Contrast на Android?

На Android «High Contrast Text» — системный оверлей, который невозможно контролировать из приложения, но можно проверить через AccessibilityManager.isHighTextContrastEnabled(). Samsung One UI предоставляет полноценный режим с изменением системных цветов. В Jetpack Compose isSystemInDarkTheme() не реагирует на HC, нужна отдельная проверка:

val am = getSystemService(AccessibilityManager::class.java)
val isHighContrast = am?.isHighTextContrastEnabled ?: false
Платформа Системный флаг Доступность для разработчика Особенности
iOS UIAccessibility.isDarkerSystemColorsEnabled Подписка через Notification Автоматическое применение к системным цветам
Android (AOSP) AccessibilityManager.isHighTextContrastEnabled() Только чтение Применяет системный оверлей, приложение не контролирует
Samsung One UI Встроенный режим Недоступен через SDK Меняет системные цвета, приложение адаптируется через theme

Что нужно адаптировать в High Contrast режиме?

Компонент Стандартный режим High Contrast
Цвет текста на фоне 4.5:1 7:1
Тонкие границы 1px серый 2px чёрный
Градиенты и изображения Полупрозрачные Сплошной фон + подложка
Тени и blur UIVisualEffectView Непрозрачный фон
Декоративные иконки Серые полупрозрачные Только функциональные, чёрные

Адаптация цветовой схемы включает создание HC-вариаций для всех кастомных цветов. Это особенно важно для компонентов, где контрастность падает ниже 7:1.

Типичные ошибки при адаптации

Рассмотрим несколько распространённых ошибок, которые возникают при внедрении HC.

  • Разделители толщиной 1px на белом фоне исчезают при HC — увеличивайте до 2px и делайте чёрными. В одном из проектов (финансовое приложение) мы обнаружили, что после включения HC все разделители исчезли — пришлось увеличить их толщину до 2px и изменить цвет на #000.
  • Frosted glass (UIVisualEffectView) не обеспечивает контраст — заменяйте на сплошной непрозрачный фон.
  • Тонкие шрифты (weight: 300) на светлом фоне теряют читаемость — используйте weight 400+.

Контрастность 7:1 — это уровень AAA для нормального текста. Для крупного текста (≥18pt или ≥14pt bold) достаточно 4.5:1. Рекомендуем соблюдать AAA для всего текста, чтобы охватить максимум пользователей.

Процесс работы

  1. Анализ: проверяем текущую реализацию цветовой схемы и компонентов.
  2. Проектирование: создаём HC-вариации цветов в Asset Catalog или кодом.
  3. Реализация: добавляем проверки системных флагов, заменяем эффекты.
  4. Тестирование: проверяем контрастность на симуляторах и реальных устройствах (3+ модели).
  5. Деплой: обновляем приложение в App Store и Google Play.

Что входит в работу

  • Полный аудит текущего интерфейса на соответствие WCAG 2.1.
  • Создание HC-цветовой схемы (iOS Asset Catalog + SwiftUI, Android colors.xml).
  • Доработка кастомных компонентов (кнопки, ячейки, экраны).
  • Тестирование на 2–3 реальных устройствах.
  • Документация по использованию HC-режима для поддержки.

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

Срок: 1–3 дня в зависимости от объёма кастомных UI-компонентов. Стоимость рассчитывается индивидуально. Получите консультацию по адаптации вашего приложения или закажите бесплатный аудит accessibility.

Доступность мобильных приложений: 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-слоя.