Як перевірити доступність сайту: безкоштовні інструменти й тести

Ось історія, яку ми чуємо часто. Людина запускає Lighthouse, отримує зелені 100 балів за доступність і йде далі. За тиждень покупець пише, що не зміг оплатити замовлення, бо до форми введення картки не дістатися з клавіатури. Правда і те, і те. Автоматичну перевірку пройдено, а живу людину сайт однаково підвів.

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

Чи може автоматичний інструмент сказати, чи доступний мій сайт?

Ні. Автоматичні інструменти швидко знаходять частину проблем, але на багато питань доступності може відповісти лише людина. Коли Служба цифрових технологій уряду Великої Британії (GDS) перевірила 10 інструментів на сторінці зі 143 відомими помилками, найкращий знайшов 41%. W3C каже прямо: інструменти оцінювання «не можуть визначити доступність, вони можуть лише допомогти в цьому».

Тест GDS (відкриється в новій вкладці) провели в лютому 2017 року, і його 41% (в Asqatasun) включали підказки інструмента для ручних перевірок. Відтоді інструменти покращилися, але розрив має ту саму причину. Програма може визначити, що зображення не має альтернативного тексту. Але не може визначити, що «червона сукня» — хибний опис фото синього костюма, чи зрозуміти, чи логічний порядок фокуса.

Тож ставтеся до автоматичної перевірки як до пожежного датчика, а не до обстеження будівлі. Запускати її однаково варто: WebAIM Million 2026 (відкриється в новій вкладці) знайшов помилки, які можна виявити автоматично, на 95,9% з мільйона найпопулярніших головних сторінок, тож майже на кожному сайті знайдеться що швидко виправити. Як сказано в посібнику W3C з вибору інструментів (відкриється в новій вкладці), «потрібне людське судження».

Якими безкоштовними інструментами перевірки доступності користуватися?

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

Що можна перевірити вручну за 15 хвилин?

Досить багато. Easy Checks (відкриється в новій вкладці) від W3C («Прості перевірки») охоплюють заголовки сторінок, альтернативний текст, заголовки розділів, контраст, посилання для пропуску, видимий фокус клавіатури, мову сторінки, масштабування, субтитри й підписи полів форм. Виберіть одну важливу сторінку, наприклад сторінку товару чи форму бронювання, і приділіть кожній перевірці хвилину-дві. Ви знайдете те, про що не повідомить жоден інструмент.

W3C пише, що ці перевірки «охоплюють лише кілька проблем доступності», тож повним оцінюванням вони не є. І все ж це найкращі чверть години, які ви можете витратити:

1. Заголовок сторінки (1 хвилина). Чи каже вкладка браузера, що це за сторінка, наприклад «Забронювати столик | Кухня Рози», а не «Головна» всюди?
2. Зображення (2 хвилини). Покажіть альтернативний текст за допомогою WAVE чи схожого інструмента. Він точний? Декоративні зображення пропускаються?
3. Заголовки (2 хвилини). Виведіть список заголовків і прочитайте їх окремо. Чи працюють вони як зміст?
4. Контраст (2 хвилини). Перевірте основний текст, дрібний сірий текст, текст кнопок і текст на зображеннях.
5. Клавіатура (4 хвилини). Відкладіть мишу й пройдіть сторінку клавішею Tab (див. наступний розділ).
6. Масштаб (2 хвилини). За 200%, а потім 400% чи можна все прочитати й користуватися меню без горизонтального прокручування?
7. Форми й мова (2 хвилини). Клацніть на підписі кожного поля: у правильно зробленій формі курсор опиниться в полі. Перевірте у звіті інструмента, чи не пропущено мову сторінки.

Як перевірити сайт із клавіатури?

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

На Mac браузер Safari пропускає посилання під час натискання Tab, доки ви не ввімкнете в додаткових налаштуваннях параметр, за якого Tab виділяє кожен елемент на вебсторінці (Press Tab to highlight each item on a webpage). Потім перевірте:

• Чи завжди видно, де ви? Якщо контур фокуса зникає, користувач клавіатури губиться.
• Чи логічний порядок? Фокус має йти в порядку читання.
• Чи не перекрито щось? Закріплена шапка чи банер про cookie, що ховають елемент у фокусі, порушують критерій WCAG 2.2 «Фокус не приховано».
• Чи можна вибратися назад? Відкрийте кожне меню, спливне вікно й вибір дати, а потім спробуйте вийти. Escape має закривати діалогові вікна.
• Чи працює весь сценарій? Додайте товар, змініть кількість, застосуйте промокод і дійдіть до оплати без миші.

Записуйте кожну помилку точно: «Вибір розміру на сторінці товару не відкривається клавішею Enter чи пробілом» виправлять значно швидше, ніж «клавіатура не працює».

Як уперше перевірити сайт зі скринрідером?

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

• Mac: Command+F5 вмикає й вимикає VoiceOver; Control+Option+U відкриває ротор — список заголовків, посилань і елементів форм.
• Windows: у NVDA натисніть H, щоб переходити між заголовками, і Insert+F7, щоб вивести список посилань і заголовків.
• Телефон: увімкніть VoiceOver (iPhone) чи TalkBack (Android) і проводьте пальцем праворуч, щоб переходити від елемента до елемента. Спершу дізнайтеся, як його вимкнути.

Дослухайтеся до головного. В опитуванні користувачів скринрідерів WebAIM 2024 року (відкриється в новій вкладці) 71,6% респондентів сказали, що на довгій сторінці спершу орієнтуються за заголовками, тож почніть із них. Потім виведіть список посилань: п’ять посилань «Докладніше» нікому нічого не кажуть. «До кошика, темно-синій светр» — корисна кнопка, а просто «кнопка» — ні. Насамкінець заповніть форму й перевірте, що кожне поле й кожна помилка зачитуються.

Не робіть далекосяжних висновків. Якщо вам здається, що щось зламано, найімовірніше, так і є; якщо все звучить нормально, це ще не доказ. Як працюють досвідчені користувачі, читайте у статті «Як люди з інвалідністю користуються сайтами».

Як перевірити масштабування, перебудову контенту й інтервали в тексті?

Збільште масштаб браузера до 200% і перевірте, що текст росте, не обрізаючись і не накладаючись. Потім перевірте перебудову: за масштабу 400% у вікні завширшки 1280 пікселів контент має вміщатися без горизонтального прокручування. Нарешті, збільште інтервали між літерами, словами, рядками й абзацами й перевірте, що нічого не ламається й не зникає.

Це відповідає критеріям WCAG «Зміна розміру тексту» (1.4.4), «Перебудова» (1.4.10) (відкриється в новій вкладці) та «Інтервали в тексті» (1.4.12) (відкриється в новій вкладці). «Перебудова» використовує ширину 320 CSS-пікселів, що, як зазначає W3C, «еквівалентно початковій ширині області перегляду 1280 CSS-пікселів за масштабу 400%». «Інтервали в тексті» вимагають, щоб нічого не губилося, коли читач задає міжрядковий інтервал у 1,5 розміру шрифту, інтервал між абзацами у 2 розміри, міжлітерний інтервал у 0,12 і міжслівний у 0,16 розміру шрифту.

Букмарклет для інтервалів — невеликий скрипт, збережений як закладка, — застосовує всі чотири значення одним клацанням. Шукайте текст, що вилазить за межі кнопок, і підписи, обрізані по краю. За масштабу 400% ноутбук показує приблизно те саме, що маленький телефон, тож добре зроблений адаптивний сайт проходить більшість цих перевірок уже зараз.

Як перевірити форми, помилки й оформлення замовлення?

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

• Помилки. Червоного «Неприпустиме введення» замало. «Введіть строк дії у форматі ММ/РР» поруч із полем — достатньо. Після надсилання фокус має переходити до зведення помилок чи до першого поля з проблемою.
• Вхід і коди. За критерієм «Доступна автентифікація» (відкриється в новій вкладці) WCAG 2.2 блокування вставлення чи менеджерів паролів — порушення, якщо немає іншого способу увійти.
• CAPTCHA й обмеження в часі. В опитуванні WebAIM користувачі скринрідерів назвали CAPTCHA найпроблемнішим елементом в інтернеті. Перевірте, чи є доступна альтернатива і чи можна продовжити обмеження в часі.

У нашому чеклісті доступності сайту є повніший перелік для магазинів, зокрема банери про cookie й спливні вікна.

Що входить у професійний аудит доступності і коли він потрібен?

Аудит доступності — це структурована перевірка, яку фахівець проводить за названим стандартом, зазвичай WCAG 2.1 чи 2.2 рівня AA. Він поєднує автоматичне сканування з ручним тестуванням і тестуванням допоміжними технологіями ключових шаблонів і сценаріїв, а наприкінці дає звіт із пріоритетами. Він потрібен, якщо на вас поширюється закон, перед великим запуском або коли клієнти просять доказів.

Перш ніж погодити ціну, запитайте:

• За яким стандартом, версією й рівнем ви перевірятимете?
• Які шаблони й сценарії входять до перевірки? Для магазину: головна, категорія, товар, кошик, оформлення замовлення, особистий кабінет і форми.
• Чи перевіряєте ви вручну зі скринрідерами, клавіатурою й масштабуванням і в яких браузерах та на яких пристроях?
• Чи ранжує звіт проблеми за серйозністю, чи вказує, де вони, і чи пропонує виправлення?
• Чи входить повторна перевірка?

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

Навіщо тестувати за участю користувачів з інвалідністю?

Бо відповідати стандарту й бути зручним — не одне й те саме. Оформлення замовлення може виконувати всі критерії WCAG і однаково забирати в користувача скринрідера двадцять хвилин. W3C пише, що оцінювання за участю користувачів з інвалідністю «виявляє проблеми зручності, яких не виявляє саме лише оцінювання відповідності», а ще воно показує вашій команді, як люди насправді користуються сайтом.

Лабораторія не потрібна. Кілька сесій щодо вашого найважливішого завдання, наприклад пошуку товару й оплати, навчать вас більшого, ніж ще один раунд сканувань. Шукайте учасників через організації людей з інвалідністю, дослідницькі агенції чи серед власних покупців і платіть людям за їхній час. Нехай вони користуються своїми пристроями й налаштуваннями. Практичний бік описано в посібнику W3C про залучення користувачів до оцінювання (відкриється в новій вкладці).

Що робити з результатами?

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

1. Розставте пріоритети. Спершу блокувальні проблеми в ключових сценаріях (оформлення замовлення, бронювання, реєстрація), потім спільні шаблони, потім окремі сторінки.
2. Виправляйте в джерелі. Змінюйте тему, компонент чи контент, а не лише симптом.
3. Перевірте знову. Повторіть ті самі перевірки — і вручну, і інструментами.
4. Задокументуйте. Перелічіть відомі проблеми з датами у своїй заяві про доступність. Новіші критерії пояснює наш посібник із WCAG 2.2.
5. Повторюйте. Додайте перевірку клавіатурою й сканування до кожного релізу.

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