Сайти й магазини
WCAG 2.2: як перевірити, чи сайтом можна користуватися
Доступність починається зі звичайного завдання: знайти інформацію, обрати варіант або поставити запитання. WCAG допомагає описати бар’єри та умови їх усунення. Одна оцінка сканера не показує, чи весь процес працює для різних людей.
Визначте сценарій і рівень перевірки
WCAG 2.2 — стандарт W3C із критеріями рівнів A, AA й AAA. У брифі зазначте версію та цільовий рівень. Загальна фраза «відповідає WCAG» не замінює звіту з обсягом, методом і результатами.
Оберіть типові екрани та повні завдання: меню, пошук, товар, кошик і контакт. Врахуйте помилки, підтвердження, зовнішні компоненти й мобільні пристрої. Самих скриншотів недостатньо, щоб перевірити перехід від одного стану до наступного.
Перетворіть чотири принципи на перевірку завдання
WCAG об’єднує вимоги навколо сприйнятності, керованості, зрозумілості та надійності. На практиці перетворіть ці принципи на запитання до одного процесу. Чи може людина отримати інформацію про послугу, вибрати варіант і продовжити? Чи розуміє умови та помилки? Чи отримують браузер і допоміжні технології правильні назви, ролі й стани? Привабливий екран у редакторі макетів не відповідає на всі питання. Потрібно перевіряти робочу взаємодію зі справжнім змістом, включно зі станами, які виникають після помилкової дії або відмови сервісу.
Приклад: форма реєстрації має читабельний текст, але після вибору дати додає нове поле без зрозумілого опису. Людина, яка користується програмою зчитування з екрана може не помітити зміни. Інша людина бачить помилку лише у вигляді кольору, якого не розрізняє. Обидві перешкоди стосуються одного завдання, але потребують різних виправлень. Спочатку опишіть сценарій і очікуваний результат, потім призначте технічні критерії. Відомості про код допомагають розробнику. Опис впливу дозволяє власнику сайту визначити пріоритет і перевірити, чи після зміни людина справді може завершити потрібний процес.
Що перевірити під час переходу з WCAG 2.1 на 2.2
Версія 2.2 додає дев’ять критеріїв до 2.1 та вилучає 4.1.1 Parsing. Вимоги мають рівні A, AA або AAA. Перелік нововведень сам собою не є повним аудитом. Попередні проблеми контрасту чи клавіатури залишаються актуальними. У замовленні зафіксуйте версію, цільовий рівень, мови, процеси й тестові середовища. Загальна фраза про відповідність WCAG недостатньо точно визначає роботу та її приймання. Виконавець і замовник мають однаково розуміти, що саме буде перевірено і які докази вони отримають.
Зверніть увагу на закріплені панелі, дрібні сусідні елементи, перетягування та вхід. Критерій 2.5.8 на рівні AA визначає мінімальну ціль 24 × 24 пікселі CSS із винятками, зокрема щодо відстані. Це не означає, що кожну кнопку варто робити рівно на межі. Наприклад, маленька іконка видалення поруч зі збільшенням кількості потребує практичного тесту на телефоні. Врахуйте ризик випадкового натискання протилежної дії. Розмір видимого символу та область натискання також є різними характеристиками. Під час перевірки оцінюйте обидві, а не лише геометрію намальованої іконки.
| Критерій | Тема | Рівень |
|---|---|---|
| 2.4.11 | Неперекритий фокус - мінімум | AA |
| 2.4.12 | Неперекритий фокус - розширений | AAA |
| 2.4.13 | Вигляд фокуса | AAA |
| 2.5.7 | Перетягування | AA |
| 2.5.8 | Розмір цілі - мінімум | AA |
| 3.2.6 | Послідовна допомога | A |
| 3.3.7 | Повторне введення | A |
| 3.3.8 | Доступна автентифікація - мінімум | AA |
| 3.3.9 | Доступна автентифікація - розширена | AAA |
Пройдіть меню, діалог і форму без миші
Оновіть сторінку та відкладіть мишу. Переходьте вперед клавішею Tab і назад через Shift+Tab. Спостерігайте за фокусом, порядком і можливістю пропустити повторювану навігацію. Відкрийте меню, розгорніть варіанти й дістаньтеся контакту. Перевірте, чи елементи закритої панелі випадково не залишаються доступними. Спробуйте невисоке вікно браузера: нижня закріплена панель може перекривати саме активну кнопку. Критерій 2.4.11 стосується повного перекриття компонента з фокусом вмістом, створеним автором. Перевірка лише на великому моніторі може не показати такого стану.
Для діалогового вікна запишіть початкове місце, спосіб закриття та повернення фокуса. Хрестик, схожий на кнопку, ще не є доказом правильної роботи. Дістаньтеся всіх полів, спричиніть помилку й виправте її без миші. Якщо інтерфейс вимагає перетягування, перевірте альтернативу без нього. W3C описує це в критерії 2.5.7 з винятками для необхідної дії та незміненої поведінки браузера. Підтримка клавіатури сама собою не вирішує всіх вимог до вказівника. Тому запишіть обидва шляхи, замість вважати успішний тест одного способу введення доказом доступності всіх інших способів керування.
Перевірте контраст, масштаб і порядок читання
Критерій 1.4.3 вимагає контраст щонайменше 4,5:1 для звичайного тексту та 3:1 для великого з визначеними винятками. Вимірюйте справжню пару кольорів, зокрема на фото, у темній темі й стані помилки. Колір, придатний на білому, може бути непридатним в іншому компоненті. Запишіть результат для конкретного використання. Логотип і декоративний текст оцінюють за іншими умовами, ніж опис послуги. Одна загальна автоматична відповідь для всіх елементів не забезпечує надійної перевірки й може приховати справжню проблему.
Перевірте макет за ширини, еквівалентної 320 пікселям CSS. Reflow має винятки для змісту, який потребує двох вимірів, наприклад певних таблиць. Практичне завдання полягає в читанні абзацу без постійного пересування всієї сторінки вбік. Таблиця може мати власне прокручування, але не повинна без потреби розширювати весь сайт. Оцініть заголовки, підписи та порядок читання. Якщо колонки переставляються на телефоні, пояснення має залишитися логічним. Збільшення тексту не повинно перетворювати назву кнопки на обрізаний фрагмент, який треба вгадувати за сусідніми елементами чи кольором оформлення.
Оцінюйте зображення та повідомлення в контексті
Текстова альтернатива має відповідати функції зображення. Дерево рішень W3C розрізняє декор, інформацію та зображення як елемент керування. Скриншот рахунку в інструкції може потребувати пояснення позначеного поля. Фактура паперу за заголовком не додає відомостей. Непорожній атрибут alt ще не доводить корисність опису. Напис «третє фото» мало пояснює, а повторення сусіднього абзацу може ускладнити слухання. Запитайте редактора, що саме з картинки потрібно зрозуміти для наступного кроку. Відповідь допоможе відділити зміст від декоративного оформлення.
У формах перевірте назви полів, інструкції до заповнення та пояснення конкретної помилки. Посібник W3C щодо сповіщень описує зрозумілі повідомлення, пов’язані з полями. Для неправильної електронної адреси потрібно пояснити виправлення, а не лише показати червону рамку. Перевірте й успішний стан: він означає фактичне прийняття даних чи лише дію браузера? Спробуйте порожнє надсилання, неправильні значення та помилку сервера з тестовими даними. Ці перевірки покажуть, чи людина розуміє помилку, може її виправити й продовжити роботу.
Оцініть вхід і повторне введення даних
Перевірте роботу менеджера паролів і можливість вставлення під час входу. Критерій 3.3.8 описує доступну автентифікацію, включно з допоміжними механізмами, альтернативами та винятками. Він не забороняє паролі загалом. Важливо, як людина проходить процес без зайвого запам’ятовування чи переписування. Перевірте реєстрацію, підтвердження, повторний вхід і відновлення доступу. Перешкода може з’явитися лише наприкінці. Доступний екран входу мало допомагає, якщо надалі неможливо відновити обліковий запис або зрозуміти інструкцію після невдалої спроби. Усі ці кроки мають потрапити до одного сценарію.
Наприклад, магазин дозволяє вставити пароль, але блокує вставлення коду підтвердження та повторно запитує вже вказану адресу. Оцінюйте ці елементи окремо в реальному процесі. Зафіксуйте джерело коду, необхідні дії та підказки після помилки. Не усувайте захист облікового запису як нібито просте рішення. Разом із відповідальним за безпеку виберіть доступний спосіб. Безпека та зручність потребують окремого оцінювання, але їх варто обговорювати спільно ще під час дизайну. Поліпшення одного напряму не має послаблювати інший чи просто переносити складність на обов’язковий телефонний дзвінок до служби підтримки.
Описуйте бар’єри так, щоб їх можна було відтворити
Корисний запис містить адресу, стан сторінки, середовище, кроки, очікуваний і фактичний результат. Додайте вплив на завдання, відповідний критерій та докази без даних клієнтів. Приклад: після відкриття способів доставки клавіатурою неможливо повернутися до форми, тому оформлення зупиняється. Це корисніше за напис «помилка ARIA». Розробник має розуміти, що виправляти, а перевіряльник як оцінювати результат. Скриншот допомагає, проте часто не передає взаємодію, що спричинила проблему. Зафіксуйте послідовність, а не лише остаточний вигляд екрана після збою.
Визначайте пріоритет за впливом і поширенням. Помилка спільного меню може стосуватися багатьох сторінок, одна проблема оплати може блокувати головний процес. Групуйте повтори, залишаючи конкретні приклади. Після виправлення повторіть залежний сценарій та перевірте інші місця використання компонента. Не закривайте запис лише тому, що код змінився. У звіті відрізняйте виправлені, відкриті та неперевірені ділянки. Неперевірене не означає справне. Зі звіту власник має розуміти, які завдання клієнтів працюють, а які залишаються заблокованими. Саме такий опис дозволяє планувати наступні кроки й не втрачати важливі бар’єри серед дрібних зауважень.
Збережіть доступність у подальших публікаціях
Після аудиту підготуйте правила для редакції та дизайнерів: назви посилань, описи зображень, підписи полів і нові варіанти компонентів. Перед зміною кошика, меню або зовнішнього віджета повертайтеся до записаних сценаріїв. Автоматизація допомагає повторюваним перевіркам, але потрібне також людське оцінювання. За можливості залучайте людей з інвалідністю до тестів конкретних завдань. Їхня участь не є автоматичним сертифікатом усього сайту. Вона дає відомості про дії та перешкоди, які легко пропустити під час перегляду коду або статичного зображення інтерфейсу.
Почніть із важливого процесу, тестового середовища та відповідального за виправлення. Визначте обсяг аудиту й очікуваний звіт до замовлення. Звертаючись до DigiDraft, надайте адресу, головні завдання клієнтів, зовнішні модулі та відомі проблеми. Це дозволить обговорити перевірку справжньої послуги. Правові вимоги визначайте окремо для ситуації компанії. WCAG є технічним стандартом; позитивний автоматичний результат чи готова декларація не підтверджують усіх обов’язків. Корисний результат складається з робочого процесу, документованих виправлень і способу виявляти повернення бар’єрів після наступного оновлення. Перевірка має продовжуватися разом із розвитком сайту, а не завершуватися одним отриманим файлом звіту.
Запитання та відповіді
Чи підтверджує високий бал сканера відповідність WCAG 2.2?
Він не підтверджує відповідність усього сайту. Сканер виявляє частину проблем, але потрібні також ручні перевірки завдань, станів помилок і роботи з допоміжними технологіями. У звіті слід зазначити версію WCAG, рівень, обсяг і метод оцінювання.
З чого почати перевірку сайту клавіатурою?
Відкладіть мишу й переходьте клавішею Tab між меню, кнопками та полями форми; Shift+Tab повертає назад. Перевірте, чи видно активний елемент, чи можна відкрити й закрити діалогове вікно та виправити помилку у формі. Запишіть, де саме не вдається завершити завдання.
Що має містити повідомлення про бар’єр доступності?
Вкажіть адресу, середовище перевірки, кроки, очікувану поведінку та фактичний результат. Опишіть наслідок для користувача, наприклад неможливість вибрати доставку. Після виправлення повторіть увесь сценарій, а не лише перевірку зміненого елемента.