Доступність — це не про комплаєнс, а про архітектуру: чому більшість команд неправильно розуміють інклюзивний дизайн

Ми поговорили з Богданом Марчуком — старшим iOS-інженером з понад 12-річним досвідом у корпоративній мобільній розробці та колишнім CTO компанії Boring Owl у Варшаві. Він є Council Member AITEX та Fellow Hackathon Raptors, автором книги про створення глобальних мобільних застосунків, а метрику ефективності screen reader, про яку йдеться нижче, опублікував як рецензоване дослідження.

— Богдане, ви стверджуєте, що застосунок може пройти будь-який аудит на доступність і при цьому залишатися неможливим у використанні зі screen reader. Як так виходить?

— Аудит перевіряє це, але не показує, скільки дій потрібно виконати, щоб підтвердити платіж, і в якому порядку екран буде озвучено. Я бачив застосунки з формальною відповідністю WCAG, де підтвердження грошового переказу вимагало двадцяти з лишком свайпів, бо фокус переходив за порядком верстки, а не за логікою завдання.

— Більшість інженерів думають про доступність як про підписи та контраст, які додають наприкінці. Чому це помилково?

— Тому що порядок фокуса визначається на етапі проєктування компонентів, а не на фінальній перевірці. Я працював над iOS-застосунком для підключеного очищувача повітря — IoT-пристрою, яким люди керують з телефону. Там потрібно було забезпечити повну відповідність WCAG 2.1 AA для користувачів із порушеннями зору й надати їм можливість керувати самим пристроєм, а не лише переглядати його статус. Інтерфейс відображав стан пристрою в реальному часі: не набір статичних екранів, а живий потік даних із фільтра. Коли відбувається критична зміна, скажімо, змінюється рівень фільтрації або обривається з'єднання, застосунок чітко пояснює, що користувачеві робити далі. І це стосується не лише доступності. Я написав книгу про створення застосунків для глобальних ринків, і там діє те саме правило: підтримка нових мов чи платіжних систем має бути закладена з першого дня — додати її наприкінці не вийде.

— Ви не лише самі будуєте такі системи — компанії також запрошують вас ззовні, щоб провести аудит їхніх продуктів і оцінити інженерну роботу на міжнародних самітах. Що бачить незалежний рецензент, чого не бачить сама команда?

— Дистанцію. Коли ти сам створив продукт, ти перестаєш його бачити — орієнтуєшся за пам'яттю. Я провів понад тридцять незалежних архітектурних аудитів — мене запрошували оцінювати такі продукти, як караоке-застосунок iSing та платформа SAO Life — а також був суддею з інженерної роботи на AITEX Summit. У зовнішнього рецензента немає пам'яті про дорожню карту й прив'язаності до старих рішень, тож ти зустрічаєш продукт так само, як новий користувач. Саме там і живуть проблеми з доступністю — команда вже давно перестала зустрічатися зі своїм власним продуктом.

— І як часто проблема, з якої ми почали — відповідність на папері, виснажливість на практиці — чекає на вас під час таких перевірок?

— Майже щоразу. Команда пройшла аудит на відповідність, випустила продукт — і ніхто жодного разу не увімкнув screen reader і не пройшов реальний флоу. Це видно за порядком фокуса вже за перші кілька хвилин. Застосунок був побудований для ока, а не для вуха.

Методологія Focus-Step Budget

— Ви навіть дали цьому явищу числовий вираз — "бюджет фокус-кроків". Звідки це взялося і чому саме "бюджет"?

— WCAG вимагає, щоб екран був керованим, але не визначає, скільки навігаційних кроків має займати підтвердження платежу. А бюджет — це конкретне число: для підтвердження транзакції я встановив стелю у дванадцять фокус-кроків. З цим числом інженер проєктує екран наперед, замість того, щоб виявляти недоліки постфактум.

— Чому саме дванадцять? І чи реальні користувачі справді вкладалися в це число?

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

— А що як білд провалиться через це — екран вийде за межі бюджету, CI зламається? Як це працюватиме?

Бюджет прописаний як перевірка в пайплайні: якщо екран перевищує ліміт, мердж блокується — так само, як при непройденому unit-тесті. Без цього доступність поступово деградує з кожним релізом: дизайнер додав елемент, розробник переставив блок — про screen reader ніхто не подумав, бо формально нічого не "зламалося". Коли перевірка вбудована в CI, доступність стає контрольною точкою, про яку неможливо забути.

Коли інтерфейс — рухома ціль

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

— У типовому застосунку екран змінюється у відповідь на дію користувача — він торкнувся, екран оновився, це передбачувана послідовність. Тут стан може змінюватися сам собою: пристрій перемикає режими фільтрації, втрачає з'єднання Wi-Fi, фільтр потребує заміни — асинхронно, без участі користувача. Якщо просто озвучувати кожну зміну через screen reader, користувача завалить потоком сповіщень. Рішенням стала ієрархія: одні зміни критичні й переривають поточну дію на пристрої, тоді як інші, менш значущі зміни застосунок повідомляє, не перериваючи фокус.

— Майже ніхто не робить реальну доступність для підключених пристроїв. Чому так і чого це коштувало вам?

— Категорія відстає, бо такі застосунки проєктуються як візуальні дашборди — графіки, індикатори, кольори статусу тощо. Перевести це в лінійний досвід для screen reader — окреме завдання, яке не випливає автоматично з дизайну. Для нашої команди це означало переробку моделі стану: замість проєктування простого інтерфейсу нам довелося визначити порядок і пріоритетність озвучування сповіщень. Звісно, це зайняло більше часу, ніж стандартна розмітка.

Юридичний вимір доступності сьогодні

— Закон лише щойно наздогнав таку практику — вимоги ADA щодо мобільної доступності набули чинності у 2024 році, European Accessibility Act — у 2025-му. Чи стала доступність тепер однозначно обов'язковою вимогою, а бюджетування — інструментом відповідності?

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

— Ваша публікація зазначає, що метод дав змогу скоротити шлях приблизно до двадцяти кроків, а не дванадцяти, до яких ви прагнули. То він взагалі працює?

— Працює в тому сенсі, що дає вимірюване покращення й переводить доступність у категорію інженерного контролю. Не працює як остаточне рішення — розрив між двадцятьма й дванадцятьма кроками реальний, і одним патерном його не закрити. Далі потрібна робота над тим, як сама модель структурована для послідовного, а не просторового сприйняття. Це наступний етап — методологія робоча, але ще не фінальна.Удар по Вінницькій області — РФ атакувала Нову пошту — Фокус