WordPress Accessibility: Make Your Site WCAG 2.2 AA and EAA Compliant

The accessibility baseline is WCAG 2.2 Level A and AA, referenced through the European standard EN 301 549. The European Accessibility Act (Directive (EU) 2019/882) has required this of in-scope products and services since 28 June 2025. If you sell products or services to EU consumers, you are likely in scope; microenterprises that provide services (fewer than 10 staff and under EUR 2,000,000 turnover) are largely exempt for those services, but the exemption is narrow, so check your scope.

WCAG is built on four principles: content must be Perceivable, Operable, Understandable, and Robust. You do not need to memorise every success criterion. For a typical WordPress site, a short list of failures accounts for most violations: missing or useless alt text, broken heading order, unlabelled forms, low colour contrast, keyboard traps, and links that say nothing. Get those right and you are most of the way to AA.

Your theme generates most of the HTML a screen reader and keyboard user rely on, so it is the highest-leverage decision you make. A poorly built theme can fail accessibility in ways no plugin can patch.

Prefer a theme that follows the 'accessibility-ready' guidelines, or a modern block theme built on the current site editor, which tends to output cleaner semantic markup than legacy page-builder themes. When evaluating a theme, check four things directly:

• Keyboard operability: tab through the menu, search, and any sliders. Every interactive element must be reachable and show a visible focus outline.
• A working 'skip to content' link as the first focusable element, so keyboard and screen reader users can bypass the menu.
• One H1 per page and a logical heading order, with no levels skipped to fake a font size.
• Colour contrast of at least 4.5:1 for body text and 3:1 for large text (18pt, or 14pt bold) and UI components, in both the default and any dark variant (WCAG 1.4.3 and 1.4.11).

Heavy visual page builders are the usual culprits for div soup, empty links, and unreadable focus states. If you use one, test the rendered output, not the editor preview.

Avoid accessibility overlays

The single most common WordPress accessibility mistake is installing an 'overlay' or 'accessibility widget' plugin and assuming the job is done. These inject a floating toolbar and client-side scripts, but they do not fix the underlying HTML and cannot deliver WCAG 2.2 AA conformance on their own. They are widely criticised by disabled users and have featured in legal complaints. Treat them as a red flag, not a solution.

Plugins that genuinely help

Useful plugins fix data and surface problems rather than masking them. A testing or scanning plugin flags machine-detectable issues during editing. A plugin that enforces alt text on upload, or one that adds proper labels and error handling to form output, addresses real criteria. Audit your existing stack too: galleries, popups, cookie banners, and chat widgets are frequent sources of keyboard traps and missing labels.

Themes and plugins set the stage, but most day-to-day WordPress accessibility lives in the content your editors publish. Three habits fix the bulk of it.

Write alt text that describes purpose

In the WordPress media library, the Alt Text field is separate from the Title and Caption, and only Alt Text is exposed to screen readers. Describe what the image conveys in context, not its filename. A product photo might be 'Navy wool overcoat, front view'. Decorative images, like a divider or background flourish, should have an empty alt attribute (alt="") so screen readers skip them.

Keep headings structural

In the block editor, choose heading levels by document structure, not appearance. The page title is the H1; major sections are H2; subsections are H3. Never jump from H2 to H4, and never use a heading block just to make text bigger. Use CSS or font-size controls for visual sizing instead.

Make link text meaningful

'Click here' and 'read more' tell a screen reader user nothing when links are read out of context. Write links that describe their destination, like 'download the 2026 price list'. The same applies to buttons and 'read more' blocks repeated across an archive page.

• Forms with placeholder text used instead of real labels. Contact and checkout forms need a visible, programmatically associated label per field, plus clear error messages.
• Low-contrast brand colours in buttons, links, and muted helper text. Verify against the 4.5:1 and 3:1 thresholds in WCAG 1.4.3 and 1.4.11.
• Auto-playing sliders and carousels with no pause control and no keyboard access.
• Modals, menus, and cookie banners that trap focus or cannot be closed with the keyboard; test with the Tab and Escape keys.
• PDFs linked from pages that are themselves untagged and inaccessible, which the EAA still counts against you.

Sequence the work by impact and effort:

• First, run an automated scan to catch the easy, high-volume wins: missing alt text, low contrast, unlabelled fields, empty links.
• Second, fix the theme-level basics that affect every page: focus visibility, skip link, heading order, menu keyboard access.
• Third, test by hand what tools cannot see: tab through key journeys, then run a screen reader over your homepage, a product or service page, and checkout.
• Fourth, publish an accessibility statement so users know your conformance status and how to report problems.

Automated tools only catch a portion of WCAG issues, so the manual pass is not optional. Work through the accessibility checklist to cover the rest. When you ship changes, re-scan, because accessibility regresses every time a new plugin or theme update lands.