Published on October 18, 20265 min read

WordPress accessibility: the plugin won’t fix it. Here’s what does.

Every WordPress site owner facing an accessibility deadline eventually finds the same answer on a forum: install an accessibility plugin. A widget appears in the corner, offers a contrast toggle and a font-size slider, and the problem feels handled.

It is not handled, and there is now a regulator’s finding to that effect. The FTC moved against overlay vendor accessiBe over claims that its product “can make any website compliant with WCAG”; the Commission’s position was that accessWidget “did not make all user websites WCAG-compliant”. The final order, approved 3-0 in April 2025, requires a $1 million payment and bars the company from representing that its automated products “can make any website WCAG-compliant or can ensure continued compliance with WCAG over time, unless it has the evidence to support such claims”.

The Overlay Fact Sheet, signed by 1,048 accessibility practitioners, puts the technical version plainly: “No overlay product on the market can cause a website to become fully compliant with any existing accessibility standard.”

The mechanism matters more than the verdict. An overlay runs after your page loads and patches the DOM it finds. Conformance is assessed on the page you deliver. And no script can infer what an image means — which is the single most common failure on a WordPress site.

So here is the unglamorous version: the code. These are the failures I find in nearly every WordPress audit, each mapped to the success criterion it breaks.

1. Heading levels chosen for size, not structure

The block editor lets an author pick any heading level from a dropdown, so they pick the one that looks right.

<!-- Fails 1.3.1 Info and Relationships — a level is skipped -->
<h2>Our services</h2>
<h4>Consulting</h4>

<!-- Correct: level follows structure. How big it looks is a CSS problem. -->
<h2>Our services</h2>
<h3 class="has-small-font-size">Consulting</h3>

Screen reader users navigate by heading level. A skipped level is a missing rung on the ladder.

2. Icon-only buttons with no accessible name

Hamburger menus, search toggles, social links. The commonest failure in commercial themes:

<!-- Fails 4.1.2 Name, Role, Value — announced as just "button" -->
<button class="menu-toggle"><svg>…</svg></button>

<!-- Correct: a real name, the icon hidden, state exposed -->
<button class="menu-toggle" aria-expanded="false" aria-controls="primary-menu">
  <svg aria-hidden="true" focusable="false">…</svg>
  <span class="screen-reader-text">Menu</span>
</button>

screen-reader-text is a WordPress core class — it is already in your stylesheet. Use it instead of inventing .visually-hidden.

3. The focus outline someone deleted

I find this line in most commercial themes, usually added because the designer disliked the ring:

/* Fails 2.4.7 Focus Visible — keyboard users now navigate blind */
a:focus, button:focus { outline: none; }

/* Correct: visible for keyboard users, no ring on mouse click */
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

4. Placeholders pretending to be labels

Contact Form 7, WPForms and Gravity Forms all make this easy to get wrong:

<!-- Fails 1.3.1 and 3.3.2 — the placeholder vanishes on focus -->
[email* your-email placeholder "Email"]

<!-- Correct: a real, associated label -->
<label for="your-email">Email address (required)</label>
[email* your-email id:your-email]

And errors must not be colour alone — that is 1.4.1 Use of Color plus 3.3.1 Error Identification. Red text with no words tells a colour-blind user nothing, and tells a screen reader user less than nothing.

5. Twelve identical “Read more” links

Standard on any WordPress archive template:

<!-- Fails 2.4.4 Link Purpose — out of context, every link is identical -->
<a href="…">Read more</a>

<!-- Correct: visible text stays short, accessible name is complete -->
<a href="…">Read more<span class="screen-reader-text"> about WordPress accessibility</span></a>

6. Alt text, the part no plugin can do for you

WordPress leaves the alt field empty by default, and an overlay will guess. Neither is right. The rule is about function, not description: an image carrying information needs alt text conveying that information; a decorative image needs alt="" so assistive tech skips it. An empty alt is a deliberate, correct choice. A missing alt attribute is not the same thing — the screen reader may read the filename instead.

The WCAG 2.2 criteria about to matter

WCAG 2.2 added nine success criteria. Four hit typical WordPress builds hard:

2.4.11 Focus Not Obscured (Minimum), AA. Your sticky header. Tab down the page and the focused element slides under it. Nearly every WordPress theme with a fixed header fails this, and almost nobody has checked.
2.5.8 Target Size (Minimum), AA. 24×24 CSS pixels. Social icon rows, pagination and mobile menu items are the usual offenders.
2.5.7 Dragging Movements, AA. Anything drag-only needs a single-pointer alternative — sliders and carousels.
3.3.8 Accessible Authentication (Minimum), AA. No cognitive function test to log in, and do not block paste into the password field.

Worth knowing too: 4.1.1 Parsing was removed in 2.2 as obsolete, so stop citing validator errors as WCAG failures.

On the legal timing, be careful what you repeat. EN 301 549 v4.1.1 — the version incorporating WCAG 2.2 — was published on September 2, 2026, but at the time of writing it had not yet been cited in the Official Journal, which is what would make WCAG 2.2 the referenced benchmark for the European Accessibility Act. Estimates point to late 2026. Verify it against the Official Journal before putting a date in a client proposal; I wrote about the wider legal framework in an earlier post.

The ten-minute test that beats any plugin

Unplug your mouse. Tab through a key journey. Can you see where you are? Can you reach everything? Can you escape the modal?
Zoom to 200%. Does the layout survive, or does the menu disappear?
Run axe or Lighthouse. Automated tools catch roughly a third of issues — real, but a floor rather than a finish line.
Turn on VoiceOver or NVDA for one journey: homepage → product → form submit.

Step one finds more than any plugin ever will, and it costs nothing. That is the uncomfortable part: accessibility is not a product you install, it is a property of the markup you ship — which is why I keep saying it costs ten times less when it is in the build rather than bolted on at audit time.

Need a WCAG assessment of your WordPress site that produces fixes rather than a widget? That is what a technical audit is for — and I build in WordPress too, as on the Espé Montréal site.