Testing and evidence contract
Evaluation layers
Use automated checks for repeatable detectable conditions, deliberate keyboard tests for interaction, rendered visual inspection for appearance and reflow, assistive-technology testing for exposed behavior, and content/user review for meaning and usability. No automated tool determines accessibility conformance on its own. [S-TOOLS]
Playwright can drive interactions and integrate axe-based checks, including states revealed after user actions. This is a possible implementation stack, not a requirement of the grammar. Select versions compatible with the repository, pin them, and record them in reports. Automated checks cover only a subset of accessibility issues. [S-PLAYWRIGHT]
Protocol A — Automated support
Use build-controlled test fixtures. Enter the intended route, role and state before scanning. Include dialogs, validation failures and asynchronous responses. Store raw tool output, tool/rule versions and the DOM context needed to reproduce an issue. Review tool results marked incomplete or uncertain.
Map a tool rule to its actual assertion and criterion coverage. Do not equate an engine's list of success-criterion tags with full evaluation of those criteria. Excluding a selector requires a documented scope decision and must not hide failures in a covered page.
Protocol B — Keyboard interaction
From a predictable starting point, navigate to the component, identify focus, operate it, cancel or close it, and continue the task. Check forward/back navigation, standard activation and any selected composite-widget key pattern. Repeat after state changes and at the relevant zoom/layout conditions.
Record the focus path and action results. A single successful Tab press does not prove that the complete operation is keyboard accessible. Define standard keys from the selected widget/native behavior, not from a universal rule that every element must respond identically. [SC-2.1.1, SC-2.1.2, SC-2.4.3, SC-2.4.7]
Protocol C — Rendered appearance
Measure applicable contrast pairs without rounding a failing ratio upward. Review backgrounds, transparency and state changes. Test text enlargement and the reflow viewport independently. Apply supported spacing overrides simultaneously, then inspect and operate the result. [SC-1.4.3, SC-1.4.4, SC-1.4.10, SC-1.4.12]
For target spacing, use the actual hit area and specified geometry rather than a generic gap token. For focused controls, distinguish partial from total authored obstruction. [SC-2.5.8, SC-2.4.11]
Protocol D — Assistive technology
Record operating system, browser, assistive-technology name/version, interaction mode and settings. Check the component name, role, state/value, reading relationships and the actual outcome/announcement of relevant interactions.
A DOM accessibility snapshot is useful evidence about exposed semantics, but not a substitute for an observed speech/Braille interaction. An AI agent without the necessary environment must create a manual task and record NOT_TESTED or BLOCKED, not a fabricated pass.
Protocol E — Meaning and task completion
Review whether descriptions, labels, instructions, captions and errors actually convey the required meaning. Observe whether representative users can complete the intended task, recover from errors and understand the result. Give participants an accessible consent process and avoid unnecessary collection of disability or health details.
User evaluation supplies important evidence but does not replace criterion-by-criterion evaluation. Record sample limitations and do not generalize one user's experience to everyone. [S-USERS]
Evidence record
execution_id, rule_id, criterion_ids, rule_version
scope_id, route, component_instance, journey_step, state_before, state_after
build_commit, fixture_id, timestamp, evaluator
browser, OS, viewport_CSS_px, zoom, locale, role, theme/preferences
assistive_technology_and_settings (when used)
applicability + reason
steps, expected_result, observed_result
verdict, exception_clause_and_proof (when used)
artifact_references, tool_versions
reviewer, repair_issue, regression_test_referenceEvery artifact reference must identify an existing record. Screenshots, logs and recordings must avoid secrets, payment details and identifiable customer data. Use controlled fixtures rather than real production accounts.
Defect and retest contract
A defect records the user-task impact before its suggested fix. Deduplicate by source cause while retaining all known affected instances. Retest the original reproduction and consumers of the changed component. Preserve the original failed evidence and link a new passing record to the repair.
Tool warnings may need confirmation before being classified as criterion failures. Conversely, a manually confirmed failure remains a failure even when no scanner flags it. Priority and WCAG level are separate fields.