Доступні UI-патерни: WCAG, WAI-ARIA і APG

Оновлено 14 жовтня 2026 · 6 хв читання

Пошукайте «WCAG combobox» чи «WCAG tabs» — і ви потрапите в три різні документи W3C, які відповідають на різні запитання. Ця серія пояснює кожен поширений патерн інтерфейсу інтернет-магазину: навіщо він потрібен, які критерії WCAG до нього застосовуються, короткий правильний приклад HTML, очікувана поведінка з клавіатури і що автоматична перевірка може і чого не може знайти. На цій сторінці — як ці документи пов'язані між собою, і список усіх патернів.

Це технічні рекомендації, а не юридична консультація.

WCAG, WAI-ARIA і ARIA Authoring Practices

Документ	Що це	На що відповідає
WCAG 2.2	Рекомендація W3C, стандарт, на який спираються EN 301 549 (в Україні — ДСТУ EN 301 549:2022) і більшість законів	Яким має бути результат: доступ з клавіатури, назви, контраст, повідомлення про помилки
WAI-ARIA 1.2	Рекомендація W3C (6 червня 2023 року) з ролями, станами й властивостями	Як повідомити допоміжним технологіям, що таке власний елемент: `role="tab"`, `aria-expanded`
ARIA Authoring Practices Guide (APG)	Рекомендації W3C WAI з патернами й прикладами	Як має поводитися віджет: які клавіші, які переміщення фокуса, які атрибути

WCAG не називає жодного віджета на ім'я. Настанови кажуть, наприклад, що кожен елемент керування має передавати свою назву, роль і стан (4.1.2), що все має працювати з клавіатури (2.1.1), що фокус має бути видно (2.4.7) і що структура має бути в коді, а не лише в макеті (1.3.1). Нативний HTML дає більшість цього безкоштовно. Коли ви будуєте те, чого в HTML немає, — вкладки, комбінований список із підказками, карусель, — WAI-ARIA дає змогу це описати, а APG підказує, якої поведінки очікують користувачі допоміжних технологій.

W3C описує WAI-ARIA як спосіб зробити доступними «динамічний вміст і складні елементи керування інтерфейсу», а APG — як супровідний документ, що «рекомендує підходи, які допомагають розробникам вебзастосунків робити віджети» доступними. APG не є вимогою відповідності: ви можете виконати WCAG з іншим, добре перевіреним рішенням. У власному вступі APG сказано, що тестування з допоміжними технологіями «необхідне, перш ніж використовувати код із цього посібника в продакшені».

Спершу нативний HTML

Нотатка W3C Using ARIA сформулювала це як перше правило використання ARIA: якщо можна застосувати нативний елемент або атрибут HTML із уже вбудованими потрібними семантикою й поведінкою, використовуйте його, а не перепрофільовуйте інший елемент, додаючи ARIA. Інші її правила: не змінюйте нативну семантику без крайньої потреби; усі інтерактивні елементи керування ARIA мають працювати з клавіатури; ніколи не ставте role="presentation" або aria-hidden="true" на елемент, що отримує фокус. (Ця нотатка тепер опублікована як припинена чернетка й відсилає до APG по подальші рекомендації, але її правила досі є загальною базою.)

APG каже те саме своїми словами: «Краще без ARIA, ніж з поганою ARIA» і «роль — це обіцянка». Додаючи role="button" до div, ви обіцяєте кнопку, але «ролі ARIA не змушують браузери надавати поведінку з клавіатури чи стилі», тож зробити елемент фокусованим і реагувати на Enter і Space доведеться самостійно.

<!-- Нативно: назва, роль, фокус і клавіатура безкоштовно -->
<button type="button">Додати в кошик</button>

<!-- Перебудовано: кожну частину треба додати вручну, і про неї часто забувають -->
<div role="button" tabindex="0" onclick="add()" onkeydown="addOnEnterOrSpace(event)">Додати в кошик</div>

Патерни в цій серії

Базові елементи керування

Кнопка чи посилання — кнопки виконують дії, посилання ведуть кудись
Посилання, що відкриваються в новій вкладці — коли це робити і як попередити
Неактивні кнопки — disabled чи aria-disabled, контраст і пояснення
Перемикачі й прапорці — мітки, групи й власні стилі

Спливні елементи й накладки

Випадний список, select і combobox — спершу нативний select, потім combobox з APG
Модальний діалог — фокус усередину, фокус утримується, фокус назад
Підказка (tooltip) — WCAG 1.4.13 і чому патерн APG досі чернетка

Навігація і структура

Навігаційне меню — чому APG радить для сайтів навігацію з розкривними блоками, а не menubar
Хлібні крихти — підписаний nav і aria-current="page"
Вкладки — tablist, клавіші зі стрілками й автоматична активація
Акордеон — заголовки з кнопками або details і summary
Таблиця даних — справжня розмітка table, заголовки й підписи
Карусель — кнопка паузи, підписані слайди, без несподіваного перегортання

Форми

Валідація форм і повідомлення про помилки — помилки текстом, пов'язані з полем і озвучені

Що автоматична перевірка знаходить у патернах

Наші перевірки запускають axe-core у справжньому браузері на сторінці в тому стані, у якому вона завантажується. Для патернів це означає, що вони надійно знаходять структурні проблеми: кнопки й посилання без назви, поля форм без мітки, невідомі ролі, атрибути ARIA, які не дозволені для ролі або посилаються на неіснуючий ID, tab поза tablist, елементи, що отримують фокус, але приховані через aria-hidden. Кожна знахідка веде до своєї картки в бібліотеці правил.

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

Почніть із безкоштовної перевірки однієї сторінки. Це автоматична перевірка, а не повний аудит.

Часті запитання

Чим WCAG відрізняється від WAI-ARIA?

WCAG описує, яким має бути результат, наприклад що кожен елемент керування передає свою назву, роль і стан (4.1.2). WAI-ARIA — це специфікація W3C з ролями, станами й властивостями, один зі способів досягти цього результату, коли нативного HTML недостатньо.

Чи вимагає WCAG використовувати ARIA?

Ні. WCAG не прив'язані до технології. Нативні елементи HTML, як-от button, a, input, select і table, зазвичай виконують критерії без жодної ARIA. ARIA потрібна для власних віджетів, яких немає в HTML, наприклад вкладок.

Що таке ARIA Authoring Practices Guide (APG)?

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

Яке перше правило ARIA?

Якщо нативний елемент або атрибут HTML уже має потрібну семантику й поведінку, використовуйте його, а не додавайте ARIA до іншого елемента. Справжня кнопка краща за div з роллю button.

Чи може автоматична перевірка протестувати UI-патерни?

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

Джерела

W3C WAI, WAI-ARIA overview: https://www.w3.org/WAI/standards-guidelines/aria/
W3C WAI, ARIA Authoring Practices Guide, Read Me First: https://www.w3.org/WAI/ARIA/apg/practices/read-me-first/
W3C WAI, APG patterns: https://www.w3.org/WAI/ARIA/apg/patterns/
W3C, Using ARIA (discontinued draft, rules of ARIA use): https://www.w3.org/TR/using-aria/