Themes, builders, plugins and the editor habits behind them
A WordPress site tested properly, and the statement that follows it.
WordPress runs a large share of the web, which means most accessibility findings in the world come from the same handful of causes: a theme chosen for looks, a page builder that treats headings as font sizes, a plugin stack nobody reviews, and years of content added by people who were never told what alt text is for. None of that is fixed by a statement. All of it is described by one, once somebody has actually tested the site.
No plugin installed. We test what visitors get.
Where the findings come from
Before deciding what to fix, it is worth knowing which layer produced each problem, because the same visible symptom can come from four different owners and the cost of the remedy differs by an order of magnitude between them.
| Source | Typical finding | Fixed by |
|---|---|---|
| Theme | No visible focus style, low-contrast buttons, skipped heading levels | Theme settings or child theme CSS |
| Page builder | Headings chosen for size, decorative markup announced as content | Editor training and a template pass |
| Slider plugin | Auto-rotation with no pause, slides unreachable by keyboard | Configuration or replacement |
| Pop-up plugin | Focus taken and not returned, no keyboard close | Configuration or removal |
| Cookie banner | Traps the keyboard, illogical button order | Configuration |
| Forms plugin | Labels missing, errors not associated with fields | Settings and small code changes |
| Media library | Informative images with empty alt text | Content work, no developer needed |
| WooCommerce | Variant selectors and checkout errors not announced | Theme and template overrides |
Three of those eight are content and configuration rather than code, which is why a first remediation on WordPress is usually cheaper than owners expect.
The editor problem, and how to end it
This is the section to forward to whoever writes your pages, because none of it requires touching code and all of it shows up in the next audit.
Half the findings on a mature WordPress site were created by people writing pages, not by developers. Four habits cause most of them, and all four can be taught in an afternoon.
Headings as styling
Choosing heading 4 because it looks right destroys the outline a screen reader user navigates by. Structure first, size adjusted with CSS.
Click here
Link text read out of context has to make sense on its own. A list of nine links all called “read more” is a maze.
Empty or decorative alt text
Informative images need a description; decorative ones need an empty attribute, not a file name.
Text inside images
Posters, prices and tables saved as pictures are invisible to search engines and to assistive technology alike.
We list these separately in the findings so the marketing team can act without waiting for a developer, which is usually the fastest improvement available on a content-heavy site.
Plugins: the update treadmill
A WordPress site changes weekly even when nobody plans a change. Plugins auto-update, a theme pushes a new version, a security patch alters a template. Each of those can reintroduce a finding that was fixed months ago, and nothing in the dashboard tells you.
This is the argument for monthly testing rather than an annual audit. The comparison with the previous run turns an invisible regression into a line in an email: this page, this criterion, since the last run. It costs nothing extra in the plan and it is the difference between a site that stays clean and one that is rediscovered as non-compliant a year later, usually by a customer.
Multisite, memberships and everything behind a login
Two situations need to be scoped explicitly. A multisite network is several sites sharing a codebase: the theme findings usually repeat, but content and plugins differ per site, so each public site needs its own statement even when the testing overlaps heavily. That is what the three-domain plan is for.
A membership or learning area is the second. It is often the part with the highest value and the least testing, because the public pages get the design attention and the logged-in area is built from whatever the plugin provides. If the members' area is where your service is actually delivered, it belongs in the scope, and we need a test account to reach it.
What arrives at the end
The findings report your developer and your editors work from, split so that each group sees what belongs to them. The accessibility statement written from those findings, dated, signed by Europe Services SE for the European Union, with a public verification code. The feedback channel hosted for you. Monthly re-testing for the year, and five years of records.
Nothing is installed on your site, no code is added, and no badge appears in the corner of your pages. If you also need the Ontario record or the British report, the same testing supports them, as set out on the Ontario page and the UK page, with one renewal date on the global plan.
A four-week plan for a typical business site
Week one, the audit runs and the statement goes online describing the site as it is. Week two, the content team works through the list that needs no developer: alt text, link wording, headings in the worst pages, any table trapped inside an image. Week three, the developer takes the blocking items, which on a typical WordPress business site means a focus style, two unlabelled controls, the pop-up configuration and the contact form errors. Week four, we re-test and reissue the statement without those entries.
After that it is monthly maintenance measured in minutes, not a project. The cost stays the annual plan price, and the work fits inside a normal content and release rhythm, which is the only way it survives past the first enthusiasm.
What an automated plugin scan will and will not tell you
Most WordPress owners have run a free checker at some point and come away with a number. The number is not meaningless, but it measures a narrow band: missing alternative text, some contrast failures, obviously malformed markup, empty links. Those are real findings and they are worth fixing. What the scan cannot see is whether the menu can be opened without a mouse, whether the cookie banner returns focus, whether the contact form tells you which field was rejected, or whether the reading order of your hero section matches what the eye follows.
The gap matters because the criteria a machine cannot check are the ones that stop a task altogether. A site can score well on an automated report and still be unusable for a keyboard user at the exact point where it earns money. That is not a criticism of the tools, which are honest about their coverage in their own documentation; it is a reason not to treat the number as an answer.
In practice we run the automated pass first precisely because it is cheap and it clears the easy findings before a person starts. The manual work then goes where the machine cannot: menus, modals, forms, announcements, focus. The report you receive separates the two, so you can see which findings came from software and which from somebody working through your site by hand.
Old content, and how far back to go
A site with ten years of posts raises a fair question: does every archived article have to be corrected? In practice no, and pretending otherwise stops people from starting. The obligation attaches to the service you provide now, so the sensible order is the pages that carry the service — home, products or services, pricing, contact, forms, checkout — then the content people actually read, which analytics will tell you is a small fraction of the archive, then everything else as it is touched. What matters is that the statement describes this honestly rather than implying the entire archive was reviewed.
There is one exception worth acting on immediately: any old page that is still the only source of something a customer needs. A price list from 2021 that is still linked from the footer, a form that people still use, a document that support keeps sending. Those are not archive; they are live content with an old date, and they belong in the first pass.
Who should own this in a small organisation
On a WordPress site the answer is usually not the developer, because most of what degrades is content. The person who publishes pages is the one who decides whether headings carry structure, whether links make sense out of context and whether the new campaign image contains text that exists nowhere else. Give that person the content half of the findings, ten minutes of explanation, and the monthly result, and the site stays reasonable between audits almost by itself.
The developer's half is shorter and more technical: focus styles, plugin configuration, template overrides where the theme produces bad markup. Splitting the report this way is not cosmetic. Reports that arrive as one long undifferentiated list tend to be read by nobody, while a list of eleven items addressed to the person who can act on them tends to get done.
WordPress questions
Is WordPress accessible by default?
The core software has an accessibility team and reasonable defaults. What visitors meet is decided by the theme, the page builder and the plugins you added.
Does a page builder make things worse?
Often, yes. Builders generate deeply nested markup, and heading levels chosen for size rather than structure are the usual result.
Which plugins cause the most findings?
Sliders, pop-ups, cookie banners, forms, galleries and anything that opens a modal.
Are accessibility plugins useful?
Some help with specific tasks such as checking contrast in the editor. None makes a site conformant, and toolbars are a separate matter covered on our overlay page.
What about WooCommerce?
It adds the whole shop journey: variants, cart, checkout and account. That is where the blocking findings usually are.
Do I need a statement?
If you sell to consumers in the EU, or you are covered in Ontario or answering UK tenders, yes.
Can I write the statement in WordPress?
Publish it as a normal page with a stable address linked in the footer. The text has to come from testing, not from a template.
Do you need admin access?
No. We test as a visitor. For members-only areas we ask for a test account.
Will you install a plugin?
No. Nothing is added to your site.
How long does the audit take?
Five business days from a complete form.
Who fixes the findings?
Your developer or agency. Many items are theme settings or editor habits rather than code.
What are the quickest wins?
Heading order, link text, alt text on informative images, contrast of buttons and a visible focus style.
How do I stop it degrading?
The monthly re-test flags what changed after plugin and theme updates.
Is an old theme a problem?
Usually. Themes older than a few years predate current focus and target-size expectations.
Do I have to rebuild the site?
Rarely. Most first audits produce a handful of blocking items and a list of small corrections.
What does it cost?
690 € a year for the EU, 1,290 € for three domains and six languages, 1,990 € including the UK and Canada.
Can I publish the statement before fixing?
Yes, listing the open barriers and the alternatives, which is what the law expects during remediation.
Where do I start?
Run the free scan and order the audit.