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

WCAG звучить лякаюче. Це 100-сторінковий документ з трьома рівнями відповідності, чотирма принципами, тринадцятьма гайдлайнами і 78 критеріями успіху. Команди читають першу сторінку і втікають.

Вам не треба читати специфікацію. Для більшості маркетингових сайтів і веб-застосунків відповідність рівня AA — це чеклист з приблизно дванадцяти конкретних речей. Зробіть усі дванадцять — і ви покрили випадки, які реально мають значення для користувачів, регуляторів доступності і людей, що користуються screen reader-ами.

Цей пост — це той чеклист. Це не вся специфікація. Це робочий підмножина для випуску сайту, який справді придатний.

AA vs AAA: на що цілитись

Три рівні відповідності WCAG:

• A — мінімум. Якщо ви не пройшли A, сайт зламаний для частини користувачів. Хіт цей рівень.
• AA — практична ціль для більшості сайтів. Вимагається EAA ЄС, ADA у США та еквівалентами у більшості юрисдикцій.
• AAA — особливо суворий. Рідко правильна ціль; деякі AAA-критерії конфліктують з мейнстрімом дизайн-практик.

AA — правильна ціль. Будуйте під AA, виправляйте все, що виявите далі. Не женіться за AAA без специфічної причини (державні контракти, певні healthcare-контексти).

Чеклист на дванадцять пунктів

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

1. Контраст кольору

Body-текст потребує 4.5:1 контрасту до фону. Великий текст (18pt+) — 3:1. Інтерактивні елементи (кнопки, focus-кільця) — 3:1.

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

Інструменти: WebAIM Contrast Checker для одиничних перевірок. Stark-плагін у Figma. axe DevTools у браузері для зрендереного сайту.

2. Клавіатурна навігація

Кожен інтерактивний елемент має бути досяжним і керованим клавіатурою. Tab рухає між елементами, Enter або Space активують, Escape закриває модалки.

Пастки:

• Кастомні dropdown, побудовані на <div> і click-обробниках. Жодної клавіатурної підтримки, поки ви її не додасте.
• Модалки, що не тримають фокус. Користувач табає поза модалку у сторінку позаду.
• Skip-to-content посилання, відсутні або сховані так, що на них не сфокусуватись.
• Кнопки, зроблені з <a>-тегів без role="button" і клавіатурних обробників.

Фікс: використовуйте справжні семантичні елементи (<button>, <a>, <select>), де можливо. Коли мусите використовувати кастомні віджети, дотримуйтесь паттернів ARIA Authoring Practices Guide. Тестуйте, відключивши мишку на годину.

3. Видимість фокусу

Коли елемент має клавіатурний фокус, має бути видимий focus-індикатор. Дефолтні браузерні focus-кільця негарні, але функціональні. Багато команд ховають їх через outline: none і забувають додати заміну.

Правило: ніколи не прибирайте outline без заміни на щось принаймні так само видиме. Кастомне focus-кільце — нормально; відсутність focus-кільця — ні.

4. Alt-текст на зображеннях

Кожне зображення потребує alt-тексту. Правильний alt залежить від зображення:

• Інформативні зображення (фото з контентом, ілюстрації, що щось означають): опишіть, що там. «Два інженери ревьюють вайрфрейм на whiteboard».
• Декоративні зображення (фонові паттерни, орнаменти, надлишкові візуали поруч із текстом, що каже те саме): порожній alt. alt="". Не відсутній alt — явно порожній.
• Функціональні зображення (іконки, що працюють як кнопки): описуйте функцію, не зображення. Кнопка-іконка лупи має мати alt="Пошук", не alt="Лупа".

Найпоширеніша помилка: використання імені файла як alt. alt="IMG_2934.jpg" гірше за відсутній alt.

5. Лейбли і помилки форм

Кожен інпут форми потребує видимого, програмно асоційованого лейбла. Placeholder — це не лейбл; коли користувач починає друкувати, placeholder зникає, і він втратив контекст.

<!-- Неправильно -->
<input type="email" placeholder="Email">

<!-- Правильно -->
<label for="email">Email</label>
<input type="email" id="email" placeholder="name@company.com">

Коли валідація провалюється, повідомлення про помилку має бути асоційоване з полем. aria-describedby на інпуті, що вказує на ID повідомлення про помилку. Screen reader-користувачі чують помилку, коли фокусуються на полі.

6. Ієрархія заголовків

Сторінки мають один <h1>, потім <h2> для секцій, <h3> для підсекцій. Не пропускайте рівні (немає <h1> одразу після якого <h3>).

Screen reader-користувачі навігують за заголовками. Сторінка з плоскою структурою заголовків — це стіна тексту для них. Сторінка з вкладеною, семантичною структурою — це навігабельний документ.

Пастка: використання заголовків для візуального стилю замість структури. Якщо хочете великий текст — використайте CSS. Якщо хочете заголовок — використайте <h2> і стилізуйте його.

7. Текст посилань

Посилання мають мати сенс поза контекстом. Screen reader-и можуть перелічити всі посилання сторінки; якщо половина з них каже «Натисни тут» або «Дізнатись більше» — список безкорисний.

Погано: «Прочитайте більше про наші послуги [тут]». Добре: «Прочитайте [більше про наші послуги]».

Ті самі слова, інший anchor. Текст посилання — «більше про наші послуги», що означає щось саме по собі.

8. Розмір touch-цілі

На мобілці інтерактивні елементи мають бути принаймні 44×44 CSS-пікселів. Менші — і люди з неточним моторним контролем не можуть на них влучити.

Пастка: щільно упаковані nav-посилання, соціальні іконки у футері, щільні інпути форми. Кожен окремо малий. Сукупно сайт важко використовувати на телефоні.

Фікс: додайте padding, навіть коли видимий елемент малий. Зона цілі виходить за межі видимих пікселів.

9. Рух і анімація

WCAG вимагає поваги до prefers-reduced-motion. Користувачі, які отримують motion sickness, vestibular розлади або просто ненавидять parallax-ефекти, виставляють цю преференцію на рівні ОС. Ваш сайт має її поважати.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Це молоток. Більш нюансований підхід: лишіть мікроінтеракції (fade-in, легке масштабування), приберіть важкі ефекти (parallax, великі слайди, autoplay video).

10. Мова документа

Кожна сторінка потребує <html lang="uk"> (або відповідної локалі). Screen reader-и використовують це, щоб обрати правильний голос і правила вимови. Без цього англійський контент може читатись з польським акцентом.

Для багатомовних сайтів змінюйте lang на сторінку на основі реальної мови. Вкладені сніпети іншою мовою можуть використовувати <span lang="...">.

11. Skip-to-content посилання

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

<a href="#main" class="skip-to-content">Перейти до контенту</a>
...
<main id="main">...</main>

Клас має ховати посилання візуально, але робити його видимим при фокусі. Не використовуйте display: none; це прибирає з tab-порядку.

12. ARIA — коли (і тільки коли) потрібно

ARIA-атрибути (aria-label, aria-describedby, aria-live тощо) додають семантичну інформацію для assistive tech. Вони потужні і перевикористовувані.

Правило: надавайте перевагу нативному HTML. Використовуйте <button> замість <div role="button">. Використовуйте <nav> замість <div role="navigation">. ARIA — для речей, які HTML не може виразити (кастомні віджети, live-регіони, async loading-стани).

Найпоширеніший корисний ARIA на маркетинговому сайті:

• aria-current="page" на активному nav-посиланні
• aria-live="polite" на повідомленнях статусу надсилання форми
• aria-expanded на toggle-кнопках
• aria-label на icon-only кнопках

Це більшість того, що використовуватимете.

Інструменти

Автоматизовані інструменти ловлять близько 30% accessibility-проблем. Вони необхідні, але недостатні. Інструменти, які ми використовуємо:

• axe DevTools браузерне розширення. Запускайте на кожній сторінці. Знаходьте легкі перемоги.
• Lighthouse accessibility audit. Запускає той самий двигун. Корисний для CI.
• WAVE браузерне розширення. Дещо інший набір правил, ніж axe; іноді ловить інше.
• Pa11y для CI-інтеграції. Фейлить білд, якщо доступність регресує.

Що автоматизовані інструменти пропускають:

• Чи alt-текст осмислений (вони детектять відсутній alt, не поганий alt)
• Чи клавіатурна навігація реально працює
• Чи порядок читання має сенс
• Чи контент має сенс без кольору (наприклад, «натисни зелену кнопку»)
• Чи інтеракції операбельні без мишки

Для цього потрібне ручне тестування.

Частини, які не автоматизувати

Реальний accessibility-прохід включає:

• Keyboard-only тест. Відключіть мишку. Користуйтесь сайтом п'ятнадцять хвилин. Що не можете — баг.
• Screen reader тест. Mac-користувачі мають VoiceOver вбудовано (Cmd+F5). На Windows — NVDA (безкоштовно). Користуйтесь сайтом зі screen reader десять хвилин. Що незрозуміло — баг.
• Zoom-тест. Браузер на 200% zoom. Лейаут має досі працювати. Жодного горизонтального скролу.
• Reduced-motion тест. Тогглніть prefers-reduced-motion у DevTools. Анімації мають зменшитись або зупинитись.
• Forced-colours тест. Тогглніть Windows high-contrast (Mac-еквівалент: інверсія кольорів). Лейаут має пережити.

Кожен забирає 10-15 хвилин. Жоден не потребує спеціальних навичок. Половина accessibility-багів, які ми знаходимо, виходить з цих ручних проходів.

Опрацьований приклад

Ми аудитували маркетинговий сайт минулого місяця. Автоматизовані інструменти позначили 12 проблем. Ручний прохід знайшов ще 18. Розподіл:

• Автоматизовані знайшли: низький контраст, відсутній alt, відсутні лейбли, відсутній lang. Механічні речі.
• Ручний знайшов: focus-пастки у модалках, клавіатурна навігація зламана на кастомній каруселі, screen reader читає секцію тестимоніалів перед героєм (баг порядку читання, невидимий автоматизованим інструментам), три icon-only кнопки без лейбла, інструкція «натисни зелену іконку», що провалюється для дальтоніків.

Механічні фікси зайняли два дні. Ручні фікси зайняли п'ять. Сайт пройшов з «майже AA» до «справді AA». Сумарний час: тиждень.

Чеклист перед запуском

Роздрукуйте:

• Контраст усього тексту відповідає 4.5:1 (3:1 для великого).
• Кожен інтерактивний елемент досяжний клавіатурою.
• Focus-індикатори видимі на кожному інтерактивному елементі.
• Кожне зображення має відповідний alt (або alt="" для декоративних).
• Кожне поле форми має видимий, асоційований лейбл.
• Ієрархія заголовків семантична (без пропущених рівнів).
• Посилання мають сенс поза контекстом.
• Touch-цілі — принаймні 44×44px.
• prefers-reduced-motion поважається.
• <html lang="..."> встановлено на кожній сторінці.
• Skip-to-content посилання існує і працює.
• ARIA використовується лише там, де нативний HTML не може нести сенс.
• Keyboard-only тест пройдено.
• Screen reader тест пройдено.
• 200% zoom тест пройдено.

П'ятнадцять пунктів. Жоден з них не складний. Більшість з них перевіряються легко. WCAG AA — це не дослідницький проєкт; це чеклист.

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