Як підготувати сайт до аудиту вебдоступності

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

Зокрема, ви можете ознайомитись з ними за посиланнями Що таке аудит вебдоступності сайту та Кому потрібен аудит вебдоступності.

У цій статті поговоримо про те, як підготуватись до аудиту доступності, щоб він був якомога якіснішим та кориснішим.

Навіщо готувати сайт до аудиту

Навіщо взагалі проводити підготовку перед аудитом вебдоступності?

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

Зокрема, підготовка до аудиту допомагає:

• пришвидшити сам процес перевірки
• отримати точніші результати
• не пропустити ключові етапи шляху користувача і протестувати їх

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

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

Визначення обсягу аудиту вебдоступності сайту

Відповідність вимогам WCAG є базовою частиною вебдоступності. Та не менш важливо, щоб користувач міг успішно пройти основні user flow та скористатися функціями сайту.

Зазвичай у вебресурсу є певний стандартний шлях користувача. Наприклад, здійснити покупку в інтернет-магазині (шлях від вибору товару до оплати) або залишити запит на певну послугу (заповнення форми зворотного зв’язку).

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

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

Перед аудитом доступності сайту варто зрозуміти такі речі:

• які основні сценарії користувача
• які сторінки потрібно перевірити
• чи потрібно перевіряти складні елементи (форми, модальні вікна, дашборди)
• чи потрібен аудит вебдоступності мобільної версії сайту

Так буде значно простіше оцінити обсяг роботи та не пропустити важливі сценарії.

Підготовка списку ключових сторінок та user flow

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

Також це допоможе скласти детальний список сторінок для аудиту.

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

Типовими сторінками для перевірки вебдоступності є:

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

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

Типові елементи для перевірки доступності:

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

Підготовка доступів (за необхідності)

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

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

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

Перед аудитом вебдоступності сайту команда може перевірити сайт автоматизованими інструментами (наприклад, Lighthouse або axe). Це робити не обов’язково, адже така перевірка теж є частиною аудиту.

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

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

Збір інформації про відомі проблеми

Перед аудитом дуже корисно зібрати інформацію про відомі проблеми.

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

Також команді може бути відомо про певні проблемні сценарії. Якщо такі є, про них варто повідомити перед перевіркою сайту.

Якщо команда розробки або продуктова команда припускає наявність порушень вебдоступності в певних місцях, їх також варто внести до списку.

Перед аудитом вебдоступності корисно буде зафіксувати:

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

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

Підготовка команди до результатів аудиту

Це доволі важливий етап, про який можна забути. До аудиту вебдоступності продукту зовнішнім спеціалістом часто ставляться як до екзамену. Однак аудит доступності має на меті, перш за все, покращити користувацький досвід клієнта, а не перевірити команду розробки продукту.

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

Тому всім замовникам аудиту варто ставитись до перевірки доступності як до допомоги, а не до звинувачень. Саме аудит допомагає виявити приховані моменти, скласти план для подальших покращень та розставити пріоритети.

Отже, варто пам’ятати, що метою аудиту є не “складання тесту”, а саме розуміння поточного стану доступності сайту.

Що НЕ потрібно робити перед аудитом

Щоб аудит вебдоступності сайту показав картину реального сайту, а не демоверсії, перед аудитом НЕ потрібно:

• робити зміни в коді нашвидкоруч лише задля того, щоб сайт успішно пройшов аудит
• додавати ARIA-атрибути до всіх елементів, щоб зробити їх доступнішими
• орієнтуватись на результати автоматизованих інструментів перевірки доступності
• приховувати сторінки або сценарії, які вважаються проблемними

Якісна підготовка до аудиту допоможе зробити перевірку доступності сайту ефективнішою та кориснішою.

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

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

Перед початком аудиту варто підготувати відповіді на такі запитання:

• Які сторінки або user flow є найважливішими для бізнесу?
• Чи потрібно перевіряти тестову версію сайту чи лише продакшн-версію?
• Чи потрібні тестові акаунти або доступ до закритих розділів?
• Чи є складні інтерактивні компоненти (модальні вікна, випадаючі списки, віджети)?
• Чи є окрема мобільна версія або окремі сценарії користувача саме для мобільного?
• Чи використовує сайт сторонні віджети або інтеграції?
• Чи були раніше скарги користувачів щодо доступності?
• Чи є сторінки або функції, які команда вважає проблемними?
• Чи є дедлайн або конкретна причина проведення аудиту (реліз, редизайн, підготовка до запуску тощо)?