Running a site
WCAG for WordPress, in plain English
19 July 2026 · 7 min read
On this page
WCAG is written for people implementing standards, which makes it hard to read if you just want to know what to do with your website. Here is the translation.
The structure
Four principles. Content must be Perceivable, Operable, Understandable and Robust. Everything else hangs off those.
Three levels. A is the minimum, AA is the practical standard everyone means, AAA is for specialist contexts and not a realistic target for a normal site.
When someone says "WCAG compliant" they mean AA, which includes all of level A as well — around 50 success criteria in total.
Which version
WCAG 2.1 AA is the operative benchmark for the European Accessibility Act today, through the harmonised standard EN 301 549 v3.2.1.
WCAG 2.2 adds a small number of criteria and is backwards compatible. A newer EN 301 549 incorporating it is published and awaiting citation, so 2.2 is where things are heading without being the current legal test.
Practical advice: aim at 2.2, because it costs almost nothing extra over 2.1 and you will not have to revisit it. But if a vendor tells you 2.2 is legally required today, they are ahead of the standard.
What each principle actually asks
Perceivable — people can take the information in
The ones that matter on a WordPress site:
- Text alternatives for images. Alt text that describes function or meaning, not filenames.
- Captions for video. Prerecorded video needs captions. This is the criterion most small sites fail without realising.
- Colour contrast. 4.5:1 for body text, 3:1 for large text and interface components.
- Do not use colour alone to convey meaning. A form field that turns red with no error message fails.
- Text can be resized to 200% without breaking the layout or losing content.
Operable — people can use it
- Everything works by keyboard. The single most important criterion, and the one our five-failures post recommends testing first.
- No keyboard traps. You can tab out of anything you can tab into.
- Visible focus indicator. You can see where you are. Many themes remove the outline for aesthetic reasons, which is a direct failure.
- Skip link to bypass repeated navigation.
- Enough time. Session timeouts and carousels that advance on their own both cause problems.
- No flashing more than three times a second.
Understandable — people can make sense of it
- Language declared in the HTML, so screen readers pronounce correctly.
- Consistent navigation across pages.
- Labels and instructions on form fields.
- Error messages that explain the problem in text, and ideally suggest the fix.
Robust — it works with assistive technology
- Valid HTML with properly nested elements.
- Name, role and value available for custom components. If you have built something that behaves like a button, it needs to announce itself as one.
- Status messages announced, so a screen reader user knows the form submitted.
What WCAG 2.2 added that affects WordPress
The practical ones:
- Focus not obscured. A sticky header that covers the focused element fails. Very common on WordPress themes.
- Target size of at least 24×24 CSS pixels for interactive elements, which affects small icon buttons and tight menus.
- Consistent help. Support links in the same place across pages.
- Accessible authentication. No cognitive tests like solving a puzzle to log in, unless an alternative exists.
- Redundant entry. Do not make people re-type information they already gave you in the same process.
The realistic subset
You will not work through 50 criteria, and you do not need to in order to make a large difference. On a typical WordPress site, these account for most of the real-world barriers:
- Keyboard operability, everywhere
- Visible focus indicators
- Colour contrast
- Form labels and error messages
- Heading structure
- Alt text
- Captions on video
Fix those and you have addressed most of what an audit would find and most of what actually blocks people.
Testing it
Automated tools — axe DevTools, WAVE, Lighthouse — take minutes and find roughly a third of issues. Use them, and do not mistake a clean scan for a compliant site.
Manual keyboard testing finds most of the rest, and costs you ten minutes.
Screen reader testing — NVDA on Windows, VoiceOver on Mac — is uncomfortable at first and the most revealing thing you will do.
Our audit does all three, ranked by severity, with code-level guidance. But the keyboard test you can do this afternoon, free, and it will tell you more than any scanner.