Accessibility monitoring vs a one-time audit: why sites regress
A one-time audit describes a site as it was on the days it was tested, and monitoring checks it again as it changes. Sites regress because content, templates, platforms and standards keep moving after the audit. Monitoring catches what software can detect and an audit covers what only people can judge, so they do different jobs and work best together.
Published . Last reviewed .
An audit and monitoring answer different questions. An audit asks how a site measures up against a named standard, on a defined set of pages, on the days it was tested. Monitoring asks what has changed since. A site can pass the first and fail the second within a week, because sites are edited constantly and an audit does not follow the edits.
A regression is a requirement a site used to meet and no longer does. W3C's guidance on sustaining accessibility, part of its planning and policies resources, says that changing content can introduce accessibility issues, and it advises monitoring changes to catch them. This guide covers why sites regress, what an audit and a monitor each can and cannot see, and how to run the two together. It is general information, not legal advice.
What a one-time audit tells you
An audit is an evaluation against a named WCAG version and level, done by people who test what software cannot read: keyboard use, focus order, reading order and screen reader output. Our website accessibility audit guide explains what one involves. Two features of the method matter for this question.
- It is dated. W3C's WCAG Evaluation Methodology 2.0 (WCAG-EM) asks the evaluation report to record the date of the evaluation, and allows an optional list of the dates of repeat evaluations. The findings describe the site on those days.
- It is a sample. WCAG-EM says a WCAG 2 conformance claim cannot be made for a whole website from a selected subset of its pages alone, because unidentified errors are always possible on the pages not tested.
WCAG-EM adds a warning about evaluations done during development: even minor changes can make them obsolete quickly, so they should not support statements about the finished product. In our reading, the same logic applies after launch, only more slowly. Each edit moves the live site a little further from the one that was tested.
Why sites regress
W3C's Sustain page names several sources of change: new and edited content, changes to the content management system (CMS), unclear publishing requirements, staff who have not had enough training, new browsers and assistive technologies, and changes to standards. The table sets them beside GotAlt's own examples. The basis column says whether a row comes from W3C's list or from our reading, so you can tell them apart.
| Cause | What it can look like | Basis | What catches it |
|---|---|---|---|
| Content edits | A new product image goes up with its file name as alt text, or an editor adds an icon-only button with no accessible name | W3C: changing content can introduce issues | Monitoring of the pages that change, and a check at publishing |
| Template or theme change | A redesign or theme update alters the header, and the same contrast or focus problem appears on every page that uses it | GotAlt's reading. W3C's Sustain page mentions redesign and development work | Monitoring one page for each template, and a re-audit after a major redesign |
| CMS, plugin or platform update | An update changes the markup that headings, forms or image fields produce | W3C asks whether a CMS change caused the issues | Monitoring, and a retest after each major upgrade |
| Third-party scripts and embeds | A vendor updates a chat widget, consent banner or video player that you do not control | GotAlt's reading. WCAG-EM notes that a product's owner does not control third-party content | Monitoring in a browser that renders the page, plus a manual keyboard test |
| Gaps in publishing or training | Editors were never shown how to write alt text or structure headings, so the same mistake keeps returning | W3C's review questions ask about training and unclear publishing requirements | Fixing the cause, with training and a publishing checklist, not only the page |
| New browsers, assistive technologies and standards | WCAG 2.2 added nine success criteria (W3C's list), so a site tested only against WCAG 2.1 has not been tested against them | W3C: adapt to new technologies and track standards | A re-audit against the version your obligations name (see which WCAG version applies and what is new in WCAG 2.2) |
Most of what turns up on ordinary pages is small. WebAIM's 2026 analysis of one million home pages found that 96% of the errors it detected fell into six categories: low-contrast text, missing alternative text, missing form labels, empty links, empty buttons and a missing document language (WebAIM Million). In our reading, an ordinary edit can reintroduce most of those, which is why they are worth rechecking on a schedule. WebAIM also cautions that a page with no detected errors is not thereby accessible, because tools find only part of the problems.
Audit and monitoring side by side
They are not alternatives. The table shows how the work divides.
| Question | One-time audit | Automated monitoring |
|---|---|---|
| What it answers | How well does this site meet the named standard, on the pages tested? | What changed since the last check, and did anything that passed start failing? |
| When it runs | Once, then again at a launch, a redesign or on a schedule you set | On a schedule, repeating on the same pages |
| Who does the work | People who know WCAG and assistive technology, usually with tools | Software, with a person acting on the results |
| What it finds | Barriers that need judgment or real use: keyboard operation, focus order, reading order, screen reader output, whether alt text is true in context | Problems software can detect, and the ones that newly appear: missing alt text, unlabeled fields, empty links, low contrast |
| What it cannot do | Watch the site between visits, or cover pages outside the sample | Judge meaning or confirm that a page works |
| What you get | A dated report of findings, and fixes if you agreed them in the scope | A history of what changed, and alerts |
The limits in the monitoring column belong to automated testing in general, not to any one product. W3C says no tool alone can determine whether a site meets accessibility standards, and that knowledgeable human evaluation is required (W3C's evaluation overview). Karl Groves puts the share of WCAG 2.0 best practices that an automated tool can definitively test at approximately 25-29% (Automated Lies with One Line of Code). Sources disagree on the exact share, so treat roughly a third as an estimate; our page on what automated testing can and cannot check in WCAG sets out the research criterion by criterion.
A monitor that reports nothing new is therefore a tripwire that did not fire, not a verdict. It means nothing changed that software can detect. Whether keyboard use and screen reader behavior still work after an edit is something a person has to confirm, and the 5-minute keyboard test is a routine you can run after a change.
How to run both
W3C's planning and managing guide describes its activities as ideally repeated over time, not finished once. These steps follow that cycle.
-
Audit to set a baseline
Agree the WCAG version and level, a sample that includes one page for each template and every key journey, and the date. W3C's Plan phase asks for a standard way of monitoring and reporting findings, so keep the report format the same from one round to the next.
-
Fix, then retest what failed
Repair shared templates and components first, because one change repairs many pages. Our guide to the most common accessibility errors shows the usual fixes.
-
Choose what to monitor
Include one page for each template, the key journeys such as checkout and sign-in, and the pages editors touch most. WCAG-EM's approach to re-running an evaluation is a useful model: keep part of the earlier sample so results stay comparable, and replace about half of it to widen coverage. Applying that to a monitored set is our adaptation, and it stops the watched pages from going stale.
-
Monitor on a schedule that fits how often the site changes
W3C asks for regular reviews as content changes and names no interval. A site that publishes daily needs a shorter gap than one that changes each quarter, and our guide on how often to test accessibility takes the question further.
-
Check at publishing too
W3C's Sustain page advises including accessibility checks within the publishing process. Its Implement phase adds that checks belong inside existing testing and quality assurance, with issues raised in an issue tracking system so they are fixed in the normal cycle. The evaluation overview gives the reason for evaluating early and throughout development: problems are easier to address when they are found early.
-
Treat each alert as a question about cause
W3C's Sustain page asks reviews to find why issues occur, with examples such as untrained staff, a CMS change or an unclear publishing process. Fix the page, then fix the reason, or the same alert comes back next month.
-
Re-audit when something big changes
A redesign, a new checkout or sign-in flow, a move to a new platform, a new WCAG version in your target or a customer asking for a conformance report (see our VPAT and ACR guide) each call for fresh testing, as does a periodic full re-run. WCAG-EM lists periodic monitoring of a product over time among the reasons to evaluate.
Which one do you need?
- Before a launch or after a redesign: an audit. Monitoring reads what is there; it does not test how the site works.
- Between audits, on a site that changes often: monitoring, with the audit repeated when one of the triggers above occurs.
- A site that rarely changes: an audit, plus manual checks whenever you do change something. Our guide to small business web accessibility covers the proportionate path.
- Many client sites: in our reading, monitoring is how you watch them between audits, and each client site still needs testing by a person. See accessibility services for agencies.
- A complaint has arrived, or you need a report to hand over: an audit, which produces dated documentation of what was tested. Our guide to responding to accessibility complaints covers the next steps.
This guide is not legal advice
Whether a law sets any testing requirement, and what it asks for, depends on where you operate and what kind of organization you are. Our laws questionnaire and laws overview are a starting point, and a lawyer who covers accessibility law can answer for your situation.
Check it yourself
Between audits, three free tools cover the machine-checkable part and help you keep a baseline.
- Accessibility bookmarklet. Click the accessibility bookmarklet on any page, including a staging site or a page behind a login, to check alt text, headings, link names, form labels and the contrast of the text on screen. Run it again after you open a menu or load more content, and after any publish that touches a template. It finds only part of the problems: it cannot tell whether a page works with a keyboard or a screen reader.
- WCAG checklist. The WCAG audit checklist tracks all 55 Level A and AA success criteria. Name the audit with the site and the date, list the pages in the sample, then download the CSV and keep it with your report. The same page can import that file later to continue the work, and your results stay in your browser.
- Free scan. Scan my site for free runs 16 rule-based checks on up to three pages and says what a scan leaves to a person.
For what software cannot check, use the keyboard test and the wider guide to testing website accessibility.
Keep it checked
An audit covers the pages as they were on the day it was done. 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. It tells you what changed, not whether the site as a whole meets WCAG. Plans are from $69 a month. Audit my whole site from $69/mo.
Accessibility monitoring and audit questions
What is the difference between accessibility monitoring and an accessibility audit?
An audit is a dated evaluation of a site against a named WCAG version and level, including expert testing of what software cannot judge. Monitoring repeats automated checks on a schedule and reports what changed. The audit sets the baseline and the monitor watches for drift from it, so each covers a gap the other leaves.
Why do websites become inaccessible after an audit?
Because the site keeps changing. W3C's guidance says changing content can introduce accessibility issues. New images, edited templates, CMS and plugin updates, third-party embeds and new editors all alter the site, and an audit only describes the pages tested on the days they were tested. Monitoring and publishing checks catch the changes in between.
Can accessibility monitoring replace an audit?
No. W3C says no tool alone can determine whether a site meets accessibility standards, and that knowledgeable human evaluation is required. Monitoring finds what software can detect, and finds it again when it changes. Keyboard use, focus order, reading order and screen reader behavior still need a person, so use monitoring between audits, not instead of them.
How long do accessibility audit results stay accurate?
There is no fixed period. An audit report describes the pages tested on the dates of testing, and WCAG-EM asks the report to record the evaluation date. Any template change, content update or platform upgrade can alter the result. Retest the affected pages after a major change, and use monitoring to catch the smaller ones.
How often should I re-audit my website?
W3C sets no interval. WCAG-EM says an evaluation may be re-run after repairs or periodically to monitor progress, and W3C advises evaluating early and throughout development. A practical pattern is a full evaluation before a major launch or after a redesign, with monitoring in between. Our guide on how often to test accessibility goes further.
What should accessibility monitoring check?
The pages most likely to change or to matter: one page for each template, the key journeys such as checkout and sign-in, and anything editors update often. Software can recheck what it can detect on those pages, such as missing alt text, unlabeled fields, empty links and contrast, and report what is new. People still make the judgment-based checks.
Does accessibility monitoring make a site accessible?
No. Monitoring reports what software can detect and what changed. People still fix the problems and test what software cannot judge, and no automated tool can establish that a site meets WCAG or a law. A clean monitoring result means nothing new was detected, not that the site works for everyone.
Start with what a scan can see
The free scan runs 16 rule-based checks on up to 3 pages of your site and says what a scan leaves to a person. No signup.
Scan my site for freeRelated guides
- Website accessibility audit: what it is and what you get.
- How often to test: a cadence for checks and re-checks.
- 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.