Чому доступність мобільних застосунків ламається під час доопрацювань
Доступність мобільних застосунків ламається не на старті, а на третій-четвертій ітерації. Новий екран додають під конкретну задачу й поспішають: іконку малюють без підпису, перемикач збирають із готових шарів, спливну панель ставлять поверх основного вмісту.
Екранні диктори такі елементи або пропускають, або оголошують безлико — «кнопка», «елемент», і людина не розуміє, що станеться після натискання.
Недоступні елементи керування майже завжди розташовані в одному й тому самому місці: там, де бізнес-логіка вимагає мінімуму дій.
Кастомний слайдер не реагує на жести керування з утриманням, поле з маскою приймає введення лише з екранної клавіатури, іконка кошика на картці товару читається як декоративне зображення.
Для користувача екранних дикторів це не дрібниця, а глухий кут: дія є візуально, але недосяжна на слух і на дотик.
Збитий порядок фокуса помітний лише під час послідовного обходу. Модальне вікно відкривається, але обхід продовжується затемненим вмістом під ним, а після закриття фокус перестрибує на початок екрана — і людина знову шукає, де вона зупинилася.
Варто поміняти блоки місцями під час редизайну, і логіка читання розходиться з візуальною: диктор веде за змістом із попередньої версії, підказка звучить раніше за заголовок.
Збільшений системний шрифт і підвищений контраст добивають сценарій: підписи обрізаються, текст заходить під кнопку, обов'язкові поля не підсвічуються. Покинутий сценарій — ось реальна ціна.
Частка незавершених оформлень зростає, надходить більше звернень «не можу натиснути», а магазин застосунків знижує застосунок у видачі за критеріями доступності. Розбираємо, як це закривається.
Екранні диктори, збільшений шрифт і контраст: що дає доопрацювання
Доопрацювання доступності вимірюється не числом правок у розмітці, а тим, скільки сценаріїв людина проходить самостійно. Нижче — три напрями, і за кожним ми фіксуємо метрику до й після.
Підтримка екранних дикторів
Кожному інтерактивному елементу призначається осмислений опис і роль, а порядок обходу вибудовується за логікою екрана, а не за порядком у розмітці.
Підсумок: частка сценаріїв, які незрячий користувач завершує без сторонньої підказки, зростає з одиниць відсотків до більшості ключових шляхів — вхід, оплата, запис.
Масштабування системного шрифту та висококонтрастний режим
Верстання перестає ламатися при збільшеному шрифті: текст переноситься, кнопки ростуть, нічого не обрізається й не наїжджає одна на одну. Паралельно перевіряється контраст — стан елемента зчитується за яскравістю та формою, а не лише за кольором. Клас відмов «підпис виїхав за межі кнопки» зникає повністю.
Керування перемикачами
Сценарії стають прохідними без точних дотиків: фокус обходить усі елементи, порядок передбачуваний, зовнішні перемикачі та голосове керування доводять дію до кінця. Це знімає ще один пласт відмов — «до елемента не можна дістатися».
Завершальний ефект — зменшення звернень до підтримки: скарги «не бачу кнопку», «шрифт обрізав текст», «не можу натиснути» перестають доходити до першої лінії, а сам продукт при цьому не змінюється.
Варіанти реалізації: правки розмітки проти переробки навігації
Доступність тримається на двох шарах. Перший — семантична розмітка: підписи до елементів, їхні ролі, порядок обходу фокуса, оголошення змін на екрані. Другий — навігація: структура екранів, логіка переходів і повернень. Обсяг робіт залежить від того, який шар просів і на якій стадії продукт.
Правки семантичної розмітки — найкоротший цикл: екрани й сценарії залишаються попередніми, змінюються атрибути й тексти підписів. Переробка навігації зачіпає структуру, тому потребує узгодження з дизайном і повного регресу.
Автоматичні перевірки показують лише частину картини: вони знаходять елементи без підпису та порушений контраст, але не кажуть, чи зрозумілий сценарій на слух, — режими роботи диктора все одно перевіряють руками.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правки семантичної розмітки | Інтерфейс стабільний, екрани зібрані з типових блоків; диктор читає елементи, але збивається на формулюваннях і порядку | Не змінює логіку екранів: заплутаний сценарій розміткою не виправити |
| Переробка навігації | Ключові сценарії проходяться наосліп помітно довше, є пастки фокуса та дублювальні переходи | Зачіпає верстання й код екранів, потрібен регрес за всіма сценаріями |
| Комплексний етап: розмітка, навігація, ручні прогони | Продукт готується до релізу або є вимоги доступності від замовника чи магазину застосунків | Найдовший цикл: аудит, правки, повторні прогони диктором, регрес |
Автоматичні перевірки має сенс включати в конвеєр збірки за будь-якого з варіантів: вони дешеві, ловлять регрес і не дають розмітці «зарости» при нових екранах. Але звіт такої перевірки не можна вважати прийманням — він покриває форму, а не сценарій.
Підсумковий критерій один: людина проходить основний шлях із увімкненим диктором і вкладається в розумний час.
Етапи роботи: аудит, схема обходу екранів, налаштування, перевірка
Доступність не можна перевірити «на око» — її збирають послідовно. Спочатку фіксуємо поточний стан, потім будуємо карту екранів і лише після цього змінюємо розмітку й налаштування. Так правки не розсипаються по релізах і не ламають уже робочі сценарії.
- Аудит доступності. Прогоняємо ключові сценарії з увімкненим екранним диктором, перевіряємо контраст, розміри зон натискання, підписи та реакцію на системне масштабування шрифту. Кожен дефект фіксуємо з прив'язкою до екрана та кроком відтворення.
- Звірка з вимогами WCAG. Вибираємо цільовий рівень і розкладаємо розходження за групами: семантика, навігація, альтернативні тексти, стійкість до збільшеного шрифту та вимкненої анімації.
- Карта екранів і порядок обходу. Описуємо дерево переходів, позначаємо місця, де фокус губиться, зациклюється або заходить у глухий кут після закриття модального вікна.
- Описи елементів. Проставляємо ролі, стани й підписи для кнопок, полів, зображень і динамічних блоків; озвучення змін стану робимо явним.
- Налаштування фокуса. Задаємо пріоритет читання, перехоплення фокуса в модальних вікнах і коректне повернення на елемент-джерело.
- Контрольна перевірка на пристрої. Проходимо ті самі сценарії з диктором, збільшеним шрифтом і зовнішньою клавіатурою, звіряємо результат із картою екранів і закриваємо розходження.
- Передача результату. Віддаємо карту екранів, правила опису елементів і регламент перевірки доступності в релізному циклі — нові екрани одразу робляться за тими самими правилами.
Передаємо на руки: розмітка, описи елементів, регламент
Пакет передаємо разом із вихідним кодом: команда замовника може змінювати інтерфейс далі, не втрачаючи розмітку. Матеріали розраховані на розробника й тестувальника без профільної підготовки з доступності — це не витяги зі стандарту, а робочі вказівки з конкретними значеннями.
- Схема навігації та порядок фокуса. Карта екранів із черговістю обходу диктором: де фокус ставиться вручну, які спливні шари його захоплюють і як повертають назад.
- Описи елементів. Таблиця «компонент → мітка, роль, підказка» на всі повторювані блоки: кнопки, поля, перемикачі, стани завантаження. Окремо — правила для динамічних списків, щоб диктор не перечитував список цілком після кожного оновлення.
- Правила контрасту та масштабування. Порогові співвідношення для тексту й іконок, поведінка при системному збільшенні шрифту до межі, значення для темної теми.
- Регламент перевірки. Що проганяють перед кожним випуском: ручні сценарії з диктором і збільшеним шрифтом плюс автоматичні правила у збірці, які зупиняють її при втраті мітки.
- Інструкція для команди розробки. Куди додати опис і як назвати елемент, щоб він потрапив в обхід; які правки інтерфейсу вимагають оновити таблицю описів.
- Інструкція для тестувальників. Набір сценаріїв з очікуваним порядком озвучення та шаблон звіту про дефект — відтворюваність замість «диктор читає незрозуміло що».
Кейс: що змінилося після переробки навігації та розмітки
Замовник прийшов із проблемою, яка на перший погляд не виглядала технічною: частка завершених сценаріїв оформлення замовлення трималася близько 60%, а до підтримки йшов потік однотипних звернень — «не знаходжу кнопку», «озвучення не читає поле», «не можу повернутися на крок назад».
Відгуки в магазинах застосунків повторювали те саме: інтерфейс працює лише для тих, хто бачить екран і впевнено влучає пальцем у дрібний елемент.
Що показав розбір
Наші інженери пройшли по всіх ключових екранах купівлі, оплати й відстеження доставки з аудитом за Web Content Accessibility Guidelines.
Знайшли три класи дефектів: підписи не пов'язані із самими полями, порядок обходу елементів не збігався з візуальним, а зони натискання були менші за комфортний мінімум. Через це користувач втрачав контекст на середині сценарію і закривав застосунок.
Що змінили
Переробили навігацію та розмітку: в елементів з'явилися коректні імена й ролі, фокус пішов у логічному порядку, зони натискання розширили, іконкам без тексту додали описи.
Окремо переписали повернення й підтвердження замовлення — при згортанні застосунку губилися крок і введені дані.
Що стало
Частка завершених сценаріїв зросла з 61% до 88%, звернення до підтримки щодо навігації впали в 2,4 раза. Частка користувачів із програмою екранного доступу піднялася з 4% до 11% — частина з них раніше просто не доходила до оплати.
У відгуках змістилися формулювання: замість «нічого не зрозуміло» дедалі частіше «все знаходиться з першого разу».
Метрики звіряли за продуктовою аналітикою та вивантаженням звернень за порівнювані періоди, а не за відчуттями команди — джерело даних зафіксовано у звіті за проєктом.
Що робити, якщо доступність не закладена в дизайн спочатку?
Що робити, якщо доступність не закладали в макети: готовий продукт не потрібно переписувати цілком.
Основна частина проблем лежить не у візуальному шарі, а в розмітці — в елементів немає підписів для екранного диктора, в іконок немає альтернативного тексту, фокус обходить екран у випадковому порядку, а стан кнопки не озвучується.
Такі правки не змінюють зовнішній вигляд ні на піксель, тому їх викочують окремим релізом, не чекаючи редизайну.
Далі визначають пріоритет екранів за аналітикою, а не за розташуванням у меню. Першими йдуть вхід, відновлення доступу, ключовий сценарій і оплата — там, де недоступність повністю блокує користувача.
Екран із формою та валідацією важливіший за декоративну стрічку: помилку введення екранний диктор має прочитати вголос, а не мовчки підсвітити червоним.
Поетапне впровадження будують так, щоб кожен крок був самостійним. Правки в семантиці не зачіпають контракти обміну даними й не ламають верстання, тому зворотна сумісність зберігається, а невдалий реліз відкочується без наслідків для решти екранів.
Візуальні зміни — масштабованість шрифту, контраст, розмір зон натискання — ідуть другим етапом, коли невізуальний шар уже закрито і продукт перестав втрачати користувачів на базових діях.
Щоб разові правки не розчинилися в наступних спринтах, вимоги до розмітки переносять у дизайн-систему та в автоматичні перевірки на збірці: нові екрани проходять ті самі правила без ручного контролю.
Через два-три цикли доступність перестає бути окремою задачею і стає властивістю продукту за замовчуванням.
Технічні сумніви: обсяг правок, терміни, риски для релізу
Сумніви щодо доступності зазвичай не про саму технологію, а про те, як правки впишуться в цикл випуску. Нижче — відповіді на часті запитання на старті: обсяг робіт, сумісність зі збіркою, терміни перевірки та риски для найближчого релізу.
Чи доведеться переписувати екрани?
Ні. Основний обсяг — семантична розмітка: підписи елементів, порядок обходу екранним диктором, альтернативні тексти, розмір зон дотику. Логіка й верстання залишаються попередніми, правки локальні й не тягнуть за собою переробку навігації.
Доопрацювання зламають поточний випуск?
Правки йдуть окремою гілкою та вмикаються віддаленим налаштуванням, а не для всіх одразу. Збірку можна випустити в попередньому вигляді, відкрити доступність частині користувачів і розширити охоплення після підтвердження результату. Якщо сплив регрес — налаштування знімається без нової збірки.
Скільки це займає і як перевіряється?
Термін залежить від кількості екранів та їхнього стану: типові списки й форми правляться швидко, налаштовувані графіки та кастомні елементи керування розбираємо окремо. Перший прохід за основними сценаріями займає тижні.
Перевіряємо ручним обходом з екранним диктором на реальних пристроях, контрольним списком за ключовими шляхами й автотестами на контрастність і розмір зон.
Як розподіляються ролі в команді?
Ми ведемо розмітку, перевірку та звіт за екранами, ваша команда узгоджує пріоритет і випускає збірку у своєму циклі. З вашого боку достатньо однієї людини, яка знає продукт і підтверджує сценарії.
Обговоримо задачу та повернемося з оцінкою й планом робіт
Розбір задачі займає одну розмову на 30–40 хвилин: інженер іде за вашими сценаріями — вхід, оплата, оформлення замовлення, підтримка — і позначає, де інтерфейс втрачає користувачів із програмами екранного доступу, збільшеним системним шрифтом або керуванням із зовнішньої клавіатури.
За підсумками ви отримуєте не загальні слова, а карту екранів із пріоритетами та оцінку трудовитрат за кожним блоком.
Щоб розбір був предметним, для старту достатньо надіслати:
- перелік платформ і актуальних гілок ОС, які підтримуєте;
- список ключових сценаріїв і екранів, де користувачі найчастіше відвалюються;
- звіти попередніх перевірок, звернення до підтримки або знімки проблемних місць;
- доступ до тестової збірки або макетів — з обліковим записом і тестовими даними;
- цільовий рівень відповідності настановам з доступності (WCAG) і перелік екранів, які до нього входять;
- терміни, до яких потрібен результат, і хто з вашого боку приймає роботу.
У відповідь надходить оцінка та план: склад робіт за етапами, порядок старту, ролі в команді, точки перевірки й формат звіту про результат. Якщо частина матеріалів під угодою про нерозголошення, підписуємо її до передачі доступів. Опишіть задачу — повернемося з оцінкою та планом робіт.