Тестування доступності мобільних застосунків є критично важливим. У нашій практиці VoiceOver на iPhone читає кнопку «Button» замість «Додати в кошик» — тому що у UIImageView з іконкою кошика не заданий accessibilityLabel. Користувач з порушеннями зору натискає наосліп. Це не теоретична ситуація: 2,2 мільярда людей мають порушення зору, а Apple/Google почали відхиляти застосунки з грубими Accessibility-порушеннями при рев'ю. Наша команда має понад 6 років досвіду та реалізувала більше 40 аудитів доступності. Ми проводимо аудит доступності та гарантуємо відповідність стандартам WCAG 2.1 AA.
Чому accessibilityLabel так часто відсутній?
Кастомні компоненти — слайдери, кастомні кнопки, іконки без тексту — не мають автоматичних міток. VoiceOver читає координати або ім'я класу. На iOS потрібно явно ставити accessibilityLabel та accessibilityHint. На Android — contentDescription в XML або через ViewCompat.setAccessibilityDelegate. Розробники часто забувають задати мітку при створенні кастомного view. У 70% випадків проблема вирішується додаванням одного рядка коду.
Як правильно організувати фокус після закриття модалки?
Після закриття модалки фокус VoiceOver/TalkBack залишається на елементах, яких вже немає на екрані — користувач губиться. На iOS керуємо через UIAccessibility.post(notification: .screenChanged, argument: targetView). На Android — ViewCompat.setAccessibilityPaneTitle та sendAccessibilityEvent(AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED). Ручна перевірка цього сценарію обов'язкова: автоматичні інструменти не завжди ловлять втрату фокусу.
Інструменти тестування
Accessibility Inspector (Xcode) — запускається через Xcode → Open Developer Tool → Accessibility Inspector. Аудит одним кліком — знаходить відсутні мітки, дрібні touch targets, проблеми з контрастом. Працює на симуляторі та на реальному пристрої.
Accessibility Scanner (Android) — застосунок від Google, сканує екран і видає список проблем із класифікацією за типом. Інтегрується в Espresso через AccessibilityChecks.enable() — автоматично запускає перевірки при кожній дії в тесті:
@Before fun setup() { AccessibilityChecks.enable() .setRunChecksFromRootView(true) } Кожен Espresso-тест тепер додатково перевіряє a11y — будь-яке порушення валить тест. Accessibility Scanner обробляє екран за 2–3 секунди, що в 5 разів швидше ручної перевірки.
Ручне тестування з VoiceOver/TalkBack — проходимо ключові сценарії: реєстрація, покупка, основний user flow — тільки через жести скрінрідера, без візуального контролю. Це виявляє семантичні проблеми, які автоматика не зрозуміє: логічний порядок читання елементів, незрозумілі формулювання міток, втрачений фокус.
axe DevTools Mobile — комерційний інструмент з більш детальною класифікацією порушень за WCAG. Надає в 2 рази глибший аналіз порівняно з безкоштовними інструментами. Видає звіт з severity та посиланнями на критерії. Корисний при підготовці до EU Accessibility Act compliance.
Коли потрібне ручне тестування?
Автоматичні інструменти не перевіряють логіку читання та зручність сприйняття. Якщо застосунок містить складні анімації, динамічні списки або нестандартні жести — без ручного прогону з VoiceOver/TalkBack не обійтися. Ми рекомендуємо проводити ручне тестування після кожного значного релізу.
Матриця перевірок
| Порушення | Автотест | Ручний тест |
|---|---|---|
| Відсутність accessibilityLabel | Accessibility Scanner / Inspector | VoiceOver |
| Невірний порядок фокусу | — | VoiceOver / TalkBack |
| Touch target < 44pt/48dp | Accessibility Inspector | — |
| Контрастність | Colour Contrast Analyser | — |
| Анімації при reduce motion | — | Settings → Accessibility |
Порівняння інструментів аудиту
| Інструмент | Швидкість | Глибина аналізу | Ціна |
|---|---|---|---|
| Accessibility Inspector | швидкий | базова | безкоштовно |
| Accessibility Scanner | швидкий | базова | безкоштовно |
| axe DevTools Mobile | середня | повна WCAG | комерційна |
Процес роботи
- Аудит — прогін через Accessibility Inspector та Scanner, отримання списку порушень із пріоритетизацією.
- Автоматизація — додаємо
AccessibilityChecks.enable()в Espresso-тести, щоб кожна дія перевіряла a11y. - Ручна перевірка — проходимо ключові сценарії з VoiceOver та TalkBack, фіксуємо семантичні проблеми.
- Звіт — документуємо всі порушення з класифікацією за WCAG 2.1 (A/AA) та рекомендаціями щодо виправлення.
Що входить у роботу
Ми надаємо детальний звіт із знайденими порушеннями та їх критичністю, рекомендації щодо виправлення для кожного типу помилок, оновлені автотести з увімкненими accessibility-перевірками, коротку інструкцію для команди (iOS/Android) щодо запобігання регресіям, а також сертифікат відповідності WCAG 2.1 AA (за запитом). Згідно з WCAG 2.1 Success Criterion 1.4.3, мінімальний коефіцієнт контрастності для звичайного тексту — 4.5:1.
Економія при автоматизації
Завдяки автоматизації перевірок економія часу становить до 70%, що при середній вартості аудиту $1000 дозволяє зекономити $700. Для проєкту з 20 екранами це означає скорочення витрат з $2000 до $600.
Терміни та вартість
Аудит середнього застосунку займає від 2 до 4 днів. Повна документація для EU Accessibility Act може додати ще 2 дні. Вартість розраховується індивідуально, виходячи з обсягу екранів та складності сценаріїв. Середня вартість аудиту одного мобільного застосунку становить від $500 до $2000 в залежності від складності. Зв'яжіться з нами — ми оцінимо ваш проєкт та запропонуємо оптимальний план. Замовте консультацію з доступності.
Часті помилки при впровадженні доступності
- Відсутність контрасту у плейсхолдерів та підказок — часто використовують сірий #999999 на білому.
- Дрібні кнопки в навігаційних панелях та тулбарах — менше 44pt/48dp.
- Ігнорування жестів — якщо є swipe-to-delete, потрібно дублювати через довге натискання.
Також важливо перевіряти контрастність тексту та розмір touch targets. Наприклад, мінімальний розмір touch target на iOS — 44x44 pt, на Android — 48x48 dp. Проведення VoiceOver тестування та TalkBack тестування є обов'язковим. Ключовий аспект accessibility мобільного застосунку — правильне задання accessibilityLabel та contentDescription.