The best accessibility fix is one that survives the next theme update. Plenty of fixes work on the day and quietly vanish six weeks later, which is worse than not fixing them, because nobody checks twice.
Here is where each kind of change actually belongs.
The hierarchy, best first
1. Fix it in the content
Alt text, heading levels, link text, table headers. These live in the post, so they survive everything: theme changes, plugin changes, migrations.
Alt text in particular should go in WordPress’s own alt field on the media item, not in a plugin’s table. Then it applies everywhere that image is used and stays behind if the plugin goes.
2. Fix it in a child theme or block theme template
Structural faults in the header, footer or templates. A missing main
landmark, a site name marked up as h1, a skip link that is not there.
A child theme survives parent updates. Editing the parent theme directly does not, and it is the most common way a fix disappears.
3. Fix it in Additional CSS
Contrast, focus outlines, target sizes, link underlines. Anything that is purely presentational.
The customiser’s Additional CSS is stored with the site, not the theme, so it survives a theme switch. It is also visible to the next person, which matters more than it sounds.
4. Fix it with a site-wide switch
Things a theme should have supplied and did not: a skip link, a visible focus ring, the page language, labels on core form fields.
A plugin can supply these at render time across the whole site. One switch, every page, and no template editing.
5. Last resort: a script
Avoid. Run-time DOM patching is how overlays work, and it inherits their problems: it depends on JavaScript loading, it can race with other scripts, and it leaves the source wrong.
Where fixes go wrong
Editing the parent theme
The classic. Works today, gone on update. If you have no child theme and cannot make one, Additional CSS covers most presentational fixes.
A fix that loses to specificity
You add a rule, nothing changes, because the theme styles the same element more specifically.
Raise specificity rather than reaching for !important:
/* Loses to .entry-content a { color: #999 } */
a { color: #4c2fcf; }
/* Wins, and is still readable */
.entry-content a { color: #4c2fcf; }If the blocking rule is itself !important, nothing can outrank it and the
honest answer is to remove that declaration rather than start an arms race.
This is worth verifying rather than assuming. Accessibility Remediation re-loads and re-measures the page after applying a style rule, and tells you when your theme outranked it instead of reporting success. See Applying and undoing fixes.
Overwriting content
A tool that rewrites your post content to fix markup has changed your data. Now every other thing that reads that content sees the change, and undoing it means hoping there is a backup.
Markup fixes belong in a reversible override layer applied at render time, so your content is untouched and removing the plugin returns the page to exactly what it was.
A rule of thumb for plugins
Before you let anything change your site, ask three questions:
- Where does the change live? Content, CSS, override layer, or injected at run time?
- Can I undo it individually?
- What happens if I deactivate the plugin?
Good answers: in my own content or my own CSS, yes, and my fixes stay and the markup goes back to normal.
Bad answers: in the plugin’s own tables, no, and everything reverts.
What survives removal, and what should
Worth being explicit, because it is a fair question to ask of any tool:
| Change | Should it stay if the plugin goes? |
|---|---|
| Alt text you wrote | Yes. It is content. |
| CSS corrections | Yes. They are in your own stylesheet. |
| Markup overrides | No. They should cleanly revert. |
| Site-wide switches | No. They were applied at render time. |
A plugin that deletes your alt text on uninstall has taken your work. One that leaves its markup rewrites behind has left you with orphaned changes nobody can trace.
Questions people ask
Can I fix accessibility without touching code at all?
Partly. Content fixes and site-wide switches cover a lot. Structural theme faults eventually need a template change or a developer.
Should I switch to a more accessible theme?
If your theme is fundamentally broken, possibly. But migrating is expensive and most faults are a handful of fixable mistakes. Audit first, then decide. See your first audit.
How do I stop regressions?
Re-scan after any significant change, and keep the statement current. A fix nobody re-checks is a fix with a shelf life.
To see where your fixes would land, the plugin is free on WordPress.org.