Web Accessibility in the UK: What Your Business Website Needs to Know

In June 2025, the European Accessibility Act came into force across all EU member states, requiring digital products and services, including websites, to meet accessibility standards. The EAA applies to any business selling into the EU, including UK businesses. It aligns with WCAG 2.1 AA, the same technical standard used in decades of disability discrimination cases. Non-compliance can result in enforcement action, fines, and restricted market access.

The UK has the Equality Act 2010, which requires service providers to make "reasonable adjustments" for disabled people, including digital services. It's less prescriptive than the EAA, which in some ways makes it harder to navigate—there's no specific technical checklist, just a general obligation not to discriminate. But the direction of travel is unmistakable.

Here's the commercial reality: an estimated 16.8 million people in the UK have a disability. That's one in four of the population. The spending power of disabled households is estimated at £274 billion a year—the Purple Pound. Seventy-three percent of disabled consumers have experienced barriers on more than a quarter of the websites they visit. Seventy-five percent have walked away from a business because of poor accessibility.

The Click-Away Pound—the value of online spending lost when disabled customers abandon inaccessible websites—stands at £17.1 billion a year. That's not a typo. Seventeen billion pounds, evaporating quietly from the UK economy every year because websites don't work for the people trying to use them.

And across the Atlantic, the legal precedent is already set. Over 25,000 digital accessibility lawsuits have been filed in the US since 2018, with nearly 5,000 projected for 2025 alone. The case that established the standard is instructive.

The Domino's Case: Why This Matters

Guillermo Robles is blind and uses screen-reading software to navigate the internet. In 2016, he visited the Domino's Pizza website to place an order. The screen reader couldn't interpret the site. Buttons had no labels. Images had no descriptions. The ordering system was, for someone using assistive technology, silence.

He sued under the Americans with Disabilities Act. Domino's fought for six years, arguing that the law didn't cover websites and that they'd provided alternatives: a phone hotline, voice ordering through Alexa. In 2019, the Supreme Court declined to hear their appeal, effectively siding with Robles. In 2021, a judge ruled that Domino's had violated the ADA. In 2022, the case settled.

The statutory damages: four thousand pounds. The legal costs, reputational damage, and years of distraction? Incalculable. And here's the crucial bit: Domino's could have fixed the accessibility issues—missing alt text, unlabelled buttons, incompatible form fields—in days. The entire six-year battle was over fixes that take a competent developer a few hours.

What Accessibility Actually Means (In Plain English)

When people hear "web accessibility," they often think it's only relevant to people with visual impairments. That's a common misconception. Accessibility is about making your site work for everyone, regardless of ability or circumstance.

This includes:

• Blind and visually impaired users who use screen readers (software that converts what's on screen to spoken words) or magnification tools.

• Deaf and hard of hearing users who need captions or transcripts for video and audio content.

• Motor impairment users who can't use a mouse and navigate using a keyboard, voice control, or specialized input devices.

• Cognitive impairment users who need clear language, simple navigation, and consistent structure.

• Low vision users who need good colour contrast and the ability to resize text.

• Temporary impairment users (someone with a broken arm, a sun-glare headache, a noisy environment) who benefit from the same features that help permanently disabled users.

WCAG 2.1 AA, the standard you need to meet, breaks down into four principles: content must be perceivable (people can see and hear it), operable (people can navigate and use it), understandable (people can comprehend it), and robust (it works with assistive technologies).

The technical requirements sound complex until you break them down. They're mostly common sense delivered precisely.

What Squarespace Does Well (And Doesn't)

The uncomfortable truth: Squarespace does some things well and some things not at all. The platform gives you tools, but the responsibility for accessibility sits entirely with you.

Squarespace templates are generally built with semantic HTML, meaning the underlying code structure is sound. The platform supports alt text on images. It generates heading tags. It handles focus states on links and buttons reasonably well. Compared to a WordPress site built from random plugins and a 2017 theme, a default Squarespace site is in decent shape.

But "decent shape" is not the same as "accessible." And the gap is almost entirely filled by decisions you're making every single day.

Alt Text: The Most Common Problem

Squarespace gives you an alt text field. It even offers AI-generated suggestions now. But if you leave it blank, or accept the auto-generated "IMG_4521.jpg," a screen reader user encounters your gorgeous portfolio image as either dead silence or meaningless characters.

Every image without alt text is a hole in the experience. Most Squarespace sites we audit have dozens of them. The fix is straightforward: write a genuine description of what's in the image, as if for someone who can't see it. Not "pastries" but "Selection of croissants and pain au chocolat on a marble countertop." Not "team photo" but "Five team members standing in the office, smiling at the camera."

Heading Structure: The Foundation of Navigation

Squarespace lets you choose H1, H2, H3, and so on. It also lets you choose them purely for visual size, which is what most people do. Result: H1 for the big text, H3 for the medium text, H1 again for another big section. Sighted visitors see an organized page. Screen reader users encounter chaos. A screen reader uses heading hierarchy to navigate, the way you might scan a table of contents. If the hierarchy is jumbled, the page is impossible to navigate.

The fix: one H1 per page at the top. H2s for major sections. H3s for subsections. If you want text to be a different size, change the styling through Site Styles, not the heading level. This single discipline fixes a massive accessibility problem and also improves your SEO and visual hierarchy.

Colour Contrast: The Reading Problem

Squarespace lets you choose any colour combination you like. Light grey text on white background? Beautiful and minimal. Completely unreadable for someone with low vision, or anyone over 50 squinting at their phone in bright sunlight. WCAG requires a contrast ratio of at least 4.5:1 for normal text. That elegant grey-on-white palette is almost certainly failing.

You can test this with a free tool like the WebAIM Contrast Checker. Plug in your text colour and background colour and it tells you instantly whether you meet the standard. If you don't, darken the text or lighten the background. It takes five minutes and fixes a barrier for millions of people.

Forms: The Interaction Problem

Squarespace's Form Block works visually, but the labels, error messages, and input fields need to be properly associated for screen readers to make sense of them. If a screen reader user can't tell which field is for their name and which is for their email, the form is useless, regardless of how it looks.

Keyboard Navigation: The Invisible Problem

Keyboard users (people with motor impairments, injuries, or preference) need to be able to tab through every interactive element on the page in a logical order. They can't use a mouse. If they can see a button but can't reach it with Tab+Enter, the button doesn't exist for them.

Squarespace handles this reasonably well by default, but custom code, third-party embeds, and certain design choices can break the tab order entirely. Test this by opening your site and pressing Tab repeatedly. Can you reach every button, link, and form field? Can you use Enter or Space to activate them? If not, you have a keyboard navigation problem.

Video: The Comprehension Problem

If you have video on your site, it needs captions or a transcript. Not optional. Not "nice to have." Essential. Deaf users need captions. Hard of hearing users benefit from them. Hearing users in noisy environments benefit from them. People watching in quiet environments where they can't play sound benefit from them. YouTube's auto-caption feature is better than it used to be but often inaccurate. If you care about accessibility, write proper captions yourself or hire someone to do it.

The Practical Accessibility Checklist

Start by running your site through the WAVE accessibility checker. It's free, it's instant, and it will almost certainly surface issues you didn't know existed. Go to wave.webaim.org, paste in your URL, and look at the report. It's not perfect (no automated tool is), but it's a solid starting point.

Then do the manual tests that automated tools miss:

Test 1: Keyboard Navigation

Open your site. Press Tab. Keep pressing Tab. Can you reach every interactive element (buttons, links, form fields)? Can you activate them with Enter or Space? If anything is unreachable or unfocusable, you have a problem.

Test 2: Screen Reader Testing

Turn on VoiceOver (Mac) or Narrator (Windows) and try to navigate your homepage with your eyes closed. Do the headings make sense? Can you find your contact information? Can you fill in a form? This is how disabled visitors experience your site. If it's confusing to you, it's confusing to them.

Test 3: Font Size

Increase your browser's font size to 200%. Does your layout break? Does text overflow or become unreadable? Users with low vision often enlarge text. Your design should handle this gracefully.

Test 4: Colour Contrast

Use the WebAIM Contrast Checker to test every text/background combination. Check your headings, body text, buttons, captions, everything. You need a ratio of at least 4.5:1 for normal text, 3:1 for large text.

Test 5: Mobile Accessibility

Test on an actual phone. Can you tap buttons easily? Is the text readable? Can you fill in forms? Is there enough spacing between interactive elements so you don't accidentally tap the wrong button?

The Practical Implementation

Here's exactly what to do, in order of impact:

Priority 1: Fix alt text and heading structure (biggest impact, relatively easy). Go through every image and write descriptive alt text. Restructure all headings to follow a proper hierarchy. Do this on every page. This alone fixes about 50% of typical accessibility issues and also improves SEO significantly.

Priority 2: Check colour contrast (huge impact, very easy). Use WebAIM Contrast Checker to test every text/background combination. If anything fails, adjust the colours. This takes a few hours for a typical site and fixes barriers for millions of people with low vision.

Priority 3: Ensure keyboard navigation works (moderate impact, mostly checking). Tab through your site. Make sure everything is reachable. If you have custom code or third-party embeds breaking the tab order, fix or remove them.

Priority 4: Add captions to videos (high impact for sites with video, moderate effort). If you have video, it needs captions. YouTube auto-captions are imperfect but better than nothing. For critical content, get professional captions.

Priority 5: Test with a screen reader (effort-intensive but educational). Turn on VoiceOver or Narrator and try to use your site. You'll discover how disabled visitors experience it. Many accessibility issues become obvious once you hear them through a screen reader.

Why This Actually Matters Beyond Compliance

Yes, there are legal and commercial reasons to fix accessibility. The Purple Pound is real. The legal risk is real. But there's something more important underneath.

There is a real person on the other side of every inaccessible website. Not a demographic. Not a statistic. Not a potential plaintiff. A person who wants to book a haircut, read about your services, buy a birthday present, find out your opening hours. A person who is being told, by the design choices you've made, that they don't matter enough to be considered. That the website is for other people. That they should find another way, or find another business.

Guillermo Robles didn't set out to become the most famous accessibility plaintiff in legal history. He set out to order a Domino's. The six years of litigation were a consequence of a company that decided fighting was easier than fixing. The tragedy isn't the lawsuit. The tragedy is that the barriers were so basic, so fixable, and so completely unnecessary that a few days of proper development work would have prevented the whole thing.

Most of the accessibility issues on Squarespace sites are the same. Not complex engineering challenges. Not prohibitively expensive overhauls. Simple, small, specific things that someone didn't know about or didn't prioritize. Alt text on images. Heading hierarchy. Colour contrast. Form labels. Keyboard navigation. These aren't mysterious or technical. They're just... care.

The Accessibility Myth You Need to Abandon

There's a persistent myth that accessibility makes design worse. That if you add alt text, fix colour contrast, improve keyboard navigation, your site will become less beautiful or less modern. This isn't true. If anything, the opposite is true. Accessibility often makes design better. Better colour contrast makes text more readable for everyone. Proper heading structure makes content more scannable. Keyboard navigation makes the site faster to use. Captions on videos help hearing users in noisy environments.

You're not compromising design for accessibility. You're making the design more robust, more considered, more intentional. And yes, that means occasionally you need to darken a trendy grey text or add a slightly less minimal button. Those are fine tradeoffs.

Don't Use Accessibility Overlay Widgets

One important warning: if you're tempted to use an accessibility overlay widget (one of those toolbar plugins that promise one-click compliance), don't. In 2024, one in four accessibility lawsuits in the US were filed against websites that had overlay widgets installed. In early 2025, the FTC fined one of the leading overlay providers a million dollars for misleading businesses about what their product could do.

These tools are a plaster on a broken bone. They don't fix the underlying issues, and they can actually introduce new barriers for assistive technology users. Real accessibility isn't a plugin. It's a practice. It requires understanding why these things matter and doing the work to fix them.

Moving Forward

Accessibility isn't a problem to solve once and then forget about. It's a practice to bake into your process. When you update your site, check the alt text and heading structure. When you add new images, write alt text first. When you change colours, test contrast. When you update navigation, test keyboard navigation. Make it routine, not an afterthought.

And if you're building sites for clients: bake accessibility into your process from the start. Audit your templates. Train yourself on WCAG 2.1 AA. The guidelines aren't exciting reading, but they're clearer than you'd expect. Include accessibility testing in your handover process. Charge for it by all means, but do it as standard, not as a premium extra for clients who happen to care.

Because the alternative—a barrier-filled website that excludes millions of potential customers, damages your brand, and exposes you to legal risk—is far more expensive than doing it right the first time.