Web accessibility: semantic contracts, focus и human verification

Accessibility — качество всей пользовательской задачи, а не атрибут одного компонента. Native HTML semantics, keyboard operation, visible focus, accessible names, status announcements, zoom/reflow и понятные errors должны работать вместе в реальном browser/assistive-technology сочетании.

WCAG 2.2 — нормативный стандарт conformance; ARIA APG — полезное, но informative руководство. ARIA может дополнить semantics сложного widget, но не добавляет keyboard behavior автоматически и не заменяет native element.

Проверяемые утверждения

• Интерактивная функция должна быть доступна с keyboard без trap; logical focus order и видимый focus indicator являются частью поведения.
• Name, role, state и value должны соответствовать фактическому control. Неправильная ARIA может ухудшить доступность по сравнению с native HTML.
• Status message, который не меняет context, должен быть доступен assistive technology без принудительного перемещения focus, когда применим WCAG 4.1.3.
• Automated checks находят ограниченный класс нарушений. Conformance и usability требуют keyboard, screen-reader, zoom/reflow, contrast и human task testing.

Границы и компоненты

Компонент	Роль в модели
Rendered Browser UI	expose semantics; operate and move focus; publish status; task execution
Semantic DOM and Accessibility Tree	expose semantics; query name role state; rule inspection
Keyboard and Focus Contract	operate and move focus
Assistive Technology	query name role state; receive status
Accessible Status Region	publish status; receive status
Automated Rule Checks	rule inspection; collect machine evidence
Human Task Tests	task execution; collect human evidence
Evidence-based Release Gate	collect machine evidence; collect human evidence

Сценарии

▶Walkthrough: operate-with-keyboard (not found)

Complete the task with a keyboard

A user traverses controls in logical order, opens a dialog, remains inside its intentional modal focus scope and returns focus to the invoking control after close.

Проверяемый исход: Every action is keyboard-operable, focus is visible, no trap exists, and focus return preserves context.

▶Walkthrough: expose-name-role-state (not found)

Expose accurate name, role and state

A native control supplies semantics. When a custom composite widget is unavoidable, implementation follows its complete keyboard and ARIA contract and is tested in supported combinations.

Проверяемый исход: Assistive technology receives the same purpose and current state conveyed visually; duplicated or conflicting labels are rejected.

▶Walkthrough: announce-async-status (not found)

Announce an asynchronous status

Saving finishes without navigation. The page updates a suitable status region so screen-reader users receive success or error while focus stays on the working control.

Проверяемый исход: The message is perceivable without an unexpected context change and error recovery remains keyboard reachable.

▶Walkthrough: verify-beyond-automation (not found)

Verify beyond automated checks

CI runs deterministic rules, then humans execute critical tasks with keyboard, zoom/reflow and representative assistive technology. Findings are tied to WCAG criteria and user impact.

Проверяемый исход: A clean scanner cannot by itself release the experience; the gate records both machine and human evidence plus known support scope.

Failure, concurrency и evolution checklist

• Test loading, empty, error, validation, timeout and permission-denied states; accessibility often regresses outside the happy path.
• After route/modal/list updates, define focus retention or movement intentionally. Do not reset focus to document body accidentally.
• Run regression tests against supported browser and assistive-technology combinations, while documenting that APG examples are illustrative rather than production certification.
• Treat a reported blocker as a product defect with severity and affected task, not as optional polish.

Security и privacy

• Do not weaken authentication, timeout or confirmation safeguards for accessibility. Provide an accessible equivalent with sufficient time and recovery.
• Avoid putting secrets into live regions, accessible names or hidden DOM: assistive APIs and extensions may expose them.
• CAPTCHA, biometric or drag-only challenges require an accessible non-discriminatory alternative and equivalent risk controls.

Метрики, формулы и допущения

• WCAG AA text contrast uses (Llighter + 0.05) / (Ldarker + 0.05): at least 4.5:1 for normal text and 3:1 for large text under the criterion definitions.
• Coverage is task-based: critical_tasks_tested / critical_tasks_in_scope. Counting scanned DOM nodes is not a substitute for task coverage.
• Defect escape rate needs a defined denominator and observation window; automated-pass percentage does not estimate accessibility conformance.
• Target-size and focus-appearance calculations use CSS pixels and WCAG 2.2 exceptions; do not convert them to physical millimetres without device assumptions.

Числа и bounds выше действуют только при названных units, population и assumptions. Ни паттерн, ни browser API сами по себе не задают SLA, capacity или correctness.

Решения для production review

• Start with semantic HTML and platform behavior; add ARIA only for semantics the native element cannot express.
• Define keyboard/focus/status behavior in the component contract and acceptance tests before implementation.
• Gate critical tasks with both automated and human evidence, including disabled/slow/error states and representative assistive technology.

Первичные и официальные источники

• https://www.w3.org/TR/WCAG22/
• https://www.w3.org/WAI/ARIA/apg/about/introduction/
• https://www.w3.org/TR/wai-aria-1.2/
• https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html

Scope note

Диаграмма обучает архитектуре accessibility evidence. Она не является юридическим заключением, VPAT/ACR, полным WCAG audit или гарантией работы во всех assistive-technology combinations.