Accessibility Test Cases

Product guide

Internal checks, review and publication authority

Guidance on Internal checks, review and publication authority for using the Accessibility Test Cases template library, package boundaries and evidence workflow.

Automated checks are internal integrity controls

Every maintained procedure receives two deterministic internal review passes recorded as accessibility-agent-review.v2. Those passes check template fields, mappings, exception logic, duplication, calibration structure and claim boundaries against the maintained source. They are internal consistency evidence only; they are not independent verification or authority for regulatory accuracy, completeness, publication or sale.

The internal ledger may mark generated content current without a named person. Source/procedure_reviews/ provides a separate facility for recording a qualified review when the candidate's intended use or an organisation's governance requires one.

Automated checks do not create legal clearance, real-product or real-platform evidence, participant evidence, WCAG conformance, professional acceptance or organisational publication authority.

Separate formal-claim status

Catalogue governance status remains separate from internal integrity checks:

  • draft
  • in_review
  • reviewed
  • approved
  • deprecated
  • superseded
  • withdrawn

The current procedures retain draft as a formal-claim boundary even when generated files and internal review records are current. This prevents an integrity signal from being mistaken for a completed audit, a conformance claim, independent review or authority to publish an edition.

authoring_readiness remains a source-authoring field (needs_revision, content_complete or ready_for_agent_verification). The final value means only that the procedure is ready for the repository's internal deterministic review passes.

Optional peer review

An organisation may use accessibility-procedure-review.v1 to record a named author, method reviewer, independent standards reviewer, competence evidence, source versions, reviewed dimensions, findings, disputes, decision and next review date. Where independence is claimed, the identities must be distinct.

Prepared peer-review records are blank templates, not evidence. If an intended use, contract, regulator, procurement policy or internal quality system requires named or independent review, that requirement must be completed and recorded truthfully for the exact candidate.

Release authority and evidence

The following remain separate because the repository cannot truthfully manufacture them from template content:

  • qualified legal or intellectual-property decisions;
  • evidence from a real target, device, browser, operating system or assistive technology where the intended claim depends on it;
  • consented observations involving disabled participants;
  • an organisation’s decision to publish, license, price or sell an edition;
  • a WCAG or other conformance claim about a tested product.

The strict npm run verify:release mode can validate the structure of a manual evidence packet when an organisation chooses that workflow. No automated mode replaces source-accuracy review, real-platform or participant evidence, legal decisions, or organisational publication authority when those are required for the intended use.

Commands

Run or validate the internal deterministic checks:

python3 Source/review_cli.py agent-review --all --force
python3 Source/review_cli.py coverage --require-agent
python3 Source/review_cli.py stale
python3 Source/review_cli.py validate Source/agent_reviews/A11Y-WCAG-001.json

Optionally prepare and validate a named peer-review record:

python3 Source/review_cli.py prepare --case A11Y-WCAG-001
python3 Source/review_cli.py seal Source/procedure_reviews/A11Y-WCAG-001.json
python3 Source/review_cli.py validate Source/procedure_reviews/A11Y-WCAG-001.json --require-complete

Sealing proves record integrity only. It does not verify a person’s identity, competence or authority.

Status changes

A formal governance transition must preserve the prior version and record its reason. reviewed or approved must not be inferred from internal automation because those labels may carry organisational meaning beyond generated-file integrity. Deprecation, supersession or withdrawal must identify the material standards, source, platform or accuracy reason and must not rewrite historical execution records.