WordPress Accessibility: A Practical Guide to WCAG Compliance

WordPress accessibility is one of those topics that gets treated as either a legal panic or a box to tick, and both attitudes produce bad websites. The truth is simpler: an accessible site is a well-engineered site. The same discipline that makes a page work for a screen reader user – semantic markup, real buttons, visible focus, sensible headings – also makes it faster, easier to maintain and better for SEO. And since June 2025 the legal side is no longer theoretical in Europe: the European Accessibility Act is enforceable, ADA lawsuits keep landing in the US, and the UK Equality Act has covered websites for years.

This guide is the practical version: why accessibility matters commercially and legally without the scaremongering, what WCAG actually asks for in plain language, the failures I find in almost every WordPress audit and how to fix each one, how I build accessibility into custom themes, what content editors need to do, an honest word about page builders and “accessibility overlay” widgets, a repeatable testing workflow, and a prioritised remediation plan with real costs. I build custom WordPress themes that score 100 on Lighthouse accessibility as a baseline – and I will also explain exactly what that score does and does not prove, because being honest about that is half the job.

Table of contents

• Why accessibility matters – users, SEO, conversions and the law
• WCAG in plain language: POUR, levels and WCAG 2.2
• The most common WordPress accessibility failures (and fixes)
• Theme-level engineering: where accessibility is really built
• Content editor habits that keep a site accessible
• Page builders, plugins and overlay widgets – honestly
• A repeatable testing workflow (and what automated tools miss)
• The accessibility statement page
• A prioritised remediation plan for an existing site
• What it costs and how long it takes
• Frequently asked questions

Why accessibility matters – users, SEO, conversions and the law

The audience is bigger than you think

Roughly 15-20% of people live with some form of disability – visual, auditory, motor or cognitive – and that is before you count temporary and situational impairments: a broken wrist, a bright sun on a phone screen, a noisy train, ageing eyesight. Nobody browses your site the way you do on a 27-inch monitor with a mouse. When a client tells me accessibility is “a niche concern”, I ask them whether they would accept a shop where one in six customers cannot open the door.

The SEO and conversion overlap

Most accessibility work is also SEO work. Descriptive headings in a logical order, alt text on images, descriptive link text, fast keyboard-navigable pages, captions and transcripts – search engines reward every one of these, because a crawler experiences your site much like a screen reader does: no visuals, only structure. Accessible forms with clear labels and useful error messages also convert measurably better for everyone, not just users with disabilities. On one client’s lead form, simply adding visible labels, larger touch targets and inline error messages lifted completions by double digits – accessibility fixes, sold as conversion work. The performance overlap is real too: lean semantic markup is exactly what makes sites fast, which is why my speed optimisation guide and this one keep recommending the same underlying discipline.

The legal reality, without the panic

• European Accessibility Act (EAA): enforceable since 28 June 2025. It applies to businesses selling products and services to EU consumers – e-commerce is explicitly covered – with an exemption for micro-enterprises (under 10 staff and under EUR 2 million turnover) on the services side. The practical benchmark used across the EU is EN 301 549, which for websites means WCAG 2.1 level AA. Enforcement is by national market-surveillance bodies, and it starts with complaints, not raids.
• United States: the ADA has been applied to websites through thousands of lawsuits and demand letters per year, most citing WCAG failures on e-commerce sites. Small businesses get these letters too; the settlements are usually more expensive than fixing the site would have been.
• United Kingdom: the Equality Act 2010 requires service providers to make reasonable adjustments, and websites count. Cases rarely reach court, but the duty exists and complaints are cheap to make.

My honest advice: do not build your accessibility case on fear of lawsuits, because fear produces minimum-effort compliance theatre. Build it on the fact that WCAG AA is simply what a professionally built website looks like in 2026 – and the legal exposure quietly disappears as a side effect.

WCAG in plain language: POUR, levels and WCAG 2.2

The four POUR principles

The Web Content Accessibility Guidelines look intimidating but rest on four ideas anyone can hold in their head:

• Perceivable – people must be able to perceive the content: text alternatives for images, captions for video, sufficient colour contrast, content that does not rely on colour alone.
• Operable – people must be able to operate the interface: everything works with a keyboard, nothing traps focus, users get enough time, nothing flashes dangerously, navigation is consistent.
• Understandable – content and controls behave predictably: readable language, labelled inputs, error messages that say what went wrong and how to fix it.
• Robust – the markup is clean enough that assistive technologies can interpret it: valid HTML, correct roles and names on custom widgets.

Levels A, AA and AAA – and why AA is the target

Every WCAG success criterion sits at one of three levels. Level A is the bare minimum – failing it means some users are simply locked out. Level AA is the practical standard: it adds things like 4.5:1 contrast for body text, visible focus indicators and consistent navigation, and it is the level referenced by the EAA, by US legal settlements and by public-sector regulations worldwide. Level AAA is aspirational – 7:1 contrast, sign-language interpretation for video – and even the W3C says entire sites should not be expected to meet it. Target AA. Say so in writing. Anything else is either negligence or gold-plating.

WCAG 2.2 in brief

WCAG 2.2, published in late 2023, adds nine criteria to 2.1. The ones that matter most for a typical WordPress site: focus indicators must not be fully hidden behind sticky headers or cookie banners (Focus Not Obscured), interactive targets need a minimum size of roughly 24 by 24 pixels (Target Size Minimum), drag-based interactions need a non-drag alternative, and users should not have to re-enter information a form already collected. If your site meets 2.1 AA and was built with care, 2.2 is usually a small delta – I fold it in by default because there is no reason not to.

The most common WordPress accessibility failures (and fixes)

These are not exotic edge cases. They are the same ten findings, in roughly the same order, in almost every WordPress audit I run – and every one has a straightforward fix.

Two habits prevent most of this list from ever appearing. First, use native HTML elements: a real <button> is focusable, keyboard-operable and announced correctly for free, while a clickable <div> needs role, tabindex and key handlers bolted on and usually gets none of them. Second, never remove behaviour you cannot replace – the developer who wrote outline: none in 2014 because the designer disliked the blue ring is responsible for more failed audits than any other single line of CSS.

Theme-level engineering: where accessibility is really built

Content editors can only be as accessible as the theme allows. This is where I spend most of my accessibility effort when building custom WordPress themes, because a mistake here is repeated on every page of the site.

Semantic landmarks and skip links

Every template gets proper landmarks – <header>, <nav> with an aria-label, <main>, <footer> – so screen reader users can jump between regions instead of wading through them. The first focusable element on every page is a skip link that becomes visible on focus:

<a class="skip-link" href="#main">Skip to content</a>

.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 1rem;
  top: 1rem;
}

Ten minutes of work, and every keyboard user is spared tabbing through forty navigation links on every page load.

Focus management in mobile drawers and modals

The mobile menu drawer is the most common keyboard trap in WordPress themes. Done properly: the hamburger is a real <button> with aria-expanded, opening the drawer moves focus into it, Tab cycles within it while open, Escape closes it, and closing returns focus to the button that opened it. The modern shortcut for the hard part is the inert attribute – while the drawer is open, set inert on the page content behind it and the browser removes that content from the tab order and the accessibility tree in one line. The same pattern applies to modals, off-canvas filters and cookie banners; I keep one tested drawer component and reuse it across projects rather than reinventing the trap each time.

Reduced motion, touch targets and contrast tokens

Animations sit behind a prefers-reduced-motion media query, so users who get motion-sick from parallax and auto-scrolling get a calm site without asking. Touch targets follow WCAG 2.2: nothing interactive smaller than 24px, and navigation, form controls and buttons at 44px on mobile. Colour lives in design tokens checked for contrast once, at the design-system stage – which means no page built later can accidentally ship a 2.8:1 pale-grey paragraph, because that grey does not exist in the palette.

What a Lighthouse 100 does and does not prove

My themes score 100 on Lighthouse accessibility, and I quote that number to clients – with an honest footnote. Lighthouse (which runs axe-core under the hood) checks what a machine can check: contrast of rendered text, presence of alt attributes and labels, valid ARIA, heading order, language attributes. It cannot tell whether the alt text is meaningful, whether focus moves sensibly through a modal, whether the link text makes sense out of context, or whether a screen reader user can actually complete your checkout. Automated tools catch roughly 30-40% of WCAG failures. A Lighthouse 100 is a necessary floor and a useful regression alarm; it is not a compliance certificate, and anyone who sells it as one is selling you the easy 40%.

Content editor habits that keep a site accessible

I can hand over a perfectly accessible theme and watch it degrade within six months if nobody briefs the editors. These five habits, written into a one-page guide at handover, keep the score honest:

• Headings are structure, not styling. One H1 (the post title – the theme handles it), H2 for major sections, H3 nested inside them. If you are choosing a heading because of its size, the theme’s typography needs fixing instead – tell the developer.
• Alt text describes purpose, not pixels. “Founder Anna Weber speaking at the 2025 trade fair” beats “woman on stage”. If the image is decorative – a divider, a background texture – leave alt empty so screen readers skip it, which is a valid choice, not laziness.
• Link text says where the link goes. Screen reader users pull up a list of all links on a page; a list of eleven “read more”s is useless. It is also exactly what search engines want fixed.
• Tables get header rows. Use the table block’s header option so each cell is announced with its column meaning; never use tables for visual layout.
• Video gets captions. YouTube’s auto-captions, corrected by hand, take fifteen minutes and serve deaf users, non-native speakers and everyone watching muted in an office – which studies consistently suggest is most viewers.

The Gutenberg editor helps more than people expect: it warns about skipped heading levels and low-contrast colour choices in many themes, and the image block asks for alt text every time. The tooling is there; the habit is the missing piece.

Page builders, plugins and overlay widgets – honestly

Page builders: div soup with good intentions

Page builders have improved – Elementor and others have shipped real accessibility work in recent versions – but the structural problem remains: builders generate deeply nested generic markup, and every fancy widget (accordions, tab sets, carousels, mega menus) is a custom JavaScript component that must reimplement keyboard behaviour and ARIA correctly. Some do; many do not; and the site owner cannot fix a widget’s internals. In audits of builder sites I routinely find hover-only dropdowns, focus that disappears into closed accordions, and sliders that trap the keyboard. A lean custom theme built on native HTML starts accessible by default, which is one more entry in the ledger I laid out in custom development vs page builders. If you are on a builder and staying there, the practical advice is: use fewer, simpler widgets, test every interactive one with a keyboard, and prefer the native blocks over third-party widget packs.

Accessibility overlay widgets: the honest warning

You have seen the little floating icon that promises “one line of JavaScript makes your site ADA and WCAG compliant”. It does not, and I will not install one for a client. Overlays bolt a settings panel (contrast toggles, font resizing, screen-reader mode) on top of broken markup – but they cannot add meaningful alt text they cannot understand, cannot repair keyboard traps in your menu, and cannot fix a form with no labels. Screen reader users overwhelmingly report that overlays interfere with the assistive technology they already have configured. The legal record is the sharpest argument: hundreds of US lawsuits each year are filed against sites that have an overlay installed, and in 2025 the US FTC ordered one major overlay vendor to pay USD 1 million over misleading compliance claims. An overlay is not a compliance shortcut; it is a public signal that you know about accessibility and chose a sticker instead. Spend the same monthly fee on actually fixing the top failures – it is cheaper within a year.

Plugins that genuinely help

Some tooling is worth installing: an audit companion that surfaces issues in the editor as content is written, a media-library nudge that flags images missing alt text, and proper caption support for video. Treat these as seatbelts for editors, not as the car. And every plugin you add is markup you do not control, so the plugin-diet advice from my custom WordPress development work applies doubly here: fewer, better, tested.

A repeatable testing workflow (and what automated tools miss)

Accessibility testing is not a one-off audit; it is a short checklist run at three moments – before launch, after any template change, and quarterly on content. Mine looks like this.

Step 1: automated scan (30 minutes)

Run Lighthouse in Chrome DevTools, the axe DevTools extension and the WAVE extension on the five most important templates: home, a content page, the blog archive, a post, and the contact or checkout flow. These three tools overlap but each catches things the others miss. Fix everything they report – this is the easy 30-40%, and there is no excuse for shipping it broken. Automated scans are also your regression alarm: a Lighthouse accessibility score in your deployment checklist catches the plugin update that silently broke your labels.

Step 2: keyboard-only pass (30-45 minutes)

Unplug the mouse. Tab through each key template and ask: can I see where focus is at every moment? Can I reach and operate every control – menu, search, forms, modals, sliders? Does the skip link work? Can I escape everything I can open? Does focus ever vanish or jump somewhere surprising? This single exercise finds more real-world blockers than any tool, and anyone on the team can run it.

Step 3: screen reader basics (45-60 minutes)

You do not need to be an expert user. On Windows, install NVDA (free); on a Mac or iPhone, VoiceOver is built in. Learn five commands: read next item, jump by heading, list links, list landmarks, enter a form. Then complete your site’s most important journey – find a product, fill the contact form, read a post – with the screen curtain on or your eyes off the monitor. The first time is humbling and worth more than any report I could write.

Step 4: zoom, contrast and motion checks (15 minutes)

Zoom the browser to 200% – nothing should overlap, vanish or require horizontal scrolling at 320px-equivalent width. Check the site in your operating system’s high-contrast or inverted mode. Toggle prefers-reduced-motion and confirm the parallax and auto-carousels calm down. Check text over images against the busiest part of the image, not the prettiest.

Total: roughly half a day for a typical site, per full pass. Document what you tested and when – that record is exactly what an accessibility statement and, if it ever matters, a legal defence are built from.

The accessibility statement page

An accessibility statement is a plain page, linked from the footer, that says four things: the standard you target (WCAG 2.1 or 2.2 level AA), the current status honestly (“partially conformant – the following known issues are being fixed”), how a user can report a barrier (an email address that a human answers), and when the statement was last reviewed. Under the EAA an accessibility statement is expected for covered services, and public-sector rules across the EU and UK already require one – but its real value is practical: a user who hits a barrier and finds a working contact route becomes a bug report, while the same user finding nothing becomes a complaint to a regulator or a law firm. Write it honestly, date it, and update it when you fix things. Thirty minutes, once a quarter.

A prioritised remediation plan for an existing site

Nobody rebuilds a live site for accessibility on day one, and nobody should. The sequence that works:

1. Audit first (half a day to a day). Automated scan plus keyboard pass on the key templates, findings sorted into two buckets: quick wins and structural.
2. Quick wins (days 1-5). Fix contrast in the stylesheet, restore focus styles, add the skip link, label the icon buttons, add form labels and error text, rewrite “click here” links, fix heading order in templates, stop the autoplay. Most of this is CSS and template edits; on a typical site it is one to three days of work and removes the majority of user-facing barriers and legal exposure.
3. Content pass (week 2, can run in parallel). Alt text on the images that matter (start with the 50 most-visited pages, not all 5,000), captions on key videos, link-text cleanup. This is editor work, guided by a short brief.
4. Structural fixes (weeks 3-6). Rebuild the mobile menu and any modals with proper focus management, replace or fix inaccessible sliders and accordions, repair forms with broken error handling. On a page-builder site this is where you sometimes hit widgets that cannot be fixed and decide between replacing the widget and replacing the builder.
5. Lock it in. Add the automated scan to your update routine, brief the editors, publish the statement, and re-test quarterly – the same rhythm as the rest of the maintenance checklist. Accessibility regressions arrive through plugin updates and new content, not through the code you already fixed, which is why my maintenance plans include the scan by default.

What it costs and how long it takes

Honest numbers from my own projects, at EUR 15 per hour or fixed prices quoted within 24 hours. An accessibility audit of a typical business site – automated plus manual, with a prioritised findings list – is 4-8 hours. The quick-wins round on an existing custom theme is usually 1-3 days. Structural work (menus, modals, forms, sliders) runs 2-5 days depending on how much JavaScript needs replacing. A full remediation of a messy page-builder site can reach 2-3 weeks, at which point I will tell you plainly if a rebuild is the cheaper path – sometimes it is, often it is not. Building accessibility into a new custom theme from the start costs close to nothing extra: perhaps 5% of the build time, because it is not a feature bolted on but the absence of mistakes. That asymmetry is the whole argument for doing it early. And for planning: the deadline that matters was June 2025, so if the EAA applies to you, the question is no longer “when should we start” but “what do we fix this month”.

Need help making your WordPress site accessible?

I audit, fix and build accessible WordPress sites for small businesses and agencies – custom theme development with WCAG 2.2 AA and a Lighthouse 100 as the baseline, remediation of existing sites, and ongoing testing inside maintenance plans. Have a look at my portfolio, then send me a message with your site’s URL – I reply within 24 hours, usually with the first three things I would fix.

Frequently asked questions

What is WordPress accessibility?

WordPress accessibility means building and running a WordPress site so that people with visual, auditory, motor or cognitive disabilities can use it – in practice, meeting the WCAG guidelines at level AA through semantic markup, keyboard support, sufficient contrast, labelled forms and meaningful text alternatives.

Is WCAG compliance legally required for my website?

Increasingly, yes: the European Accessibility Act has been enforceable since June 2025 for businesses serving EU consumers (micro-enterprises are partly exempt), US courts apply the ADA to websites, and the UK Equality Act requires reasonable adjustments. WCAG 2.1 AA is the benchmark in all three.

Does a Lighthouse accessibility score of 100 mean my site is compliant?

No. Automated tools catch roughly 30-40% of WCAG failures; a 100 is a necessary floor, not a certificate. Keyboard testing and basic screen reader testing are needed to cover the rest.

Do accessibility overlay widgets make a site WCAG compliant?

No – overlays cannot fix broken markup, keyboard traps or missing labels, they often interfere with users’ own assistive technology, and sites running overlays are regularly sued anyway. Fix the underlying issues instead.

How much does WordPress accessibility remediation cost?

At my rate of EUR 15 per hour: an audit is 4-8 hours, quick wins 1-3 days, structural fixes 2-5 days, and a messy page-builder site up to 2-3 weeks. Building it into a new theme from the start adds almost nothing.

Which level of WCAG should I aim for – A, AA or AAA?

AA. It is the level named by the EAA, by US settlements and by public-sector rules, and it is achievable on a normal budget. AAA is aspirational and not expected for entire sites.

How do I test my WordPress site for accessibility?

Run Lighthouse, axe and WAVE on your key templates, then do a keyboard-only pass, a basic NVDA or VoiceOver session on your most important user journey, and a 200% zoom and reduced-motion check. Repeat after template changes and quarterly.