How often should you test your website's accessibility?

W3C's guidance sets no fixed interval: it says to evaluate early and regularly, to monitor after launch and to re-check when content changes. Our suggested rhythm is an automated check every week, a manual test of anything you change, and a full evaluation before a launch or redesign and at least once a year after that.

Published October 13, 2026. Last reviewed October 13, 2026.

Test on a schedule, and again whenever the site changes. A page that passed a review in March can fail in April, because accessibility depends on content, templates and code that people keep editing. W3C's guidance on sustaining accessibility says changing content "can introduce accessibility issues" as well as opportunities for improvement. So the useful question is what changed and which test that change calls for, as well as how many weeks have passed.

This guide builds a rhythm from W3C's guidance and marks the parts that are our own reading. The methods themselves are in how to test website accessibility, and the difference between watching a site and reviewing it once is in accessibility monitoring vs a one-time audit. This page is general information, not legal advice.

What the standards say about how often

None of the W3C pages we read sets a number of days or weeks. Each ties testing to a moment or a pattern: early, at milestones, after changes, periodically, with a dated record. W3C's planning pages and its evaluation overview lead to the sources below.

What W3C, WCAG 2.2 and GOV.UK say about when to test and re-test
Source	What it says about timing
W3C, Implement	Evaluate throughout design and development, "particularly at key milestones and sprints", and build the checks into existing testing and quality assurance work rather than a separate review.
W3C, Plan	For ongoing goals, "plan regular monitoring to ensure that achieved goals do not slip", because content updates and maintenance work can introduce new barriers. Assign responsibility for the checks and a route for escalating what they find.
W3C, Sustain	"As your website content changes, ensure that regular accessibility reviews are performed", and "Include accessibility checks within the publishing process".
WCAG-EM 2.0, W3C's evaluation method	An evaluation can be needed before releasing, acquiring or redesigning a product and for "periodic monitoring" over time. It "may be re-run after a short period", for example once issues are repaired or to monitor progress.
WCAG-EM 2.0, on early evaluations	An evaluation made during design and development "can quickly become obsolete" after even minor changes, so it should not support statements or conformance claims about the finished product.
WCAG 2.2, conformance claims	Claims are optional. If you make one, it must include the date of the claim.
GOV.UK, accessibility statements	Review and update the statement "when there are major changes and at least once a year". This is guidance for UK public sector websites and apps.

Of these sources, the only fixed interval is GOV.UK's yearly statement review, which applies to UK public sector bodies. Everything else is a pattern. Laws and contracts can add requirements of their own, so ask a lawyer what applies to you.

What makes a tested site need testing again

Each change below alters what a visitor meets. Re-test the pages it touches.

Content edits. A new image with no alt text, a heading chosen for its size, a link that says "here". This is the case W3C describes: changing content can introduce issues.
New or changed templates and components. Menus, forms, carousels, a checkout, a cookie banner. Keyboard and focus problems live here, and a scan of the HTML cannot see them. Our keyboard accessibility test takes about five minutes.
Updates and third-party code. A theme or plugin update, a new chat widget, a booking or payment embed. You may not have written that code, but visitors meet it as part of your site.
Redesigns and migrations. WCAG-EM names redesign as a time to evaluate, and an earlier evaluation of the old design says little about the new one.
Changes to standards and laws. W3C notes that "Changes in legislation tend to include dates by which compliance must be achieved." For example, ADA.gov reports that an April 20, 2026 interim final rule moved the ADA Title II web rule dates to April 26, 2027 for public entities with a population of 50,000 or more, and to April 26, 2028 for smaller ones and special districts. Our Title II deadline guide and law updates log track changes like this.
New browsers and assistive technology. W3C's Sustain page asks sites to keep their list of supported browsers and assistive technologies up to date.
Reports from visitors. A complaint is a test result you did not schedule. W3C asks sites to invite feedback and use it to find areas that need attention. Re-test the page, then look for the same problem on pages built the same way.

A testing rhythm that fits most sites

W3C gives no schedule, so the rhythm below is our reading of its guidance. Adjust it to how often your site changes.

A suggested rhythm for each layer of testing, and what each layer covers
Layer	How often	What it covers
Automated scan of key pages	Every week, and after each release	Problems a program can read from the page: missing alt text, unlabeled fields, a missing page language, low contrast on the rendered page.
Spot check of each change	Each time you publish or ship, ideally before it goes live	The page or component you changed, in the browser. The accessibility bookmarklet suits this.
Manual routine on key templates	When a template or component changes, and before launches	Keyboard use, zoom, a screen reader, forms. The testing guide has a 15-minute routine.
Full evaluation	Before a launch, acquisition or redesign, then at least once a year	A sample of pages and complete processes tested against your target level, written up and dated, as in a website accessibility audit.
Testing with people who use assistive technology	At milestones, and for your key journeys	Real tasks such as finding a product or checking out. W3C says this finds "usability issues that are not discovered by conformance evaluation alone" (W3C on involving users).
Accessibility statement review	After major changes, and at least once a year	The statement and its review date. GOV.UK sets this interval for UK public bodies, and our statement guide suggests the same default for other sites.

Weekly is our suggestion for a site that publishes or changes something every week. A scan costs little, so it can run more often than anyone would think to look. A site that changes a few times a year can scan after each change instead.

The scan is only the first layer. Sources disagree on how much of WCAG software can test, and roughly a third is the defensible framing (our page on how much of WCAG can be automated attributes each figure). W3C says "no tool alone can determine if a site meets accessibility standards". Run weekly scans, and still do the manual rows, because keyboard, reading order and screen reader problems only show up there.

The rhythm for different kinds of site

The examples are generic, not real sites.

A brochure site that changes a few times a year. Scan after each change, run the manual routine on the home page and contact form when they change, and do a full evaluation before any redesign. Web accessibility for small businesses covers where to start.
A store or publisher that adds products or posts every week. Scan key pages weekly, use the bookmarklet on new templates and campaign pages, repeat the manual routine on checkout or sign-up after any change, and do a full evaluation each year.
A team shipping releases. Put automated checks in the release process and test each changed component by keyboard, which follows W3C's advice to evaluate at "key milestones and sprints". Run a full evaluation at major releases.
A site with a legal date ahead. Start with a full evaluation to set a baseline, then re-run it as you fix things to track progress, as WCAG-EM describes. Our guides to the ADA Title II deadline and EAA compliance explain two such dates.

How much to re-test each round

Re-testing does not mean starting again. WCAG-EM says a later evaluation can reuse part of the earlier sample, so results can be compared, and replace part of it to widen coverage. The replaced share is "typically about half of the initial sample set", and unless significant changes were made there is usually no need to change the sample size or the sampling approach.

Our reading of that, in practice:

Keep a fixed core list that you test every round: the home page, one page for each template, search, a form, and a checkout or sign-up flow. Rotate other pages in around it.
After a change, test the changed page and the pages that share its template or component.
After a fix, re-test that item where it was found and wherever the same pattern is used.
When something fails, ask why, as W3C's Sustain page does. Was it a change in the content management system, an untrained editor or an unclear publishing requirement? Fix the cause as well as the page.

Date every round. The WCAG-EM report template asks for the date of the evaluation and has an optional list of the dates of repeat evaluations. A test result describes the site on the day it was tested, so a dated log can feed your accessibility statement and is the kind of documented testing a buyer's request for a VPAT or accessibility conformance report draws on.

Check it yourself

Three free tools cover the rounds between full evaluations.

The accessibility bookmarklet is for the spot check after each change. It runs in your own browser, so it works on a staging site, localhost or a page behind a login, and it checks alt text, headings, link names, form labels and the contrast of the text actually on screen. It reads one page at the moment you click, so run it again after opening a menu or loading more content. It cannot tell whether alt text is true of the picture, or whether the page works by keyboard or screen reader.
The WCAG audit checklist is for the dated record. You mark each of the 55 Level A and AA success criteria Pass, Fail or Not applicable, add notes, list the pages in your sample and download the audit as a CSV file. Your results stay in your browser. Import last round's CSV to continue from it, then export the new one.
Scan my site for free is the quick weekly look. It runs 16 rule-based checks on up to three pages, reading the HTML your server sends. It does not see content a script adds afterwards, and it does not press keys.

Read a clean result from any of them as "these checks found nothing", not as a pass.

Keep it checked

A manual round describes the site on the day you test it. GotAlt checks the pages you monitor every week. It compares the alt text of up to six images per page with the image itself, runs its rule checks, opens monitored pages in a browser for contrast and other checks that need a rendered page (see what we check), and reports what changed. Plans are from $69 a month. Monitoring covers the automated layer, so the keyboard, screen reader and user testing in the rhythm above stay with people. Audit my whole site from $69/mo.

Questions about how often to test accessibility

How often should automated accessibility scans run?

W3C sets no interval, so this is our suggestion: weekly for a site that publishes or changes something every week, and after each change for a site that rarely changes. A scan is cheap, and W3C advises including accessibility checks in the publishing process. Pair scans with manual tests, because no tool alone can determine whether a site meets accessibility standards.

How often should I get a full accessibility audit?

WCAG-EM sets no schedule. It says an evaluation can be needed before releasing, acquiring or redesigning a product and for periodic monitoring. Our suggestion is a full evaluation before a launch or redesign and at least once a year after that, with automated checks in between. A site that changes heavily may need one sooner.

Do I need to test after every website update?

Test what the update touched. A content edit needs a spot check of that page, for example with a browser tool. A new template or component needs the keyboard, zoom and screen reader checks too. W3C says changing content can introduce accessibility issues, and asks for accessibility checks within the publishing process.

Do I have to test every page each time?

No. WCAG-EM works from a sample of pages and complete processes. For a repeat evaluation it suggests reusing part of the earlier sample so results can be compared and replacing part of it, typically about half, to widen coverage. Test the pages you changed and the pages that share their templates.

How often should I review my accessibility statement?

GOV.UK tells UK public sector bodies to review and update their statement when there are major changes and at least once a year. Outside the UK public sector that is not a rule we can point to, but it is a sensible default. Change the review date only after you have re-checked the statement's contents.

Is a yearly accessibility test enough?

Not on its own for a site that changes. A yearly evaluation describes the site on the days it was tested, and W3C says changing content can introduce accessibility issues. Between evaluations, scan regularly, check each change and repeat the manual routine whenever a template or component changes. Whether a law or contract requires more is a question for a lawyer.

How to test website accessibility: automated and manual methods.
Offering accessibility as an agency: scope, delivery and what to promise.
Accessibility in procurement: what to ask vendors and put in an RFP.
Responding to an accessibility complaint: what to do when a visitor reports a barrier.
WCAG vs ADA vs Section 508: standard, law and federal rule, told apart.
Web accessibility for small businesses: where to start.
Monitoring vs a one-time audit: why sites regress after a fix.

Start with the weekly look

The free scan runs 16 rule-based WCAG checks on up to three pages of your site and shows what to fix first. It cannot press keys, so use the manual rows above for the rest. No signup.

Scan my site for free