Оновлено: .

HTML повідомляє браузеру та допоміжним технологіям, що є на сторінці і як із цим взаємодіяти. Спочатку вибирайте елемент із потрібною поведінкою. Потім забезпечуйте зрозумілі імена, видимий фокус і стійке компонування.

Кнопку й посилання визначає дія

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

<!-- Перехід до розділу цієї статті -->
<a href="#focus">Перейти до перевірки фокуса</a>

<!-- Дія без надсилання форми -->
<button type="button">Відкрити фільтри</button>

<!-- Надсилання форми -->
<button type="submit">Надіслати заявку</button>

Div з обробником click не отримує автоматично ані ролі кнопки, ані місця в послідовності Tab, ані очікуваної активації клавішами. Додати role="button" недостатньо: поведінку доведеться реалізувати окремо. Нативний button знімає значну частину цієї роботи.

Семантика допомагає орієнтуватися

Використовуйте main для основного вмісту, nav для навігаційного блоку, заголовки — для структури документа. Не перетворюйте кожну групу посилань на окрему навігаційну область. Коли областей кілька, давайте їм відмінні імена: «Основна навігація», «Розділи статті».

Nav має неявну роль navigation. Тому запис <nav role="navigation"> зазвичай надлишковий. Подібна роль у div не робить усі HTML-елементи взаємозамінними: нативну семантику простіше підтримувати, і вона менше залежить від ручних доповнень.

ARIA доповнює інтерфейс, але не виправляє його автоматично

Видимий текст кнопки зазвичай уже формує її доступне ім’я. Для кнопки з однією іконкою ім’я потрібно задати; для поля краще використати пов’язаний label. Не замінюйте зрозумілий видимий підпис зовсім іншим aria-label: людині, яка користується голосовим керуванням, буде складно звернутися до елемента за написом на екрані.

aria-expanded повідомляє стан розкриття; він має відповідати фактичному стану. aria-hidden="true" вилучає вміст із дерева доступності, але не робить його автоматично невидимим і не вилучає з клавіатурної послідовності. Не ставте цей атрибут на елемент керування, здатний отримати фокус, або його предка.

Фокус має бути видимим і передбачуваним

Прибирати outline «тому що не вписується в дизайн» — погана відправна точка. Спочатку спроєктуйте добре помітний індикатор фокуса, потім перевірте його на всіх фонах. Box-shadow не є універсальною заміною: у режимі примусових кольорів тінь може зникнути. Зберігайте працездатний outline.

/* Приклад для перевіреної світлої поверхні */
.action:focus-visible {
  outline: 3px solid #1239a6;
  outline-offset: 3px;
}
@media (forced-colors: active) {
  .action:focus-visible {
    outline-color: Highlight;
  }
}

:focus-visible не означає «тільки Tab». Браузер вирішує, чи потрібен видимий фокус, за евристиками; наприклад, текстове поле може зберігати його і після кліку. Hover не замінює фокус: ці стани виконують різні завдання.

Перевірте закріплену шапку, cookie-банер і спливні панелі. WCAG 2.4.11 AA вимагає, щоб авторський вміст не приховував сфокусований компонент повністю. Зручніша проєктна ціль — бачити весь елемент і його індикатор.

Tab — лише частина навігації

Пройдіть основні сценарії клавіатурою: Tab і Shift+Tab переміщують фокус, Enter активує посилання та кнопки, Space — кнопки; усередині складених компонентів потрібні відповідні патерну клавіші. Не змушуйте Tab відвідувати кожен пункт списку, якщо патерн передбачає керування стрілками.

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

Збільшення: 150% недостатньо

Для 1.4.4 текст має збільшуватися до 200% без втрати вмісту та функціональності, із зазначеними в критерії винятками. Окремо 1.4.10 перевіряє перекомпонування за ширини, еквівалентної 320 CSS px, для вмісту з вертикальним прокручуванням. Типовий спосіб — масштаб 400% за початкової ширини області перегляду 1280 CSS px. Це дві різні перевірки.

Рядки тексту не повинні вимагати постійного руху у двох напрямках. Для вмісту, якому необхідна двовимірна структура, наприклад деяких таблиць і карт, передбачено винятки. Це не виправдовує горизонтальне прокручування всієї сторінки через надто широку кнопку.

Збільште також міжрядковий інтервал до 1,5 розміру шрифту, інтервал після абзацу до 2, міжлітерний до 0,12 і міжслівний до 0,16. Перевіряється відсутність втрати вмісту за такої користувацької зміни, а не обов’язок установити ці значення всім за замовчуванням.

Alt залежить від завдання зображення

Інформативному зображенню потрібне передавання змісту, декоративному — порожній alt="". Іконка всередині вже підписаної кнопки зазвичай не повинна дублювати її ім’я. Для складного графіка короткого alt недостатньо: потрібні пояснення висновку та доступні дані поруч.

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

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

Застосувати правила з ШІ-агентом

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

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