Six months after an accessibility project, a lot of sites are quietly worse than the day it ended. Nobody broke anything on purpose. A plugin update changed a form’s markup, the marketing team added a landing page with an autoplaying video, someone installed a new reviews widget, and a theme update brought back a gray that fails contrast. Each change is small. Together they undo work you paid for, and you only find out when a customer complains or another audit lands on your desk. Website accessibility monitoring is the routine that catches those changes early, while they are still one or two items rather than forty.
What website accessibility monitoring means in practice
Our monitoring service is a scheduled, repeating check of your site against WCAG 2.2 Level AA, focused on the pages and tasks that matter most to your visitors. It mixes automated scanning with a person testing by keyboard and screen reader, because scanners only catch part of what goes wrong. Each month you get a short written report: what changed, what we found, what we fixed, and what is waiting on a decision from you.
It is the third stage of the audit, fix and monitor cycle described in our overview of website accessibility services. It is not a replacement for the first two. Monitoring keeps a site where it is; it does not lift a site that has never been fixed.
What it is not: a badge, a toolbar, or a dashboard number that turns green. We will not tell you the site is “compliant” because a scan came back clean. We will tell you what was tested, how, and what we saw.
Why a fixed site slides back
Accessibility is a property of the live HTML, and on a WordPress site the live HTML is changing all the time. These are the causes we see most.
Updates to core, theme and plugins
Developers change markup between versions. A form plugin restyles its error messages, a theme update overwrites a template you had adjusted, a slider plugin adds a new layout with different controls. Most updates are harmless; a few undo specific fixes. Our article on keeping WordPress accessible after updates explains the mechanics for anyone running updates in-house.
New pages and posts
Every new page is written by a person who may not know that a bold line is not a heading, or that “click here” tells a screen reader user nothing. A new landing page built in a rush is one of the most common places new barriers appear.
New plugins and third-party scripts
Chat widgets, booking tools, cookie banners, embedded maps and marketing popups all inject their own code. Some are added by plugin, some through a tag manager, some by a vendor asking for a snippet in the footer. Any one of them can cover content, steal focus or add a dozen unnamed buttons.
Changes in who edits the site
Staff change. The person who learned to write alt text leaves and the new hire uploads images straight from a phone. Without a check, habits drift with the people.
Four regressions a monthly check is built to catch
It helps to picture what drift actually looks like. These are the kinds of changes the routine is designed around.
The form that stopped talking. After a form plugin update, error messages still appear in red under each field, but they are no longer linked to the fields. A sighted visitor sees the problem. A screen reader user presses Submit, hears nothing, and assumes the form is broken. A scanner usually will not flag this. Submitting the form with a screen reader running does.
The hero video. Marketing replaces a static banner with a looping background video on the home page. It has no pause control, the headline text over it drops below the contrast ratio on some frames, and on a phone it pushes the main button below the fold. Three separate issues, one change.
The chat bubble on top of the cookie banner. A new chat vendor is added through a tag manager. On narrow screens its launcher sits right over the banner’s Accept button, and its pop-out window grabs focus on page load. Neither shows up in the WordPress plugin list, which is why we test the rendered page rather than only reviewing the dashboard.
The vanishing outline. A theme update ships a new stylesheet that removes the focus ring on buttons. The fix we placed in the child theme still exists, but the new rule has higher specificity and wins. Tabbing through the header once is enough to notice.
None of the four would show up as a dramatic drop in a scanner score. Each one would stop somebody halfway through a task.
What each monthly check covers
We agree a fixed set of pages at the start, typically the home page, the pages that bring in most leads or sales, any page with a form, the checkout if you sell online, and one example of each template. Then every month we:
- Scan the agreed pages with automated tools such as axe and WAVE, and compare the results with last month’s to spot anything new.
- Review content published since the last check: new pages, posts and landing pages, looking at headings, links, images, color choices and embedded media.
- Walk the key journeys by keyboard: reach the menu, open the dropdowns, fill in and submit each important form, dismiss any popup or banner.
- Spot-check with a screen reader, on the pages that changed, using NVDA as our default and VoiceOver where Apple devices matter to your audience.
- Check after significant updates, re-testing the parts of the site those updates touch, such as forms after a form plugin release.
- Zoom and narrow the window on new layouts to catch reflow and overlap problems.
- Review your accessibility statement so its date and contact details stay correct. If you do not have one yet, our accessibility statement service can draft it.
A monthly rhythm suits most small and mid-sized sites. Sites that publish heavily or run frequent campaigns may want checks tied to releases as well; we set that up with you rather than guessing.
We are also clear about what the monthly routine leaves out. It does not re-audit every page on the site each month, it does not test every past blog post, and it does not cover documents or video libraries in depth. Those can be scheduled as separate reviews, perhaps once or twice a year, so the monthly work stays focused on where change is happening.
| Check | Done by | Good at catching | Misses |
|---|---|---|---|
| Automated scan of agreed pages | Tools, reviewed by us | Missing alt attributes, low contrast, empty links, missing form labels | Whether alt text is meaningful, keyboard behavior, focus order |
| Keyboard walk-through | A person | Traps, hidden focus, menus and popups that need a mouse | What a screen reader announces |
| Screen reader spot check | A person | Unnamed buttons, silent errors, confusing reading order | Visual issues like contrast on images |
| New content review | A person | Fake headings, vague links, uncaptioned video, poor alt text | Code-level problems in templates |
| Post-update retest | A person, guided by the changelog | Regressions in the parts an update touched | Pages the update did not affect |
The monthly report you receive
We keep the report short enough to read over coffee. It has four parts:
- A change log for the period: which updates ran, which pages went up, which plugins came or went.
- New issues found, each with the page, the WCAG criterion, how it affects people, and a severity: blocks a task, makes a task hard, or a minor annoyance.
- What we fixed and how we confirmed it.
- Open items that need your decision, such as replacing a third-party widget, captioning a long video, or rewriting content only you can write.
Over time the reports build into a running record of care. That record is useful if a lawyer, a grant officer or a procurement team ever asks what you have done about accessibility. It does not shield you from anything, and we are not lawyers, but a dated history of testing and fixes is better than nothing on paper. If you want to understand how to read findings like these, our guide to reading an accessibility audit report applies to monthly reports too.
When a check turns something up
Small regressions are fixed as part of the service: a missing label on a field, alt text on new images, a heading level, a link that needs better wording, a CSS rule that an update overrode. We fix them on staging where the change is to code, then retest.
Larger problems get written up separately with options. A new plugin that is fundamentally inaccessible, a redesigned section built by another agency, or a video library that needs captions are bigger jobs. We describe the issue, the choices and the effort, and you decide. Nothing is changed outside the agreed scope without your say-so.
How do we decide what comes first? By what a visitor loses. If a visitor can no longer send an inquiry, book, pay or reach a page, that item goes to the top. Problems that make a task slower or more confusing come next. Cosmetic items that technically fail a criterion but barely affect anyone are batched and handled when there is a quiet month. That order is written into each report, so you can see why one item was fixed and another is still waiting.
If something serious appears, like a checkout or booking form that can no longer be completed by keyboard, we flag it to you straight away rather than waiting for the month’s report.
Where monitoring starts: a known baseline
Monitoring only makes sense against a known starting point. If your site has never been properly tested, the first month of monitoring would simply be an audit under another name, and the report would be long and confusing. So we usually begin one of two ways:
- You have had a recent audit and fixes, from us or someone else. We review that report, retest the key pages to confirm the current state, and use it as the baseline.
- You have not. We start with a WCAG audit of your key pages, followed by remediation of what it finds, and monitoring picks up once those are done.
Starting from a baseline is what lets each month’s report say “this is new” with confidence.
Setup: access and the page list
To run checks properly we need:
- An administrator account on WordPress, so we can see recent changes, plugin versions and content.
- Access to a staging site, or permission to create one, for testing fixes before they go live.
- The list of pages, forms and journeys you care about most, and who on your side approves changes.
- A heads-up when you plan a campaign, a new section or a vendor integration, so we can check it soon after launch.
- Your previous audit or accessibility report, if you have one.
We revisit the page list every few months. Sites grow, and a page that was minor last year may now be where most of your leads come from.
Telling useful monitoring from a dashboard score
Plenty of services sell “accessibility monitoring” that is really an automated crawler with a score. A crawler is useful, and we run them too, but on its own it can report a site as nearly perfect while the menu is unusable by keyboard. Ask yourself a few questions about any monitoring you pay for:
- Does a person ever press Tab on my site, or is it all automated?
- Does the report name specific pages and elements, or just give totals?
- When something is found, does anyone fix it, or am I handed a list?
- Does the provider know what changed on my site this month?
- Is anyone looking at the new content my team published?
If the answer to most of those is no, you have a scanner subscription, not website accessibility monitoring.
Running checks yourself versus handing them off
A careful in-house person can run a light version of this. Pick five key pages, scan them with a free tool like WAVE, tab through the contact form, and read through anything published that month. Our full walkthrough of how to test a site for accessibility and our explainer on using an in-dashboard accessibility checker are both written for that person.
Handing it off makes sense when nobody has the time every month, when screen reader testing is outside your team’s comfort zone, or when updates and fixes should be done by the same people so nothing falls through the cracks.
Common mistakes with ongoing checks
- Only scanning the home page, which rarely changes, while new landing pages go unchecked.
- Running updates on live with no retest of forms and menus.
- Treating a clean automated score as proof that nothing regressed.
- Letting the accessibility statement go years out of date.
Questions to put to any monitoring provider
- Which pages will you check, and how did you choose them?
- Which parts are automated and which are done by a person?
- Are fixes included, and where is the line between a fix and a project?
- What does a sample report look like?
How monitoring fits with WordPress maintenance
Most regressions start with an update, so website accessibility monitoring works well as ongoing accessibility maintenance run by whoever applies your updates. On our WordPress monthly maintenance plan, updates are tested on a staging site before they reach live, and the accessibility checks use the same changelog to decide what to retest. If you want to understand how we handle the updates themselves, see our explanation of core, plugin and theme updates.
The two reports can also be combined, so you receive one document covering security, backups, updates and accessibility each month, built on the same layout as our monthly website maintenance report.
If you want neutral background reading on accessibility for site owners, the W3C’s Web Accessibility Initiative publishes it in plain language.