Accessibility checks, human review and recorded findings

Automated checks before publication

Automated tests run across site routes and flag the issues their rules can detect. A failed required check stops publication and identifies the finding for review.

Checks include axe results and declared color combinations. Components are designed to support keyboard operation, visible focus, target sizes and reflow; completed pages and user journeys still need review.

• Axe runs over every route and reports violations by rule and element.
• Declared color pairings are checked against WCAG contrast thresholds. Images, interactive states and other non-text contrast still need review.

Limits of automated testing

Automated tools find a large share of barriers and never all of them. Whether alternative text is accurate, whether a reading order makes sense, whether an error message helps: those need a person. Each site receives a manual accessibility review every quarter.

• The monthly record names what was automated and what was reviewed by hand.
• Your accessibility statement lists known gaps, which is what makes it worth publishing.

Accessibility statement contents

A published accessibility statement names the standard, describes how the site was assessed, lists what is known to fall short, and gives somebody a way to report a barrier. The statement is updated from the site's assessment records and known issues.

Records you receive

• Automated accessibility checks before publication, quarterly manual review and a dated record of findings.
• A published accessibility statement, kept current.
• Per-build artifacts, archived, so the record covers a period.