WordPress core is in decent shape and has an accessibility team with real standards. Almost nothing that fails on a WordPress site comes from core.
It comes from the theme, the page builder, the plugins, and twelve years of uploaded images with no alt text. Those are the four places to look.
The media library is the biggest single win
Every image ever uploaded has an alt field, and on most sites most of them are empty. This is one bulk edit away from a large improvement, and it is work an editor can do without a developer.
Two rules make it quick: if the image carries information, write what you would say reading the page aloud; if it is decoration, leave the alt empty rather than typing the filename. Empty is correct and silent — missing is not.
Page builders
Elementor, Divi, WPBakery and their peers generate deep `div` structures with styling that only looks like semantics. Headings become styled text, buttons become linked divs, and accordions ship without `aria-expanded`.
You usually cannot rewrite the builder's output, but you can choose its widgets carefully: use the heading widget rather than a styled text block, the button widget rather than a linked image, and check what each one emits before it goes on fifty pages.
- not thisHeading widgets set to a level chosen for its size rather than its place in the outline.
- not thisIcon boxes and image boxes wrapping a whole card in a link with no accessible name.
- not thisSliders with autoplay and no pause control.
- not thisTabs and accordions with no keyboard behaviour and no ARIA state.
Themes
Check whether the theme declares `accessibility-ready` — WordPress.org reviews that tag against a real checklist, and it is a meaningful signal. Most commercial themes do not carry it.
Whatever the theme, four things need checking directly: is the skip link present and does it become visible on focus; is focus visible on every control; does the mobile menu work by keyboard; and do the heading levels in the templates make an outline.
Plugins
Forms, cookie banners, popups and search widgets are where injected markup arrives. Contact form plugins in particular vary enormously: some emit proper labels and error associations, others emit placeholders and a red border.
Test a form by submitting it empty with a screen reader running. If nothing is announced and focus does not move, the plugin fails 3.3.1 and you will not be able to fix it from the theme.
Where to start
In this order, because each step is cheaper than the one after it.
- doScan the home page, a post, a page template, the search results and the contact page.
- doFix contrast in the theme's CSS variables — one change, whole site.
- doWork through the media library for the images that are actually in use.
- doTest the contact form with the keyboard and a screen reader. Replace the plugin if it fails.
- doSet a weekly scan so a plugin update cannot undo it quietly.
Questions
- Is WordPress accessible?
- Core is in reasonable shape and the block editor keeps improving. What ships to visitors is core plus your theme plus your plugins plus your content, and the failures almost always come from the last three.
- Do accessibility plugins fix WordPress accessibility?
- Plugins that help you author well — alt-text prompts, contrast checkers in the editor — are genuinely useful. Plugins that inject an overlay widget do not fix the underlying markup.
- What does "accessibility-ready" mean on a theme?
- It is a tag WordPress.org reviews against a published checklist covering keyboard navigation, contrast, headings and forms. It is not a conformance guarantee, but it means someone checked.
Keep reading