15. Accessibility-First Design
Permalink to 15. Accessibility-First DesignThis section is normative; rationale is informative.
The following constraints on the language are deliberate, normative, and not to be relaxed by extensions:
- Targets MUST be expressed as role + accessible name (or as one of the
explicit
id/data-*escape hatches). CSS selectors and XPath are NOT part of the surface language. locateasserts visibility in the accessibility tree for every role token: the role query excludes elements hidden from assistive technology, so a visually present but accessibility-hidden element MUST causelocateto fail. Thefield,text,idanddata-*tokens do not consult the tree (§5.4), andlocateon them asserts CSS visibility only.focusasserts the element actually receives focus. Callingfocus()without verification is non-conforming. Receiving programmatic focus is not the same as being reachable by keyboard; that is asserted withkeyboardandverify: focus(§5.6.2).verify: alertchecksrole="alert". Visual-only error display does not pass.verify: field_errorchecks BOTHaria-invalid="true"AND a non-emptyaria-describedbyoraria-errormessagereferencing a visible message. Either alone is insufficient.verify: live_regionchecks a real ARIA live region — a live-region role (status,alert,log,marquee,timer) or an explicitaria-livedeclaration — examining every one on the page rather than one chosen by role priority. Narrowing is by role or by politeness; politeness is the only one that can name a region declared by the attribute alone. Polling a visual element by class is non-conforming; thearia-liveattribute is the semantic itself, not a visual hook.
The rationale: a use case is an accessibility test. If a target cannot be
addressed by role and name, the test failure is the finding. If focus() is
called but the document's active element does not become the target — it is
hidden, inert, disabled, or not focusable — the test failure is the finding.
The language is shaped so that the easy thing to write is also the right thing
to assert.