Pa11y 10 підняв вимоги до Node.js і оновив Puppeteer та axe-core

Pa11y 10 піднімає мінімальну версію Node.js до 22.13, переходить на Puppeteer 25 та axe-core 4.13. Це major-реліз без великої нової панелі чи API, але він змінює середовище запуску автоматизованих accessibility-тестів і може змінити самі результати перевірок. Командам потрібно оновити CI-образ, перевірити системні утиліти для браузера та переглянути новий baseline, не маскуючи реальні проблеми масовим прийняттям snapshot.

Node.js 22.13 стає нижньою межею

Pa11y 10 підтримує стабільні парні версії Node.js, починаючи з 22.13.0. Старі CI images на Node 20 більше не відповідають вимогам. Причина не лише в політиці підтримки: проєкт прибрав залежність kleur і використовує вбудований util.styleText, доступний із потрібної версії Node.

Під час міграції варто оновити всі точки запуску: локальний devcontainer, GitHub Actions або інший CI, Docker image та окремий scheduler для нічних перевірок. Якщо частина pipeline залишиться на старому Node, тести можуть падати ще до запуску браузера або, гірше, використовувати різні major-версії Pa11y.

Puppeteer 25 змінює браузерне оточення

Перехід із Puppeteer 24 на 25 виправляє проблему інсталяції браузерів, але додає залежність від platform-specific інструментів розпакування. Для більшості повних Linux images це непомітно; мінімальні Alpine/distroless образи та закриті runners потрібно перевірити окремо. У контейнері також мають бути системні бібліотеки, sandbox configuration та достатня shared memory.

Версія Chromium може впливати на layout, accessibility tree, фокус і timing. Тому невелика різниця результатів не завжди походить від змін axe. Відтворюйте тест з тією самою URL, viewport, locale, cookies і browser binary, перш ніж класифікувати regression.

axe-core 4.13 може змінити список порушень

Pa11y оновлює axe-core з 4.11 до 4.13. У цих версіях є виправлення правил, тому той самий HTML може отримати інший набір findings. Це очікувана зміна аналізатора, а не обов’язково новий дефект у продукті. Проте автоматично приховувати нові повідомлення не можна: кожне потрібно звірити з DOM, WCAG-критерієм і реальною поведінкою assistive technology.

Інший runner Pa11y може дати інший результат, тому в звітах корисно зберігати engine, версію, standard, URL, viewport і commit застосунку. Такий контекст дозволяє відрізнити зміну коду від оновлення правил.

Практичний висновок: створіть два звіти на одному commit — Pa11y 9 та Pa11y 10 — і перегляньте лише різницю. Це швидше й надійніше за повне перезатвердження baseline.

Залежності та операційна стабільність

Реліз також піднімає Commander до 15 і SemVer до 7.8, оновлює actions та документацію. Зміна Commander може бути помітною для обгорток, які викликають CLI, аналізують help output або покладаються на неофіційний порядок аргументів. Краще використовувати documented options і машиночитний reporter, а не парсити кольоровий консольний текст.

План переходу

• Зафіксувати Node 22.13+ та Pa11y 10 у тестовому CI job.
• Перевірити встановлення Chromium у чистому container image й на всіх архітектурах runner.
• Запустити однаковий набір сторінок Pa11y 9 і 10 та класифікувати delta.
• Не видаляти allow-list бездумно: перевірити, чи старі винятки ще відповідають реальним правилам.
• Додати ручну keyboard і screen-reader перевірку для критичних flows, бо автоматизація не покриває всю доступність.

Major-оновлення робить стек актуальнішим, але Pa11y залишається інструментом виявлення, а не доказом повної відповідності WCAG. Зелене проходження не оцінює зрозумілість тексту, логічність фокусу в усіх сценаріях або якість живого досвіду користувача.

Джерело та права

Матеріал є самостійним українським перекладом-переказом release notes Pa11y 10.0.0, опублікованих 28 серпня 2026 року учасниками Pa11y. Код, документація та release notes офіційного репозиторію поширюються за GNU Lesser General Public License v3.0. Перекладено, адаптовано й доповнено редакцією «Бібліотеки програміста». Обкладинка створена редакцією за допомогою AI і не входить до першоджерела.