Як зробити сайт доступним: стартовий посібник з WCAG 2.2

Щоб зробити сайт доступним, створюйте його так, щоб ним можна було користуватися з клавіатури, програми для читання з екрана, масштабування або пристрою з перемикачем, а не лише мишею: використовуйте справжні HTML-елементи для кнопок, посилань, заголовків і міток полів форм, давайте зображенням змістовний alt-текст, тримайте високий контраст тексту і робіть фокус видимим. Ціль — WCAG 2.2 рівня AA. Автоматичні перевірки ловлять частину проблем; десятихвилинний тест з клавіатурою і програмою для читання з екрана знаходить велику частину решти.

Що означає «доступний» на практиці

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

Еталонний стандарт — Web Content Accessibility Guidelines (WCAG) від W3C. Станом на вересень 2026 року чинна версія — WCAG 2.2 (опублікована у жовтні 2023 року, оновлена у грудні 2024-го); WCAG 3 — ранній проєкт. WCAG побудовано навколо чотирьох принципів: контент має бути сприйманим, керованим, зрозумілим і надійним, — і має три рівні відповідності:

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

Варіанти: як до цього прийти

Для більшості невеликих сайтів вистачає перших двох: скажіть ШІ будувати доступно з самого початку, а потім проведіть аудит перед запуском.

Виправлення, які важать найбільше

Використовуйте правильні HTML-елементи

Більшість доступності дається безплатно з правильним HTML. <button> можна сфокусувати, він працює з Enter і Пробілом і оголошується як кнопка. <div> з обробником кліку — ні того, ні іншого. Згенерований ШІ код іноді використовує стилізовані div для всього; просіть семантичні елементи:

• <button> для дій, <a href> для навігації
• Один <h1> на сторінку, далі <h2>, <h3> у правильному порядку — користувачі читалок переходять між заголовками
• Орієнтири: <header>, <nav>, <main>, <footer>
• <label>, пов’язаний з кожним полем форми
• Мова сторінки в <html lang="uk">

Атрибути ARIA використовуйте лише тоді, коли жоден рідний елемент не підходить — наприклад, для власного набору вкладок або combobox. Неправильний ARIA гірший за його відсутність.

Навігація з клавіатури і видимий фокус

Усе, що можна зробити мишею, має працювати лише з клавіатурою (WCAG 2.1.1). Натисніть Tab по сторінці: кожне посилання, кнопка і поле мають бути доступні в логічному порядку, і ви завжди бачите, де фокус (2.4.7 Focus Visible). WCAG 2.2 додав, що сфокусований елемент не повинен бути повністю схований за липкими шапками або банерами cookie (2.4.11, рівень AA).

Типові збої: меню, які відкриваються лише при наведенні, модальні вікна, які не утримують фокус або не закриваються клавішею Escape, і outline: none у CSS без заміни.

Текстові альтернативи

Кожне значущі зображення потребує alt-тексту, який пояснює, що воно показує в контексті («Шеф подає дегустаційне меню», а не «image1.jpg»). Декоративні зображення отримують порожній alt="", щоб програми для читання їх пропускали. Кнопки лише з іконкою потребують доступної назви («Закрити», «Пошук»). Відео потребують субтитрів; аудіо — транскрипції.

Колір і контраст

WCAG 2.2 рівня AA вимагає коефіцієнта контрасту щонайменше 4,5:1 для звичайного тексту і 3:1 для великого (1.4.3), а також 3:1 для частин інтерфейсу, як-от рамки полів введення і значущі іконки (1.4.11). Типові збої — світло-сірий текст-підказка в полях і блідні кнопки. Крім того, ніколи не передавайте значення лише кольором: червона рамка недійсного поля також потребує повідомлення про помилку.

Масштабування і перекомпонування

Текст має залишатися зручним при збільшенні до 200% (1.4.4), а вміст має працювати при ширині 320 CSS-пікселів без горизонтальної прокрутки (1.4.10). Добре адаптивний макет вирішує більшість цього.

Цілі, форми і помилки

• Розмір цілі: WCAG 2.2 рівня AA вимагає, щоб цілі для вказівника були щонайменше 24 на 24 CSS-пікселі або мали достатній відступ навколо менших (2.5.8). Більше — зручніше на телефонах.
• Форми: видимі мітки (не лише плейсхолдер), зрозумілі інструкції і повідомлення про помилки, які пояснюють, що не так і як це виправити, поруч з полем.
• Вхід: не змушуйте людей розв’язувати головоломку або переписувати код без альтернативи; дозволяйте менеджери паролів і вставлення (3.3.8 Accessible Authentication).

Промпти, які працюють

Зроби цей сайт відповідним WCAG 2.2 рівня AA: семантичні орієнтири HTML, один h1 на сторінку із заголовками в порядку, справжні елементи кнопок і посилань, мітки для кожного поля форми, видимі стилі фокусу, контраст тексту щонайменше 4,5:1, alt-текст для значущих зображень і alt="" для декоративних, а також встановлений html lang.

Проаудитуй сторінки /signup і /checkout на доступність. Перевір використання лише з клавіатурою, порядок фокусу, видимий фокус, мітки, повідомлення про помилки, контраст і назви для кнопок-іконок у програмах для читання з екрана. Перелічи кожну проблему з критерієм WCAG, а потім виправ їх, не змінюючи візуальний дизайн більше, ніж потрібно.

Мобільне меню неможливо використати з клавіатури. Зроби його кнопкою з aria-expanded, переміщуй фокус у меню при відкритті, закривай клавішею Escape і повертай фокус на кнопку.

Покроково

1. Запустіть автоматичну перевірку. Розділ Accessibility у Lighthouse в інструментах розробника Chrome або розширення axe для браузера на кожній основній сторінці. Виправте все, що вони показують.
2. Відключіть мишу. Пройдіться Tab по кожній сторінці і виконайте кожне ключове завдання — реєстрацію, пошук, оформлення. Відмітьте все, до чого не можна дістатися, де не видно фокусу або з чого не можна вийти.
3. Збільште до 200% і звузьте вікно до ширини телефона. Нічого не має обрізатися або вимагати горизонтальної прокрутки.
4. Спробуйте програму для читання з екрана хвилин десять: VoiceOver на Mac та iPhone, TalkBack на Android або NVDA на Windows (безплатно). Послухайте заголовки, посилання і поля форм. «Кнопка» без назви або «посилання, натисніть тут» — це роботи, які треба виконати.
5. Перевірте контраст тексту, кнопок і полів за допомогою перевірки контрасту.
6. Виправте, потім перевірте знову ті самі завдання.
7. Опублікуйте заяву про доступність, де вказано, яку ціль ви ставите і як повідомити про проблеми, — і відповідайте на ці повідомлення.

Типові помилки

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

Чеклист доступності

• Автоматична перевірка (Lighthouse або axe) чиста на основних сторінках
• Кожне завдання можна виконати лише з клавіатурою
• Фокус завжди видимий і ніколи не схований за липкими елементами
• Семантичні заголовки, орієнтири, кнопки і посилання; встановлено lang
• Змістовний alt-текст; декоративні зображення з alt=""; субтитри до відео
• Контраст тексту ≥ 4,5:1 (великий текст ≥ 3:1); частини інтерфейсу ≥ 3:1
• Працює при масштабі 200% і ширині 320 px
• Кожне поле форми має видиму мітку і зрозумілі повідомлення про помилки
• Заява про доступність зі способом повідомити про проблеми

Щоб зрозуміти концепції, читайте що таке веб-доступність. Доступний і гарний дизайн значною мірою перетинаються; як створити гарний додаток за допомогою ШІ розповідає про візуальний бік.

Доступність у Mythex

Mythex будує за тим стандартом, який ви просите, тож додайте «WCAG 2.2 AA» у свій перший промпт і в подальші запити. Для перевірки на малих екранах можна скористатися рамкою розміру телефона в Preview (Preview and Code), але тести з клавіатурою, масштабуванням і програмою для читання з екрана найкраще працюють на опублікованій адресі або прев’ю, відкритому у власній вкладці. Попросіть агента проаудитувати сторінку, виправити знайдене, а потім протестуйте виправлення самі — автоматична перевірка є початком, а не остаточним схваленням.

Запитання