Six months ago someone fixed your site. The menu worked with a keyboard, the contact form announced its errors, the focus outline was back. Then came a theme update, a new booking plugin, a homepage refresh by the marketing team and a dozen new blog posts. Nobody broke anything on purpose, but when you press Tab today, the outline is gone again.
This is the normal life of a WordPress site, and it is why the work to keep WordPress accessible after updates matters as much as the first round of fixes. This post explains how regressions creep in, what a light monthly routine looks like, and how a staging site helps you catch problems before visitors do.
Why accessibility slips on a living site
An accessibility regression is anything that used to work for disabled visitors and now does not. On WordPress, it rarely comes from one big change. It comes from small ones that nobody tested with a keyboard.
A theme update lands
A theme update can replace templates, CSS and scripts. If your fixes were made directly in the parent theme’s files, the update overwrites them outright. Even when fixes sit safely in a child theme, the parent may rename a CSS class or rebuild the header, and your custom styles stop matching. The focus outline you restored can disappear simply because the selector it targeted no longer exists.
A plugin changes its markup
Plugins that output front-end markup are the usual suspects: form builders, sliders, popups, consent banners, mega menus, page builders and store add-ons. A new version may change the HTML of a form, add a new icon button with no name, or switch a dropdown to a different script. Changelogs sometimes mention accessibility work, good or bad, which is a reason to read them; our guide to reading a plugin changelog explains what to look for.
Someone installs something new
Adding a plugin is a bigger risk than updating one. A chat widget, a review carousel or a promo popup can each add an overlay that covers focused content, a new keyboard trap, or text that fails contrast. These rarely get tested for accessibility before they go live.
Editors publish without checking
Editors add pages every week. Each one is a chance for an image without alt text, a heading picked for its size, a link that says “click here”, a PDF that is just a scan, or a video without captions. Content regressions are also the easiest kind to prevent, because they come down to habits.
WordPress core and the browser move on
WordPress core updates usually improve accessibility, and the Make WordPress Accessible team works on that directly. Even so, changes to the block editor or default block output can interact with a theme’s styling in ways nobody expected. Browsers change too, though less often in ways that matter here.
Test updates on staging first
The single most useful habit is to apply updates on a staging copy of the site before the live one. Staging is a private clone where you can break things safely. If your host offers one-click staging, use it; if not, there are other ways to set one up, covered in our guide to a WordPress staging site.
On staging, after running updates, do a short accessibility pass on the pages most likely to change:
- Open the homepage and press Tab from the top. Is focus visible on every stop? Does the menu still open?
- Open the mobile menu at a narrow window width. Does the toggle still work by keyboard?
- Open the main contact or booking form. Submit it empty. Are the errors shown in text and does focus go somewhere sensible?
- Trigger any popup, cookie banner or chat widget. Can you close it with the keyboard?
- If you run a store, add a product to the cart and go to checkout with the keyboard only.
- Run your usual automated scanner on those same pages and compare the count with last time.
Once you know the site, this becomes quick. If something broke, you hold the update, check the plugin’s support forum or changelog, and update once there is a fix. Our general guide to WordPress core, plugin and theme updates covers the order and safety side; this checklist adds the accessibility side to it.
A light monthly routine to keep WordPress accessible after updates
You do not need a full audit every month. A small, consistent routine catches most regressions early. Here is one that works for a typical small business site.
| Task | What you are looking for |
|---|---|
| Scan your key templates with an automated checker | A jump in errors compared with last month |
| Keyboard pass on homepage, one inner page, main form | Missing focus, menus that will not open, traps |
| Review new content published this month | Alt text, headings, link text, captions, documents |
| Check any new plugins or embeds added | Overlays, unlabeled buttons, contrast |
| Zoom one page to 200 percent | Horizontal scrolling, overlapping text, hidden buttons |
| Note what you found and what was fixed | A simple running record |
Pick the same pages each month so results are comparable. Add a new page type to the list when one is created, such as a new landing page template.
Keep a record
Write down the date, the pages checked, what was found and what was done. A spreadsheet is fine. Over time, this becomes a record of ongoing effort, which is useful when you update an accessibility statement, when a customer asks about access, or when you need to explain to a lawyer or a new developer what has been done. It also shows patterns, such as one plugin that breaks something on every update.
Habits that prevent content regressions
On a site that is otherwise maintained, new content is where problems creep in week by week, so it pays to make good habits easy for editors.
- A short editor checklist pinned somewhere obvious: alt text on every meaningful image, headings in order, descriptive links, captions on video, no text inside images.
- Reusable patterns for common layouts, built and tested once, so editors do not rebuild them from scratch with different headings each time.
- An in-editor checker that flags obvious issues before publishing.
- A rule for documents. Before uploading a PDF, ask whether it could be a page instead.
- Brand colors chosen for contrast and saved in the theme, so editors pick from safe combinations rather than guessing.
Walk every new editor through this list in their first week. A new person who never saw it will undo old fixes without knowing it.
Keeping fixes safe from updates
Some regressions come from where the fixes were made in the first place. When fixes are done, or when you review past work, check that:
- Theme fixes live in a child theme or a small custom plugin, not in the parent theme’s files.
- Custom CSS for focus styles, contrast and target sizes is documented, with a note of what each rule is for.
- Any changes to plugin output are done through hooks or filters where possible, not by editing the plugin’s files, which the next update will overwrite.
- There is a list of the plugins that affect the front end, so you know which updates need the staging check.
That last list is worth having anyway. If you have never looked at what each plugin does, our guide on how to audit your WordPress plugins is a good place to start.
When to get help
Doing this yourself is realistic for a site owner or office manager who can set aside a little time each month to keep WordPress accessible after updates. It stops being enough when the site is large, changes often, runs a store with many templates, or depends on plugins that update frequently. Then it makes sense to have someone check after each update cycle, or set up ongoing website accessibility monitoring as part of regular care.
The first round of work that this routine protects is laid out in our guide to how to make a WordPress website accessible, and the full range of what we do sits under our accessibility services for US businesses.
Frequently asked questions
Can a WordPress update make my site less accessible?
Yes. Theme and plugin updates can change markup, scripts and styles, which can remove focus outlines, break keyboard menus or change form output. Updates also carry security fixes, so skipping them is not the answer. Test them on a staging copy and do a short keyboard check before updating the live site.
How often should I check my site for accessibility regressions?
A short check after each round of updates and a slightly fuller pass once a month suits most small business sites. Sites that publish a lot of content, run a store or add plugins often benefit from more frequent checks, especially on forms, checkout and anything new.
Will an automated scanner catch regressions?
It catches some, such as missing alt text, empty links or new contrast failures, and a sudden rise in errors is a useful warning sign. It will not reliably catch broken keyboard menus, hidden focus or popups that trap people, so pair the scan with a quick keyboard pass on your key pages.
Should I turn off automatic updates to protect accessibility fixes?
Not across the board, because updates also carry security fixes. A middle path works for many sites: leave security releases and back-end plugins on automatic, and update the plugins and theme that change what visitors see by hand, on staging first, with a quick keyboard check before they go live.
Keeping a WordPress site usable through updates, new plugins and new content is part of how we look after sites over time. If you would like that handled for you, see our WordPress accessibility work.
