WordPress accessibility: the theme, plugin, and editor issues that fail WCAG 2.2 AA

WordPress is an unusually good starting point for accessibility and an unusually easy place to lose it. The project's own coding standards require new and updated core code to conform to WCAG 2.2 AA, and the admin and bundled themes are built to that target. None of that carries over to the theme you bought, the eleven plugins you installed, or the way your marketing team builds pages.

This is where WordPress sites actually fail, in the order we tend to find it.

What core gives you, and what it does not

WordPress states that all new and updated code released in WordPress must conform with WCAG 2.2 AA under its accessibility coding standards, and that the WordPress admin and bundled themes aim to be fully compliant at that level where possible. That covers the editing experience and the default themes.

It does not cover third-party themes or plugins, and WordPress says so directly: the project cannot guarantee that all themes are compliant. Since a typical site runs a commercial theme and a dozen plugins, most of the front end a visitor receives is outside the guarantee.

What the accessibility-ready tag actually means

Themes in the WordPress.org directory can carry an accessibility-ready tag, which means a reviewer checked them against the Theme Review Team's accessibility guidelines. It is a meaningful signal and it is worth preferring a tagged theme over an untagged one.

It is not a conformance claim. The review handbook is explicit that accessibility-ready does not mean the theme meets WCAG AA — it means the theme reaches the minimum standards the review team set. Treat it as a floor on the theme's own markup, not a verdict on the site you build with it.

Theme-level failures

• Focus outlines removed. A CSS reset with outline: none and no replacement is the most common single failure in commercial themes. WCAG 2.4.7 Focus Visible, Level AA.
• No skip link, or a skip link that does not move focus. Keyboard users tab through the entire navigation on every page.
• Mega menus that only open on hover. If it cannot be opened and closed with the keyboard, the links inside it are unreachable.
• Sticky headers that cover the focused element. New in WCAG 2.2 — 2.4.11 Focus Not Obscured (Minimum), Level AA.
• Brand colours below 4.5:1. Themes ship with a demo palette chosen for screenshots, and the body-copy grey is usually the first thing to fail.
• Icon-only controls with no accessible name — search toggles, cart icons, menu buttons, social links in the footer.
• Sliders and carousels that autoplay with no pause control, and that respond to swipe only. WCAG 2.2.2 Pause, Stop, Hide and 2.5.7 Dragging Movements.
• Tap targets under 24 by 24 CSS pixels on mobile navigation and pagination. WCAG 2.5.8 Target Size (Minimum), Level AA.

Plugin-level failures

Plugins inject markup you did not write into pages you are responsible for. The recurring offenders are form builders, cookie and consent banners, popup and email-capture plugins, page builders, and any plugin that renders a modal.

• Form plugins that render placeholders instead of labels, and that announce validation errors visually only. Errors need to be programmatically associated with the field and surfaced to assistive technology.
• Consent banners that trap keyboard focus, or that sit above the page without being reachable by keyboard at all. This one blocks the entire site rather than one component.
• Popups that do not move focus into the dialog on open, do not return focus on close, and cannot be dismissed with Escape.
• Page builders that produce heading markup from a font-size setting, so a visual H2 is a styled div and the document outline is empty.
• Lightbox galleries with no keyboard controls for next, previous, and close.
• Any plugin advertising one-click ADA or WCAG compliance. These are overlay widgets in a plugin wrapper: they run in the visitor's browser and do not change your code, so the markup a complaint would cite is still the markup you shipped. Treat a compliance guarantee as a claim that needs evidence behind it.

Editor and content failures

The block editor will happily let an author build an inaccessible page out of accessible blocks. These are the patterns to train out, and they are worth putting in a one-page editorial standard rather than fixing repeatedly.

• Heading levels chosen for size. An H2 followed by an H4 because H3 looked too big breaks the document outline that screen-reader users navigate by. WCAG 1.3.1 Info and Relationships.
• More than one H1 per page, or a page whose H1 is the site logo.
• Alt text left blank on informative images, or auto-filled with the filename. The media library keeps whatever was set the first time the image was used, so one bad alt text propagates.
• Link text that reads 'click here', 'read more', or 'learn more' repeated down the page. A screen-reader user listing the links hears the same phrase eight times.
• Tables built from columns blocks, which look like tables and carry none of the header relationships that make them navigable.
• Text baked into images — a promo banner whose offer exists only as pixels cannot be read, resized, or translated.
• Embedded video with no captions. WCAG 1.2.2 Captions (Prerecorded), Level A.

How to audit a WordPress site

1. Scan the front end first, across templates rather than one page. You want the home page, an archive, a single post, a page built by the page builder, and any form or checkout.
2. Fix in the theme, not the page. Almost every finding above lives in a template or a stylesheet, so one change clears it everywhere.
3. Deactivate plugins one at a time on a staging copy and re-scan. This is the fastest way to attribute an injected failure to the plugin that caused it.
4. Walk the site with the keyboard only. Menus, search, forms, popups, consent banner. Automated tools cannot tell you whether the focus order made sense.
5. Re-scan after every theme or plugin update. WordPress sites regress through updates more than through edits, and a fixed issue returning is the failure mode nobody watches for.

Where AdaChecked fits

The AdaChecked Site Scanner scans any public site regardless of stack, so a WordPress site needs no plugin installed and no code change to be audited — the scan runs on our infrastructure against the pages your visitors actually receive, which is the only way to see what your theme and plugins combine to produce. Issues come back mapped to the WCAG 2.2 criterion they fail, with how-to-fix guidance, and monitoring re-scans catch the regressions that arrive with updates.

Scheduled scans matter more on WordPress than on most stacks: plugin and theme updates ship on their own cadence, and a fixed issue returning after an update is the failure mode nobody is watching for. Monitoring turns that into an email rather than a discovery.

← All posts