WordPress accessibility and the UK legal position

Accessibility is the area of WordPress work where the legal floor moves faster than the code. The Equality Act 2010 has applied to UK websites for over a decade. The Public Sector Bodies Accessibility Regulations have applied to public sector sites since 2018. The European Accessibility Act started biting on 28 June 2025. Most WordPress sites I look at would not stand up to a careful audit against any of those.

This is a developer read of where things stand in 2026, written for owners and marketing leads who run WordPress sites in the UK. It is not legal advice. For edge cases, particularly around the European Accessibility Act and whether your business is in scope, talk to a solicitor.

The four legal frameworks that matter

There is no single UK web accessibility law. There are four overlapping frameworks. Whether they apply to you depends on what you do, who you serve and where your customers are.

Equality Act 2010

The Equality Act covers everyone providing a service to the public in the UK, including a private business with a website. Section 20 requires reasonable adjustments so that disabled users are not placed at a substantial disadvantage. There is no specific technical standard named in the act. In practice, a court asks whether the service was usable and whether reasonable steps were taken.

Enforcement happens through individual claims in the County Court, sometimes supported by the Equality and Human Rights Commission. Awards tend to be modest. A blind user who could not access a public sector recruitment site received a settlement of £3,000 in a 2023 case. The amount is the wrong thing to focus on. The harder cost is investigation time, legal fees and reputational exposure. The right comparison is the cost of building accessibility in versus the cost of arguing it out later.

Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018

If you are a public body or you build for one, this is the binding floor. WCAG 2.1 AA, a public accessibility statement, an annual review and a clear contact route for complaints. Enforcement sits with the Cabinet Office and the Equality and Human Rights Commission. Monitoring includes both automated and manual sampling and the published results name organisations that fail.

In private sector work this regulation is the model I follow even when it does not strictly apply, because the accessibility statement is good practice and the WCAG 2.1 AA target is a sensible technical baseline.

European Accessibility Act 2025

The European Accessibility Act came into force on 28 June 2025 across all EU member states. The act applies to a defined list of products and services placed on the EU market, including e-commerce, banking, transport ticketing, e-books and consumer-facing telecoms.

For UK businesses, the question is whether you serve EU consumers. The act has extraterritorial reach. A UK e-commerce site that ships to the EU is in scope. A UK SaaS product that lists EU users on its terms is in scope. A UK consultancy with no EU consumer offering is not. There is a small business exemption for organisations with fewer than ten employees and turnover under two million euros, but only for the service side, not for products.

The technical baseline the act points to is EN 301 549, which in practice aligns with WCAG 2.1 AA and is moving toward WCAG 2.2 AA over time. Enforcement runs through national regulators in each EU member state. Early enforcement in 2026 has focused on clear failures and complaints. The transitional period for services using inaccessible products that were already in use before June 2025 runs until 2030.

The practical effect: many UK WordPress sites that ship a product or service into the EU now have a second regulator on top of the UK position. If you sell into the EU, treat WCAG 2.2 AA as the working target.

Other frameworks worth a sentence

Procurement frameworks for public sector contracts often write accessibility requirements into the contract terms. If you build for the public sector through G-Cloud or any framework, you are bound by what you signed in addition to the regulations above. Financial Conduct Authority Consumer Duty also indirectly raises the floor for regulated firms, because services need to be usable by vulnerable customers.

There is one more thing worth flagging about the EAA. UK regulators have signalled that they will mirror the broad direction of the EAA for UK businesses over the next few years, even where current UK law does not yet require it. So if you are running a planning horizon of three to five years, treat the EAA-aligned standard as the floor you are aiming at regardless of where your customers live.

WCAG 2.2 AA: the working standard in 2026

WCAG 2.2 became a W3C Recommendation in October 2023 and has been adopted as ISO/IEC 40500:2025. WCAG 3.0 is still in working draft and unlikely to become a recommendation before 2028. For any WordPress site you are building or maintaining in 2026, treat WCAG 2.2 AA as the practical target. AAA is harder to justify outside specific contexts and there is no mainstream legal framework that requires it.

The new criteria in 2.2 over 2.1 are mostly common-sense improvements. Focus appearance, dragging movements, target size for pointer inputs and consistent help. None of them are hard to meet on a WordPress site if you start during the build rather than retrofitting later.

A point on WCAG 2.2 that is worth getting right. The success criteria are written as testable outcomes, not implementation rules. Two builds can both pass the same criterion by very different means. That is by design and it is why audits cannot be fully automated. Automated scanners do well on contrast and missing alt attributes. They miss the harder criteria around focus order, error handling and meaningful sequence almost entirely.

Where WordPress sites usually fail

The same patterns come up on almost every audit I do.

Form fields without proper labels. WordPress contact form plugins are particularly bad at this. The visible label is fine, the screen reader label is wrong, the error messages are not announced.

Colour contrast that fails on body text. Theme designers love grey on white. Body text needs a contrast ratio of at least 4.5:1 against the background. A lot of themes ship at 3:1 or worse out of the box.

Keyboard traps in modal popups, off-canvas menus and image lightboxes. If you can tab into something with a keyboard and not tab out, that is a hard fail.

Missing alternative text on images. Either none at all, or auto-generated alt that says "image" or repeats the filename.

Heading hierarchy out of order. h1 then h3 then h2. Often caused by themes that style headings visually but ignore the semantic level.

PDFs that are unreadable to screen readers. PDFs come under the same accessibility duties as the HTML pages around them. A scanned image PDF is inaccessible by default.

Video without captions or transcripts. If you embed video on a site that falls under the European Accessibility Act, captions are required, not optional.

Cookie banners deserve a separate mention. The standard WordPress cookie banner plugin is often the worst-performing component on the page from an accessibility angle. Modal overlays that trap keyboard focus, decline buttons hidden behind colour contrast failures, controls that cannot be operated with a screen reader. The banner is also usually the first thing a visitor encounters, which means an inaccessible banner blocks the whole site. Pick a banner that has been built with WCAG 2.2 in mind, then test it.

WooCommerce checkout flows are the other recurring weak spot. The default Woo checkout has improved over the years but custom themes and bolt-on plugins still introduce regressions. Address autocomplete that traps focus. Coupon code fields with no accessible name. Error states announced visually but not to assistive technology. If you sell anything online from the UK into the EU, the checkout is where the European Accessibility Act bites first.

Why overlay plugins do not create legal cover

There is a category of WordPress plugin and SaaS tool that promises to make your site accessible by adding an overlay widget. UserWay, accessiBe and EqualWeb are the names you have probably seen. The pitch is that you drop in a script, an accessibility menu appears in the corner of every page and your compliance problem disappears.

It does not work this way and it has not worked this way for several years.

The FTC announced a proposed settlement with accessiBe in January 2025 and finalised the order in April 2025, requiring the company to pay one million dollars over deceptive marketing about WCAG compliance. A magistrate report in February 2026 recommended that a small business suing UserWay over its overlay product can continue its case under consumer fraud claims. Hundreds of US businesses using overlay products have faced accessibility lawsuits in recent years. The pattern is clear. An overlay can make a site harder to use for some assistive technology users, it does not fix the underlying HTML, and it does not change the legal position of the site owner.

In the UK, no overlay product has been tested through the courts to anything like the same depth. But the legal reasoning would be similar. The Equality Act looks at whether reasonable adjustments were made, not whether you bought a product. If the underlying site is inaccessible and the overlay does not make it accessible, the duty is not discharged.

There is a more practical point. The disability community largely opposes overlay tools because they often interfere with the user’s own assistive technology setup. A blind user with NVDA configured for their workflow does not want a third-party script trying to take over the page. If your users are telling you the overlay makes things worse, that is information about whether you are meeting the underlying duty.

What to actually do on a WordPress site

The practical work splits into three phases.

Audit first. Run a free automated scan as a sanity check, then commission a manual audit if accessibility is genuinely a risk for your business. Automated tools catch perhaps a third of issues. The rest need a human, ideally a tester who uses a screen reader as their primary tool.

Fix at the source. Address the issues in the theme, in the plugins and in the content. Choose a theme that has accessibility credentials or has been actively maintained against WCAG 2.2. Use form plugins that produce accessible markup. Train your content editors on alt text, heading order and link text. Replace plugins that produce inaccessible widgets with ones that do not.

Maintain. Accessibility is not a project that ends. New content goes up every week, plugins update, themes get tweaked. Build a quarterly review into your maintenance routine. Publish an accessibility statement that names the standard you are working to, the known gaps and how someone can report a problem. This statement is required for public sector bodies under the 2018 regulations. For private sector sites it is a strong signal that the duty is being taken seriously.

Cost and time, honestly

A typical small business WordPress site can usually be brought to WCAG 2.2 AA in two to five working days if the theme is sound. A site with a custom theme, a complex form setup and a content library full of PDFs and video can run two to four weeks. E-commerce sites with custom checkout flows take longer because the checkout is where most enforcement attention sits.

None of this is more expensive than the cost of dealing with a complaint after the fact. It is much less expensive than an EU regulator opening a file on you.

Where to start

If you are not sure whether your WordPress site meets the standard you actually need to meet, the first move is an honest audit. I do this as a fixed-price piece of work, with a written report and a prioritised list of fixes. See WordPress services for the development side, or support and maintenance if you want accessibility folded into a quarterly review. For anything else, get in touch and I will give you a straight read on what your site needs.