The pattern
What breaks in most WordPress sites
WordPress core is not the problem. It has improved a great deal, and a plain block theme can pass comfortably. What breaks a site is almost always the theme somebody bought, the builder they laid it out with, or a plugin installed to save an afternoon.
Headings chosen for size, not structure
A designer wants a smaller heading, so an H2 becomes an H4. Someone navigating by heading then jumps from a main section into what sounds like a sub point, and loses the shape of the page. This is the failure I find most often, and it is usually the cheapest one to fix.
Page builder output
Elementor, Divi and WPBakery will all happily produce a div that looks exactly like a button. It cannot be reached by keyboard, it announces nothing, and a screen reader user never learns it is there. The builder is not at fault. The default settings are, and they can be changed.
Sliders and carousels that cannot be stopped
Auto advancing, no pause control, arrows that the keyboard cannot reach. WCAG asks for a way to stop moving content that starts on its own. Most slider plugins ship without one, which is why I wrote my own accessible carousel.
Forms with placeholders instead of labels
The question disappears the moment somebody starts typing, and they cannot check what they were asked. Then the error message prints in red with no text explaining it and nothing announced. Contact Form 7 and Gravity Forms can both be made accessible. Out of the box they usually are not.
Mega menus that trap the keyboard
A large drop down that opens on hover, swallows the keyboard once entered, and offers no way out with Escape. On a phone the same menu often cannot be closed at all.
Images with the alt field left empty
The Media Library makes alt text optional, so in a hurry it is skipped. The image then announces its filename, and a gallery of twenty products becomes twenty readings of a camera reference number.
WooCommerce checkout that changes silently
Variation selectors that update the price with nothing announced, and cart totals that change quietly in the corner. A blind customer fills the basket and cannot confirm what they are about to pay. This is the failure that costs you real money, because it stops the sale at the last step.
An overlay installed in good faith
A widget added because it promised compliance. It does not remove the failures underneath, and it often adds new ones. What an overlay can and cannot do is set out on its own page.
Scope
What the audit covers
Every template a visitor can actually reach, on the published site, driven with the same tools your visitors use.
Templates, not pages
Home, archive, single post, page, product, cart, checkout, search results and 404. A site with two hundred posts still has one post template. That is the thing worth testing.
The theme and the child theme
Including anything a previous developer left in functions.php, a custom block, or a template part that overrides the parent.
Every plugin on the front end
Forms, sliders, pop ups, cookie notices, booking calendars, chat widgets. Each one is tested where it actually sits, not in isolation.
Keyboard alone
No mouse at any point. Tab through the whole journey, including menus, modals, forms and the checkout, and check that focus is always visible.
Real screen readers
JAWS and NVDA on Windows 11, VoiceOver on macOS and iOS, TalkBack on Android. Different readers fail differently, which is why one is not enough.
Zoom and forced colours
200 and 400 percent zoom, and Windows High Contrast mode, where a surprising number of themes simply vanish.
Process
How a WordPress audit runs
Four stages. You get something you can act on at the end of each one, not a single document at the very end.
Scope and where I test
We agree the template list and the journeys that matter. A staging copy is ideal, but a live site is perfectly fine. I do not need admin access to audit a site. I need it only if you want me to make the fixes afterwards.
Manual testing against WCAG 2.2 AA
Each template driven by hand with a screen reader and then by keyboard alone. Automated tools run alongside, because they are fast and they catch the obvious things. They find roughly a third of what matters, and they cannot tell you whether a page makes sense to a person.
The written report
Every finding named, with the criterion it fails, the template or plugin responsible, the file to change, and a severity so you can decide what to do first. Written for your developer, not for a filing cabinet.
Retest and written sign off
Once the fixes are in, I test again and confirm in writing what now passes and what does not. That written confirmation is the document you show a lawyer, a procurement officer or a client.
Proof
Built, not just inspected
I do not only write reports about WordPress accessibility. I build for it, and the work is public, so you can open it and judge for yourself.
- An accessibility ready block theme. Ariade is my own full site editing theme, built to WCAG 2.2 AA rather than retro fitted to it. You can see how it is put together on the accessible WordPress theme page.
- Plugins in the WordPress repository. Ananyoo Accessible Carousel, Ananyoo Accessible Login and Ananyoo Accessible Forms. Between them they answer three of the failures listed above, at source rather than by patching.
- The full set. Carousel, login, forms, portfolio and events are listed together on the WordPress accessibility plugins page.
- The same work on other platforms. Accessible themes for Shopify, BigCommerce and Webflow sit on the accessible theme hub, because the failures repeat across platforms even when the code does not.
- A named tester, not an agency queue. The testing is done by a DHS Trusted Tester, which is the certification the United States federal testing process itself is built around, with IAAP certified colleagues on the audits.
Questions
WordPress accessibility audits, answered
These are the questions that come up before an audit is commissioned. Broader questions about themes, builders and overlays are answered on the WordPress accessibility FAQ.
Do you need admin access to my site?
Not to audit. I test what a visitor sees, so a public address is enough. Admin access matters only if you want me to carry out the remediation as well, and even then I would rather work on a staging copy.
Can you test pages behind a login?
Yes, and it is worth doing. Send me a test account. Membership areas, dashboards and account pages are usually where the worst problems sit, precisely because nobody outside the business ever looks at them.
We run a multisite network. How does that work?
Each site needs its own scope, but a shared theme or plugin is audited once and the finding applies across every site using it. On a large network that brings the cost down a long way compared with auditing each site separately.
We built the site in Elementor. Is that a problem?
No. Elementor can produce perfectly accessible markup. It just does not do so by default. On a builder site most findings turn out to be widget choices and settings rather than code, which usually makes them faster to fix than people expect.
Will the audit break anything?
Auditing changes nothing at all. If I go on to remediate, I work on a staging copy or in a child theme, and nothing reaches your live site until you have seen it and approved it.
How long does it take?
A small brochure site is usually a few days. A WooCommerce store takes longer, because every step of the buying journey has to be driven by hand, one product variation at a time. I will give you a real number in writing before you commit, not a range.
Next step
Get your WordPress site tested
Send the address, and tell me which builder you used and which plugins are running. Within one working day you get a written reply setting out what the audit covers, how long it takes and what it costs. If your deadline is not achievable I will say so rather than take the work.