Website accessibility in the UK means making your site usable by disabled people, and for most small business sites it comes down to five fixes: contrast, image descriptions, form labels, link and button names, and keyboard use.
No law says a private business website must reach a named technical standard. The Equality Act 2010 does require reasonable adjustments, and the small failures that block real customers are well known and cheap to repair.
This article explains what the law expects, what the largest annual accessibility audit finds on live sites, and how to fix and test each of the five. It belongs to our wider guide to UK web design agencies, because most of these problems are cheapest to prevent at build time.
What does UK law require of a business website?
Private-sector organisations must make reasonable adjustments so that disabled people are not excluded, and that duty covers websites, apps and documents such as PDFs.
According to Scope, the disability charity, the Equality Act 2010 places an anticipatory duty on service providers. That means planning for users with a range of impairments, not waiting until someone is blocked. Disabled people should never pay for the adjustment.
Small businesses are still expected to get the basics right, such as alt text on images. Claiming that an adjustment would be a disproportionate burden requires an assessment.
There is no UK-specific private-sector web accessibility regulation yet, and Scope says there have been no UK web accessibility court cases to date. One example it cites is the RNIB starting court action against BMIbaby, which settled out of court after making its website accessible.
Public bodies are in a different position: under the 2018 regulations, their sites must meet WCAG 2.1 at level AA.
So the risk for a small firm is less a lawsuit than lost customers and a poor impression. WCAG, the Web Content Accessibility Guidelines, is the sensible yardstick to work to.
How common are accessibility failures?
Almost every website has them. WebAIM's 2026 analysis of the top one million home pages found detectable WCAG failures on 95.9% of them, with an average of 56.1 errors per page.
That figure rose from 51 the year before, which reversed several years of slow progress. WebAIM reported that 96% of the errors fall into just six categories, which is good news: a short list covers nearly all the problems.
The three most frequent were low-contrast text on 83.9% of pages, missing image descriptions on more than half and unlabelled form fields on 51%.
WebAIM also found more detected errors on pages that use ARIA attributes, the extra code developers add to describe interface parts, and on complex ecommerce pages and sites with many third-party scripts. The lesson is that modern tools do not deliver accessibility by default. Plain, well-structured HTML usually does better.
These checks are automated, so they find only part of the problem. A page that passes can still be confusing to use with a screen reader. Treat the automated findings as the floor.
Fix 1: text that has enough contrast
Text needs enough difference in colour from its background for people with low vision or colour blindness, and for anyone reading on a phone in sunlight.
WCAG level AA asks for a contrast ratio of at least 4.5 to 1 for normal text, and 3 to 1 for large text. Grey on white and white on a pale brand colour are the usual offenders. Low contrast was the most common error in WebAIM's report, found on 83.9% of pages.
To test, paste your text and background colours into a free contrast checker, or use the colour picker in your browser's developer tools, which shows the ratio. Fix the brand palette once. A slightly darker version of the grey or the accent colour usually passes without changing the look.
Fix 2: descriptions for images that carry meaning
Every image that conveys information needs a short text description, called alt text, so a screen reader can say what it shows.
Describe the purpose, not the pixels. "Dentist checking a patient's teeth" is acceptable, and "Book a free consultation" is right for a banner that carries those words. Decorative images, such as a background swirl, should have empty alt text so that a screen reader skips them.
Logos need the company name. Images of text are best avoided, since the words should exist as text.
To test, turn images off in your browser, or use a screen reader's image list, and check that the page still makes sense. Alt text also helps search engines and AI tools understand your pages, which is why it appears again in our piece on AI crawlers.
Fix 3: labels on every form field
Each form field needs a visible label that is programmatically linked to it, because placeholder text disappears when someone starts typing and screen readers may not announce it.
Half of the pages in WebAIM's report had unlabelled inputs. A contact form with fields that say only "Name" in faint grey inside the box is typical. The fix is a proper label above or beside each field, tied to the field in the code.
Also mark which fields are required, say what format you expect for a phone number or a date and write error messages that say what went wrong and how to put it right.
To test, click on a label. In a correctly built form, the cursor jumps to the field. Then submit the form empty and read the error messages. This matters directly for enquiries, since it is the step where your customer gives you their details. It also affects conversion.
Fix 4: links and buttons with names that make sense
Links and buttons must say where they go or what they do, because screen reader users often pull up a list of all the links on a page.
A list of fifteen links that all read "Click here" or "Read more" is useless. "Book a dental check-up" and "Download the price list" make sense out of context. Icon buttons, such as a hamburger menu or a search magnifier, need a text name in the code. An empty link or button is announced as nothing at all.
To test, scan your page for repeated "Read more" links and icon-only buttons. Rewrite them so each has a distinct, descriptive name. The fix is nearly always a copy edit.
Fix 5: a page you can use with the keyboard alone
Everything that works with a mouse must also work with the Tab, Enter and arrow keys, and you must be able to see where you are on the page.
Some visitors cannot use a mouse because of motor impairments, or prefer the keyboard. Plenty of people use only a keyboard on a laptop in a hurry. The common failures are menus that open only on hover, pop-ups that trap the focus, custom widgets with no keyboard support and a missing or invisible focus outline.
To test, put your mouse aside and press Tab repeatedly from the top of the page. You should see a clear outline move through the links, buttons and form fields in a logical order.
You should be able to open the menu, fill in the form and submit it. If the outline vanishes, or you get stuck, you have found a fault worth fixing before anything else.
How do you check the rest?
Run an automated checker, then do a keyboard pass and a zoom test, then ask one person who uses assistive technology to try the key tasks.
Free browser-based checkers catch many of the issues above. Zoom the page to 200% and check that nothing is cut off. Resize to a phone width and check that you do not have to scroll sideways. Then try the three tasks that matter: find your phone number, read a service page and send an enquiry.
Add an accessibility statement if you can, with a way to report a problem. It signals that you take the duty seriously and gives people an alternative route to reach you.
What should you ask your web agency?
Ask which standard they build to, how they test and whether you can see the results.
A sound answer names WCAG 2.2 level AA, describes automated and manual testing and promises to fix failures before launch. A weak answer says the template is "accessible" without evidence. Put the standard in the brief. For a clinic or private practice, where patients are more likely to have impairments, it is more important still.
A retailer or ecommerce brand benefits too, since a checkout that cannot be used with a keyboard loses sales.
The cost of getting it right at build time is small. Retrofitting a finished site, especially one built on a heavy page builder, is slower, and our article on the cost of a cheap website shows how those extras add up.
Start with an hour
Run the keyboard test, the contrast check and the form test on your own site this week, and write down what fails. Most small sites need a morning's work to clear the worst of it.
If you would like help, our website design service covers accessible builds, and you can contact us about your current site.
