Чому accessibility tree має значення
Chrome вказує, що агенти переглядають accessibility tree, щоб знаходити interactive elements. Видима кнопка без programmatic name може заблокувати screen-reader user і змусити агента вгадувати дію.
Tree не є другою версією сайту. Це похідне представлення rendered page. Native elements, коректні labels і valid relationships зазвичай працюють краще, ніж масове додавання ARIA до вже неоднозначного інтерфейсу.
Які сигнали варто перевіряти
Lighthouse виділяє names and labels, tree integrity і visibility як agent-centric accessibility signals. Це корисні deterministic checks, але вони не доводять працездатність повного customer journey.
- Controls мають унікальні accessible names, пов'язані із задачею.
- Roles відповідають поведінці, а parent-child relationships є valid.
- Interactive content не прихований від accessibility tree.
- Disabled, expanded, selected, invalid і busy states оновлюються коректно.
- Form errors пов'язані з полями й надають recovery path.
Тестуйте задачу, а не лише node
Control може пройти label check і все одно зламати journey. Назва може бути технічно присутньою, але неоднозначною серед повторюваних actions. Calendar може показувати buttons, але втрачати selected date після navigation.
Поєднуйте static checks з agent scenario, який має визначену goal, allowed actions і deterministic final-state assertion. Зберігайте accessibility snapshot і visible state у точці failure.
Keyboard behavior завершує contract
Named control не є usable, якщо focus не може його досягти, activation відрізняється від native pattern або modal повертає focus у невідоме місце. Тестуйте той самий journey через keyboard input, бо він виявляє defects у порядку, focus management і composite widgets, яких не видно у static tree snapshot.
Віддавайте перевагу native HTML behavior. Якщо custom widget необхідний, дотримуйтеся established keyboard pattern і перевіряйте focus order, visible focus, escape behavior та selected або expanded state після кожної дії.
Dynamic states потребують observable recovery
Loading, validation, empty, error і success states мають залишатися доступними людям та агентам. Visual spinner без accessible busy state, error без зв'язку з field або toast, що зникає до inspection, можуть перетворити recoverable issue на blocked task.
Зберігайте visible UI та accessibility tree до й після transition. Перевіряйте, що intended object, form value або server state змінився рівно один раз, а retry не створює duplicate action.
- Показуйте актуальні busy, invalid, expanded, selected і disabled states
- Пов'язуйте instructions та errors з affected control
- Переміщуйте focus лише коли change потребує негайної уваги
- Зберігайте success confirmation достатньо довго для verification
Accessibility не замінює layout stability
Chrome також визначає Cumulative Layout Shift як agentic browsing signal. Агент може правильно знайти target через semantics і натиснути не туди, якщо late content рухає інтерфейс під час action window.
Вимірюйте CLS сторінки й target movement навколо важливих actions. Резервуйте dimensions для media, не вставляйте banners над активними controls і узгоджуйте loading states з final layout.
Accessibility checks для agent-readiness audit
- Віддавати перевагу native elements і перевіряти custom widgets за established interaction pattern.
- Зберігати accessibility tree до й після важливих state changes.
- Порівнювати visible labels з accessible names для повторюваних controls.
- Виконувати primary actions через keyboard і accessibility-tree-driven executor.
- Перевіряти error, loading і success states deterministic assertions.
- Вимірювати CLS і target displacement під час action windows.
Первинні джерела
- Accessibility for agentsChrome for Developers
- Lighthouse agentic browsing scoringChrome for Developers
- The accessibility treeweb.dev
- ARIA Authoring Practices GuideW3C Web Accessibility Initiative