Оновлено: .

Базова доступність не має вимагати ввімкнення спеціального режиму. Людина повинна мати змогу знайти інформацію, зрозуміти її та виконати дію у звичайному інтерфейсі. Особисті налаштування корисні, коли розширюють цю можливість, а не маскують її відсутність.

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

Зручний для мене — ще не доступний

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

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

Три шари, які не можна підміняти один одним

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

Це наша робоча модель проєктування, а не нова класифікація WCAG. Її зміст простий: перемикач теми не виправляє кнопку, яку неможливо натиснути з клавіатури. І навпаки, правильно реалізована кнопка не скасовує користі особистих налаштувань.

Основа: зміст, керування, зворотний зв’язок. Сумісність: браузер і допоміжні технології. Налаштування: особистий комфорт.
Три шари доступного UI. Персоналізація доповнює основу, а не замінює її.

Що не так із «версією для людей зі слабким зором»

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

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

Не варто й видавати цю позицію за буквальну заборону WCAG на альтернативні подання. Стандарт описує умови для альтернативних версій, що відповідають його вимогам. Це суворіше поняття, ніж наявність кнопки зміни теми: потрібно перевірити еквівалентність інформації, функціональності та доступність переходу.

Чотири міфи, які заважають покращувати продукт

  • «Додамо віджет — отримаємо доступність». Спершу перевірмо, що змінилося в реальних сценаріях. Колірний фільтр сам собою не пояснює причину помилки форми й не задає змістовного імені кнопці.
  • «Потрібен лише хороший контраст». Читабельний підпис не рятує керування, доступне тільки мишею.
  • «Що більше ARIA, то краще». Неправильна роль може приховати початковий зміст елемента. Краще коректний HTML із необхідними, а не максимальними доповненнями.
  • «Автотест зелений — роботу завершено». Автоматизація перевіряє частину умов. Вона не замінює проходження сценарію людиною.

Останні два обмеження безпосередньо розглядають ARIA Authoring Practices і настанова WAI щодо інструментів перевірки.

WCAG — справді офіційний стандарт?

WCAG випускає W3C. Статус W3C Recommendation означає зрілу специфікацію, рекомендовану як вебстандарт. WCAG 2.2 також прийнято як ISO/IEC 40500:2025; W3C повідомив про це 21 жовтня 2025 року. Це не просто порада окремого блогера чи виробника скринридера.

Однак стандарт і закон — різні речі. Застосовна версія, рівень відповідності, коло організацій і строки визначаються конкретною юрисдикцією, договором або процедурою закупівлі. Не можна універсально стверджувати, що «всім сайтам за законом потрібен WCAG 2.2 AA».

Для нової розробки доцільно зафіксувати WCAG 2.2 AA як інженерну ціль, якщо вимоги проєкту не визначають іншого. AA охоплює застосовні критерії A та AA; це не середня оцінка і не відсоток успішних перевірок. Водночас відповідність стандарту не означає задоволення абсолютно всіх індивідуальних потреб.

Як перетворити принцип на робоче рішення

Для кожної ключової дії записуйте чотири речі: що людина хоче зробити; який бар’єр заважає; що змінюємо; як перевіряємо результат. Наприклад: «Вибрати дату → календар працює тільки мишею → додати керування клавіатурою та зрозуміле введення дати → пройти запис без миші й перевірити оголошення вибраного дня».

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

Скіл для Codex і Claude Code

За результатами дослідження ми створили відкриті скіли для Codex і Claude Code, які допомагають аналізувати й покращувати сайти та застосунки. Accessible UI спрямовує агента під час перевірки семантики, керування клавіатурою, фокуса, форм і контрасту; Adaptive Interfaces допомагає адаптувати інтерфейс до розмірів вікна, масштабу тексту, клавіатури та складаних пристроїв. Агент вивчає поточний проєкт, пропонує обґрунтовані покращення та перевіряє погоджені зміни. Скіли не замінюють перевірку з користувачами й допоміжними технологіями.

Якщо ви розробляєте інтерфейси з ШІ, можна встановити скіл Accessible UI із GitHub. У ньому зібрано практичні правила цієї серії: семантика, клавіатура, фокус, форми, контраст і перевірка результату. Інструкції написані англійською.

Встановлення з GitHub: у Codex передайте цю команду вбудованому інсталятору скілів:

$skill-installer install https://github.com/wladislaw353/agent-skills/tree/main/skills/accessible-ui

У Claude Code всю колекцію можна встановити як плагін із цього самого репозиторію. Інструкція для Claude Code на GitHub містить команди встановлення, оновлення й виклику кожного скіла. Для плагіна використовується назва на кшталт /agent-skills:accessible-ui; для окремого встановленого скіла — /accessible-ui.

Для ручного встановлення склонуйте репозиторій із GitHub. Вміст папки skills/accessible-ui розмістіть у каталозі вибраного інструмента:

  • Codex: ~/.agents/skills/accessible-ui/
  • Claude Code: ~/.claude/skills/accessible-ui/

Файл SKILL.md має бути безпосередньо всередині accessible-ui. Після встановлення відкрийте нову сесію. Для явного виклику використовуйте $accessible-ui у Codex CLI або розширенні для IDE чи /accessible-ui у Claude Code.

Джерела та статус стандартів перевірено 5 листопада 2026 року.