Let me be direct: accessibility is not optional for UK business websites, but it’s also not as overwhelming as it seems.
The Equality Act 2010 has applied to websites since 2010. It’s not new. What’s new is increased awareness, better enforcement, and more people with disabilities expecting digital services to work for them.
I’m going to explain what the law actually requires, what WCAG means in plain English, and give you an actionable plan to make your site compliant.
The Legal Framework in the UK
Equality Act 2010 applies to service providers. If you provide services to the public (which includes your website), you must not discriminate against disabled people. This means making “reasonable adjustments” so disabled people can use your services.
For websites, “reasonable adjustments” generally means following WCAG (Web Content Accessibility Guidelines) to Level AA standard.
Public Sector Bodies Accessibility Regulations 2018 go further for government and public sector websites. They MUST meet WCAG 2.2 Level AA, publish accessibility statements, and conduct regular audits.
If you’re private sector, you’re covered by the Equality Act. If you’re public sector, you’re covered by both.
What “Reasonable Adjustments” Means
The law doesn’t say “every website must have X feature.” It says you must make reasonable adjustments. What’s reasonable depends on:
- Size and resources of your organization - Expected more from large companies than solo traders
- Cost of the adjustment - £50 fix is always reasonable, £50,000 overhaul might not be
- Benefit to disabled users - High-impact changes are more important than edge cases
- Technical feasibility - You can’t do what’s technically impossible, but most accessibility improvements are straightforward
In practice, following WCAG 2.2 Level AA is considered the standard for “reasonable.” It’s a clear, internationally recognized benchmark that courts and regulators reference.
WCAG Explained: What It Actually Means
WCAG stands for Web Content Accessibility Guidelines. It’s a technical standard maintained by W3C (the web standards body).
Three levels:
- Level A: Minimum accessibility (bare minimum, not sufficient for Equality Act)
- Level AA: Standard for legal compliance (this is your target)
- Level AAA: Maximum accessibility (nice to have, not legally required)
Current version: WCAG 2.2 (released October 2023, supersedes 2.1)
Four principles (POUR):
- Perceivable - People can perceive the content (see, hear, or touch it)
- Operable - People can use the interface (mouse, keyboard, voice, etc.)
- Understandable - People can understand the content and how to use it
- Robust - Content works with current and future technologies
Let me translate what this means in practical terms.
Perceivable: People Can Access Your Content
What this means:
Text alternatives for images Every image needs alt text describing what it shows. Screen readers read this aloud to blind users.
Bad: <img src="photo.jpg">
Good: <img src="photo.jpg" alt="Sarah Chen, physiotherapist, standing in clinic reception area">
Captions and transcripts for video/audio Videos need captions for deaf users. Audio content needs transcripts.
Color isn’t the only way to convey information Don’t rely solely on color. “Click the red button” doesn’t help colorblind users. “Click the Submit button (shown in red)” is better.
Sufficient contrast Text must have enough contrast against backgrounds. Black on white is fine. Light gray on white is not.
Minimum contrast ratios:
- Normal text: 4.5:1
- Large text: 3:1
- UI components: 3:1
Content doesn’t rely on sensory characteristics Don’t say “click the round button” or “the option on the right.” Users with screen readers can’t see shapes or positions. Say “click the Submit button.”
Operable: People Can Use Your Site
What this means:
Keyboard navigation Everything must work with keyboard alone (no mouse). Many disabled users can’t use mice.
Test: Press Tab key to move through your site. Can you reach everything? Can you see where you are? Can you activate buttons and links with Enter/Space?
No keyboard traps Users should never get stuck. If Tab takes you into a popup, you must be able to Tab/Escape out.
Enough time to read and interact If you have time limits (session timeouts, auto-advancing carousels), users need to:
- Be warned before time runs out
- Be able to extend or disable the time limit
- Have at least 20 hours for time limits (or option to turn off)
No seizure triggers Nothing should flash more than 3 times per second. This can trigger seizures in people with photosensitive epilepsy.
Skip navigation links Users should be able to skip repeated content (like navigation menus) to jump straight to main content. This helps keyboard and screen reader users.
Clear focus indicators When you Tab through a page, there should be a visible outline showing where you are. Don’t remove the default focus outline unless you replace it with something equally visible.
Understandable: People Can Comprehend Content
What this means:
Language is declared
HTML should specify the language: <html lang="en"> or <html lang="cy"> for Welsh. Screen readers need this to pronounce words correctly.
Consistent navigation Navigation should be in the same place on every page. Buttons should look like buttons. Links should look like links.
Clear form labels Every form field needs a label that stays visible even when you’re filling it in.
Bad: Placeholder text that disappears when you click Good: Label above the field that’s always visible
Error messages are helpful “Error: Invalid input” is useless. “Please enter a UK phone number (11 digits starting with 0)” is helpful.
Complex interactions are explained If something works in an unusual way, explain it. Don’t assume users will figure it out.
Readable text Use clear, simple language where possible. This helps everyone, especially people with cognitive disabilities or reading difficulties.
Robust: Content Works Across Technologies
What this means:
Valid HTML
Use proper HTML structure. <div onclick="..."> is not a button. <button> is a button. Screen readers understand semantic HTML.
Assistive technology compatibility Content should work with screen readers, screen magnifiers, voice control software, etc.
Future-proof code Use web standards, not proprietary hacks. As browsers and assistive technologies update, your site should continue working.
This is mostly about good development practice. If your developer is using modern frameworks and semantic HTML, you’re probably fine here.
Practical Accessibility Checklist
Here’s what to check on your site, prioritized by impact:
Critical (fix these first):
- All images have descriptive alt text
- Text has sufficient color contrast
- All functionality works with keyboard only
- Forms have visible labels
- Headings are used in logical order (H1 → H2 → H3)
- Links have descriptive text (not “click here”)
Important (do these soon):
- Skip-to-content link at top of page
- Videos have captions
- Focus indicators are visible
- Error messages are specific and helpful
- Page language is declared in HTML
- Navigation is consistent across pages
All our website development service includes WCAG 2.2 Level AA compliance as standard.
Good to have (when you have time):
- Audio content has transcripts
- Complex images have detailed descriptions
- Tables have proper headers and captions
- ARIA labels supplement where needed
- Site works at 200% zoom without breaking
Real-World Example: Accessibility Audit
I recently audited a solicitor’s website. Here’s what I found and fixed:
Critical issues:
- 23 images with missing alt text → Added descriptive alt text to all
- Low contrast text (gray on white, 2.8:1) → Changed to darker gray (4.6:1)
- Contact form labels were placeholders that disappeared → Changed to persistent labels
- No keyboard focus visible → Added focus outline styles
Important issues:
- Headings jumped from H1 to H3 (skipped H2) → Fixed heading hierarchy
- Links said “Read more” (not descriptive) → Changed to “Read more about conveyancing services”
- Form errors just highlighted fields red → Added text explaining what was wrong
Time to fix: 6 hours of development work
Cost: £420
Result: Site now passes WCAG 2.2 Level AA automated tests and manual keyboard testing. Solicitor documented the improvements in case of future audit.
Common Accessibility Myths
Myth: “Accessibility is expensive”
Reality: Building accessibility in from the start adds maybe 10% to development time. Retrofitting can cost more, but for most small business sites, it’s a few hours of work. Compare that to potential legal costs or lost customers.
Myth: “No one with disabilities uses my site”
Reality: You don’t know this. Many disabilities are invisible. And if your site is inaccessible, disabled users are leaving immediately—you never see them in your analytics.
Myth: “Accessibility makes sites look ugly”
Reality: Accessible sites can be beautiful. Apple, Microsoft, and Gov.uk all have excellent accessibility and excellent design. Constraints often lead to better design.
Myth: “My site is too small to worry about this”
Reality: The Equality Act doesn’t have a small business exemption. A disabled user has the same rights whether your site has 10 visitors or 10,000.
Myth: “I can just add an overlay widget and be compliant”
Reality: Accessibility overlay widgets (overlays that claim to “make any site accessible”) are controversial and often ineffective. They don’t fix underlying issues. The National Federation of the Blind opposes them. Fix your site properly instead.
Enforcement and Risk
Public sector: Monitored by GDS (Government Digital Service) and ICO. Regular compliance monitoring. Can face enforcement action.
Private sector: Complaints-based. Someone needs to complain before action is taken.
What happens if someone complains?
- Usually they’ll contact you first
- You have opportunity to fix issues
- If you refuse or ignore, they can sue under Equality Act
- Courts can order you to fix it and may award damages (typically £1,000-20,000)
- Legal costs can be £10,000-50,000+
Have people actually been sued? Yes. UK cases are increasing:
- Beyoncé’s company fined £10,000 in 2020 (settled) for inaccessible website
- Domino’s (US but widely cited) lost appeal in 2021
- Numerous UK companies have settled accessibility claims for £2,000-15,000
The risk is real but manageable. Make a good-faith effort to follow WCAG 2.2 Level AA, and you’re in a strong position.
Accessibility Statement
Public sector sites must have an accessibility statement. Private sector sites don’t legally need one, but it’s good practice.
What to include:
- Commitment to accessibility
- Known issues and planned fixes
- How to request accessible formats
- Contact information for accessibility concerns
- Date of last review
Example statement:
“We’re committed to making our website accessible to everyone. We aim to meet WCAG 2.2 Level AA standards.
We know our site isn’t perfect. Currently:
- Some older PDF documents aren’t fully accessible (we’re updating these)
- Our contact form could have better error messages (planned fix: June 2026)
If you have difficulty using our site, please email us at [email] or call [number]. We’ll help you access the information you need in an alternative format.
Last reviewed: January 2026”
This demonstrates good faith and gives users a way to get help if they encounter issues.
Getting Help: Audits and Testing
DIY testing (free):
- WAVE browser extension
- Lighthouse in Chrome DevTools
- Keyboard testing (use your Tab key)
- Try a screen reader for 10 minutes
Professional audit (£500-2,000 for small sites):
- Expert reviews your site against WCAG
- Detailed report of issues
- Recommendations for fixes
- Some auditors retest after fixes
User testing with disabled users (£1,000-5,000):
- Real people with disabilities use your site
- Identifies issues automated tools miss
- Valuable insights into user experience
For most small businesses: Start with DIY testing, fix obvious issues, then consider professional audit if you’re in a high-risk sector (public sector, large customer base, history of complaints).
Accessibility in Practice: Design & Development
If you’re working with a developer or designer, here’s what to ask for:
During design:
- “Please ensure all text meets WCAG contrast requirements”
- “Make sure form labels are visible, not just placeholders”
- “Include focus states for all interactive elements”
During development:
- “Please use semantic HTML”
- “Ensure keyboard navigation works throughout”
- “Add appropriate alt text to images”
- “Test with WAVE and Lighthouse”
Before launch:
- “Can you run an accessibility audit?”
- “Let’s test with keyboard navigation”
- “Please fix any critical WCAG violations”
Good developers should know this already. If they act like accessibility is some exotic extra, that’s a red flag about their skills.
The Business Case Beyond Legal Compliance
Forget legal risk for a moment. Accessibility is good business:
1 in 5 UK adults has a disability. That’s 14.6 million people. If your site doesn’t work for them, you’re turning away customers.
Accessibility helps everyone:
- Captions help people in noisy environments
- Clear navigation helps people in a hurry
- Good contrast helps people using phones in sunlight
- Keyboard shortcuts help power users
SEO benefits:
- Alt text helps image search rankings
- Semantic HTML helps Google understand your content
- Good heading structure helps ranking
- Accessible sites tend to be faster (technical correlation)
Reputation: Being known as accessible builds trust. Being known as ignoring disabled users damages brand.
Starting Today: Your Action Plan
Week 1: Assess
- Run WAVE on your key pages
- Try navigating with keyboard only
- Note critical issues (missing alt text, contrast problems, keyboard traps)
Week 2: Quick wins
- Add alt text to all images
- Fix color contrast issues
- Ensure forms have visible labels
- Add skip-to-content link
Week 3: Navigation and structure
- Check heading hierarchy (H1 → H2 → H3 logically)
- Test keyboard navigation, add focus styles if needed
- Ensure all links have descriptive text
Week 4: Testing and documentation
- Run Lighthouse audit
- Test with a screen reader for 30 minutes
- Document accessibility improvements made
- Create accessibility statement if appropriate
Ongoing:
- Check accessibility for new content
- Periodic audits (quarterly or annually)
- Stay informed about WCAG updates
Final Thoughts
Accessibility is not a optional extra or a nice-to-have. It’s a legal requirement, a business opportunity, and the right thing to do.
The law has been clear since 2010: websites are covered by the Equality Act. Service providers must make reasonable adjustments. For websites, that means following WCAG 2.2 Level AA.
Most accessibility improvements are straightforward. Add alt text. Fix contrast. Make keyboard navigation work. These aren’t expensive or complex changes.
Start with the critical issues, make steady progress, document your efforts. You don’t need perfection overnight—you need demonstrable commitment to improvement.
If you’re redesigning your site or building a new one, insist on accessibility from the start. It’s far easier to build it in than retrofit later.
And remember: 1 in 5 UK adults has a disability. Making your site accessible isn’t just avoiding legal risk—it’s serving 20% of your potential customers better.
That’s not compliance. That’s good business.
