Website Accessibility Explained: WCAG and Practical WordPress Fixes

WCAG 2.2 Level AA is the accessibility standard most laws and contracts point to, and a WordPress site can meet it, but usually not out of the box. The theme, the page builder, plugins and the content your team adds all affect the result, and the common failures are fixable: low contrast, headings chosen for looks, missing image descriptions, unlabelled forms, and menus or pop-ups that do not work with a keyboard. Overlay widgets that promise instant compliance do not fix these problems; changes to the site itself do.

This article is the practical, WordPress-focused companion to my piece on website accessibility for business, which covers the business case and Indian law. Here the focus is what WCAG asks for in plain words, which laws refer to it, what usually goes wrong on WordPress sites, and how to test. It is general information, not legal advice.

#WCAG 2.2 AA in plain words

WCAG, the Web Content Accessibility Guidelines from the W3C, sets testable rules grouped under four principles: content must be perceivable, operable, understandable and robust (works with assistive technology such as screen readers). Each rule, called a success criterion, has a level: A, AA or AAA. "Meeting AA" means meeting every A and AA criterion.

These are the AA requirements that affect WordPress sites most often:

The W3C summary of what is new in WCAG 2.2 (opens in a new tab) lists the 9 new criteria and notes that the old 4.1.1 Parsing criterion was removed. If a contract says "WCAG 2.1 AA", a site that meets 2.2 AA meets it too, apart from that removed criterion.

#Which laws point to WCAG

Laws rarely copy WCAG word for word, but most accessibility laws and public-sector rules use it, or a standard built on it, as the measure. A high-level view, as of November 2026:

• European Union. The European Accessibility Act (opens in a new tab) (Directive 2019/882) covers services provided to consumers from 28 June 2025, and e-commerce services are listed among them. Microenterprises providing services, defined as fewer than 10 staff and annual turnover or balance sheet of no more than EUR 2 million, are exempt from the service requirements. If you sell online to EU consumers from outside the EU, check with a lawyer whether it reaches you.
• United States. The Department of Justice's guidance on web accessibility (opens in a new tab) says the ADA's requirements apply to goods and services that businesses open to the public offer on the web, and points to WCAG as helpful technical guidance.
• India. The Rights of Persons with Disabilities Act, 2016 and the government website guidelines are covered in website accessibility for business.

Whether a law applies to your business depends on where you sell, your size and your sector. Ask a lawyer before relying on any summary, including this one. Building to WCAG 2.2 AA is the practical target in almost every case.

#Where WordPress sites usually fail

WordPress itself is a reasonable base. Its accessibility coding standard (opens in a new tab) states that new and updated core code is expected to conform to WCAG 2.2 at Level AA. Most problems come from what sits on top of core.

#Themes

The "accessibility-ready" tag on WordPress.org themes is a good sign, but the theme review handbook (opens in a new tab) is clear that it does not mean the theme meets WCAG AA; it means the theme reaches the review team's minimum standards. Premium themes vary widely. Common theme faults are pale grey body text, focus outlines removed in the stylesheet, and mobile menus that open only on tap, not with a keyboard.

#Page builders

Page builders such as Elementor, Avada and Divi make it easy to build pages that look right and are structured wrong:

• Headings picked by size. An editor chooses H4 because it looks right, so the page jumps from H1 to H4, or uses headings for decorative text. Screen reader users navigate by headings, so the outline becomes useless.
• Icon-only buttons and links. A phone, WhatsApp or social icon with no text label is announced as just "link" or "button".
• Sliders, carousels and tabs that move on their own, cannot be paused, or cannot be reached with the keyboard.
• Pop-ups that do not move keyboard focus into the pop-up, cannot be closed with the Escape key, or trap the user behind them.
• Text placed over images with no overlay, so contrast changes with the photo.

My comparison of Elementor, Gutenberg and Avada covers how each builder affects the code a site produces.

#Forms

Forms are where accessibility failures cost leads directly. Typical problems are fields that use placeholder text instead of a visible label, required fields marked only with colour, error messages that appear only as a red border, and CAPTCHA puzzles with no alternative. Whatever form plugin you use, check that each field has a real label and that errors are announced in text.

#Content

Your team's daily edits matter as much as the code. Missing or useless alt text ("image1.jpg"), links that say only "click here", PDFs that are scanned images, and videos without captions all fail WCAG even on a perfect theme.

#How to test a WordPress site

Testing combines free automated tools with manual checks. The W3C's guidance on selecting evaluation tools (opens in a new tab) is blunt: tools cannot check all accessibility aspects automatically, and human judgement is required.

1. Automated scan. Run WAVE from WebAIM, the axe DevTools browser extension, or the accessibility audit in Chrome's Lighthouse on one page of each template: home, service, blog post, contact form, product and checkout. These catch contrast, missing labels, empty links and missing alt text in bulk.
2. Keyboard walk-through. Put the mouse away. Press Tab through the page and check you can always see where you are, open the menu, use every form, close pop-ups and complete the main journey.
3. Screen reader check. Use NVDA (free on Windows) or VoiceOver (built into Mac and iPhone) on the same journey. Listen for unlabelled buttons, confusing link text and headings out of order.
4. Zoom and mobile. Zoom the browser to 200% and use a phone with large text. Nothing should be cut off or overlap, and tap targets should be easy to hit.
5. Content review. Check alt text, link wording, heading order, captions and PDFs.

#Why overlay widgets are not a fix

Overlay widgets add a floating accessibility button and claim to fix the site automatically with a script. They do not change your theme, your forms or your content, so the underlying failures remain, and screen reader users often already have their own settings that the overlay can conflict with.

Regulators have taken note. In 2025 the US Federal Trade Commission finalised an order requiring accessiBe to pay USD 1 million (opens in a new tab) and barring it from claiming its automated product can make any website WCAG compliant without evidence. If a vendor promises compliance by adding one line of code, treat it as a warning sign.

Money spent on an overlay subscription is usually better spent fixing templates once.

#Fixing it: what to do first

Fix templates and components before individual pages, because one fix then applies everywhere.

1. Colours. Adjust text and button colours in the theme or global builder settings to meet 4.5:1.
2. Focus styles. Restore a clear visible focus outline, and make sure sticky headers and cookie bars do not cover it.
3. Header and menu. Make the main menu and mobile menu fully keyboard usable, and add a "skip to content" link.
4. Forms. Add visible labels, text error messages and an accessible spam check.
5. Headings and buttons. Correct heading levels in templates and give icon buttons text labels.
6. Content habits. Train editors on alt text, heading order and link wording, and add accessibility checks to your website maintenance checklist.

If the theme or builder setup produces inaccessible markup everywhere, a rebuild on a cleaner base may cost less than patching. My article on custom vs premium WordPress themes covers that decision.

#When to get help

Your team can handle alt text, headings, link wording and captions. Get a developer for theme and builder fixes, forms, menus, pop-ups and keyboard behaviour, and get a formal audit when a tender, client contract or EU sales require you to state a conformance level. My website accessibility audit service combines automated and manual testing into a prioritised fix list, and WordPress development covers the fixes.