Ручне тестування мобільних застосунків
Тестування доступності мобільних застосунків
Нативні iOS та Android, React Native і Flutter — на живих пристроях зі скрінрідерами, а не в емуляторі. Стандарт — розділ 11 «Програмне забезпечення» EN 301 549.
Відповідаємо в робочі години
Застосунки названі в законі прямо
Це не «бажано». Чотири документи згадують мобільні застосунки окремим рядком.
European Accessibility Act
Директива (ЄС) 2019/882 діє з 28 червня 2025 року. Охоплює застосунки банків, e-commerce, транспорту, електронних книг і зв’язку.
BFSG · Німеччина
Національна імплементація EAA з тією ж датою. Для німецького ринку це основний документ, за яким питають застосунок.
Постанова КМУ №895
Пункт 7 зобов’язує постачальників універсальних електронних комунікаційних послуг забезпечити доступність і сайтів, і мобільних додатків. Чинна з 15.07.2028.
ДСТУ EN 301 549:2022
Технічний стандарт, на який посилаються і європейські, і українські вимоги. Для застосунків працює розділ 11, не розділ 9.
Розділ 11 — це не той самий чек-лист, що для сайту
Вебсторінку EN 301 549 перевіряє за розділом 9, який посилається на WCAG. Нативний застосунок — за розділом 11 «Програмне забезпечення»: там свої вимоги до імен і ролей елементів, фокуса, жестів і системних налаштувань. Аудит сайту цього не покриває, навіть якщо застосунок показує ті самі дані.
Для застосунків автоматики майже немає
Для вебу автоматика зріла: наш Аудит щодня проходить сайт за 90+ правилами. Для нативних застосунків інструментів такого рівня немає. Accessibility Scanner на Android і Accessibility Inspector у Xcode ловлять базове: відсутні підписи, малі цілі дотику, слабкий контраст. Порядок фокуса, логіку жестів, озвучення станів і поведінку при системному збільшенні шрифту вони не бачать.
Тому все ключове проходиться руками
Тестувальник проходить кожен користувацький шлях на живому пристрої з увімкненим скрінрідером — реєстрацію, оплату, зміну налаштувань. Саме так знаходяться екрани, з яких неможливо вийти, кнопки без імені, модальні вікна, що не забирають фокус, і форми, помилки яких ніхто не озвучує.
Обидві платформи, реальні пристрої
Емулятор не відтворює ані скрінрідер, ані системні налаштування доступності
iOS
Ключові сценарії з VoiceOver на фізичному iPhone: порядок фокуса, жести ротора, підписи й ролі елементів, робота з Dynamic Type і Voice Control, поведінка з Switch Control.
Android
Те саме з TalkBack на пристроях різних поколінь і версій системи: озвучення, порядок обходу, Switch Access, поведінка після зміни розміру шрифту та масштабу екрана.
React Native, Flutter і нативний код
Крос-платформні застосунки тестуємо як нативні — з боку користувача різниці немає. У звіті вказуємо, на якому рівні лежить проблема: у вашому коді, у компоненті фреймворку чи в налаштуваннях збірки.
Що саме перевіряємо
Вісім напрямів, кожен — на обох платформах
Скрінрідер і порядок фокуса
Кожен екран проходимо на слух: чи всі елементи мають імена й ролі, чи логічний порядок обходу, чи не губиться фокус у модальних вікнах і чи є з них вихід.
Цілі дотику й жести
Мінімум 44×44 pt на iOS і 48×48 dp на Android, достатні відступи між сусідніми елементами, альтернатива складним жестам — свайпу, довгому натисканню, перетягуванню.
Масштабування тексту
Dynamic Type на iOS і системний розмір шрифту на Android до найбільших значень: без обрізання, накладання й кнопок, що виїхали за межі екрана.
Контраст і теми
Світла й темна теми, режим високого контрасту, інверсія кольорів, читабельність тексту поверх зображень і відео.
Орієнтація та рух
Робота в портреті й ландшафті без втрати контенту, повага до системного Reduce Motion, відсутність автоматичної анімації, яку не можна зупинити.
Форми та помилки
Підписи полів, підказки, тип клавіатури, озвучення помилок, можливість виправити введене без втрати вже заповненого.
Медіа й таймаути
Субтитри у відео, керування відтворенням, автостарт звуку, а також усі місця, де застосунок обмежує час на дію — код із SMS, сесія, кошик.
Системні налаштування
Чи поважає застосунок те, що людина вже налаштувала в телефоні: жирний текст, зменшену прозорість, відключену анімацію, збільшений курсор, зовнішню клавіатуру.
Що ви отримуєте
- Звіт про знайдені проблеми з прив’язкою до розділу 11 EN 301 549 і до критеріїв WCAG, за критичністю та з оцінкою складності виправлення
- Відеозаписи екрана з увімкненим скрінрідером — видно й чути, що саме ламається, тож розробнику не треба відтворювати баг наосліп
- План дій із пріоритетами: що виправити до релізу, що в наступному спринті, що вимагає зміни архітектури навігації
- Повторна перевірка критичних проблем після ваших виправлень
Вартість
Рахуємо за брифом
Ціна залежить від кількості екранів, платформ і того, чи потрібні сесії з реальними користувачами. Надішліть застосунок або опишіть його — повернемось із розрахунком і термінами.
Надіслати брифПотрібен ще й сайт? Ручне тестування вебсайтів
Часті запитання
Чи можна протестувати застосунок автоматично, як сайт?
Частково. Accessibility Scanner на Android і Accessibility Inspector у Xcode знаходять відсутні підписи, малі цілі дотику й слабкий контраст. Але для нативних застосунків немає нічого рівня вебових сканерів: порядок фокуса, логіку жестів, озвучення станів і поведінку при збільшеному шрифті доводиться проходити руками на пристрої.
Чи підходить це для React Native і Flutter?
Так. З боку користувача різниці немає — скрінрідер працює з тим, що віддає платформа. У звіті ми окремо вказуємо, де лежить причина: у вашому коді, у компоненті фреймворку чи в налаштуваннях збірки, бо виправлення в цих випадках різні.
Який стандарт застосовується до застосунків?
EN 301 549, розділ 11 «Програмне забезпечення». Це важливо: вебсторінки перевіряють за розділом 9, який посилається на WCAG, а застосунки — за розділом 11 із власними вимогами до імен, ролей, фокуса й системних налаштувань. Аудит сайту не покриває застосунок, навіть якщо в них однакові дані.
На яких пристроях ви тестуєте?
На фізичних. Емулятор не відтворює ані скрінрідер, ані системні налаштування доступності, ані реальні жести. Беремо кілька поколінь пристроїв і версій системи, бо поведінка TalkBack і VoiceOver між версіями відрізняється.
Чи потрібен нам ще й аудит сайту?
Якщо у вас є і сайт, і застосунок — так, це дві окремі перевірки за різними розділами стандарту. Сайт закриває автоматичний Аудит плюс ручне тестування; застосунок — тільки ручне. Замовляти їх одночасно дешевше, ніж окремо, бо частина підготовки спільна.
Розкажіть про застосунок
Повернемось у робочі години з розрахунком, термінами й переліком того, що перевіримо.
Надіслати брифБриф → пропозиція з термінами і вартістю