Як перевірити сайт на відповідність WCAG, крок за кроком

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

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

Крок 0: що тестувати (вибірка)

Перевіряти кожну сторінку доводиться рідко. Методика оцінки відповідності вебсайтів WCAG (WCAG-EM) від W3C описує п'ять кроків: визначити обсяг, дослідити сайт, вибрати репрезентативну вибірку, оцінити вибірку і викласти результати у звіті. Для вибірки вона поєднує структуровану вибірку з кількома випадково вибраними сторінками.

Для інтернет-магазину структурована вибірка зазвичай охоплює:

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

Запишіть версію і рівень WCAG (наприклад, WCAG 2.2 AA), браузери й допоміжні технології, якими користуєтеся, і дату. Це знадобиться для вашої інформації про доступність.

Крок 1: автоматичне сканування

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

• Перевірте одну сторінку безкоштовно нашим WCAG тестером або всі сторінки сайту з тарифом Pandus.
• Сторінки після входу, кошик і оформлення замовлення перевіряйте нашим розширенням для браузера.
• Інші інструменти порівняно в статті інструменти для тестування доступності.

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

Крок 2: тестування з клавіатури

Відкладіть мишу і користуйтеся лише клавіатурою:

Перевірте, що:

1. Усе працює з клавіатури — меню, фільтри, параметри товару, додавання в кошик, оформлення замовлення, банер cookie (2.1.1).
2. Фокус ніде не застрягає — у спливному вікні, чат-віджеті чи вбудованому плеєрі (2.1.2).
3. Фокус завжди видно (2.4.7) і він не ховається під липкою шапкою чи банером (2.4.11).
4. Порядок логічний і відповідає візуальному (2.4.3).
5. Посилання для пропуску або орієнтири дають змогу оминути меню (2.4.1).
6. Діалоги переносять фокус усередину, коли відкриваються, і повертають його назад, коли закриваються.

Крок 3: збільшення, перекомпонування та інтервали в тексті

1. Збільште сторінку в браузері до 200 %: жоден текст не обрізано, нічого не накладається, усім можна користуватися (1.4.4).
2. Збільште до 400 % або зробіть вікно шириною 320 CSS-пікселів: текст переноситься, для читання не потрібна горизонтальна прокрутка (1.4.10).
3. Застосуйте більші інтервали в тексті: нічого не обрізано (1.4.12).
4. Поверніть телефон: сторінка працює в портретній і альбомній орієнтації.

Більше про розміри — у статті розмір шрифту за WCAG.

Крок 4: тестування з екранним читачем

Екранний читач (скринрідер) показує, чи зрозуміла сторінка без зору. Використовуйте щонайменше одну настільну і одну мобільну комбінацію:

• NVDA (безкоштовний, Windows) з Firefox або Chrome;
• VoiceOver (вбудований у macOS та iOS) із Safari;
• TalkBack (вбудований в Android) із Chrome.

Прислухайтеся, чи є:

• змістовний заголовок сторінки і структура заголовків, якою можна переходити (1.3.1);
• описи зображень, які кажуть те, що важливо (1.1.1);
• кнопки й посилання, які кажуть, що вони роблять: «Додати в кошик», а не «Кнопка» (4.1.2);
• повідомлення про стан, як-от «Додано в кошик» чи «3 результати», які зачитуються без переміщення фокуса;
• підписи полів, обов'язкові поля й помилки, що зачитуються разом із полем.

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

Крок 5: форми й оформлення замовлення

Пройдіть кожну форму і навмисно помиліться:

• кожне поле має видимий підпис, а не лише підказку-placeholder;
• помилки описано текстом біля поля, з підказкою, як виправити (3.3.1);
• уже введені дані не запитуються знову (3.3.7);
• вхід дозволяє менеджери паролів і вставлення, а головоломки мають альтернативу (3.3.8);
• для імені, email, адреси й телефону задано атрибути autocomplete;
• обмеження часу можна продовжити, а замовлення можна перевірити перед надсиланням.

Крок 6: медіа, колір і рух

• Відео мають субтитри (1.2.2); для лише аудіо є текстова розшифровка.
• Ніщо не відтворює звук автоматично довше трьох секунд без можливості його зупинити.
• Каруселі й анімації можна призупинити.
• Колір не є єдиним сигналом для помилок, наявності товару чи посилань у тексті.
• Текст і елементи керування мають достатній контраст; неочевидні випадки перевіряйте калькулятором контрасту.

Крок 7: фіксуйте і перевіряйте повторно

Записуйте кожну проблему зі сторінкою, елементом, критерієм WCAG, знімком екрана і серйозністю. Виправляйте за впливом: спершу те, що блокує покупку або вхід. Перевіряйте знову після кожного релізу, оновлення теми чи нового застосунку — після змін проблеми доступності часто повертаються. Щотижневий моніторинг ловить автоматизовану частину таких повернень.

Коли замовити аудит доступності

Власні тести — добра регулярна практика, але це не аудит. Замовте професійний аудит доступності, коли вам потрібна декларація відповідності, перед запуском чи публічним тендером, після скарги чи листа-вимоги або коли результати незрозумілі. Аудитор перевіряє всі критерії рівня вручну, кількома допоміжними технологіями, і документує методику. Для державних сайтів в Україні вимоги до приймання описано у статті про ДСТУ EN 301 549 і постанову №757.

Відповіді на часті питання

Що таке тестування за WCAG?

Це перевірка сайту за критеріями успіху настанов з доступності вебвмісту (WCAG). Вона поєднує автоматичні тести, які швидко знаходять проблеми в коді, з ручними тестами людиною з клавіатурою, збільшенням і екранним читачем.

Чи можна повністю автоматизувати тестування за WCAG?

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

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

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

З яким екранним читачем тестувати?

NVDA з Firefox або Chrome на Windows, VoiceOver із Safari на macOS та iOS і TalkBack із Chrome на Android. Тест з одним настільним і одним мобільним екранним читачем знаходить більшість проблем.

Скільки сторінок треба перевірити?

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

Коли потрібен професійний аудит доступності?

Коли вам потрібна декларація відповідності, перед публічним запуском чи тендером, після скарги або листа-вимоги, або коли власні тести залишають відкриті питання. Аудит охоплює всі критерії вручну; автоматична перевірка — ні.

Джерела

• W3C, WCAG-EM overview: https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/
• W3C, Easy Checks — a first review of web accessibility: https://www.w3.org/WAI/test-evaluate/preliminary/
• W3C, WCAG 2.2: https://www.w3.org/TR/WCAG22/