Tested before it publishes, and written down
Accessibility is a state a site holds rather than a project it completed. A site that passed an audit in March and has published forty pages since has an audit, and a current obligation it knows nothing about.
Every route, every change
Automated testing runs across every page of the site whenever anything changes. Publishing waits for a pass, so a barrier introduced on a Tuesday is caught on Tuesday by the person who introduced it.
- Axe runs over every route and reports violations by rule and element.
- Contrast is measured for every declared color pairing at 4.5:1 for body text and 3:1 for interface boundaries.
- Keyboard operation, focus visibility, target size and reflow are properties of the components, so a new page inherits them.
What automated testing does not catch
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. We say so here because a vendor claiming full coverage from automation is describing a tool that does not exist.
- 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.
What the accessibility statement has to contain
A published accessibility statement names the standard, describes how conformance was established, lists what is known to fall short, and gives somebody a way to report a barrier. Ours is built from the same facts the tests check, so it cannot describe a site we are not running.
What you can show
- A dated monthly record naming every route tested and every finding.
- A published accessibility statement, kept current.
- Per-build artifacts, archived, so the record covers a period.