WordPress Accessibility in 2026: The Essential Guide

WordPress accessibility used to be filed under “nice to have, when there’s budget”. That changed. There is now a legal driver in the EU, a long-standing one in the UK and US, and — separately from any of it — a straightforward commercial argument, because an inaccessible site turns away customers who were ready to buy.

This article is the WordPress accessibility audit we actually run, and what to do about each finding.

What the law now says

Two points that matter commercially. The European Accessibility Act reaches businesses selling into the EU, not only those based there — so a UK store shipping to Ireland is in scope. And it carries a micro-enterprise exemption for service providers with fewer than 10 staff and turnover under roughly €2 million, which covers a lot of small businesses. Confirm your own position rather than assuming either way.

Whatever applies to you, the technical target is the same: WCAG 2.2, level AA. That is what regulators, procurement forms and lawyers all point at.

WCAG 2.2 AA, in plain terms

Every WordPress accessibility requirement traces back to four ideas. Stripped of the formal language:

Level AA is the middle tier and the one every regulation names. Level AAA is not expected of a business site and is not achievable for all content.

The eight WordPress accessibility failures we find most

1. Contrast that fails on body text and buttons

Light grey on white is the most common WordPress accessibility failure we see, and the most common on the web generally. AA requires 4.5:1 for normal text and 3:1 for large text and interface components.

The usual offenders on a WordPress site: muted paragraph text, placeholder-grey form labels, white text on a mid-tone brand colour, and disabled-looking buttons that are actually live.

/* Fails AA on white: #999 is about 2.8:1 */
.post-meta { color: #999; }

/* Passes: #595959 is about 7:1 */
.post-meta { color: #595959; }

2. Nothing visible when you tab

Some themes remove the focus ring because designers find it ugly. For anyone navigating by keyboard that makes the site unusable — they cannot see where they are.

/* Never ship this */
*:focus { outline: none; }

/* Ship this instead — visible, and only for keyboard users */
:focus-visible {
	outline: 3px solid #0b57d0;
	outline-offset: 2px;
}

3. Placeholders used instead of labels

A placeholder disappears the moment someone types, taking the question with it. It is also frequently too low-contrast to read. Every field needs a real label — visually hidden if the design demands, but present in the markup.

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

4. Images with missing or useless alt text

Two WordPress accessibility failures here, in opposite directions. Meaningful images with no alt, and decorative images with alt text that a screen reader then reads aloud pointlessly.

Find the gaps across the whole media library:

wp eval '
$imgs = get_posts( array( "post_type" => "attachment", "post_mime_type" => "image", "numberposts" => -1 ) );
$missing = 0;
foreach ( $imgs as $i ) {
    if ( "" === trim( (string) get_post_meta( $i->ID, "_wp_attachment_image_alt", true ) ) ) { $missing++; }
}
echo $missing . " of " . count( $imgs ) . " images have no alt text\n";'

5. Heading levels used for size

Screen reader users navigate by headings the way sighted users skim, so heading order is a WordPress accessibility requirement rather than a style preference. A page that jumps H1 → H4 because H4 looked the right size is a broken outline. One H1 per page, then descend in order, and control size with CSS.

6. Link text that says nothing

“Read more”, “click here”, “learn more” — repeated fifteen times down a page, all going somewhere different. Assistive technology can list every link on a page; fifteen identical entries is fifteen unusable choices. Make the link text describe its destination.

7. Sliders, modals and menus that trap or exclude

The interactive components in page builders are where WordPress accessibility most often breaks:

• Carousels that auto-advance with no pause control, and whose arrows are unreachable by keyboard.
• Modals that do not move focus in on open, do not return it on close, and cannot be dismissed with Escape.
• Dropdown menus that only open on hover, so keyboard and touch users never reach the sub-items.
• Accordions built from divs with no aria-expanded, so state is invisible to a screen reader.

8. Target sizes too small on mobile

WCAG 2.2 added a target size criterion, and in WordPress accessibility terms it lands squarely on the small icon links and tight menu rows that phones inherit from desktop designs. Aim for 24×24 CSS pixels as the floor and 44×44 as a comfortable default.

How to test WordPress accessibility yourself

Automated tools catch perhaps a third of real WordPress accessibility issues. They are worth running, and they are not the test.

1. Unplug the mouse. Tab through a key page. Can you reach every link, open every menu, complete the form, and see where you are at all times? This one exercise finds more than any scanner.
2. Run an automated check — axe DevTools, WAVE, or Lighthouse’s accessibility audit. Fix what it finds, then keep going.
3. Zoom to 200%. Does the layout hold, or does content overlap and disappear?
4. Turn the sound on and use a screen reader — VoiceOver on Mac, NVDA on Windows. Ten minutes is uncomfortable and extremely informative.
5. Check your forms specifically. Submit one with a deliberate error and see whether the message is announced and tied to the field.

The full standard is published at the W3C’s WCAG quick reference, which is the authoritative wording when a criterion is ambiguous.

Why overlay widgets are not the answer

You will be sold a one-line script promising instant WordPress accessibility compliance. It is worth understanding why that does not work.

An overlay sits on top of the problem; it does not remove it. It cannot know what your image means, cannot fix a broken heading structure, and cannot make a custom widget keyboard-operable. Meanwhile it adds its own interface that screen reader users frequently report as making the site harder to use.

Businesses using overlays have still received accessibility complaints, and accessibility advocates have campaigned against them specifically. If a supplier offers compliance for a monthly script fee, treat that the way you would treat any other guarantee that seems too simple.

The part that decays: what editors publish

A site can launch fully accessible and fail within a year, because WordPress accessibility is not only a build-time property. Every published post is a chance to reintroduce the same failures.

The four editors reliably get wrong, and what to do about each:

Run the alt-text check from earlier once a month and the number tells you whether the habit is holding. It is the cheapest ongoing WordPress accessibility measure there is, and it is the one that stops a good build quietly degrading.

Building it in instead

Retrofitting WordPress accessibility is several times more expensive than building it in, because it means revisiting design decisions rather than writing code. What to establish at the start:

• Contrast checked at design stage, not after build. It is a five-minute check per palette.
• Focus states designed, so nobody is tempted to remove an ugly default.
• Components chosen for behaviour, not just looks — an accessible accordion and a pretty broken one cost the same to place on a page.
• Locked patterns so editors cannot accidentally break the heading order — see design systems and block patterns.
• A test in the launch checklist, alongside forms and redirects, in staging.

Ask any agency the questions in briefing a design project — the accessibility answer tells you quickly whether it is part of their process or an upsell.

The commercial case, separately from the law

Even where no regulation applies, WordPress accessibility work pays for itself, because the barriers above exclude paying customers:

• Around one in five people has a disability of some kind. A meaningful share of those affect how a website is used — vision, motor control, cognition, hearing.
• Temporary and situational limits count too. A broken wrist, bright sunlight on a phone screen, a noisy train, a slow connection. Accessible design is what holds up in all of them.
• The population is ageing. Contrast and target size stop being an edge case somewhere around 50 and never stop mattering again.
• The fixes are ordinary usability fixes. Readable text, clear labels, obvious focus, sensible tap targets. Everybody benefits; some people simply cannot proceed without them.

Which is why the conversion advice in design mistakes that hurt conversions and the WordPress accessibility list here overlap so heavily. They are largely the same work argued from two directions.

Content nobody audits: tables, video and PDFs

The WordPress accessibility audits we are asked to run almost always focus on the theme. These three live in the content and fail just as often.

Data tables

A table used for layout is a problem; a table used for data needs proper headers so a screen reader can announce which column a cell belongs to.

<table>
	<caption>Pricing by plan</caption>
	<thead>
		<tr><th scope="col">Plan</th><th scope="col">Monthly</th></tr>
	</thead>
	<tbody>
		<tr><th scope="row">Starter</th><td>£29</td></tr>
	</tbody>
</table>

Also give wide tables their own horizontally scrolling container, so the page body never scrolls sideways on a phone.

Video and audio

Captions are required for pre-recorded video at level A, and an audio description or transcript at AA. Auto-generated captions are a starting point, not a finish — they need correcting, particularly for names and product terms. A transcript on the page is also the version search engines and AI assistants can actually read.

PDFs

A scanned PDF is an image of text and is invisible to assistive technology and to search engines alike. If the content matters, it should be a web page. If it must be a PDF, it needs real text, tags and a reading order — which is more work than making the page.

WooCommerce: the journey that must not break

On a store, WordPress accessibility failures cost money directly, because they sit on the path to checkout:

Test the whole journey with the keyboard alone, all the way to a completed test order. It usually takes ten minutes and it is the highest-value accessibility test a store can run — the checkout detail is in checkout optimisation.

Which WordPress accessibility fixes come first

You will not fix everything at once. The WordPress accessibility work, ordered by impact against effort:

The first three are close to free and remove a large share of the day-to-day barriers. Anyone telling you WordPress accessibility must start with a five-figure audit has the order wrong.

The accessibility statement

Where regulations apply, you are generally expected to publish a WordPress accessibility statement covering what standard you aim for, known limitations, and how someone can report a barrier and get a response. Writing an honest one is genuinely useful: it forces the audit, and it gives a person who hits a problem somewhere to go other than a complaint.

Do not claim full conformance unless you have tested it. An inaccurate statement is worse than a candid one.

Common questions

Does the European Accessibility Act apply to my site?

It depends on what you sell, to whom, and how large you are. Consumer ecommerce selling into the EU is the clearest case; there is a micro-enterprise exemption for smaller service providers. Get advice on your specific position rather than relying on any article, including this one.

Is my WordPress theme accessible?

Some themes are audited for WordPress accessibility and say so; most make no claim. Test rather than trust — tab through the theme demo before you buy, and check contrast and focus states. A theme that fails these is a poor starting point regardless of how it looks.

How much does an accessibility fix cost?

The first WordPress accessibility pass — contrast, focus states, labels and alt text — is usually a day or two on a typical business site. Rebuilding inaccessible custom components costs considerably more, which is the argument for getting it right at build time.

Will an accessibility plugin make my site compliant?

No plugin can deliver WordPress accessibility on its own. Some help — contrast checkers and editor warnings are genuinely useful. Compliance comes from the markup, the design and the content, which is where the work has to happen.

Does accessibility help SEO?

Indirectly and consistently. The WordPress accessibility basics — semantic headings, descriptive links, real alt text and pages that work on any device are the same things search engines and AI assistants rely on to understand a page.