Автоматичне та ручне тестування вебдоступності: у чому різниця

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

Більшість команд, принаймні поверхово, знайомі з вебдоступністю. Багато команд додають доступність ІТ-продуктів до базових вимог. А одним із найпростіших і найшвидших способів аналізу вебресурсу на доступність є використання автоматизованих інструментів. Зокрема, серед найпопулярніших є Axe та Google Lighthouse.

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

Але потім може виникнути запитання — чи дійсно все так просто і чи достатньо такої автоматичної перевірки?

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

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

Що таке автоматичне тестування вебдоступності

Автоматичне тестування доступності — це перевірка сайту на відповідність критеріям вебдоступності за допомогою автоматизованих інструментів. Вони аналізують код і структуру сторінки та перевіряють її на відповідність частині критеріїв WCAG (Web Content Accessibility Guidelines).

Найпопулярніші інструменти:

• Axe від deque
• Google Lighthouse

Зазвичай їх використовують двома способами.

Google Lighthouse вбудований в браузер Google Chrome і доступний в інструментах розробника. Тому найчастіше запускають перевірку сторінок в браузері через Lighthouse. Він формує звіт, де вказано моменти, які слід покращити, а також пункти, які успішно пройшли перевірку. Це доволі структурований звіт зі зрозумілими рекомендаціями.

Другий спосіб — це додавання автоматичного тестування вебдоступності окремим кроком до автотестів. Зокрема для цього використовують axe-core. Таким чином в звичайному циклі CI/CD відбуваються регулярні перевірки доступності продукту. Це корисно і зручно, оскільки нові зміни автоматично перевіряються і система повідомить, якщо з’явились нові порушення вимог вебдоступності.

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

• відсутність alt-текстів у зображень
• недостатній контраст контенту щодо фону (однак, не у всіх випадках)
• помилки з ARIA (ролі та ARIA-атрибути)
• відсутність label у формах
• порушення семантики або структури сторінки
• відсутність текстових альтернатив у кнопок або у посилань-іконок

У автоматизованого тестування є свої плюси:

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

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

Обмеження автоматичного тестування вебдоступності

Автоматична перевірка доступності дещо відірвана від реального досвіду користувача і не завжди тестує реальні сценарії взаємодії.

Перевіряються критерії WCAG, які можна формалізувати.

У практиці часто трапляються ситуації, коли вимога WCAG формально виконана, а фактично — ні.

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

Автоматизовані інструменти не перевірятимуть зрозумілість і відповідність тексту конкретному зображенню.

За оцінками розробників axe-core, за допомогою автоматизованої перевірки в середньому можна виявити приблизно половину (близько 50–60%) типових порушень WCAG, що описано в документації axe-core.

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

Приклади аспектів, які автоматичні інструменти не можуть повністю перевірити:

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

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

Що таке ручне тестування вебдоступності

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

Щоб перевірити основні сценарії взаємодії, зазвичай потрібна інтерпретація контексту.

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

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

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

Порівняння автоматичної та ручної перевірки вебдоступності

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

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

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

• швидкість виконання
• легкість впровадження (часто не вимагає спеціалізованого навчання)
• можливість автоматичних перевірок (в CI/CD)
• регулярність тестування
• менша ймовірність пропуску типової помилки через відсутність людського фактору

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

• глибокий аналіз взаємодії через розуміння контексту
• можливість виявити непомітну проблему в UX сторінки
• тестування сайту за допомогою асистивних технологій (як-от скринрідерів)

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

Оптимальним підходом є комбінація автоматичного та ручного тестування вебдоступності

Ці два підходи не конкурують один з одним, а доповнюють одне одного.

Аудит вебдоступності є комбінацією ручної перевірки з використанням автоматизованих інструментів.

В командах розробки бажано запровадити регулярне автоматичне тестування доступності ресурсу. Або окремим етапом тестування за допомогою Lighthouse, або ж додаванням етапу під час запуску автотестів. Це допоможе запобігти релізу типових порушень вебдоступності.

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

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

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

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