Доступність сайту за WCAG 2.2: практичний чекліст для бізнесу

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

Для бізнесу це означає ширшу аудиторію, менше бар’єрів у заявках і покупках, зрозуміліший інтерфейс та нижчу вартість подальших переробок. Якщо вимоги врахувати під час UI/UX-дизайну або редизайну, виправлення кольорів, фокуса, форм і компонентів не перетворюється на окремий дорогий проєкт після запуску.

Цей матеріал не є сертифікатом відповідності та не замінює юридичну оцінку для конкретної країни чи галузі. Він допомагає підготувати сайт до глибшого аудиту й системно усунути найпоширеніші проблеми.

Що таке WCAG 2.2

WCAG — настанови з доступності вебконтенту, розроблені W3C Web Accessibility Initiative. Версія 2.2 організовує критерії навколо чотирьох принципів:

1. Сприйнятність — інформацію можна отримати не лише одним способом.
2. Керованість — інтерфейсом можна користуватися з різними способами введення.
3. Зрозумілість — контент і поведінка елементів передбачувані.
4. Надійність — код коректно взаємодіє з браузерами та допоміжними технологіями.

Критерії мають рівні A, AA та AAA. Для практичного планування часто орієнтуються на A та AA, однак потрібний рівень слід визначати за договором, вимогами замовника й актуальними правилами конкретної юрисдикції.

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

Кому корисна вебдоступність

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

Рішення часто покращують досвід усіх:

• субтитри допомагають дивитися відео без звуку;
• високий контраст покращує читання на вулиці;
• логічні заголовки спрощують швидке сканування;
• видимий фокус показує, де перебуває користувач;
• зрозумілі помилки допомагають завершити форму;
• великі зони натискання зменшують випадкові кліки;
• семантичний HTML полегшує підтримку й автоматизацію.

З чого почати: визначте обсяг

Не починайте з випадкової зміни кольору кнопок. Спочатку складіть перелік шаблонів і критичних сценаріїв:

• головна;
• сторінка послуги або категорії;
• стаття;
• пошук і фільтри;
• картка товару;
• кошик та оформлення;
• форма заявки;
• вхід, реєстрація й відновлення пароля;
• політики та завантажувані документи;
• 404, помилки й системні повідомлення.

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

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

1. Перевірте структуру сторінки

Заголовки повинні описувати логіку документа, а не просто бути великим текстом. На сторінці потрібен зрозумілий H1, а підрозділи мають іти послідовно. Не обирайте H3 лише через бажаний розмір шрифту — візуальне оформлення належить CSS.

Перевірте:

• чи назва сторінки в <title> пояснює її зміст;
• чи встановлена правильна мова документа;
• чи є один чіткий основний заголовок;
• чи не пропускаються рівні без логічної причини;
• чи використовуються області header, nav, main, aside, footer;
• чи списки, таблиці й цитати мають відповідні HTML-елементи;
• чи порядок читання в DOM відповідає візуальному порядку.

Відкрийте сторінку без CSS або перегляньте дерево доступності. Якщо зміст утрачає логіку, декоративна сітка приховує структурну проблему.

2. Додайте текстові альтернативи зображенням

Alt-текст передає функцію або зміст важливого зображення. Він не повинен механічно повторювати назву файла або починатися словами «зображення». Опис залежить від контексту.

Приклади:

• товар: Бежеве лляне крісло з дерев’яними ніжками;
• схема: коротко передайте головний висновок, а повне пояснення дайте поруч;
• кнопка-іконка: доступна назва має описувати дію, наприклад «Відкрити пошук»;
• декоративна пляма: порожній alt="", щоб скринрідер її пропустив.

Не дублюйте alt-текст, підпис і сусідній абзац без потреби. Для складних графіків потрібен доступний текстовий еквівалент із даними або висновком, а не фраза «графік продажів».

3. Перевірте контраст і використання кольору

Для звичайного тексту критерій WCAG 2.2 рівня AA вимагає контраст щонайменше 4,5:1, для великого — 3:1. Важливі межі полів, іконки й графічні компоненти також потребують достатньої помітності відповідно до застосовного критерію.

Не покладайтеся на враження дизайнера або яскравість монітора. Вимірюйте фактичні пари кольорів у нормальному, hover, focus, disabled та error-станах. Текст поверх фотографії потрібно перевіряти в найслабшій ділянці або підкладати стабільний фон.

Колір не повинен бути єдиним сигналом. Червона межа без тексту «Введіть номер телефону» не пояснює помилку. Зелений і червоний статуси слід доповнювати підписом, формою, іконкою або патерном.

Фірмовий лаймовий чи пастельний колір можна зберегти як акцент, але текст на ньому іноді потребує темного відтінку, а не білого. Доступність не забороняє бренд-стиль — вона вимагає перевірених комбінацій.

4. Зробіть сайт повністю керованим із клавіатури

Відкладіть мишу й пройдіть критичний маршрут клавішами Tab, Shift+Tab, Enter, Space, стрілками та Escape. Усі інтерактивні елементи повинні отримувати фокус, працювати в логічному порядку й не створювати «пастку».

Перевірте:

• посилання, кнопки, меню, вкладки й акордеони;
• слайдери, модальні вікна, підказки й випадаючі списки;
• календарі, фільтри й автодоповнення;
• завантаження файлів;
• відеоплеєр;
• кошик та оплату;
• cookie-банер.

Коли відкривається модальне вікно, фокус переходить усередину, не виходить у фон, закривається Escape і повертається на елемент, що відкрив діалог. Якщо після закриття користувач опиняється на початку сторінки, сценарій порушений.

5. Не приховуйте індикатор фокуса

Правило outline: none без якісної заміни робить клавіатурну навігацію майже невидимою. Фокус має чітко відрізнятися від звичайного й hover-стану, не обрізатися контейнером та не ховатися під sticky header, cookie-банером або плаваючою кнопкою.

Проєктуйте focus-стан у дизайн-системі для кожного компонента. Не залишайте його на етап «розробник щось додасть». У складних інтерфейсах перевіряйте також, чи після динамічної дії фокус переходить до нового повідомлення або логічного наступного кроку.

6. Зробіть посилання й кнопки зрозумілими

Текст «Натисніть тут» втрачає зміст поза абзацом. Краще: «Завантажити прайс у PDF», «Переглянути кейси» або «Перейти до умов доставки». Користувач скринрідера може переглядати список посилань окремо від контексту.

Кнопка виконує дію, посилання веде в інше місце. Не стилізуйте <div> під кнопку, якщо можна використати нативний <button>. Нативні елементи вже мають очікувану семантику та клавіатурну поведінку.

Для іконки без видимого тексту потрібна доступна назва. Водночас декоративну іконку всередині кнопки зі зрозумілим написом не слід озвучувати вдруге.

7. Перевірте розмір і відстань між цілями

WCAG 2.2 містить критерій мінімального розміру цілі 24×24 CSS-пікселі з винятками, зокрема для достатньо рознесених елементів. У реальному mobile UX доцільно робити важливі кнопки ще зручнішими, особливо в кошику, формах і навігації.

Не оцінюйте лише видиму іконку. Натискувана область може бути більшою завдяки padding. Перевірте близько розташовані хрестики, пагінацію, варіанти товару, стрілки слайдера й кнопки кількості.

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

8. Дозвольте масштабувати й змінювати текст

Не блокуйте pinch-to-zoom через viewport. Перевірте сайт при масштабі браузера 200% і на вузькій ширині. Основний зміст та функції не повинні безслідно зникати, накладатися або вимагати горизонтального скролу, крім обґрунтованих винятків на кшталт широкої таблиці.

Збільште міжрядковий інтервал, відстані між літерами, словами й абзацами. Кнопки, вкладки та картки мають витримувати довший текст. Не фіксуйте висоту контейнера, якщо вміст може зрости.

9. Побудуйте доступні форми

Placeholder не замінює label: він зникає під час введення, може мати низький контраст і не завжди дає достатній контекст. Кожне поле повинно мати програмно пов’язану назву, зрозумілу підказку та повідомлення про помилку.

Перевірте:

• логічний порядок полів;
• правильні типи email, tel, number і autocomplete;
• позначення обов’язковості не лише кольором;
• інструкцію до введення до, а не після помилки;
• текст помилки поруч із полем;
• загальне повідомлення зі списком проблем для довгої форми;
• збереження введених даних після помилки;
• переміщення фокуса до важливого повідомлення;
• доступний статус успішного надсилання;
• достатній час для завершення, якщо сесія обмежена.

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

10. Додайте субтитри, транскрипти й контроль медіа

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

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

Не створюйте контент, що блимає частіше безпечного порога. Анімації мають враховувати налаштування prefers-reduced-motion, особливо паралакс, великі переходи та автоматичні каруселі.

11. Пишіть зрозумілий контент

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

Корисні правила:

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

Зрозуміла мова підтримує і доступність, і SEO-просування сайту: сторінка точніше відповідає на запит, а структура полегшує навігацію людям і пошуковим системам.

12. Використовуйте ARIA лише там, де потрібно

ARIA допомагає описувати складні компоненти, але не виправляє неправильну основу. Перше правило — віддати перевагу нативному HTML. <button> майже завжди надійніший за <div role="button">, для якого доведеться вручну відтворювати фокус, клавіші й стани.

Перевіряйте:

• доступну назву компонента;
• роль;
• поточний стан expanded, selected, checked, invalid;
• зв’язок поля з підказкою та помилкою;
• оголошення динамічних статусів;
• відсутність конфлікту між видимим текстом і доступною назвою.

Надлишкове або неправильне ARIA може зробити інтерфейс гіршим. Тестуйте результат у дереві доступності та скринрідері.

13. Перевірте динамічні компоненти

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

Після дії перевірте:

• чи оголошується кількість результатів;
• чи повідомляється про додавання товару;
• чи не скидається фокус;
• чи можна закрити діалог;
• чи завантаження має текстовий статус;
• чи помилка API пояснює наступний крок;
• чи нескінченний скрол має доступну альтернативу;
• чи drag-and-drop можна виконати інакше.

Під час розробки сайту ці стани потрібно додавати до технічного завдання й компонентної документації, а не тестувати випадково перед релізом.

14. Не забувайте про документи й сторонні сервіси

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

Для документів перевірте структуру заголовків, порядок читання, теги, мову, альтернативи зображень і доступні таблиці. Якщо швидко виправити PDF неможливо, надайте HTML-версію важливої інформації.

Під час вибору віджета запитайте постачальника про клавіатуру, скринрідери, звіт про доступність і відомі обмеження. Обіцянка «відповідає WCAG» без версії, рівня та обсягу перевірки недостатня.

15. Поєднайте автоматичну й ручну перевірку

Автоматичний скан добре знаходить частину проблем: відсутні alt, неправильні ролі, деякі контрасти, порожні кнопки, повторені id й базові помилки структури. Але він не визначить, чи alt передає зміст, чи порядок фокуса логічний, чи інструкція зрозуміла, чи модальне вікно реально зручне.

Практичний цикл:

1. автоматично проскануйте репрезентативні шаблони;
2. пройдіть критичні сценарії лише клавіатурою;
3. перевірте масштаб 200% і вузький viewport;
4. перевірте контраст усіх станів;
5. перегляньте дерево доступності;
6. протестуйте основні сценарії скринрідером;
7. залучіть користувачів із різними потребами, якщо рівень ризику й масштаб продукту це виправдовують;
8. повторіть перевірку після виправлень.

Технічні коди відповіді, редиректи й частину базової діагностики можна додатково перевірити через інструменти BB STUDIO, але вони не замінюють спеціалізований аудит доступності.

Як пріоритезувати виправлення

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

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

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

Готовий чекліст перед запуском

Контент і структура

• На сторінках правильна мова й описовий title.
• Заголовки утворюють логічну ієрархію.
• Списки, таблиці та області мають семантичну структуру.
• Важливі зображення мають доречні текстові альтернативи.
• Декоративні зображення не створюють шуму для скринрідера.
• Посилання зрозумілі без сусіднього речення.

Візуальний дизайн

• Контраст тексту й компонентів виміряний.
• Колір не є єдиним способом передати стан.
• Фокус видимий на всіх інтерактивних елементах.
• Текст і функції зберігаються при масштабі 200%.
• Немає необґрунтованого горизонтального скролу.
• Touch-цілі достатні та не розташовані надто близько.

Взаємодія

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

Форми й медіа

• Поля мають постійні label та зрозумілі інструкції.
• Помилки називають проблему й спосіб виправлення.
• Статус надсилання доступний без візуального здогаду.
• Відео має потрібні субтитри й альтернативи.
• Плеєр керується клавіатурою.
• Завантажувані документи перевірені або мають HTML-альтернативу.

Перевірка процесу

• Використано автоматичний скан і ручне тестування.
• Перевірено реальні критичні шаблони, а не лише головну.
• Задокументовано браузери, технології та межі аудиту.
• Виправлення повторно протестовані.
• Відповідальність за доступність після релізу визначена.

Коли достатньо виправлень, а коли потрібен редизайн

Локальні правки підходять, якщо структура логічна, компоненти послідовні, а основні проблеми зосереджені в кольорах, назвах, фокусі та розмітці. Редизайн доцільний, коли сторінки мають хаотичну ієрархію, важливі сценарії залежать від hover або drag-and-drop, дизайн-система відсутня, а кожен шаблон реалізований по-різному.

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

Висновок

Доступність — це властивість усього продукту, а не окремий віджет. Вона починається з логічного контенту, продовжується у дизайн-системі та компонентах, підтверджується ручним тестуванням і підтримується після кожного релізу.

Найкраща стратегія для бізнесу — спочатку прибрати блокери в заявці, покупці та навігації, потім виправити повторювані компоненти, а далі включити перевірку доступності до звичайного процесу дизайну, розробки й контенту.