HIF Accessibility Assurance and Conformance Record

Status: controlled template for HIF 0.5

Use one record per product release or audit scope. This record preserves the evidence behind an accessibility statement, procurement response, remediation plan or bounded conformance claim. It does not turn a technical assessment into a legal opinion.

Use with Accessibility and Inclusion, the Product Profile Template and, for client work, the Web Audit Playbook.

1. Record control

Record ID:
Product/service:
Release/build:
Owner:
Evaluation lead:
Independent reviewer:
Assessment dates:
Report date:
Next review:
Repository/evidence location:
Confidentiality and retention:
Status: draft | reviewed | approved | expired

2. Intended statement

Purpose:
Audience:
Claim type:
  internal quality gate | sampled audit | full conformance evaluation
  accessibility statement | procurement response | ACR | other
Standard and exact version:
Conformance level:
Exact scope:
Explicit exclusions:
Legal review required: yes | no | undecided
Authorised claimant:

Do not begin with “fully conformant”. Begin with the evidence needed to test that hypothesis.

3. Jurisdiction and obligation register

Record separately:

• equality or anti-discrimination duties;
• public-sector digital-accessibility rules;
• product or service accessibility rules;
• procurement and employment requirements;
• sector-specific duties;
• complaint, monitoring and enforcement routes.

4. Product and content inventory

Inventory content types:

• HTML or native UI
• forms and transactional processes
• authentication and account recovery
• documents, PDF and office formats
• audio, video and live media
• maps, charts, diagrams, canvas or WebGL
• email, notification and support content
• embedded or third-party services
• user-generated content
• AI-generated or personalised content
• downloadable software or mobile applications
• kiosk, terminal or hardware interaction

5. Complete processes

Include error, empty, loading, timeout, offline, denied, interrupted and reauthentication paths.

6. Supported environment matrix

Document the rationale for inclusion and exclusion. Record real device versus emulation.

7. User-needs coverage

8. Criteria matrix

Use one row for every applicable requirement. No blank result is permitted.

Allowed outcomes:

• PASS
• FAIL
• NOT APPLICABLE, with rationale
• NOT TESTED, which blocks a complete conformance claim
• CANNOT TELL, which requires expert resolution

For WCAG, evaluate the conformance requirements as well as individual success criteria.

9. Automated checks

• False positives were reviewed.
• Inapplicable rules were explained.
• Scanner coverage was not represented as total accessibility coverage.
• Regressions run in the build pipeline.

10. Semantic and code inspection

• Native elements are used where suitable.
• DOM and accessibility-tree reading order is meaningful.
• Landmarks, headings, lists and tables represent structure.
• Every interactive control has an effective name, role and state.
• Labels, descriptions, errors and instructions are associated correctly.
• Custom controls implement semantics and behaviour.
• Dynamic status and errors are announced without interruption storms.
• Hidden, inert and disabled content is exposed correctly.
• Client-side navigation restores orientation.
• Third-party and embedded surfaces were included or explicitly limited.

Evidence:

11. Keyboard and alternative input

Check:

• complete action coverage;
• logical focus order;
• visible and unobscured focus;
• no trap;
• correct composite-widget keys;
• focus containment and restoration;
• target size and spacing;
• pointer cancellation;
• timeout and extension behaviour;
• label in accessible name.

12. Screen-reader journey log

Test headings, landmarks, control lists, forms, validation, dialogs, tables, dynamic updates, authentication, transaction review and support.

13. Low-vision and visual adaptation log

Do not record dark mode as evidence of forced-colour support.

14. Motion, flashing and timing

• Applicable flash thresholds pass.
• Reduced-motion preference is respected.
• Essential motion and alternatives are documented.
• Moving or auto-updating content can be controlled where required.
• Autoplay does not create unexpected sound or focus.
• Time limits are absent, adjustable or covered by an applicable exception.

Evidence and findings:

15. Media and communication

Record caption accuracy, speaker identification, meaningful sound, timing and quality review.

16. Cognitive and content review

• purpose and next action are clear;
• terminology, navigation and help are consistent;
• memory demand is externalised where possible;
• errors preserve valid work and explain recovery;
• irreversible consequences have preview and confirmation;
• authentication supports password managers and accessible alternatives;
• distractions and interruptions are controlled;
• reading level and language match the audience;
• important content is available in an appropriate alternative format;
• AI-generated summaries or simplifications preserve meaning.

Evidence, user need and source of each non-WCAG requirement:

17. Disabled-user evaluation

Research questions:
Participant inclusion criteria:
Recruitment route:
Accessibility arrangements:
Compensation:
Consent and privacy:
Tasks:
Stopping and safeguarding rules:
Analysis method:
Limits on generalisation:

Do not publish diagnoses or identifying data unless essential, consented and lawfully governed.

18. Finding register

Severity:

• critical — critical or safety task blocked, no effective alternative;
• major — primary task blocked or unreasonable assistance required;
• moderate — material extra difficulty, delay or error exposure;
• minor — limited local harm that still requires correction.

Do not derive severity mechanically from WCAG A, AA or AAA.

19. Exception and alternative record

Check equivalence of information, functionality, timeliness, privacy, cost, reliability and dignity. An expired exception blocks release and claim renewal.

20. Accessibility statement record

Public URL:
Product and scope:
Standard/version:
Status: fully conformant | partially conformant | non-conformant | not assessed
Assessment method and date:
Supported environments:
Known limitations in user language:
Alternatives:
Remediation commitments:
Feedback channels:
Response target:
Enforcement/escalation route if required:
Statement owner:
Publication date:
Review date:

The public status MUST match the criteria matrix and open findings.

21. Procurement or supplier evidence

• updates remain in scope;
• documentation and support are accessible;
• the organisation retains test and retest rights;
• unresolved gaps have an owner and exit plan.

22. Claim boundary

Use precise language:

Supported:
“The defined sample met the listed criteria under the recorded conditions.”
“The complete declared scope was evaluated using the recorded methodology.”

Unsupported:
“The scanner gave 100%, therefore the site is accessible.”
“A WCAG failure proves a statutory breach or entitlement to damages.”
“One screen-reader run proves compatibility for all disabled people.”

Only authorised counsel or a competent authority determines a legal conclusion. The technical report preserves facts required for that analysis.

23. Release decision

• Scope and complete processes are approved.
• Criteria matrix has no unexplained result.
• Required environment and task matrix passed.
• Critical and major findings are closed or have an approved effective alternative.
• Exceptions are authorised and current.
• User evaluation is proportionate to risk.
• Accessibility statement matches evidence.
• Regression coverage and monitoring are active.
• Legal review is complete where required.

Decision: approve | approve with conditions | reject
Conditions:
Residual risk:
Product owner:
Accessibility owner:
Legal reviewer if required:
Approval date:
Next review:

24. Change and regression history