При розробці мобільного додатку ми зіткнулися з реальною проблемою: користувачі зі слабким зором не могли читати текст навіть при ввімкненій темній темі. Контрастність 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 для всього тексту, щоб охопити максимум користувачів.
Процес роботи
- Аналіз: перевіряємо поточну реалізацію колірної схеми та компонентів.
- Проєктування: створюємо HC-варіації кольорів у Asset Catalog або кодом.
- Реалізація: додаємо перевірки системних прапорців, замінюємо ефекти.
- Тестування: перевіряємо контрастність на симуляторах та реальних пристроях (3+ моделі).
- Розгортання: оновлюємо додаток в 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 не закладений в архітектуру з самого початку — вбудовувати його в готовий продукт боляче. Ми знаємо, як це виправити, і маємо досвід 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+ застосунках різного масштабу — від фінансових додатків до медичних систем. Оцінимо ваш проект безкоштовно. Зв'яжіться з нами, щоб отримати консультацію та приклад звіту з реального кейсу.
