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.

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

Сценарии

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.

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.

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.

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.