WordPress accessibility in 2026: the practical guide to WCAG 2.2

About 41.5 percent of all websites run on WordPress; no other system comes close (W3Techs, July 2026). For accessibility that is good news: WordPress ships with much of what accessible pages need, from the clean HTML of the block editor to the alt text field in the media library. It guarantees none of it, though. Whether a WordPress site is actually accessible comes down to theme choice, plugins and everyday editing habits. This guide walks through those levers as of 2026, with WCAG 2.2 as the target rather than the 2.1 of years past. Where your site stands today takes two minutes to find out.

Why WordPress accessibility looks different in 2026

Most WordPress accessibility tutorials you will find today were written for WCAG 2.1. That was fine for years, but it is out of date: since October 2023, WCAG 2.2 has been the current W3C recommendation, and the revised EN 301 549, the European standard behind Germany's BFSG and the European Accessibility Act, is expected for 2026 with WCAG 2.2 AA as its reference. If you are fixing your site now, aim straight at 2.2, or the next round of work is already scheduled. What the conformance levels A, AA and AAA mean is covered in our guide to WCAG conformance.

The step from 2.1 to 2.2 is not a fresh start but a handful of new success criteria. Six of them hit typical WordPress patterns squarely:

The striking thing about this list: most of it lives in the theme or in plugins, not in your content. You stay responsible anyway. A scan measures your website, not the good intentions of your theme developer. So after every major update, check whether a plugin has quietly reintroduced one of these patterns.

The legal side in three sentences

If your WordPress site only publishes information, accessibility law will in most cases leave you alone for now; fixing barriers still pays, because every barrier costs visitors. As soon as people can buy, book or sign contracts on the site, typically through WooCommerce or a booking plugin, the European Accessibility Act applies across the EU, and for sales to German consumers its notably enforced local implementation, the BFSG, complete with official inspections and fines. Who exactly is covered and which exemptions really apply is explained in our guide to Germany's BFSG.

The foundation: a theme that does not work against you

Accessibility in WordPress starts before the first piece of content, with the theme. The theme sets colour contrast, focus styling, skip links and the HTML structure every single page inherits. A sensible starting point is the official theme directory filtered by the accessibility-ready tag: around a hundred themes that passed a review against defined minimum standards, instead of thousands that were never checked.

Premium themes outside the directory carry no such tag. There, three quick tests in the live demo help before you buy: is the default colour scheme high-contrast enough? When you tab through a page, can you always see where the focus currently is? And does the first tab stop offer a skip link straight to the content? Ten minutes of demo testing save weeks of patchwork in production.

The eight problem areas in everyday WordPress work

With the theme in place, daily work in the editor decides whether the site stays accessible. These eight points cover most of what regularly goes wrong on WordPress sites:

• Check the theme basics: contrast, visible focus, skip link (see above). Skimp here and every following point becomes a fight against your own foundation.
• Treat headings as structure: in the block editor, an H2 is an outline level, not a font size. Do not skip levels, and do not pick an H4 because it looks prettier.
• Maintain alt text in the media library: every informative image gets an alternative text; purely decorative images deliberately stay empty so screen readers skip them.
• Choose form plugins with real labels: a placeholder inside the field is not a label. The label must be programmatically attached and must not vanish while typing.
• Check contrast after every colour change: the delicate grey on white that looks elegant in the customizer is the first thing a scan flags.
• Schedule a keyboard test: tab through your most important pages. Can you reach every menu, button and field, and can you get back out everywhere?
• Verify the skip link: the first tab stop should be a link straight to the content. Accessibility-ready themes ship one, many others do not.
• Avoid auto-advancing sliders or make them pausable: a carousel that moves on by itself needs at least a pause control. Often the better fix is removing it entirely.

In practice, the biggest single item is almost always alt text. WordPress makes it easy to forget: the field in the media library is inconspicuous, and the page looks perfect without it. For screen reader users, a missing alt text means: there is an image here, and nobody tells you what it shows. What good alternative text looks like is described in the W3C images tutorial; with hundreds of legacy images, a generator is worth using for the first draft.

Plugins: what genuinely helps and what merely reassures

Useful plugins check while you write: they warn in the editor about missing alt text or skipped heading levels before the post goes live. Checkers like that move quality control to the right place, before publication. What does not exist is the plugin that makes a website conformant automatically. Conformance comes from theme, content and routines, and none of those three can be installed.

Be especially sceptical of overlay plugins that inject a settings panel via script and promise accessibility at the push of a button. They can offer visitors display comfort, nothing more: unlabelled forms, broken keyboard paths and missing alt text persist unchanged underneath. Why that is technically unavoidable, and how professionals and authorities judge overlays, is covered in our guide to accessibility overlays.

Testing: automated first, then by hand

An automated scan is the right start because it finds the machine-detectable violations reliably and repeatably: weak contrast, missing alt text, unlabelled fields. Those are also the errors anyone else sees first when they point a tool at your site. The scan is not the end, though: whether an alt text actually fits, or the menu turns into a keyboard trap, only a human can tell.

• Tab through the home page, one content page and your most important form: everything reachable, focus visible at all times?
• Skip link: does the first tab stop really lead to the content?
• Sliders and animations: can they be paused, and does everything work without dragging?
• Spot-check five images: does the alt text say what the image is doing in this exact spot?
• Submit a form with deliberate mistakes: is the error explained in text rather than just coloured red?

For the colour questions you do not need gut feeling. Contrast is a measurable value with clear thresholds, and checking it takes seconds.

Frequently asked questions about WordPress accessibility

WordPress does not stand in the way of accessibility; it just waits for instructions. The alt text field exists, the heading levels exist, reviewed themes exist. What is usually missing is an overview of where your own site concretely fails. That is exactly what the scan at the top of this article delivers: two minutes, a prioritised work list, and a vague intention becomes a project with an end.