WCAG compliance in WordPress means making your site usable by people who use screen readers, keyboards, magnifiers or other assistive tools. WCAG stands for Web Content Accessibility Guidelines, and the W3C publishes it. This guide turns the rules into steps you can follow on a WordPress site.
You will learn what the three WCAG levels mean, which success criteria matter most, and how to check your theme, images, colors, forms and keyboard use. A checklist closes the guide. It is general guidance, not legal advice.
Aim for WCAG 2.2 Level AA. Pick a theme that passes WordPress accessibility review, add text alternatives to images, keep text contrast at 4.5:1 or better, make everything work with a keyboard, label every form field, and test with real tools. Fix the basics first, then retest after each update.
⚡ Key Takeaways
- WCAG has success criteria at three levels: A, AA and AAA. Most sites aim for AA.
- Content that meets WCAG 2.2 also meets WCAG 2.1 and 2.0, according to the W3C.
- Normal text needs a contrast ratio of at least 4.5:1. Large text needs 3:1.
- Everything that works with a mouse must also work with a keyboard.
- WordPress runs an optional Accessibility Ready review for themes, but you still need to test your own content.
Why WCAG Compliance in WordPress Matters
The World Health Organization estimates that 1.3 billion people, or 16% of the world’s population, experience significant disability. Many of them use the web with assistive tools. A site that ignores them loses visitors and customers.
Accessible sites are also easier for everyone to use. For example, clear headings, good contrast and labeled forms help people on small screens, in bright light or with a slow connection. For the legal side, see this explanation of ADA compliance for websites, and check the rules in your own country.
Understand the WCAG Compliance Levels
The W3C says WCAG success criteria are testable and sit at three levels: A, AA and AAA. Level A covers the basics, while AA adds more, such as the contrast rules. AAA is the strictest. However, the W3C does not expect every site to meet it for all content.
The current version is WCAG 2.2. In fact, the W3C states that content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and 2.1. So aiming for 2.2 Level AA is a safe target for most WordPress sites.
WCAG 2.2 added new criteria. Three examples at Level AA are Focus Not Obscured (Minimum), Target Size (Minimum) and Accessible Authentication (Minimum). The target size rule asks for pointer targets of at least 24 by 24 CSS pixels, with some exceptions.
Step 1: Start With a Theme That Supports WCAG Compliance
Your theme controls most of your markup. WordPress offers an optional Accessibility Ready review for themes, run by the themes team. Choosing a theme that has passed it gives you a better base.
Even so, the review covers the theme, not your content. For instance, you can still add low-contrast text, missing alt text or broken headings, so keep testing after you publish.
Step 2: Add Text Alternatives to Images
WCAG Success Criterion 1.1.1 says non-text content needs a text alternative that serves the equivalent purpose. In WordPress, that means the alt text field in the media library and the block editor.
- Describe what the image shows and why it is there.
- Leave the alt text empty for purely decorative images, so screen readers skip them.
- Do not start with “image of”. Screen readers already announce an image.
- If an image is a button or link, the alt text should say what it does.
Step 3: Check Color Contrast and Text Size
Success Criterion 1.4.3 asks for a contrast ratio of at least 4.5:1 for text and images of text. Large-scale text needs at least 3:1. Criterion 1.4.11 asks for at least 3:1 for user interface components and graphical objects.
Success Criterion 1.4.4 also says text should be resizable up to 200 percent without loss of content or function. Test your pages by zooming the browser to 200 percent, and watch for overlapping text or hidden buttons.
Step 4: Make Everything Work With a Keyboard
Success Criterion 2.1.1 says all functionality must be operable through a keyboard interface. First, put your mouse aside and press Tab through the page. Menus, forms, sliders, pop-ups and buttons should all work.
Two related rules help here. First, criterion 2.4.7 says the keyboard focus indicator must be visible, so never hide the focus outline without a replacement. Criterion 2.4.1 asks for a way to bypass repeated blocks, which is why many themes include a skip link to the main content.
Step 5: Build Accessible Forms
Success Criterion 3.3.2 says labels or instructions must be provided when content needs user input. Give every field a visible label that stays on screen, not only placeholder text that disappears.
Next, check error messages. Criterion 3.3.3 asks that when an error is detected and a fix is known, the suggestion is shown to the user. Plain words such as “Enter an email address like name@example.com” help more than “Invalid input”.
Step 6: Use Clear Headings, Links and Semantic HTML
Use real heading levels in order, so that screen reader users can jump through the page. Criterion 2.4.4 asks that the purpose of each link can be worked out from the link text, or from the link text together with its context. So write “Download the price list”, not “Click here”.
Criterion 4.1.2 says the name and role of interface components can be determined by software. When you build custom widgets, use native HTML elements where you can. Use ARIA only to fill gaps, because wrong ARIA can make things worse.
Good structure also helps search engines read your pages. This on-page SEO checklist for WordPress covers the overlap.
Step 7: Test WCAG Compliance With Real Tools and Real Use
Automated tools find only part of the problems. So, run a scanner first, then test by hand. Use a keyboard, zoom to 200 percent, and try a screen reader such as NVDA on Windows or VoiceOver on a Mac.
If you can, ask people who use assistive technology to try your key pages. Their feedback shows problems that tools miss. Then, retest after theme, plugin or content updates, because changes can bring problems back.
Worked Example of WCAG Compliance (Made-Up)
Imagine a small clinic site on WordPress. First, a quick audit finds four problems: gray text on a white background, a contact form with placeholder text only, a menu that does not open with the keyboard, and photos with no alt text.
| Problem | WCAG area | Fix |
|---|---|---|
| Light gray body text | 1.4.3 Contrast (Minimum) | Darken the text color until it reaches at least 4.5:1 |
| Form with placeholder-only fields | 3.3.2 Labels or Instructions | Add visible labels above each field |
| Menu closed to keyboard users | 2.1.1 Keyboard | Switch to a menu that opens with Tab and Enter |
| Photos without alt text | 1.1.1 Non-text Content | Write short, useful alt text for each photo |
This site is made up. It shows how a short audit turns into a clear to-do list.
WCAG Compliance Checklist for WordPress
- Choose a theme that has passed the WordPress Accessibility Ready review.
- Write useful alt text, and leave decorative images empty.
- Check that text meets 4.5:1 contrast, and large text 3:1.
- Tab through the whole page and confirm that a focus outline is visible.
- Label every form field and write helpful error messages.
- Use headings in order and write clear link text.
- Test with a scanner, a keyboard and a screen reader, then retest after updates.
Conclusion
WCAG compliance is a habit, not a one-time project. So, start with the criteria in this guide, fix the biggest problems first, and test each time you change your theme, plugins or content.
If your site needs custom templates or a rebuild, WordPress development that follows accessibility rules from the start is easier than fixing issues later.
Frequently Asked Questions About WCAG Compliance in WordPress
Which WCAG level should I aim for?
Most sites aim for Level AA of WCAG 2.2. The W3C notes that content meeting WCAG 2.2 also meets 2.1 and 2.0.
Is a plugin enough for WCAG compliance?
No. Plugins and scanners can help, but they find only part of the problems. You still need to test with a keyboard, a screen reader and real content.
What contrast ratio does WCAG require for text?
At least 4.5:1 for text and images of text, and at least 3:1 for large-scale text, under Success Criterion 1.4.3.
Does WCAG require alt text for every image?
Non-text content needs a text alternative that serves the equivalent purpose, with listed exceptions. Decorative images can have empty alt text so assistive tools skip them.
Is this legal advice?
No. This is general guidance. Accessibility laws differ by country and sector, so check the rules that apply to you.
