A recent article on UnHerd has been doing the rounds in developer circles. It tells the story of a small business owner who got hit with an accessibility lawsuit, and it paints WCAG compliance as an impossible, expensive burden that small businesses can't possibly meet.
The piece has struck a nerve. But it also gets several things wrong—and those mistakes matter if you're building websites for UK clients.
The article's core argument
The author's position is essentially: WCAG is too complex, compliance is impossible to prove, and the whole system exists mainly to enable lawsuits. They suggest that even if you try to make your site accessible, you can still get sued, so why bother?
This is a frustrating take, because it conflates the US legal environment (where ADA lawsuits are genuinely problematic) with the situation in the UK and Europe, where enforcement works differently.
How UK accessibility law actually works
In the UK, the Equality Act 2010 requires service providers to make "reasonable adjustments" for disabled users. This includes websites. But here's what the UnHerd piece misses: UK enforcement is primarily complaint-driven and handled by the Equality and Human Rights Commission, not through the kind of serial litigation that happens in the US.
That doesn't mean you can ignore accessibility. It means the approach is different. You're more likely to face a complaint to the EHRC than a lawsuit from a specialist law firm. And the standard you're measured against is reasonableness, not perfection.
For public sector websites, the requirements are more specific. The Public Sector Bodies Accessibility Regulations 2018 explicitly require WCAG 2.1 AA compliance. If you're building for councils, NHS trusts, or government departments, this isn't optional.
What WCAG actually requires
The article suggests WCAG is impossibly complex. It's not. WCAG 2.1 AA has 50 success criteria. Some are technical, but most are straightforward once you understand them.
Here are the issues that cause 80% of accessibility failures:
Missing alt text on images (WCAG 1.1.1) Every non-decorative image needs a text alternative. If an image conveys information, describe it. If it's purely decorative, mark it as such with an empty alt attribute.
Insufficient colour contrast (WCAG 1.4.3) Text needs a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) needs 3:1. You can check this in seconds with browser dev tools or a contrast checker.
Missing form labels (WCAG 1.3.1, 4.1.2)
Every form input needs a programmatically associated label. Not placeholder text—an actual label element linked with the for attribute.
Keyboard inaccessibility (WCAG 2.1.1) Everything that works with a mouse needs to work with a keyboard. Custom dropdowns, modals, carousels—if you can't tab to it and activate it with Enter or Space, it's broken.
Missing focus indicators (WCAG 2.4.7) When users tab through your page, they need to see where they are. Don't remove the browser's default focus outline unless you're replacing it with something equally visible.
These five issues account for most accessibility failures. Fix them and you've handled the majority of problems.
The cost argument doesn't hold up
The article implies that accessibility is prohibitively expensive for small businesses. But building accessibly from the start costs almost nothing extra. It's retrofitting inaccessible sites that gets expensive.
If you're a developer, this means:
- Use semantic HTML. A
<button>is accessible by default. A<div>with a click handler isn't. - Test with your keyboard regularly. Can you complete every task without a mouse?
- Run automated checks during development, not just before launch.
- Check your colour contrast before signing off designs.
None of this adds significant time to a project. It's just part of building things properly.
The real problem with the article
The UnHerd piece frames accessibility as a legal minefield rather than a quality standard. This is backwards.
WCAG exists because 16 million people in the UK have a disability. One in five of your users might struggle with low contrast text, keyboard-only navigation, or screen reader compatibility. Building accessible sites isn't about avoiding lawsuits—it's about not excluding a fifth of your potential audience.
The legal requirements exist because voluntary compliance wasn't working. But the goal isn't to create a litigation industry. It's to make the web work for everyone.
What to do next
If you're worried about accessibility compliance, start with an audit of your current sites. Identify the common issues—contrast, alt text, form labels, keyboard access—and fix them. Then build accessibility checks into your development process so new work doesn't introduce the same problems.
Automated tools catch about 30-40% of accessibility issues. They're a starting point, not a complete solution. But they'll flag the obvious problems quickly and give you a clear list of what needs fixing.
WCAGCheck scans your website for WCAG compliance issues and tells you exactly what to fix. Try it free at wcagcheck.co.uk