Де роблять помилки девелопери: як побудувати інклюзивну дизайн-систему за стандартами Мінцифри

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Ми звикли пишатися темпами української цифровізації, і для цього є всі підстави. Проте окрім передових застосунків є десятки вебсайтів обласних адміністрацій, міськрад та держпідприємств, які розроблялися 10-15 років без урахування сучасних нормативів і тому можуть бути незручними для користувачів. Особливо, коли йдеться про людей із порушеннями зору, слуху чи моторики, для яких інтернет—ресурси часто є єдиним способом зв’язку з державою.

Мене звати Катерина Зайко, я Experience Design Manager в EPAM Україна. Окрім роботи на комерційних проєктах, ми приділяємо час технологічному волонтерству — розробці важливих рішень для держави та громадського сектору pro bono. У цій колонці я поділюся досвідом нашої волонтерської команди, яка розробляла платформи для обласних адміністрацій, міськрад і державних лікарень. Це будуть орієнтири, як впроваджувати вебдоступність та побудувати ергономічну дизайн—систему сайтів.

Від «жовто-чорних» версій до універсального дизайну

Сама тема цифрової доступності (accessibility) існує вже понад тридцять років. У США діє закон ADA (Americans with Disabilities Act), на основі якого комерційні бренди регулярно отримують позови на мільйони доларів за неадаптовані інтерфейси. В Євросоюзі, окрім профільної Директиви для публічного сектору, з 2025 року стає обов’язковим European Accessibility Act (EAA). Цей закон робить жорсткі вимоги до інклюзивності сайтів безальтернативними для всього приватного бізнесу — від онлайн-ритейлу до банківського сектору.

В Україні цей процес довго розвивався суто в комерційному секторі, а для державних органів став обов’язковим із появою «Дії» та ухваленням наказу Мінцифри № 52. Цей документ повністю гармонізував наші вимоги з європейським стандартом EN 301 549 та міжнародними правилами WCAG 2.1 на рівні AA.

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

Створюючи єдиний дизайн-код, ми спиралися на базові UX-евристики Нільсена — це 10 універсальних правил для проектування інтерфейсів. Якщо дизайнер їх дотримується, інтерфейс стає інтуїтивно зрозумілим, логічним і не викликає у людини стресу. Ми зробили ставку на «узгодженість стандартів» та «впізнавання замість згадування». Коли людина вже користувалася застосунком «Дія», а потім заходить на сайт ОВА чи лікарні й бачить знайомі патерни навігації, розміри кнопок та структуру — її рівень стресу знижується до мінімуму. Їй не потрібно щоразу заново вчитися взаємодіяти з державою.

Менше шаблонів — легше сприйняття

Робота нашої волонтерської команди з регіональними сайтами розпочалася з Одеської ОВА в 2024-му. Над проєктом працювало 6 фахівців: розробники, бізнес-аналітики, дизайнер та проєктний менеджер. Дизайн ми створили швидко, але сама розробка, інтеграція та наповнення контентом тривали майже рік.

Проєктування державного продукту завжди починається з етапу Discovery, де ми аналізуємо наявний контент та будуємо нову інформаційну архітектуру. У таких проєктах дизайн та дослідження займають близько 20–30% усього часу.

Головне завдання дизайнера тут — створити мінімальну кількість шаблонів. Що менше різнопланових сторінок бачить користувач — то менш когнітивне навантаження він відчуває. Йому н легше орієнтуватися. Ми проаналізували тисячі старих статей ОВА, прибрали дублікати й розробили всього 7 універсальних шаблонів для організації контенту (текстові сторінки, картки, контакти тощо).

Але коли ми передали готову платформу замовникам, у гру вступив людський фактор. У штаті ОВА немає UX-дизайнерів. Наповненням сайтів займаються люди, яких призначили відповідальними — наприклад, прессекретарі чи системні адміністратори. Був випадок, коли такий співробітник почав використовувати шаблони не за призначенням, міняти відступи, завантажувати неконтрастні зображення. Це моментально зламало доступність сайту в тих розділах, куди ми фізично не мали доступу.

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

«Прибрали помилки і отримали нагороду»

Наступним проєктом стало Закарпаття. По суті, ми взяли базову модель Одеси, але провели глибоку роботу над помилками. Ми доопрацювали технічне ядро, налаштували роботу з асистивними технологіями, вичистили баги. Як результат — саме сайт Закарпатської ОВА отримав державну нагороду за доступність. Дослідження від Мінцифри охопило 100 вебсайтів органів державної влади та проводилося протягом останнього кварталу 2025 року. Фахівці оцінювали, наскільки зручно громадянам, зокрема людям із порушеннями зору чи слуху, користуватися електронними послугами.

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

Основні помилки на сайтах: досвід нашого аудиту

Коли ми здавали свої проєкти на верифікацію в Мінцифру, ми звірялися з внутрішнім чек—листом на 10 пунктів (який базується на рекомендаціях ПРООН та WCAG). Якщо проаналізувати більшість українських сайтів через призму цього чек—листа, стає зрозуміло, де найчастіше помиляються девелопери.

По-перше, це керування з клавіатури. Будь—яку дію на сайті користувач має виконувати без мишки — лише клавішами Tab, Enter та пробілом. Найчастіша помилка — коли розробники не налаштовують логіку переходу і створюють «клавіатурні капкани». Це ситуація, коли користувач за допомогою Tab може відкрити якесь вікно чи календар, але вже не може вийти з нього чи закрити без мишки.

По-друге — відключення рамки фокусу. Часто грішать тим, що прописують в CSS outline: none для кнопок та посилань, бо стандартна обводка «псує естетику». Але для людини, яка не користується мишкою, ця рамка — єдиний спосіб зрозуміти, де саме на сторінці вона зараз перебуває.

По-третє — відсутність швидкого обходу («Skip to content»). Коли людина з вадами зору відкриває нову сторінку, її скрінрідер (програма, яка озвучує екран) починає знову й знову зачитувати все верхнє меню сайту. Щоб цього уникнути, у самому верху коду має бути приховане посилання «Перейти до основного вмісту», яке активується першим натисканням Tab і дозволяє одразу перестрибнути шапку сайту.

Також критичними є банальні помилки верстки: відсутність тегу мови документа (<html lang="uk«>), через що скрінрідери починають читати українські слова з жахливим англійським акцентом, непідписані графічні кнопки (коли іконка пошуку зчитується просто як слово «кнопка», без опису дії) та неінформативні посилання на кшталт «детальніше» чи «читати тут».

«Дія—лайт» для Полтави та межі свободи

Коли ми почали працювати з міськими радами (зокрема, з Полтавою), то зіткнулися з іншим викликом. Офіційні вимоги Мінцифри щодо інклюзивності обов’язкові для ОВА, але для міських рад на той момент вони мали скоріше рекомендаційний характер.

Представники міських рад не хотіли бачити на своїх ресурсах гігантські кнопки та строгі шаблони «Дії». Вони просили зробити інтерфейс більш сучасним, легким та кастомізованим. Ми називали це для себе «Дія—лайт».

Нам доводилося йти на компроміси, дещо зменшувати розміри окремих елементів та міняти відступи за запитом клієнта (хоча це формально відхилялося від еталонного державного гайдлайну), але ми тримали оборону в базових речах:

• Логічна архітектура та наочна навигація.

• Контрастність кольорів (стандартні 4.5:1 для звичайного тексту).

• Чітка ієрархія заголовків (H1, H2, H3).

Окрім сайтів для обласних адміністрацій та міських рад, ми також працювали над вебплатформами для медичних установ — зокрема для дитячої лікарні «Охматдит» та Львівської університетської лікарні.

Для цих проєктів ми частково перевикористали той самий підхід та дизайн—систему на основі гайдлайнів «Дії». Проте медична сфера має свою специфіку контенту, тому ми розробили нові, полегшені шаблони. Ми адаптували інтерфейси під потреби пацієнтів, але зберегли базові вимоги до інклюзивності, які використовувалися для міськрад. Користувачі могли швидко знаходити інформацію про відділення чи послуги лікарні.

Чому інклюзивність вигідна всім?

У сучасному UX-дизайні діє просте правило: рішення, створені з дотриманням принципів цифрової доступності для людей з порушенням зору, у підсумку покращують користувацький досвід абсолютно для всіх.

Чітка ієрархія заголовків та семантична розмітка HTML роблять сайт доступним для скрінрідерів, але водночас покращують пошукову оптимізацію (SEO). Google любить сайти з чистою структурою. Контрастні кольори допомагають людям із порушенням зору, але водночас роблять ваш продукт зручним для читання на дешевих моніторах чи на вулиці під сонцем. Текстові альтернативи для зображень (alt—тексти) допомагають незрячим, але також рятують користувачів при поганому мобільному інтернеті, коли картинки просто не завантажуються.

Інклюзивність — це не тільки про виконання нормативів держави. Це про якість коду та повагу до свого користувача.

У багатьох командах тему accessibility згадують наприкінці проєкту як необов’язкову фічу. Але розуміння інклюзивного дизайну та стандартів доступності є базовою гігієною для кожного спеціаліста, починаючи з рівня Junior. Це світовий стандарт розробки, який ми за замовчуванням закладаємо в кожен архітектурний макет.