Аудит та консультації з вебдоступності

Проводимо аудит вебдоступності сайтів за WCAG 2.2.

Надаємо технічні рекомендації щодо покращення доступності інтерфейсів.

Залишити запит

Що входить в аудит вебдоступності

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

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

Відповідність критеріям WCAG 2.2
HTML-структура сторінки та семантика
Доступність контенту на сторінці для різних категорій відвідувачів
Зручність навігації сайтом з клавіатури
Взаємодія з інтерфейсом за допомогою асистивних технологій (скринрідерів)
Складні компоненти (модальні вікна, форми, випадні списки тощо)

Перевірка за стандартом вебдоступності WCAG 2.2

W3C (World Wide Web Consortium) займається розробкою рекомендацій для забезпечення цифрової доступності. Ці рекомендації представлені у вигляді списку критеріїв — WCAG (Web Content Accessibility Guidelines). Актуальною версією стандарту є WCAG 2.2, тому наші перевірки сайтів ґрунтуються саме на версії 2.2.

Існує три рівні відповідності WCAG:

A: базові вимоги доступності
AA: загальноприйнятий і рекомендований для більшості рівень
AAA: найвищий рівень відповідності стандарту WCAG

Ми тестуємо інтерфейси за кожним із цих рівнів, залежно від мети вашого проєкту.

Аналіз семантики та HTML-структури

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

Тому під час тестування доступності сайту перевіряється:

Логічність та зрозумілість структури сторінки
Наявність семантичних тегів та коректність їх використання
Правильне використання ARIA-атрибутів, зокрема дотримання першого правила ARIA

Тестування сайту за допомогою клавіатури

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

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

Основні сценарії без використання миші і тачпада
Доступність інтерактивних елементів з клавіатури
Видимість фокусу для розуміння поточного активного елемента
Логічність порядку навігації

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

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

Аудит складних компонентів

Складні та кастомні елементи потребують особливої уваги під час оцінки доступності.

До таких елементів належать:

Форми
Модальні вікна
Меню
Випадаючі списки
Каруселі із зображеннями чи текстом

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

Більше інформації ви можете знайти в нашому матеріалі Що входить в аудит вебдоступності.

Як проходить аудит доступності сайту

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

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

Зазвичай аудит складається з таких етапів:

Аналіз сторінок і сценаріїв користувача (user flows)
Тестування за допомогою автоматичних інструментів
Ручна перевірка доступності сторінок
Перевірка навігації сайтом за допомогою клавіатури
Тестування вебресурсу за допомогою скринрідера
Аналіз критеріїв WCAG 2.2
Формування звіту та рекомендацій

Ручне та автоматичне тестування доступності

Є швидкі способи перевірки вебдоступності сайту. Наприклад, за допомогою автоматизованих інструментів. Найпопулярнішим інструментом для попередньої перевірки доступності є Google Lighthouse, вбудований у браузер Google Chrome в інструментах розробника (DevTools).

Перевірити базову вебдоступність свого сайту можна прямо зараз:

Відкрийте сайт у Chrome
Відкрийте інструменти розробника (Windows: Ctrl + Shift + I; Mac: Cmd + Option + I)
Знайдіть панель Lighthouse в інструментах розробника
У Категоріях можна залишити одну галочку Accessibility (але можете перевірити й інші категорії)
Натисніть кнопку "Аналізувати"

Через декілька секунд Lighthouse сформує звіт із загальною оцінкою вебдоступності (максимально — 100 балів) та детальним описом виявлених проблем.

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

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

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

Що ви отримаєте після аудиту

Після завершення аудиту доступності ви отримуєте детальний технічний звіт, який містить:

Загальний підсумок (Summary): загальна картина доступності сайту, кількість перевірених сторінок, обсяг виявлених помилок і успішно пройдених перевірок.
Детальний звіт за критеріями WCAG: покроковий аналіз сторінок згідно з міжнародними стандартами доступності зі статусом (Pass, Fail, N/A) для кожного критерію.
Опис проблем та технічні рішення: кожне виявлене порушення містить детальний опис, приклади коду та технічні рекомендації щодо виправлення.
Пріоритезація за рівнями критичності: усім критеріям зі статусом Fail присвоюється ступінь важливості, що дозволяє вашій команді спланувати роботу та впровадити найнагальніші зміни першочергово.

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

Перевірка сайту nasa.gov

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

Результати перевірки сайту:

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

Рекомендації щодо виправлення:

Використати тег <button> замість <div role="button">
Додати заголовок першого рівня <h1>
Додати атрибут lang для частини контенту іншою мовою
Змінити порядок фокусу відповідно до інтерфейсу
Зробити повідомлення про помилки інформативнішими

Детальніше про результати перевірки та аналіз сайту читайте у статті на Medium Аудит вебдоступності на прикладі сайту nasa.gov.

Перевірка сайтів для пошуку роботи

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

Результати перевірки:

наявність aria-label у декоративних іконках, що створює шумове навантаження для користувачів скринрідера без змістової користі
Порушення ієрархічності структури HTML
Мета-теги не унікальні для кожної сторінки
Недостатня контрастність тексту та фону
Відсутність текстових альтернатив для інтерактивних елементів

Рекомендації щодо виправлення:

Видалити aria-label з елементів, які не мають смислового навантаження
Виправити ієрархічність певних HTML-елементів
Додати текст до мета-тегів (title, description), який описує конкретну сторінку
Змінити колір тексту на темніший
Додати aria-label до кнопок-іконок з описом їхніх функцій

Кому потрібен аудит вебдоступності

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

Категорії вебресурсів, які найчастіше потребують аудиту вебдоступності:

Інтернет-магазини (e-commerce)
Корпоративні сайти та сайти-візитки
Онлайн-сервіси та освітні платформи
Медичні установи
Ресурси, які надають державні та публічні послуги
Цифрові продукти перед релізом (наприклад, SaaS чи SPA)

Більше інформації ви знайдете в нашому матеріалі Кому потрібен аудит вебдоступності.

Варіанти співпраці

Консультація

Що входить:

Відповіді на запитання з вебдоступності
Пояснення вимог WCAG 2.2
Рекомендації під ваш проєкт

Підходить для:

Продуктових команд
Базового ознайомлення з доступністю

Залишити запит

Експрес-перевірка

Що входить:

Перевірка окремих UI-компонентів або функцій
Виявлення критичних проблем
Перевірка з Lighthouse

Підходить для:

Невеликих проєктів
Перевірки під час розробки
Базової оцінки доступності

Залишити запит

Аудит

Що входить:

Ручний аудит за WCAG 2.2
Тестування клавіатурою та скринрідером
Технічний звіт і рекомендації

Підходить для:

Сайтів і SPA-застосунків
Продуктів перед релізом
Моніторингу вебдоступності

Залишити запит

Вартість залежить від складності та кількості сторінок для перевірки. Пишіть — обговоримо ваш проєкт.

Поширені запитання про вебдоступність

Що таке A11y?

A11y — це скорочення від слова Accessibility (доступність). Між першою та останньою літерами "A" та "y" — 11 літер. Такий запис часто використовують у матеріалах про доступність.

Що таке аудит вебдоступності?

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

Чи достатньо автоматичного тестування?

Ні, тому що автоматизовані інструменти перевірки (як от Lighthouse) зазвичай виявляють лише частину порушень вебдоступності. Щоб оцінити зручність користування сайтом, необхідна ручна перевірка.

Чи проводиться ручне тестування?

Так, під час повного аудиту вебдоступності проводиться ручне тестування сайту. А саме:

Тестування навігації за допомогою клавіатури та скринрідера
Перевірка логічності та видимості фокусу
Аналіз структури та семантики сайту
Перевірка основних сценаріїв користувача та складних компонентів

Чи перевіряється доступність на мобільних пристроях?

Перевірка доступності на мобільних пристроях може входити в комплексний аудит вебдоступності. Необхідність такого тестування обговорюється індивідуально.

Чи перевіряються React та SPA-застосунки?

Так. React-застосунки, або Single Page Applications, створені за допомогою інших технологій, перевіряються на відповідність критеріям вебдоступності. Для таких продуктів рекомендовано проводити ручний аудит доступності, оскільки автоматизовані інструменти не здатні оцінити багато аспектів взаємодії користувача з інтерфейсом.

Чи відбувається тестування зі скринрідером?

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

Скільки часу займає аудит?

Термін проведення аудиту залежить від декількох факторів:

Складності проєкту та user flow
Кількості сторінок або екранів у SPA, які перевіряються
Підготовки сайту до аудиту

Для однієї сторінки повний аудит доступності може тривати до 2 робочих днів.

Що входить у фінальний звіт?

Кінцевим результатом аудиту вебдоступності сайту є структурований звіт, який містить:

Список критеріїв WCAG обраного рівня відповідності (A/AA/AAA) зі статусом (Pass, Fail, N/A)
Пояснення та технічні рекомендації щодо виправлень для виявлених порушень доступності
Рівні критичності для кожного порушення, що допомагає визначити пріоритетність у беклозі
Підсумкову сторінку, на якій видно загальний стан сайту: кількість успішно виконаних критеріїв та кількість аспектів, які слід покращити

Чи надаються рекомендації для виправлення проблем?

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

Як підготувати сайт до аудиту?

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

Зокрема, слід зробити такі речі для підготовки:

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

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

Готові розпочати?

Бажаєте перевірити вебдоступність сайту або отримати консультацію?

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

Залишити запит