Аудит доступності мобільного додатку за WCAG

Аудит доступності мобільного додатку за WCAG

Якщо ваш мобільний додаток не проходив аудит доступності, ви ризикуєте втратити до 15% користувачів з обмеженнями та отримати судові позови (наприклад, за ADA у США). Стандарт WCAG 2.1 через WCAG2ICT застосовується до мобільних додатків. Наші сертифіковані інженери перевіряють контрастність, текстові альтернативи, навігацію зі скринрідерами та інші критерії. Замовте аудит під ключ — ми виявимо всі порушення рівня A та AA і підготуємо звіт із прикладами коду на Swift, Kotlin, Flutter або React Native. Зв'яжіться з нами, щоб оцінити ваш додаток.

Чому аудит доступності критичний для вашого додатку?

Без аудиту ви ризикуєте втратити до 15% користувачів з обмеженнями та зіткнутися з судовими позовами (наприклад, за ADA у США). WCAG 2.1 через WCAG2ICT застосовується до мобільних додатків. Рівні A та AA — мінімальний поріг для держзакупівель та більшості вимог. Рівень AA покриває в 3 рази більше сценаріїв використання для людей з порушеннями зору та моторики, ніж рівень A. Наш аудит гарантує, що ваш додаток відповідає EN 301 549 та іншим стандартам.

Які проблеми виявляє аудит WCAG?

Ми виявляємо типові проблеми: відсутність accessibilityLabel на іконках, низький контраст тексту, неправильний порядок фокусу, невидимі для скринрідерів помилки форм та багато іншого. Наш звіт включає скріншоти кожного порушення з пріоритетом виправлення. Приклад: сірий плейсхолдер #9E9E9E на білому фоні дає контраст 1.9:1 (потрібно 4.5:1).

Що перевіряємо

Критерій 1.1 — Текстові альтернативи — аудит доступності мобільного

Усі нетекстові елементи повинні мати текстову альтернативу. На iOS — accessibilityLabel, на Android — contentDescription. Декоративні елементи позначаються як пропущені. Інструмент: Accessibility Inspector (Xcode) та Android Accessibility Scanner.

Критерій 1.3 — Адаптивність

Структура не повинна залежати від візуального сприйняття. Порядок читання screen reader'а має збігатися з логічним порядком. Для ConstraintLayout та ZStack порядок фокусу задаємо явно.

Критерій 1.4 — Розрізнення

1.4.3 Контрастність (AA): мінімум 4.5:1 для тексту, 3:1 для великого. Перевіряємо всі елементи. 1.4.4 Зміна розміру тексту: підтримка Dynamic Type (iOS) та font scaling (Android). 1.4.10 Перекомпоновка: контент без горизонтальної прокрутки при масштабі до 400%. 1.4.11 Контраст для нетекстових елементів: іконки, межі — 3:1.

Критерій 2.1 — Керування з клавіатури

На мобільному — Switch Control та зовнішня клавіатура. Усі функції мають бути доступні без сенсорного екрану. Перевіряємо Tab-навігацію, Enter для активації, Escape для закриття модалок.

Критерій 2.4 — Навігація

Фокус при відкритті модального вікна переходить на перший елемент, при закритті — повертається. Заголовки екранів структурують сторінку. Видимий фокус обов'язковий.

Критерій 3.3 — Допомога при введенні

Повідомлення про помилки повинні бути пов'язані з полем через accessibilityHint або UIAccessibility.post(notification:). Тільки червоний border невидимий.

Формат аудиту

Фінальний звіт містить:

• Таблицю критеріїв WCAG з оцінками Pass/Fail/N/A
• Скріншоти з описом порушень
• Пріоритети (блокувальні vs minor)
• Рекомендації з прикладами коду

Приклад таблиці:

Що входить в аудит?

У вартість включено:

• Детальний звіт з посторінковим розбором
• Файл із прикладами коду для iOS, Android, Flutter, React Native
• Пріоритезація порушень за критичністю
• Консультація щодо виправлення через 1 тиждень після звіту
• Рекомендації щодо довгострокової підтримки доступності

Порівняння рівнів A та AA

Рівень A — мінімальні вимоги (25 критеріїв). Рівень AA додає ще 21 критерій, включаючи контраст 4.5:1 та субтитри. На практиці більшість клієнтів обирають AA, оскільки він покриває основні потреби користувачів і відповідає законодавству.

Як ми проводимо аудит?

1. Підготовка: вивчаємо ваш додаток, збираємо сценарії використання
2. Автоматизована перевірка: запускаємо Accessibility Scanner та Lighthouse
3. Ручне тестування: 3–5 сценаріїв на фізичних пристроях
4. Складання звіту: документуємо кожне порушення
5. Фінальна консультація: обговорюємо план виправлень

Наш досвід та гарантії

За 5 років роботи ми перевірили понад 100 мобільних додатків на доступність. Наші інженери сертифіковані IAAP (International Association of Accessibility Professionals). Ми гарантуємо, що після виправлення за нашим звітом ваш додаток пройде повторний аудит з результатом Pass за обраним рівнем.

Термін аудиту: від 2 до 5 днів залежно від масштабу. Зв'яжіться з нами для точної оцінки та замовлення.

WCAG

Доступність мобільних застосунків: 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 до критичних помилок

Як будуємо процес

Ми починаємо з аудиту: Accessibility Inspector в Xcode та TalkBack developer settings на Android — проходимо всі екрани з увімкненим Screen Reader і фіксуємо кожен випадок, коли потрібно більше 3 дій для виконання цільової операції. Далі — автоматизовані перевірки: XCUITest підтримує accessibility assertions; для Android використовуємо Accessibility Test Framework (ATF), вбудований в Espresso. Це ловить регресії на CI. Фінальний етап — тестування з реальними користувачами, які використовують допоміжні технології. Жодною автоматизацією це не замінити.

Що входить у роботу

Пропонуємо варіант «під ключ»: від аудиту до передачі документації. У результаті ви отримуєте:

• Детальний звіт зі знайденими порушеннями та пріоритетами виправлень.
• Виправлений код з коментарями (Swift, Kotlin, Flutter або React Native).
• Документацію для команди щодо підтримки accessibility далі.
• Навчання розробників (2–4 години воркшопу).
• Гарантію на виправлення — 6 місяців безкоштовної підтримки регресій.

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