WordPress accessibility checklist (2026)

Written against WCAG 2.2 level AA. Last reviewed 22 October 2026.

How to use this checklist

Work through it in order. The theme comes first because a fix there fixes every page. Each check says what to look for, how to do it in WordPress, and which WCAG 2.2 success criterion it comes from, with the level (A or AA). Where A11yMate checks for it automatically, there is a link to the rule, which has examples and code.

Before you start, check one page for free to see the kind of problems your site has. Then check every page: problems in a header or footer repeat across the whole site, and the free A11yMate plugin scans the lot and groups them, so you see "on 48 pages" once instead of 48 times.

Automated checks find only part of the problems. The last section is how to test the rest yourself, and it takes about twenty minutes.

Your theme: fix once, fixed on every page

The theme draws the header, menu, footer and the styles every page shares. A problem here repeats on every page, and so does the fix. Start here.

• The page language is set

  Settings → General → Site Language. Your theme passes it to the <html lang> attribute, so screen readers use the right voice and pronunciation.

  WCAG 3.1.1 (A) · A11yMate rule

• There is a skip link

  A "Skip to content" link as the first thing you can tab to, so keyboard users do not tab through the whole menu on every page. Block themes get one from WordPress automatically. Classic themes have to provide it.

  WCAG 2.4.1 (A) · A11yMate rule

• The page has landmarks

  One <main> around the content, <nav> around menus, and a label on each menu if there is more than one ("Main", "Footer"). Screen reader users jump between them.

  WCAG 1.3.1 (A) · A11yMate rule

• You can see where focus is

  Tab through the page. Every link, button and field needs a visible outline or highlight when it has focus. Themes that remove the outline with outline: none and put nothing back fail this.

  WCAG 2.4.7 (AA) · A11yMate rule

• Sticky headers do not hide the focused item

  New in WCAG 2.2. When you tab down the page, a sticky header, cookie banner or chat button must not completely cover the thing that has focus. Adding scroll-padding-top to the page usually fixes a sticky header.

  WCAG 2.4.11 (AA) · A11yMate rule

• Text has enough contrast

  At least 4.5:1 for body text, and 3:1 for large text (24px, or about 19px bold). Pale grey on white is the most common failure on WordPress sites. Fix it in the theme's colour palette, not post by post.

  WCAG 1.4.3 (AA) · A11yMate rule

• Buttons, fields and icons have enough contrast

  The edges of form fields, icon buttons and focus outlines need 3:1 against what is around them, so people can find them.

  WCAG 1.4.11 (AA) · A11yMate rule

• Links do not rely on colour alone

  Links in a paragraph need something besides colour to show they are links, and an underline is the simplest. A link colour with 3:1 contrast against the text around it, plus an underline on hover and focus, also passes.

  WCAG 1.4.1 (A) · A11yMate rule

• People can zoom

  Pinch zoom must work on phones. Some themes still switch it off with user-scalable=no or maximum-scale=1 in the viewport tag.

  WCAG 1.4.4 (AA) · A11yMate rule

• The page works at 400% zoom

  At 1280px wide and 400% zoom (the same as a 320px-wide screen), the page should reflow into one column with no sideways scrolling, and nothing cut off.

  WCAG 1.4.10 (AA) · A11yMate rule

• Text survives extra spacing

  Some people use their own line and letter spacing. Text must not be cut off or overlap when line height is 1.5, paragraph spacing 2× and letter spacing 0.12em. Fixed-height boxes are the usual cause.

  WCAG 1.4.12 (AA) · A11yMate rule

• Things to tap are big enough

  New in WCAG 2.2. Click and tap targets need to be at least 24 by 24 pixels, or have enough space around them. Watch social icons, close buttons and tightly packed footer links.

  WCAG 2.5.8 (AA) · A11yMate rule

• The menu works with a keyboard

  Drop-down menus must open with the keyboard, not only on hover, and close again with Escape. The mobile menu button needs a name ("Menu") and should say whether it is open.

  WCAG 2.1.1 (A)

• Animation respects reduced motion

  Parallax, scroll effects and large animations should calm down when the visitor has asked their device to reduce motion (prefers-reduced-motion).

  WCAG 2.3.3 (AAA, good practice) · A11yMate rule

Your content: posts and pages in the block editor

These are the problems that arrive one post at a time. Each is quick to fix while you write and slow to find later.

• Headings follow the structure

  Most themes use the post title as the H1, so headings in the content start at H2, with H3s inside them. Pick a level for the structure, not for the size: change the size in the block's Typography settings. The Outline tab in the editor's Document Overview shows your structure.

  WCAG 1.3.1 (A) · A11yMate rule

• Every meaningful image has alt text

  In the Image block or the Media Library's Alternative Text field, describe what the image tells the reader in a sentence. Not the file name, and no need to start with "image of".

  WCAG 1.1.1 (A) · A11yMate rule

• Decorative images have empty alt text

  If the image adds nothing a reader would miss, leave the alt text empty, as WordPress suggests. Screen readers then skip it. Empty is fine. Missing alt text, or a file name, is not.

  WCAG 1.1.1 (A) · A11yMate rule

• Linked images say where they go

  If an image is a link (a logo, a product card), its alt text should describe the destination, such as "Home" or "Blue linen shirt".

  WCAG 2.4.4 (A) · A11yMate rule

• Link text makes sense on its own

  "Click here", "read more" and "here" tell a screen reader user nothing when they jump from link to link. Write "Download the 2026 price list", or put the post title in the "read more" link.

  WCAG 2.4.4 (A) · A11yMate rule

• Buttons have words

  Button blocks and icon buttons need text or a label. A button with only an icon and no name is read as just "button".

  WCAG 4.1.2 (A) · A11yMate rule

• Links to files say what they are

  Add the type and size: "Menu (PDF, 2 MB)". And where you can, put the content on a web page instead of in a PDF. Most PDFs uploaded to WordPress have no structure for screen readers.

  WCAG 2.4.4 (A) · A11yMate rule

• Colour choices in blocks pass contrast

  Text and background colour settings on Paragraph, Group, Cover and Button blocks can undo a good theme. Check each pair, especially white text on a light photo in a Cover block.

  WCAG 1.4.3 (AA) · A11yMate rule

• Lists are lists and tables have headers

  Use the List block, not lines that start with dashes. In the Table block, turn on the header section so each column has a heading.

  WCAG 1.3.1 (A) · A11yMate rule

• Videos have captions

  For YouTube or Vimeo, add or check captions there. Self-hosted videos in the Video block can carry a captions file (WebVTT) as a text track. Auto-captions need checking: names and numbers come out wrong.

  WCAG 1.2.2 (A) · A11yMate rule

• Nothing plays sound on its own

  Background videos should be muted, and any audio that starts by itself for more than three seconds needs a way to stop it.

  WCAG 1.4.2 (A) · A11yMate rule

• Embeds have a title

  Maps, videos and booking widgets embedded in a frame need a title on the frame. WordPress's own embed blocks usually add one. Code pasted into a Custom HTML block often does not.

  WCAG 4.1.2 (A) · A11yMate rule

Forms: contact, booking, checkout and login

Forms are where accessibility problems cost you enquiries and sales. Whichever form plugin you use, check its output, not its settings screen.

• Every field has a visible label

  A label people can see, linked to the field. A placeholder alone is not a label: it disappears as soon as someone types, and some screen readers skip it.

  WCAG 1.3.1 and 3.3.2 (A) · A11yMate rule

• Required fields are marked properly

  Say which fields are required in the label, and mark them as required in the code too, not just with a red asterisk.

  WCAG 3.3.2 (A) · A11yMate rule

• Errors say what is wrong and how to fix it

  An error message next to the field, in words ("Enter an email address like name@example.com"), not just a red border.

  WCAG 3.3.1 (A) and 3.3.3 (AA)

• Personal details fields use autocomplete

  Name, email, phone and address fields should have the right autocomplete value, so browsers can fill them in. Most good form plugins have a setting for it.

  WCAG 1.3.5 (AA) · A11yMate rule

• Radio buttons and checkboxes are grouped

  A group of choices needs a group label (a fieldset and legend), so "Yes" and "No" are read with the question they answer.

  WCAG 1.3.1 (A) · A11yMate rule

• No puzzles to log in or send a form

  New in WCAG 2.2. Logging in must not depend on solving a puzzle or remembering something without help. Let people paste passwords and use password managers (some security plugins block this), and prefer a spam check that asks nothing of the person over picture puzzles.

  WCAG 3.3.8 (AA)

• People are not asked for the same thing twice

  New in WCAG 2.2. In a multi-step form or checkout, do not make people type information they already gave. WooCommerce's "Ship to a different address?" option, which reuses the billing address unless ticked, is the pattern to follow.

  WCAG 3.3.7 (A)

Plugins and extras: the parts you did not build

Cookie banners, pop-ups, sliders and chat widgets come from plugins, and they cause a large share of the problems on otherwise good sites. Test each one with a keyboard.

• The cookie banner works with a keyboard

  You must be able to reach it, choose an option and close it without a mouse. It should not cover the content you are tabbing through.

  WCAG 2.1.1 (A) and 2.4.11 (AA)

• Pop-ups can be closed and do not trap people

  A pop-up needs a close button with a name, should close with Escape, should put focus inside it when it opens, and should return focus to where you were when it closes.

  WCAG 2.1.2 (A) and 2.4.3 (A)

• Sliders and carousels can be paused

  Anything that moves on its own for more than five seconds needs a pause button. Better still, do not auto-advance at all.

  WCAG 2.2.2 (A) · A11yMate rule

• Nothing needs dragging

  New in WCAG 2.2. If something works by dragging (a before-and-after slider, a range control, a map), there must also be a way to do it with single clicks or taps.

  WCAG 2.5.7 (AA)

• Page builder output is checked, not assumed

  Page builders can produce empty headings, unlabelled icon links and tab widgets that need a mouse. Scan the pages they build, not just the posts.

  Several · A11yMate rule

• No overlay pretending to fix it all

  An accessibility overlay widget does not fix the site underneath. Spend the money on fixing the site.

  n/a

Across the site

A few things that only show up when you look at the site as a whole.

• Every page has its own title

  The browser tab title is the first thing a screen reader announces. Each page needs a different one that says what the page is. SEO plugins set this; check that archives and paged lists are not all the same.

  WCAG 2.4.2 (A) · A11yMate rule

• Help is in the same place on every page

  New in WCAG 2.2. If you offer contact details, a contact page link or a chat button, keep it in the same place across pages, such as in the header or footer.

  WCAG 3.2.6 (A)

• There is an accessibility statement

  Say what standard you aim for, what is known not to work yet, and how people can get help or report a problem. UK public sector sites must publish one, and businesses covered by the European Accessibility Act must publish accessibility information. A11yMate Pro writes one from your scan results.

  Good practice

Test it like a person

These four tests find most of what automated checks cannot. Do them on your homepage, a typical post, a form and your checkout or booking page.

1. Keyboard only. Put the mouse away. Use Tab and Shift+Tab to move, Enter and Space to use things, Escape to close, and arrow keys in menus. Can you reach and use everything, always see where you are, and never get stuck?
2. Zoom. Zoom the browser to 200%, then 400%. Is anything cut off, overlapping or only reachable by scrolling sideways?
3. Screen reader. Turn on VoiceOver (Command+F5 on a Mac, or in Settings on an iPhone) or install NVDA on Windows, which is free. Listen to a page from the top, then jump through the headings and the links. Does it make sense without seeing it?
4. Phone. Use the site on a phone held in either orientation. Can you tap everything without hitting the wrong thing, and fill in the forms?

Keep it that way

Accessibility slips every time someone adds a post, installs a plugin or changes the theme. Three habits keep it in hand:

• Check as you write. A11yMate's free Editor Assistant flags missing alt text, skipped headings, vague links and low contrast in the block editor, before you publish.
• Rescan after changes. Scan the whole site after a theme change, a new plugin or a redesign. A11yMate Pro can scan on a schedule and email you what changed.
• Write down what you know. Keep your accessibility statement up to date with what works and what you are still fixing.

Would you rather someone else did it? OakFox audits and fixes WordPress sites: the studio that makes A11yMate.

Questions

Sources

• Web Content Accessibility Guidelines (WCAG) 2.2 and What's new in WCAG 2.2 (W3C)
• WordPress Accessibility Coding Standards (WordPress Developer Resources)
• Accessibility-ready theme requirements (WordPress Themes Team handbook)
• Understanding accessibility requirements for public sector bodies (GOV.UK)

Related: Does the European Accessibility Act apply to my UK website? and why overlays do not make a site compliant.