There is a law coming that most WordPress site owners have not heard of yet. The European Accessibility Act goes into full enforcement on June 28, 2025, and if your site serves customers in Europe, it matters regardless of where your business is based. I have been working on WordPress sites for over a decade. When I first dug into accessibility compliance, I expected it to be a checkbox exercise. What I found instead changed how I think about building for the web.

Why I Stopped Ignoring Accessibility (And Why You Should Too)

I want to be honest about something. For years, accessibility was the thing I added at the end of a project, mostly as a client checkbox, rarely as a genuine priority. I convinced myself that “real” accessibility work required a specialist and that my typical clients, running small-to-mid-size WordPress sites, did not have the budget or the audience for it to matter.

That changed when a client of mine received a formal legal notice. Their e-commerce site, built on WooCommerce, professionally designed, regularly updated, was flagged for accessibility barriers by a user who relied on a screen reader. The barriers were not exotic edge cases. Missing form labels. No keyboard navigation on the checkout flow. Images without descriptive alt text. Things that had been in the site since day one.

The legal path resolved without major consequence, but the episode forced a reckoning. Accessibility is not a feature you add later. It is infrastructure, and like most infrastructure, the cost of retrofitting is always higher than building right from the start.

That reckoning is now arriving at scale. The European Accessibility Act creates enforceable obligations for private sector websites and digital services, and 2026 is the year businesses are genuinely feeling the pressure. This guide is what I wish had existed when I started taking this seriously.

What the European Accessibility Act Actually Requires

The European Accessibility Act (EAA) is a directive, it sets minimum requirements that EU member states must implement into national law. The deadline for compliance was June 28, 2025. The EAA applies to a much broader range of businesses than previous regulations. It covers private sector companies providing products or services to consumers in the EU, including websites and mobile apps.

The technical standard the EAA references is EN 301 549, which maps to WCAG 2.1 Level AA. So for practical purposes, if your WordPress site meets WCAG 2.1 AA, you are in the right territory for EAA compliance.

Who Does It Apply To?

If your business has fewer than 10 employees AND annual turnover under €2 million, the EAA has a microenterprise exemption. For most businesses above that threshold, including many mid-size WordPress-powered businesses selling to European customers, compliance is expected.

This is not just a European business concern. If you are running an online store, SaaS product, or services business from the US, Australia, India, or anywhere else, and you accept customers from EU countries, the EAA applies to those transactions.

What Happens If You Are Not Compliant?

Each EU member state sets its own enforcement mechanisms and penalties. In practice, enforcement in the early years is expected to focus on larger organizations and repeat offenders. But the legal exposure for smaller businesses is real, particularly because accessibility lawsuits in the US have set a precedent for using accessibility claims as a business tactic by some legal firms. The EAA creates a parallel risk in Europe.

More practically: non-compliance will increasingly disqualify you from government procurement, enterprise vendor lists, and any partner programs that require accessibility attestation.

WCAG 2.1 AA: What It Means in Plain English

WCAG stands for Web Content Accessibility Guidelines. Version 2.1 Level AA is the current benchmark for legal compliance in most jurisdictions. The guidelines are organized around four principles, often called POUR.

  • Perceivable, Users can perceive all information and interface components. This means: alt text for images, captions for video, sufficient color contrast.
  • Operable, Users can operate the interface. This means: full keyboard navigation, no seizure-inducing animations, enough time to complete tasks.
  • Understandable, Users can understand the information and operation. This means: predictable navigation, clear error messages, language declared in markup.
  • Robust, Content can be interpreted reliably by assistive technologies. This means: valid HTML, proper ARIA landmark roles, compatible with screen readers.

There are 50 success criteria at Level AA. You do not need to memorize all of them. What you need is to understand the most common failure patterns on WordPress sites, and address those first.

The Most Common WCAG Failures on WordPress Sites

After auditing dozens of WordPress sites over the past two years, the same issues appear repeatedly. These are the failures most likely to affect real users and most likely to draw complaints or legal attention.

IssueWCAG CriterionReal-World Impact
Missing image alt text1.1.1 Non-text ContentScreen reader users hear “image” with no context
Insufficient color contrast1.4.3 Contrast (Minimum)Low-vision users cannot read content
No keyboard focus indicator2.4.7 Focus VisibleKeyboard users cannot tell where they are on the page
Form inputs without labels1.3.1 Info and RelationshipsScreen readers cannot identify form field purpose
Video without captions1.2.2 Captions (Prerecorded)Deaf users cannot access video content
Links with non-descriptive text2.4.4 Link Purpose“Click here” is meaningless out of context
Missing page language3.1.1 Language of PageScreen readers use wrong pronunciation rules
Popup modals that trap keyboard focus2.1.2 No Keyboard TrapKeyboard users cannot escape modal dialogs

I want to push back on something I hear often: “accessibility is a compliance cost.” That framing is wrong, and it leads to bad decisions.

There are approximately 1.3 billion people worldwide with some form of disability, according to the World Health Organization. In the EU alone, around 87 million people, about one in five, have a disability that affects how they use digital technology. These are not edge-case users. They are customers with purchasing power and high brand loyalty when a service works well for them.

Beyond disability-specific users, accessibility improvements benefit everyone. Captions help people watching video on mute, on a train, in a quiet office, or wherever audio is inconvenient. High contrast text is easier to read in sunlight. Clear error messages help users with cognitive challenges and also help everyone who fills out a form quickly and makes a typo.

When you fix accessibility, you fix usability. The two problems have remarkable overlap at the level of implementation. This is why the business case for accessibility is not charity, it is product quality.

SEO Benefits Are Real and Measurable

Google’s crawler is essentially a blind user navigating your site programmatically. It cannot see images. It follows link text. It reads heading structure to understand content hierarchy. The overlap between what makes a site accessible and what makes a site crawlable is not coincidental, both are about making information machine-readable.

Fixing alt text makes images indexable. Adding proper heading structure helps Google understand your content outline. Descriptive link text signals topic relevance beyond just the URL. A site that passes a WCAG audit will almost always perform better in search than a technically similar site that does not, all else being equal.

Page speed is a ranking factor, and many accessibility improvements (semantic HTML, reduced JavaScript dependency for core navigation, efficient DOM structure) also improve performance. The synergies are real.

What Your WordPress Site Actually Needs

Let me break this down into what actually needs to happen on a typical WordPress site. I am going to organize this into layers: theme, plugins, content, and process.

Layer 1: Your Theme Must Be the Foundation

The single highest-leverage decision you can make for accessibility is your theme choice. An inaccessible theme will require constant patching as new content is added. An accessible theme provides a correct baseline that content can build on.

What to look for in an accessible WordPress theme:

  • Skip navigation links, a link that jumps to main content, visible or hidden, for keyboard users who do not want to tab through the entire header on every page
  • Correct heading hierarchy, the theme should use one H1 per page (the post title), with H2 and H3 used for sections and subsections respectively
  • Focus styles, keyboard focus must be visible. Many themes remove focus outlines with CSS because they look “ugly”, this is a WCAG failure
  • ARIA landmark regions, header, navigation, main, and footer regions must be marked up correctly so screen reader users can jump between them
  • Color contrast in the default palette, text on background must meet at least 4.5:1 contrast ratio for normal text, 3:1 for large text

The WordPress theme directory now requires themes to meet accessibility standards for the “accessibility-ready” tag. Block themes built using Full Site Editing tend to have better baseline accessibility because they lean on semantic HTML5 more heavily than classic themes. If you are choosing WordPress as your platform for a new site in 2026, an FSE block theme with the accessibility-ready tag is the right starting point.

Layer 2: Your Plugins Must Not Break What the Theme Fixed

This is the most underappreciated problem in WordPress accessibility. You can start with a perfectly accessible theme and have it completely undermined by a plugin that injects a modal without focus management, adds a slider without keyboard controls, or outputs form fields without proper labels.

The plugins most likely to introduce accessibility issues are: page builders (especially older ones that generate divs instead of semantic HTML), contact form plugins, popup and overlay plugins, slider and carousel plugins, cookie consent plugins, and social sharing plugins. This does not mean avoid these categories, it means audit them specifically.

When evaluating a plugin for accessibility, run it through a screen reader. Tab through the interface with keyboard only. Check the generated HTML for ARIA attributes. Look for whether the plugin documentation even mentions accessibility, if it does not, that tells you something about the developer culture.

Layer 3: Content Practices Must Be Built Into Your Workflow

Accessibility tools and accessible themes help enormously with structural issues. But content accessibility, the daily work of writing and publishing, requires human judgment and consistent habits.

The most important content practices:

  • Write descriptive alt text for every meaningful image. Decorative images (spacers, visual dividers) should have empty alt attributes (alt=””) so screen readers skip them. Informative images need text that conveys the meaning of the image, not just what it depicts.
  • Use heading structure deliberately. Do not use headings for visual size, use them to represent document structure. H2 for major sections, H3 for subsections within those sections. Never skip heading levels for visual effect.
  • Write descriptive link text. “Click here” and “read more” are not acceptable when the destination is not clear from context. Use the destination or action as the anchor text.
  • Caption all videos. Auto-generated captions from YouTube or Vimeo are a starting point, but they need human review and correction, especially for technical terminology, proper nouns, and non-standard speech patterns.
  • Do not use color alone to convey meaning. “Required fields are marked in red” is not accessible. Use both color and a text indicator (like an asterisk) together.

Layer 4: An Accessibility Statement Is Not Optional

The EAA and related regulations require an accessibility statement published on your site, a page that discloses your current compliance status, known issues, and a contact method for users to report barriers. This is not just legal boilerplate. A genuine accessibility statement signals to users that you take this seriously and gives them a pathway when something does not work.

Your accessibility statement should include: the standard you are targeting (WCAG 2.1 AA), the date of your last audit, known accessibility barriers and your plans to address them, and contact details for reporting issues. Update it after every significant site change.

Practical Steps to Audit Your Site Today

Accessibility auditing does not require expensive specialists for an initial triage. You can identify most high-severity issues in an afternoon with free tools and structured testing. Here is the process I use for initial site assessments.

Step 1: Automated Scan With a Browser Extension

Install the WAVE accessibility evaluation tool (browser extension for Chrome and Firefox). Run it on your homepage, a blog post, a contact page, and your most important conversion page (pricing, product, checkout). WAVE will flag missing alt text, contrast failures, empty form labels, and missing page language declarations. It cannot catch everything, automated tools find roughly 30-40% of WCAG failures, but it identifies the low-hanging fruit fast.

Also run Google Lighthouse (built into Chrome DevTools) with the Accessibility category enabled. Lighthouse gives you a score and specific failed criteria with links to fix guidance.

Step 2: Keyboard Navigation Test

Put your mouse away. Navigate your entire site using only Tab, Shift+Tab, Enter, and Arrow keys. Can you reach every interactive element? Is the focus indicator always visible? Can you operate all forms, dropdown menus, and popups? Can you close any modal or overlay that appears? This test takes 20-30 minutes and will surface failures that no automated tool finds.

Step 3: Screen Reader Spot Check

If you are on macOS, VoiceOver is built in (Command+F5 to activate). On Windows, NVDA is free. Navigate your homepage and one of your most important content pages using the screen reader. Listen to how images are described. Navigate using the heading list (in VoiceOver, open the Web Rotor with Control+Option+U). Check that form labels are announced correctly. This is sobering the first time you do it, you will hear your site the way a significant portion of your users experience it.

Step 4: Color Contrast Check

Use the WebAIM Color Contrast Checker or the Colour Contrast Analyser desktop app to verify your text-to-background contrast ratios. Check your primary body text, links, placeholder text, and any text on colored backgrounds (button labels, banner text, callout boxes). Normal text needs 4.5:1. Large text (18pt+ or 14pt bold) needs 3:1. Focus indicators need 3:1.

Step 5: Document Your Findings

Create a simple spreadsheet with columns for: page tested, issue found, WCAG criterion, severity (blocker vs. moderate vs. minor), and fix status. This becomes the foundation of your accessibility statement and your remediation roadmap. It also protects you legally, demonstrating ongoing effort matters as much as achieving perfect compliance.

The Role of WordPress Accessibility Plugins

I want to be careful here because this is an area where marketing often outruns reality. There are two fundamentally different categories of what gets marketed as “accessibility plugins”, and understanding the difference protects you from wasting money and from false confidence about your compliance status.

Category 1: Overlay Tools (Approach With Caution)

These are plugins and SaaS products that add a JavaScript overlay to your site, usually an icon button that opens a panel of accessibility controls. They promise to make your site compliant without requiring any code changes. Some are offered at substantial cost, with claims of legal compliance guaranteed.

The accessibility community’s position on overlays is clear and well-documented: overlays cannot fix the underlying code issues that cause accessibility barriers. They can provide user-facing adjustments (font size, contrast mode, reading guides) that some users find helpful, but these are preference tools, not compliance solutions. The Web Accessibility Initiative at W3C and hundreds of accessibility professionals have signed statements explaining this.

More critically: several widely-deployed overlays have been shown to introduce new accessibility barriers, disrupt screen reader behavior, and actively interfere with assistive technologies. If you are using an overlay as your primary accessibility strategy, you may be paying for something that makes your site less accessible for the users you are trying to serve.

Overlays as supplementary user preference controls, fine. Overlays as a compliance strategy, not sufficient.

Category 2: Genuine Accessibility Tooling

The second category covers plugins that make it easier to implement accessibility correctly in your content workflow. These include plugins that add skip navigation links, improve focus management in navigation menus, help enforce correct heading structure in the editor, provide structured alt text workflows, and audit content during the editorial process.

These tools address root causes, the actual markup and content issues, rather than applying a surface patch over them. They make your development and content teams more capable, rather than replacing capability with a UI widget.

For a curated list of WordPress accessibility plugins that fall into this second category, covering menu accessibility, skip links, image alt text management, and more, I have covered specific tool recommendations and how to evaluate them in a separate post on the best WordPress accessibility plugins available today. The tools are only part of the story, which is why this article exists: the strategy and the understanding have to come first.

Building an Accessibility Culture on Your Team

The hardest part of accessibility is not the technical implementation. It is building the habits and team culture where accessibility is considered at every step, not tacked on at the end. Here is what has worked in my experience.

Make Accessibility Part of Your Definition of Done

If your development process includes code review, add accessibility to your review checklist. If you have a QA step before any deployment, include a keyboard navigation test and an automated scan. If you have content guidelines for writers, add alt text requirements and heading structure rules. Accessibility integrated into existing gates costs almost nothing extra, it is accessibility as a retrofit that costs the most.

Train the People Who Create Content, Not Just Developers

Your developers can build an impeccable accessible theme, and then your content team can undermine it every week by publishing images without alt text, using heading styles for visual effect, or embedding videos without captions. Accessibility training is not a technical topic, the content half of it is about writing habits and editorial judgment. A two-hour workshop on accessible content creation pays dividends for years.

Test With Real Users, Not Just Automated Tools

If you have the ability to include disabled users in usability testing, do it. Organizations like Fable and Access Works connect product teams with paid disabled testers. The insights from an hour of testing with a screen reader user who has been using assistive technology for fifteen years are qualitatively different from anything an automated tool can surface. For most small WordPress sites, this is not a realistic budget item, but for enterprise sites, it is irreplaceable.

Schedule Periodic Audits

Your site is not a static object. Every plugin update, theme update, new page, new form, and new embed is an opportunity to introduce a regression. Build a lightweight quarterly accessibility check into your site maintenance routine, run the automated scans, do a keyboard navigation pass on new pages, check that your accessibility statement is still current. This does not have to be comprehensive every time. Regular light-touch audits prevent the accumulation of issues into an overwhelming remediation project.

A Realistic Timeline for Getting Your WordPress Site Compliant

I want to give you a realistic sense of what accessibility work actually looks like, because I think the all-or-nothing framing paralyzes a lot of site owners. Nobody becomes fully WCAG 2.1 AA compliant in a weekend. But meaningful progress is absolutely achievable in stages.

Month 1: Audit and Triage

Run the automated scans and keyboard navigation test on your five most important pages. Document findings. Identify your highest-severity issues, the ones that completely block users from core functionality (checkout, contact forms, navigation). Assign these to your developer as a priority sprint. Publish a draft accessibility statement acknowledging your current status and commitment to improvement.

Month 2-3: Fix Critical Barriers

Address the blockers. This typically means: adding skip navigation, fixing keyboard traps in menus and modals, adding missing form labels, fixing the most severe contrast failures. If you are using a page builder that generates inaccessible output on your main content pages, this is also the phase to evaluate a migration path. Retest after each fix.

Month 4-6: Systematic Content Remediation

Work through your content backlog. All images need reviewed alt text. Videos need checked captions. Internal links need descriptive text. This is the high-volume, lower-skilled work, you can involve non-technical team members here with proper training. Use a plugin that surfaces missing alt text in your media library to prioritize this work.

Ongoing: Maintenance and Improvement

After the initial remediation, accessibility becomes a maintenance item rather than a project. New content follows your accessibility guidelines. New features go through an accessibility review before deployment. Quarterly automated scans catch regressions. If you work with a developer on a WordPress site maintenance retainer, add accessibility checks to the scope. Your accessibility statement is kept current. At this stage, you are running a genuinely accessible site, and the work to keep it that way is minimal compared to the initial investment.

The Founder Perspective: Why I Now Lead With Accessibility

I have built and launched many WordPress sites over the years. The shift I have made in how I approach accessibility is not primarily about legal risk, although that is now real and measurable. It is about the kind of builder I want to be.

When I started paying attention to accessibility, I started noticing the everyday experience of using the web with a disability. The frustration of a checkout form that cannot be navigated with a keyboard. The silence where image descriptions should be. The popup that cannot be closed without a mouse. These are not minor inconveniences for the people who encounter them. They are barriers that communicate, however unintentionally, that the site was not built with them in mind.

Building accessible WordPress sites is a craft commitment. It requires more care upfront and ongoing attention thereafter. But the sites that come out the other side are genuinely better, more usable, more performant, more future-proof, and serving a wider audience.

The European Accessibility Act is not the reason to care about accessibility. It is just the deadline that makes the business case undeniable. The real reason is that your site exists to serve people, and making sure it actually can is the baseline expectation of professional work on the web in 2026.

Quick Reference: WordPress Accessibility Checklist for Site Owners

Use this as a starting point for your next site review. These are not all 50 WCAG 2.1 AA criteria, they are the issues most commonly found on WordPress sites, ordered by severity.

  • All images have descriptive alt text (or empty alt=”” for decorative images)
  • All form inputs have associated label elements
  • Keyboard focus is always visible on interactive elements
  • No keyboard traps, all modals and overlays can be closed with keyboard
  • Color contrast meets 4.5:1 for normal text, 3:1 for large text
  • Page language is declared in the html lang attribute
  • Heading structure follows a logical hierarchy (H1 to H2 to H3)
  • Skip navigation link is present and functional
  • All videos have accurate captions
  • Link text is descriptive out of context (no “click here” or “read more” without context)
  • ARIA landmark regions are correctly marked (header, nav, main, footer)
  • Error messages are descriptive and associated with the relevant form field
  • Accessibility statement is published and kept current

Next Steps

If you are starting this process and want a concrete place to begin: run the WAVE browser extension on your homepage right now. It will take three minutes and will very likely surface several issues you were not aware of. Document what you find. Then work through the checklist above methodically.

If you are evaluating plugins to help with specific aspects of accessibility implementation, skip links, menu keyboard navigation, alt text workflow, accessibility auditing in the editor, the specific tool recommendations are in my separate guide to the best WordPress accessibility plugins available today. That piece focuses on what each category of plugin can and cannot do, so you can make informed choices rather than relying on marketing claims.

Accessibility on the web is a long game. The goal is not a passing score on an audit, it is building and maintaining sites that work for everyone. That work is never completely finished, but it is absolutely worth doing. In 2026, with the EAA in force and user expectations rising, there has never been a better time to start.

Talk to me about your site’s accessibility