Посібники

Доступність застосунку: розділ 11 EN 301 549

Чому аудит сайту не покриває мобільний застосунок, що перевіряють на живих iPhone і Android зі скрінрідерами та які закони вимагають цього вже зараз.

Андрій Вдовин

18 вересня 2026 р.

10 хв читання

Коротко

Застосунок перевіряється за розділом 11 EN 301 549, а не за розділом 9, яким перевіряють сайт.
Аналога axe-core для нативних застосунків не існує — ключове проходиться руками.
Емулятор не відтворює ані скрінрідер, ані системні налаштування доступності.
EAA, BFSG і постанова КМУ № 895 згадують мобільні застосунки окремим рядком.

Чому застосунок не можна перевірити як сайт

Компанія замовляє аудит доступності, отримує звіт по сайту, виправляє все й вважає питання закритим. Через півроку з’ясовується, що 70% звернень до підтримки приходять із застосунку, і саме там незряча людина не може завершити оплату. Формально претензій до аудиту немає: перевіряли сайт — сайт і перевірили.

Розділення закладене в сам стандарт. EN 301 549 — той самий, на який посилаються і європейські вимоги, і ДСТУ — перевіряє вебсторінку за розділом 9, який просто відсилає до WCAG. Нативний застосунок перевіряється за розділом 11 «Програмне забезпечення», і там власний набір вимог: імена, ролі й стани елементів, керування фокусом, альтернативи жестам, повага до налаштувань платформи.

Тому речення «наш сайт відповідає WCAG 2.1 AA» не говорить нічого про застосунок, навіть якщо застосунок показує рівно ті самі дані з рівно того самого API.

Автоматики тут майже немає

Для вебу є axe-core: понад 90 правил, які можна ганяти на кожному деплої. Він не покриває всього — стеля будь-якої автоматичної перевірки оцінюється приблизно в половину порушень, — але цей фундамент існує і він безкоштовний.

Для нативних застосунків такого фундаменту немає. Є два офіційні інструменти, і обидва свідомо скромні.

Інструмент	Знаходить	Не знаходить
Accessibility Scanner Android, Google	Елементи без підпису, замалі цілі дотику, слабкий контраст, дубльовані описи. Працює просто на екрані, без доступу до коду.	Порядок обходу, пастки фокуса, озвучення зміни стану, логіку жестів.
Accessibility Inspector iOS, у складі Xcode	Дерево доступності екрана, імена й ролі елементів, аудит базових проблем на запущеному застосунку.	Те саме: усе, що вимагає пройти сценарій і послухати результат.
Тести в CI Espresso, XCTest	Регресії: якщо підпис у кнопки колись був і зник, тест це зловить.	Нічого нового — перевіряє лише те, що ви явно описали заздалегідь.

Емулятор дає хибне відчуття перевіреності

В емуляторі не працюють ані жести ротора VoiceOver, ані свайпи TalkBack, ані більшість системних налаштувань доступності. Поведінка скрінрідерів до того ж відрізняється між версіями систем: те, що озвучується коректно на свіжій iOS, може мовчати на пристрої трирічної давнини. Висновок робиться лише на живих пристроях кількох поколінь.

Вісім напрямів перевірки

Це той перелік, за яким проходить ручне тестування — і водночас чекліст, за яким ваша команда може перевірити застосунок сама перед тим, як щось замовляти.

Скрінрідер і порядок фокуса

Кожен екран проходиться на слух: чи всі елементи мають ім’я й роль, чи логічний порядок обходу, чи не губиться фокус у модальних вікнах і чи є з них вихід. Найчастіша знахідка — екран, з якого неможливо піти назад свайпом.

Цілі дотику й жести

Мінімум 44×44 pt на iOS і 48×48 dp на Android, достатні відступи між сусідніми елементами. Складний жест — свайп, довге натискання, перетягування — повинен мати простішу альтернативу.

Масштабування тексту

Dynamic Type на iOS і системний розмір шрифту на Android виводяться на найбільші значення. Шукаємо обрізання, накладання й кнопки, що виїхали за межі екрана. Це найшвидший спосіб знайти жорстко задані висоти.

Контраст і теми

Світла й темна теми, режим високого контрасту, інверсія кольорів, читабельність тексту поверх зображень і відео. Темна тема, додана в останній момент, зазвичай дає найбільше провалів контрасту.

Орієнтація та рух

Робота в портреті й ландшафті без втрати контенту, повага до системного Reduce Motion, відсутність анімації, яку не можна зупинити.

Форми та помилки

Підписи полів, підказки, доречний тип клавіатури, озвучення помилок і можливість виправити введене, не втративши вже заповнене.

Медіа й таймаути

Субтитри у відео, керування відтворенням, автостарт звуку, а також усі місця, де застосунок обмежує час на дію: код із SMS, сесія, кошик.

Системні налаштування

Чи поважає застосунок те, що людина вже налаштувала в телефоні: жирний текст, зменшену прозорість, вимкнену анімацію, збільшений курсор, зовнішню клавіатуру.

Що зробити самим за один вечір

Перед тим як замовляти аудит, корисно подивитися на масштаб. Ці чотири прогони не вимагають ані бюджету, ані спеціальних знань — лише телефон і трохи терпіння.

1Пройдіть головний сценарій із заплющеними очима. Увімкніть VoiceOver або TalkBack і виконайте те, заради чого застосунок узагалі встановлюють: замовлення, оплату, реєстрацію. Не підглядайте. Місце, де ви зупинилися, — перший пункт майбутнього звіту.
2Виведіть шрифт на максимум. Налаштування системи, найбільший розмір тексту. Пройдіть ті самі екрани. Обрізаний текст і кнопки, що зникли за межами екрана, видно одразу.
3Увімкніть темну тему й високий контраст. Особливо на екранах із текстом поверх фотографій і на всьому, що додавалося останнім.
4Прогоніть офіційний сканер. Accessibility Scanner на Android або Accessibility Inspector на iOS. Він дасть базовий список, з якого видно, наскільки системна проблема: три елементи без підпису чи триста.

React Native, Flutter і нативний код

Крос-платформні застосунки тестуються як нативні: з боку користувача різниці немає, бо скрінрідер працює з деревом доступності, яке віддає платформа. Різниця з’являється тоді, коли треба виправляти.

У React Native доступність описується властивостями компонентів — підпис, роль, стан. У Flutter той самий шар будується віджетами семантики. І там, і там типова проблема одна: готовий компонент з бібліотеки виглядає як кнопка, але для системи лишається просто областю, яку можна торкнутися. Тому у звіті завжди вказується, на якому рівні лежить причина — у вашому коді, у компоненті фреймворку чи в налаштуваннях збірки. Вартість виправлення в цих трьох випадках відрізняється в рази.

Що вимагає закон

Мобільні застосунки не «бажано зробити зручнішими» — вони названі в нормативних документах окремим рядком.

European Accessibility Act

Директива (ЄС) 2019/882 діє з 28 червня 2025 року. Охоплює застосунки банків, e-commerce, транспорту, електронних книг і зв’язку.

BFSG · Німеччина

Національна імплементація EAA з тією ж датою. Для німецького ринку це основний документ, за яким питають про застосунок.

Постанова КМУ № 895

Пункт 7 зобов’язує постачальників універсальних електронних комунікаційних послуг забезпечити доступність і сайтів, і мобільних додатків. Чинна з 15 липня 2028 року.

ДСТУ EN 301 549:2022

Технічний стандарт, на який посилаються і європейські, і українські вимоги. Для застосунків працює розділ 11, не розділ 9.

Якщо потрібен погляд ззовні

Ми проходимо ключові сценарії на живих iPhone і Android зі скрінрідерами й повертаємо звіт із прив’язкою до розділу 11 EN 301 549, відеозаписи екрана з озвученням і план дій за пріоритетами. Якщо у вас є і сайт, і застосунок — це дві окремі перевірки за різними розділами стандарту.

Тестування застосунків Ручне тестування сайту

Часті запитання

Чи можна протестувати мобільний застосунок автоматично, як сайт?

Лише частково. Accessibility Scanner на Android і Accessibility Inspector у Xcode знаходять відсутні підписи елементів, замалі цілі дотику й слабкий контраст. Але для нативних застосунків немає нічого рівня axe-core: порядок фокуса, логіку жестів, озвучення станів і поведінку при збільшеному системному шрифті доводиться проходити руками на живому пристрої.

Аудит сайту покриває мобільний застосунок?

Ні. EN 301 549 перевіряє вебсторінку за розділом 9, який посилається на WCAG, а нативний застосунок — за розділом 11 «Програмне забезпечення». Там власні вимоги до імен і ролей елементів, фокуса, жестів і поваги до системних налаштувань. Це дві окремі перевірки, навіть якщо сайт і застосунок показують ті самі дані.

Чи підходить таке тестування для React Native і Flutter?

Так. З боку користувача різниці немає — скрінрідер працює з тим деревом доступності, яке віддає платформа. Відрізняється лише те, де лежить причина проблеми: у вашому коді, у компоненті фреймворку чи в налаштуваннях збірки. Це важливо фіксувати у звіті, бо виправлення в цих трьох випадках різні за вартістю.

Чи можна тестувати доступність в емуляторі?

Для чернеткової перевірки розмітки — так. Для висновку — ні. Емулятор не відтворює реальну поведінку VoiceOver і TalkBack, жести ротора й свайпи, системні налаштування доступності та зовнішні пристрої введення. Крім того, поведінка скрінрідерів помітно відрізняється між версіями систем, тому беруть кілька поколінь пристроїв.

Які закони вимагають доступності мобільних застосунків?

European Accessibility Act — Директива (ЄС) 2019/882 — діє з 28 червня 2025 року й охоплює застосунки банків, e-commerce, транспорту, електронних книг і зв’язку. У Німеччині це BFSG з тією ж датою. В Україні постанова КМУ № 895 від 8 липня 2026 року прямо називає мобільні додатки поряд із вебсайтами для постачальників універсальних електронних комунікаційних послуг, чинність — з 15 липня 2028 року. Технічний стандарт у всіх випадках один: EN 301 549, для застосунків — розділ 11.

Джерела та посилання

Останнє оновлення: 19.09.2026