Як воркшоп з доступності WCAG усунув 350+ помилок

Британська компанія, у якій я працювала, підпадала під дію Equality Act 2010, що зобов’язує забезпечувати доступність цифрових продуктів. Але попри юридичні вимоги, доступність не була інтегрована в процеси: сайт містив десятки бар’єрів, а інклюзія сприймалася як «приємний бонус», а не як частина якісного UX.

Проблема

Під час перших тижнів роботи я помітила, що:

• користувачі з порушеннями зору не могли навігувати клавіатурою;

• скрінрідери плутались у структурі сторінок;

• компоненти дизайн-системи не відповідали WCAG 2.1 AA;

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

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

Тоді я щойно завершила курс Inclusive Web Design у Projector, тож вирішила ініціювати зміни.

Дослідження та підготовка

Я провела експрес-аудит 12 ключових сторінок продукту.
На цьому етапі я:

• зібрала типові помилки відповідно до WCAG 2.1 AA;

• оцінила вплив кожної помилки на реальний досвід користувачів;

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

Освітній воркшоп: запуск змін

Я провела 1,5-годинний воркшоп для продукту, девелоперів і дизайнерів, де ми розібрали:

• закони та стандарти: Equality Act 2010, WCAG 2.1 AA, принципи POUR;

• реальні приклади бар’єрів на нашому сайті і й як вони ускладнюють користування;

• типові патерни помилок і їхній вплив на користувачів;

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

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

Зовнішній аудит: діагностика масштабу

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

• 350+ помилок по WCAG 2.1 AA;

• понад 50% — критичні, що унеможливлювали користування сайтом;

• найбільші провали: клавіатурна навігація, aria-атрибути, структура заголовків та контрасти:

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

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

Впровадження: системна робота

Ми розділили роботу на паралельні потоки:

Оновлення дизайн-системи

• перевірили всі UI-токени на контраст та масштабування;

• переписали кнопки, input-поля, модальні вікна й інші компоненти;

• додали state-поведінки для фокусу, ховерів, помилок та скрінрідерів.

  Переробка бібліотеки компонентів

• впровадили рекомендовані aria-labels, role;

• налаштували коректну читабельність скрінрідерами (NVDA, VoiceOver);

• усунули пастки фокусу та проблеми з клавіатурною навігацією.

  Автоматизація

• додали автоматичні перевірки (axe, WAVE API) у пайплайн;

• створили чеклісти WCAG для дизайнерів, девелоперів та тестувальників;

• інтегрували ручні перевірки у рев’ю процеси.

  Документація

Підготували внутрішній гайд із правилами:

• як створювати доступні компоненти;

• як писати alt-тексти та aria-описи;

• як перевіряти доступність перед релізом.

Документація стала основою для підтримки доступності після завершення проєкту.

Результати

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

• WCAG 2.1 AA — підтверджено;

• усі критичні помилки — усунуті;

• залишилися тільки low-impact issues, які не впливають на користування;

• дизайн-система стала повністю сумісною з технологіями доступності;

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

Висновки

Цей кейс довів мені кілька важливих речей:

• Доступність не можна «прикрутити» в кінці. Цей кейс показав, що спроба виправити доступність після релізу перетворюється на боротьбу з наслідками. Справжня інклюзія закладається на етапі архітектури та прототипування.

• Інвестиція в освіту команди дає найвищий ROI. Замість того, щоб я особисто фіксила кожен баг, я надала команді інструменти та знання. Тепер доступність підтримується силами самої команди без мого постійного нагляду.

• Compliance — це лише старт. Юридичні вимоги забезпечують доступ, але наше завдання — забезпечити зручність. Ми перейшли від формальної відповідності до створення справді якісного UX для всіх.
  

Доступність — це не технічна вимога, а фундамент якісного UX для всіх користувачів.

«Анастасія відіграла ключову роль у забезпеченні доступності нашої освітньої платформи. Вона проявила високий рівень самоорганізації, опанувавши стандарт WCAG 2.1 та інтегрувавши необхідні інструменти тестування в наш процес розробки. Особливо варто відзначити її внесок у навчання команди: Анастасія змогла трансформувати складні вимоги інклюзивності у зрозумілі гайдлайни, що значно спростило подальшу підтримку продукту»

- Анатолій Крисан, Engineering Manager

Анастасія Савушкіна

Експертка WCAGENTS