Hacked, redirecting or showing a blank page? We clean and restore WordPress sites in 24 hours.

Get emergency help
WP Site Kept.
All guides

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:

  1. Keyboard operability, everywhere
  2. Visible focus indicators
  3. Colour contrast
  4. Form labels and error messages
  5. Heading structure
  6. Alt text
  7. 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.

Share this

Would rather not do it yourself?

We keep WordPress sites updated, backed up and fixed.

Weekly updates with a backup taken first and the site checked afterwards, daily off-site backups, malware monitoring with free cleanup, and engineers who answer. From $79 a month, covered within 24 hours.