Accessibility Law in the UK
Date: 2026-08-17
The Equality Act 2010 requires reasonable adjustments for disabled people, and it applies to websites as service providers. There is no accessibility-specific web statute for private companies — the obligation comes from anti-discrimination law, which is broader and vaguer than a technical standard.
The primary obligation for a UK private-sector website comes from the Equality Act 2010, which requires service providers to make reasonable adjustments so disabled people are not placed at a substantial disadvantage.
It does not name WCAG. It creates a duty; WCAG is the practical means of demonstrating you’ve discharged it — WCAG.
The structure
EQUALITY ACT 2010
applies to service providers,
including online
→ anticipatory duty: you must
anticipate need, not wait to be
asked
→ "reasonable" depends on size,
resources, and cost of the
adjustment
PUBLIC SECTOR
additional, specific regulations
requiring a stated standard and a
published accessibility statement
→ does not apply to private retail
EU ACCESSIBILITY ACT
applies to businesses selling into
the EU, including ecommerce
→ relevant if you sell to EU
customers, regardless of where
you are
[CHECK: your specific obligations — whether you sell into the EU, whether any public-sector contracts apply, and the current commencement and scope of the European Accessibility Act as it affects UK sellers. Take advice rather than relying on a summary.]
”Anticipatory” is the word that matters
The duty is anticipatory. You are expected to have considered disabled users’ needs in advance, not to respond once someone complains.
Practical consequence: “no one has raised it” is not a defence. Most disabled users who encounter a barrier leave rather than complain, which means absence of complaints is evidence of nothing.
What “reasonable” means
Undefined by statute, and assessed on:
the cost and practicality of the
adjustment
the size and resources of the
organisation
whether it would be effective
whether the same outcome is available
another way
A large retailer has a higher bar than a sole trader. And “we’d have to rebuild the site” is weaker as a defence when the barrier was introduced by a recent redesign.
The commercial argument
Worth having ready, because it usually moves faster than the legal one:
MARKET SIZE
a substantial share of the UK
population is disabled, with
significant collective spending
power
→ and they leave inaccessible sites
for competitors
OVERLAP WITH EVERYTHING ELSE
captions help in noisy places
contrast helps in sunlight
keyboard access helps power users
semantic markup helps SEO
clear errors help everyone
— Inclusive Design
RETROFIT COST
fixing at design time is a fraction
of fixing after build
See: Inclusive Design
[CHECK: current UK disability prevalence and spending-power figures before quoting any — the commonly-cited numbers vary by source and definition.]
Where legal risk concentrates
CHECKOUT blocking someone from
buying is the clearest
"substantial
disadvantage"
ESSENTIAL SERVICE account management,
FUNCTIONS prescriptions, returns
FORMS unlabelled fields,
inaccessible errors
— Accessible Forms
PDF-ONLY CONTENT policies and
information available
only as inaccessible
PDFs
VIDEO WITHOUT where it carries
CAPTIONS necessary information
THIRD-PARTY WIDGETS you are responsible
for what you embed
the chat widget and
the review plugin are
your problem
See: Accessible Forms
Third-party components are the most-missed risk. A cookie banner or a payment iframe that traps keyboard focus blocks the whole journey, and “it’s the vendor’s code” isn’t a defence to a customer who can’t buy — Third-Party Scripts.
Accessibility overlays
Do not rely on an overlay widget. These are the products promising one line of JavaScript makes a site compliant.
- They do not fix the underlying markup
- Assistive-technology users have objected to them consistently and publicly
- They have not prevented legal action elsewhere, and in some cases have been the subject of it
They address the appearance of compliance rather than the barrier, and the money is better spent on the actual fixes.
The practical position
1 target WCAG 2.2 AA
2 test with keyboard and a screen
reader on core journeys
3 publish an accessibility statement
with a contact route
4 fix reported barriers promptly and
record that you did
5 build it into design and QA, not a
remediation project
Point 5 is the one that determines cost. Accessibility retrofitted at the end is expensive and partial; designed in, it’s close to free — Design Systems, Component Documentation.