After every meaningful user-interface change
Test the changed page, the shared component, and any key journey it affects.
A calendar cannot tell you when a new form, navigation, theme update or third-party embed introduced a barrier.
Accessibility testing frequency
How often should you test website accessibility?
There is no single useful interval for every website. Test after meaningful changes, use a scheduled scan as a backstop, and reserve deeper human review for important journeys and releases.
Create a free baselineOne live page, no signup.
The short answer
Use triggers and a backstop, not one arbitrary anniversary.
GOV.UK guidance recommends regular testing throughout development and testing whenever a new feature is added. DWP guidance similarly says to restart the testing process whenever the interface changes.
On a scheduled automated baseline
For an active small-business site, a weekly automated baseline is a practical backstop. Increase the frequency for high-change or high-value pages.
Scheduled checks catch drift from content and platform changes that did not pass through a formal release.
Before a major release
Repeat automated checks, then test the important journey with a keyboard and relevant assistive technology.
Automated rules cannot judge whether the whole task remains understandable and operable.
During periodic manual review
Review representative templates and critical journeys. Set the interval from change rate, user impact and risk rather than a ceremonial date.
Manual review catches context, focus order, instructions and assistive-technology behaviour that automation misses.
Set the frequency by risk
Test the pages that change outcomes first.
A five-page brochure site and a busy ecommerce store should not share the same schedule. Shorten the interval where change is frequent, one defect repeats widely, or a blocked task has commercial or human consequences.
Revenue and lead journeys
Checkout, booking, signup, enquiry and payment paths deserve the shortest feedback loop.
Shared templates
Header, navigation, footer, product and article templates can repeat one defect across many URLs.
Frequently edited pages
Campaign, product and editorial pages need a stronger schedule than stable reference content.
Third-party experiences
Embedded forms, chat, payment and scheduling tools can change independently of your own code.
A small-team routine
A weekly loop that survives a busy week.
- 01
Choose the baseline
Start with the homepage and the page that matters most to the next customer action.
- 02
Run the automated layer
Compare the result with the previous scan and separate newly detected rules from unchanged backlog.
- 03
Check the changed journey
Use a keyboard and, where relevant, a screen reader on the path affected by the week’s releases or content work.
- 04
Repair the source
Fix the component, template, theme or content field that produced the barrier rather than masking one rendered instance.
- 05
Re-test and record
Run the same check again. Record the date, result and any manual questions still open.
What each layer proves
Frequent does not mean complete.
Automated checks are the frequent layer, not the whole test. They can catch repeatable machine-checkable findings quickly, which makes them useful after releases and on a schedule.
Keyboard, screen reader and human judgement are still needed for focus order, instructions, meaningful alternatives and whether a complete journey works. W3C describes its Easy Checks as a first review, not a definitive accessibility evaluation.
A passing automated scan does not determine WCAG conformance or legal compliance.
Start with today’s result.
Scan one important page, repair the source, and use the next result as evidence that the detected finding cleared.
Run the free scanWant ClearSite to keep the automated baseline? See the website accessibility monitoring and regression-check workflow.
Need the limits of automation first? Read what a website accessibility scanner can and cannot test or use the tested accessibility issue repair guides.
ClearSite is a diagnostic and guidance tool, not legal advice or a compliance determination.
Primary guidance consulted: GOV.UK on testing regularly and after new features, DWP on restarting tests after interface changes, and W3C WAI Easy Checks and their limits.