Website accessibility for a UK small business — and the 1,271 failures on our own site

The short version

• The ADA is a United States statute. If you are a UK business serving UK customers, it is not the law you are under.
• Your duty comes from the Equality Act 2010, and the whole of the famous “anticipatory” principle is nine words in Schedule 2: the reference to a disabled person “is to disabled persons generally”. You are expected to think ahead, not to wait for a complaint.
• The regime that names WCAG and demands an accessibility statement is the Public Sector Bodies Regulations. It binds the state, councils and bodies governed by public law. It does not bind your shop.
• There is no accessibility regulator fining small businesses. There is a claim in the county court, where damages can include compensation for injured feelings.
• I ran eight machine-checkable tests across all 101 pages of lolasquared.com. We passed everything people talk about and failed three things nobody looks at: 1,271 elements of text below the contrast minimum, a contact form whose labels are not attached to its fields, and a menu button with no name on every page.

“ADA compliant” is a question from a different country

The Americans with Disabilities Act is US federal law. Its Title III is the part about businesses, and the US Department of Justice describes its reach plainly: it applies to “Businesses, including nonprofits, that serve the public (also called public accommodations)” — restaurants, hotels, shops, private schools, doctors’ surgeries, gyms.

Asking a British developer for an “ADA compliant” website usually gets you WCAG work anyway, so you may well end up in the right place. But the phrase points you at American guidance about American enforcement, and that is a genuinely different system. If you sell into the United States, whether and how the ADA reaches you is a real question and a lawyer’s question, not a blog post’s. I am not going to answer it here.

If your customers are in Chesterfield rather than Chicago, the law you want is closer to home.

What UK law actually says

Two sections and one schedule do almost all of the work. I read them on legislation.gov.uk in the revised text, fetched on 8 September 2026.

Section 29 puts the duty on you as a service provider. Its first subsection reads: “A person (a ‘service-provider’) concerned with the provision of a service to the public or a section of the public (for payment or not) must not discriminate against a person requiring the service by not providing the person with the service.”

Note the bracket in the middle. For payment or not. The duty does not switch on when someone gets their card out. A free brochure site is still the provision of a service to a section of the public.

Section 20 defines the duty to make reasonable adjustments, and splits it into three requirements. The first is the one your website engages: where “a provision, criterion or practice” of yours puts a disabled person at a substantial disadvantage, you must “take such steps as it is reasonable to have to take to avoid the disadvantage”.

That is the wording everyone quotes. But on its own it sounds like something that happens after a particular person has struggled. The bit that changes the meaning is elsewhere.

The nine words that make it anticipatory

Every piece of guidance you will read says the duty on service providers is “anticipatory”. Almost none of them tell you where that comes from. It comes from Schedule 2, paragraph 2(2), and this is the whole of it:

“For the purposes of this paragraph, the reference in section 20(3), (4) or (5) to a disabled person is to disabled persons generally.”

That is the entire mechanism. The Act does not add a new duty to think ahead. It takes the ordinary reasonable-adjustments duty and quietly swaps out the individual for the category. Wherever section 20 said “a disabled person”, in the services context it now means disabled people as a class — including the ones who have not visited yet, and the ones who tried, failed, and simply went somewhere else without telling you.

That last group is why waiting for complaints is such a poor strategy. A customer who cannot use your booking form does not usually file a grievance. They buy from someone whose form works.

There is a limit, and it is in the same paragraph. Sub-paragraph (7) says nothing requires a service provider to take a step that would “fundamentally alter” either “the nature of the service” or “the nature of A’s trade or profession”. You are not obliged to stop being what you are. You are obliged to be reasonable about getting there.

The rules that do not apply to you, and get quoted at you anyway

If you have been told your website must meet WCAG 2.2 and carry an accessibility statement, someone has handed you the public sector rulebook. The instrument is the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 — and yes, the “(No. 2)” is part of the name, because these regulations revoked an earlier set made the same year. Regulation 3 defines who is caught:

“‘public sector body’ means— the State; regional or local authorities; bodies governed by public law; or associations formed by one or more of the authorities… or one or more of the bodies…”

A private limited company selling kitchens, legal advice or dog grooming is none of those things. The government’s own guidance page on the subject is titled “Understanding accessibility requirements for public sector bodies”, and it is the page that tells those bodies to check against WCAG 2.2 and to publish and maintain an accessibility statement.

So: no statutory WCAG duty on your business, and no legally required accessibility statement. What you are left with is the Equality Act asking for reasonable steps — and WCAG remains far and away the most useful description anyone has written of what those steps look like. The difference is that you adopted it. Nobody issued it to you.

What actually happens if you get it wrong

This is where most advice goes vague, usually in the direction of implied fines. The Act is specific. Section 114 says a claim about the provision of services is heard by “The county court or, in Scotland, the sheriff”. Section 119 sets the remedies, and subsection (4) adds a detail worth knowing: “An award of damages may include compensation for injured feelings (whether or not it includes compensation on any other basis).”

No inspector. No penalty notice. An individual claim, brought by a person, in a county court. That is a rarer event than a regulatory sweep and a more personal one, and it generally begins with somebody who could not do business with you and minded enough to act.

So I ran the checks on our own site

Writing a checklist you have not applied to yourself is cheap. So before publishing this I took the 101 URLs in our sitemap, fetched every one of them raw, parsed the HTML myself and ran eight tests that a machine can genuinely settle: page language, page title, images without alternative text, heading structure, whether the viewport blocks zooming, link and button names, form labelling, and colour contrast.

Here is what passed, honestly reported including the bits that flatter us more than they should:

• 101 of 101 pages have a non-empty <title> and exactly one <h1>.
• 202 images, none missing an alt attribute. That number deserves a caveat: it is two per page, and both are the logo. Our posts carry their illustration as a social-share image rather than in the body, so this test barely tested us.
• 2,324 links, and not one with text like “click here” or “read more”.
• Every page sets a viewport, and not one of them disables pinch-zoom — a common and nasty failure, since blocking zoom is precisely what a partially sighted visitor needs.

And then three failures.

Failure one: the colour nobody questions

WCAG 2.2 success criterion 1.4.3, Contrast (Minimum), is a Level AA requirement and it is arithmetic rather than opinion: “The visual presentation of text and images of text has a contrast ratio of at least 4.5:1”, with an exception letting large text down to 3:1. The specification defines large as “at least 18 point or 14 point bold”. Those are points, not pixels; converting at the usual 96 dpi — my conversion, not the spec’s — that is roughly 24px, or about 18.7px if the text is bold.

Our site is dark. The body background is #0D0D0D on all 101 pages. I took every text colour we actually use, in order of how often we use it, and computed the ratio. The grey values are Tailwind’s defaults, which I read out of the JavaScript bundle the CDN actually serves us rather than trusting my memory of them.

Our second most-used text colour does not meet the standard. It is not far off — 4.02 against a required 4.5 — which is exactly why it survived: it looks fine, because it very nearly is fine.

“Nearly” matters more once you count. Of the 1,075 elements carrying text-gray-500, 973 also carry a size class of 12px, 14px or 16px, which is comfortably below any definition of large text. All 298 uses of text-gray-600 are at 12px, and that colour misses even the relaxed large-text threshold. That is 1,271 elements below the minimum, across our own hundred-odd pages, in the theme I have been happily publishing into every day.

Two caveats I want on the record rather than buried. First, I computed every ratio against #0D0D0D, the darkest background we use, which is the most flattering choice available: on our lighter card surfaces the same greys score 3.81, 3.53 and 3.13. Second, this counts elements in the markup, not rendered runs of text on screen. So 1,271 is a floor, arrived at by giving ourselves the benefit of every doubt.

One more that made me wince: our brand red, #E53E2E, scores 4.68:1 on the page background — a pass, by 0.18. Put the same red on a card and it drops to 4.11:1. Our own brand colour is one surface away from failing.

Failure two: the form that looks completely right

This is the one I would put in front of anyone who thinks they can check a website by looking at it.

Our contact page has four fields: name, email, company, message. Above each one sits a <label> element, correctly worded, properly styled, exactly where you would expect. Open the page and it is obviously fine.

None of those labels is attached to its field. There is no for attribute pointing at an input, and no label wrapping one. In the code they are four pieces of decorative text that happen to sit above four anonymous boxes. Seven of the eight form fields on our entire website are in this state.

Two Level A criteria land on this. 1.3.1, Info and Relationships, requires that “Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text”. The relationship here is conveyed purely by position on screen. And 3.3.2, Labels or Instructions, requires simply that “Labels or instructions are provided when content requires user input” — provided to the user, which for a screen reader user means provided in the markup.

A sighted visitor sees a well-labelled form. Somebody using a screen reader hears “edit text”, four times. Nothing about looking at the page can tell you this, which is the entire point: the failure is in the relationship between two things that are both individually correct.

It is the same shape of problem as the one I wrote about in what AI notetakers miss in a meeting — a machine only ever receives what was actually put into words. A label that exists only as a visual arrangement was never put into words at all.

Failure three: the button on every single page

The mobile menu button — the three-line “hamburger” in the corner — contains two SVG icons and nothing else. No text, no aria-label, no title. Announced by a screen reader, it is: “button”.

WCAG 4.1.2, Name, Role, Value, another Level A criterion, asks that “For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined”. This one has a role and no name.

It sits in the shared page template, so it is on all 101 pages. Put differently: of the 122 buttons on our website, 101 of them are that one button, repeated, nameless. A per-page audit would report it a hundred times and a content editor would never see it once, because nobody thinks of the navigation as part of the page they are writing.

The button on the page you are reading has a name, incidentally. I added one while writing this paragraph. The other hundred pages do not have it yet, and I would rather publish that sentence than quietly fix everything first and present a clean sheet.

The checker was wrong before it was right

The first time I ran the link test it reported that all 101 pages contained a link with no accessible name. A hundred and one out of a hundred and one is not a finding, it is a bug, and it was: the flagged links were our logo, which wraps an image carrying alt="Lola Squared". The alt text supplies the name perfectly well. My script had stripped the tags and thrown the name away before checking whether there was one.

After fixing that, the same test found exactly one genuine case: an X icon in the contact page’s links, drawn as an SVG with no label. Real, but one.

The moral is worth more than the finding. The first output of an automated accessibility report is a hypothesis, not a verdict. Round numbers — everything, nothing, exactly all of them — are usually telling you about your tool. The button result survived that scepticism. The link result did not.

What this test cannot tell you

Everything above is the part a machine can decide. That is a minority of what accessibility means, and I would rather say so than let eight passing checks imply a clean bill of health.

No script I can write will tell you whether alt text is useful or merely present, whether the tab order through your page makes sense, whether a keyboard user can get back out of a menu they have opened, whether an error message explains what to do, or whether your checkout can actually be completed without a mouse. Those need a person, and ideally a person who uses the web differently from you.

I should also be honest about something I nearly reported as a fault and did not. Eighty of our pages declare lang="en" and twenty-one declare lang="en-GB". That inconsistency is untidy and I will tidy it. It is not a failure: criterion 3.1.1 asks only that “The default human language of each web page can be programmatically determined”, and en determines it. Finding something odd is not the same as finding something broken, and an audit that cannot tell the difference will send you off fixing the wrong hundred things.

And the largest caveat of all: passing WCAG is not the same as meeting the Equality Act. The Act asks whether you took reasonable steps to avoid putting disabled people at a substantial disadvantage — which takes in your phone line, your emails, and whether there is any route to you that does not run through the website at all. I wrote about the phone-line half of that when looking at who an AI receptionist will fail, and the same anticipatory logic applies there.

Five things worth doing on Monday

1. Check your form labels are actually attached. View source on your contact page. Every label should have a for matching its field’s id, or wrap the field entirely. This is ten minutes and it is the highest-value fix on this list.
2. Name every icon-only button and link. Menu buttons, search icons, social icons, close buttons. An aria-label is one attribute.
3. Put your body-text colours through a contrast checker. Your captions, footers and small print are where this bites, because that is where designers reach for a lighter grey. Under 4.5:1 at normal size is a problem.
4. Try your own website using only the keyboard. Tab from the top. Can you reach everything, see where you are, open and close the menu, and send the contact form without touching the mouse? This takes five minutes and finds things no scanner will.
5. Make sure there is a route to you that is not the website. A phone number and an email address, easy to find, actually monitored. It is the cheapest reasonable adjustment there is, and it is the one that helps when everything else has failed.

We ran it again this morning

The audit above was run on 8 September. Before publishing this I ran the whole thing again on 10 September, because a measurement taken once is a claim and a measurement taken twice, on dated occasions, is something a reader can check.

The site had grown by one page in between — we publish most days — and the count went up: 1,259 elements below the minimum on 8 September, 1,271 on 10 September. Nothing was fixed and nothing broke. We simply published another post, and the post inherited the template.

That is the whole argument in miniature. The fault is not in any particular page. It is in the thing every page is made from, so it grows by about a dozen every time we write anything at all.

The re-run also caught a mistake of mine, which is the more useful half. In the first pass I counted how often each colour was used by searching the raw HTML for the class name — and that quietly counted hover:text-white as a use of text-white. Of 3,602 matches, 1,413 were hover states: a different colour, in a different situation, shown only to people using a mouse. The table above now counts elements that actually carry the class, which is what I meant all along.

The two failing greys were never affected, because we do not use them as hover colours, so the finding stands. But the top row of that table was wrong by about a third, and correcting it quietly would have been the easier thing to do.

Why publish our own failures

Because a checklist written by someone who has not run it on themselves is worth very little, and because the interesting result was not that we failed — it is which things failed. We passed every test that content editors think about: titles, headings, alt text, link wording. We failed on a colour in the theme, a relationship in a form, and a button in the navigation. All three live in places nobody edits and everyone inherits.

If you take one thing from this, take that. The accessibility problems on a small business website are usually not in the writing. They are in the template, they arrived with it, and they are on every page at once.