Як ми автоматизували VPAT доступності в CI Як ми автоматизували VPAT доступності в CI
Аудити доступності швидко застарівають. Одне злиття коду змінює все.
Ми це виправили. Ми перетворили наші звіти про доступність на артефакт безперервної збірки.
Наш конвеєр використовує три рівні для пошуку помилок:
- Статичні перевірки: ми використовуємо axe-core для базових тестів у Storybook.
- Інтерактивні тести: ми використовуємо кастомні хелпери Vitest для тестування правил роботи з клавіатурою.
- Ручні аудити: ми зберігаємо результати роботи скрінрідерів у файлах JSON.
Наш CI-конвеєр об'єднує ці результати.
Якщо тест не проходить, PR не проходить. Якщо всі тести пройдені, система створює новий PDF. Цей PDF постачається разом із вашим релізом.
Ми спробували одну річ, яка не спрацювала.
Ми намагалися використовувати LLM для заміни ручних аудитів. Ми негайно припинили це робити. Результати ШІ занадто нестабільні. Для CI-gate потрібні стабільні результати.
Прочитати повний технічний розбір тут:
Джерело: https://dev.to/yassine_lakhdar_d0226709a/how-we-automated-our-accessibility-vpats-in-ci-46jk
ARTICLE: Команда розробників автоматизувала створення VPAT доступності (Voluntary Product Accessibility Templates) безпосередньо у своєму конвеєрі безперервної інтеграції (CI), перетворивши те, що раніше було періодичним ручним звітом, на артефакт збірки, який постачається з кожним релізом. Новий робочий процес блокує pull requests, які вносять регресії доступності, і автоматично створює PDF-документ про відповідність, коли збірка успішна, гарантуючи, що кожна зміна коду відповідає стандартам доступності.
Why automation matters
Аудити доступності стають неактуальними в той самий момент, коли з'являється новий код. Одне злиття може призвести до відсутності alt-тексту, неправильного порядку фокусування або проблем із скрінрідерами, що робить попередній VPAT недійсним. Підтримання відповідності вручну означає повторне проведення аудитів після кожної зміни — це витратний і схильний до помилок процес, який часто відстає від швидкості розробки. Впроваджуючи перевірки в CI, команди отримують миттєвий зворотний зв'язок, підтримують актуальність відповідності стандартам і уникають юридичних та репутаційних ризиків, пов'язаних із випуском недоступного програмного забезпечення.
The three-layer testing approach
Static checks – Конвеєр запускає axe-core, бібліотеку з відкритим кодом, яка сканує компоненти, відрендерені в Storybook, на наявність відомих порушень, таких як відсутність знакових елементів (landmarks) або недостатній колірний контраст. Ці тести виявляють проблеми ще до будь-якої взаємодії.
Interactive checks – Кастомні хелпери Vitest перевіряють правила навігації за допомогою клавіатури, підтверджуючи, що фокус переміщується логічно, а інтерактивні елементи реагують на стандартні події клавіатури. Цей рівень виходить за межі статичного аналізу, щоб забезпечити реальну зручність використання.
Manual audit artifacts – Результати тестування скрінрідерами зберігаються у файлах JSON. Розробники фіксують спостереження під час дослідницького тестування та комітять JSON разом із кодом. CI-завдання об'єднує ці артефакти з автоматизованими результатами, створюючи єдине джерело істини для VPAT.
Якщо будь-який тест у перших двох рівнях не проходить, pull request блокується, що не дозволяє зміні потрапити у продакшн. Якщо всі тести пройдені, конвеєр збирає комбіновані дані в PDF, який додається до релізу, забезпечуючи актуальний VPAT без додаткових зусиль.
What didn’t work
Команда експериментувала з використанням великої мовної моделі (LLM) для автоматичної генерації частини ручного аудиту. Результати, створені ШІ, були занадто нестабільними, що робило CI-gate ненадійним. Послідовність є важливою для бінарної перевірки "пройдено/не пройдено", тому від експерименту відмовилися на користь ручних артефактів на основі JSON.
What to watch next
Наразі трирівнева модель CI пропонує прагматичний шлях для підтримки актуальності VPAT, зменшення ручних витрат і забезпечення пріоритетності доступності в кожній зміні коду.