VoiceOver — вбудований screen reader від Apple, який дозволяє незрячим та слабозорим користувачам взаємодіяти з пристроєм. Якщо ваш додаток його не підтримує, вони просто не можуть ним користуватися. Ми проводимо аудит та впровадження VoiceOver під ключ, гарантуючи відповідність стандартам доступності. Наш досвід — понад 10 років у розробці iOS-додатків для різних галузей. Зв'яжіться з нами для оцінки вашого додатку.
Чому VoiceOver важливий для бізнесу?
За даними Apple, понад 15% користувачів iOS активно використовують функції доступності. Ігнорування цієї аудиторії призводить до втрати до 15% потенційних клієнтів. Крім того, багато контрактів у державному секторі, медицині та освіті вимагають відповідності WCAG 2.1 або Section 508. Додатки без VoiceOver не проходять ці вимоги, що обмежує ринок збуту. Більше того, невідповідність стандартам може спричинити юридичні санкції та фінансові штрафи. Автоматизований аудит скорочує час перевірки в 3–5 разів порівняно з ручним, а виправлення помилок на етапі розробки обходиться на 40% дешевше, ніж після релізу.
Які елементи додатку ламаються без VoiceOver?
Кастомні UIView та SwiftUI View
Стандартні UIButton, UILabel, UITextField — VoiceOver розуміє з коробки. Кастомні UIView з намальованим на CALayer контентом — ні. VoiceOver бачить весь кастомний view як один елемент без опису.
Для UIKit: isAccessibilityElement = true, accessibilityLabel, accessibilityHint, accessibilityTraits. accessibilityLabel — що це таке («Кнопка додати в кошик»). accessibilityHint — що відбудеться при активації («Додає товар у кошик, переходить до оформлення»). accessibilityTraits — тип елемента (.button, .link, .image, .header, .selected).
| Аспект | UIKit | SwiftUI |
|---|---|---|
| Label | accessibilityLabel |
.accessibilityLabel() |
| Hint | accessibilityHint |
.accessibilityHint() |
| Traits | accessibilityTraits |
.accessibilityAddTraits() |
| Об'єднання дітей | Масив accessibilityElements |
.accessibilityElement(children: .combine) |
Для SwiftUI: модифікатори .accessibilityLabel(), .accessibilityHint(), .accessibilityAddTraits(). Якщо кілька вкладених View потрібно об'єднати в один accessible елемент — .accessibilityElement(children: .combine) або .accessibilityElement(children: .ignore) + явний label.
Зображення без alt-тексту
UIImageView з isAccessibilityElement = false (за замовчуванням) — VoiceOver пропускає. Декоративні зображення — правильно. Смислові — ні, потрібен accessibilityLabel. Іконки в кнопках: якщо UIButton містить лише UIImageView без тексту — потрібен accessibilityLabel на кнопці, інакше VoiceOver зачитає ім'я файлу або мовчить.
Порядок фокусу
VoiceOver обходить елементи по accessibilityActivationPoint — зазвичай центр frame. Для складних layout (overlay, absolute positioning в SwiftUI, кастомні контейнери) порядок може бути хаотичним. Виправляється через accessibilityElements на батьківському контейнері — масив у потрібному порядку:
override var accessibilityElements: [Any]? {
get { [titleLabel, priceLabel, addButton] }
set { }
}
У SwiftUI — .accessibilitySortPriority() для керування порядком.
Модальні екрани та кастомні оверлеї
UIAlertController — VoiceOver фокусується автоматично. Кастомний UIView-оверлей поверх контенту — ні. Потрібно UIAccessibility.post(notification: .screenChanged, argument: firstElement) щоб перевести фокус на перший елемент оверлею. При закритті — post(notification: .screenChanged, argument: triggerButton) щоб повернути фокус на кнопку, яка відкрила оверлей.
accessibilityViewIsModal = true на контейнері оверлею — ховає фоновий контент від VoiceOver. Без цього користувач свайпом може «провалитися» крізь оверлей на задній контент.
Як ми проводимо аудит та впровадження: покроковий процес
- Включення VoiceOver — Cmd+F5 в Simulator або потрійний клік Home/Side Button на пристрої. Проходимо всі ключові флоу: онбординг, головний екран, основні actions (оформити замовлення, відправити повідомлення, відтворити медіа).
- Фіксація проблем — елементи без label, неправильний порядок фокусу, недосяжні елементи, модальні оверлеї без керування фокусом.
- Інструменти — Accessibility Inspector (Xcode) перевіряє контрастність, знаходить елементи без label без запуску додатку. XCTest з
XCUIAccessibilityAudit(iOS 17+) дає автоматизований аудит в UI-тестах. - Пріоритет виправлень — спочатку навігація та ключові CTA, потім списки та форми, потім медіа-контент.
Наприклад, на проекті медичного додатку для записів ми скоротили час навігації з 8 с до 1,2 с завдяки правильному порядку фокусу та додаванню accessibilityHint для критичних дій.
Порівняння ручного та автоматизованого тестування:
| Критерій | Ручне тестування | Автоматизований аудит |
|---|---|---|
| Час на один екран | 10–15 хв | 1–2 хв |
| Охоплення | Вибірковий | Повний (всі елементи) |
| Точність | Залежить від тестувальника | Стабільна |
| Повторюваність | Низька | Висока (можна в CI) |
Що входить у роботу?
- Аудит доступності зі звітом по кожному екрану та пріоритетом виправлень.
- Реалізація accessibility labels, hints, traits для всіх кастомних компонентів.
- Налаштування порядку фокусу для складних layout та модальних вікон.
- Інтеграція з VoiceOver для динамічного контенту (наприклад, оновлення після завантаження).
- Тестування за допомогою Accessibility Inspector та ручне проходження ключових сценаріїв.
- Документація та рекомендації для команди щодо підтримки доступності в майбутньому.
Термін: 3-5 днів для додатку середнього масштабу. Вартість розраховується індивідуально — напишіть нам, і ми оцінимо ваш проект. Отримайте консультацію по вашому проекту — ми допоможемо впровадити VoiceOver якісно та вчасно.
Типові помилки при реалізації VoiceOver
- Забувають задати
accessibilityLabelдля кнопок-іконок (тільки зображення). - Не використовують
accessibilityTraits, через що VoiceOver не відрізняє кнопку від статичного тексту. - Не обробляють dynamic type — шрифти не масштабуються, і текст обрізається.
- Ігнорують порядок фокусу на екранах з кастомною анімацією або overlay.
Уникаючи цих помилок, ви робите додаток доступним для мільйонів користувачів.