Website accessibility: what a UK small business has to get right

Somebody emails to say they could not book an appointment on your site. They use a screen reader, or they cannot use a mouse, and the form would not let them past the second field. You had no idea. Your web designer says the site passed every test they ran, and they are right, because nobody tested it with a keyboard.

This is the usual way a small business finds out about accessibility. A short check now costs far less than that email.

What the law asks of you

The Equality Act 2010 says a business that provides a service to the public must not treat disabled people worse, and must make reasonable adjustments so they can use that service. The duty covers a website in the same way it covers your front door. If a customer can walk into your shop but cannot use your online booking form, the duty applies to the form.

Three things are worth knowing about it.

No law names a technical standard. The Act does not mention websites or give a checklist. In practice, courts, regulators and complaint handlers look to WCAG, the Web Content Accessibility Guidelines, at level AA. Public sector sites must meet WCAG 2.2 AA by law. A private business is not bound by that regulation, but WCAG AA is what anybody judging your site will measure it against.

“Reasonable” depends on your size. A five-person firm is not expected to match what a bank spends. It is expected to fix the basic faults that stop people using the site, particularly the ones that cost almost nothing to put right.

Complaints begin with a message. In most cases a disabled customer writes to you, or tells you on the phone, long before anything formal happens. How you answer that message matters more than the fault. A business that says “thank you, we have fixed it” is in a very different position from one that ignores it.

The law is only part of it. Plenty of people use your site in ways you do not: with the sun on a phone screen, one-handed with a baby on the other arm, or with eyes that are sixty years old. The fixes below help all of them.

The four faults behind most problems

Text that is too pale to read

Light grey text on white looks smart in a design mockup. On a phone outside, or for anybody with weak eyesight, it disappears. WCAG AA asks for a contrast ratio of at least 4.5 to 1 for normal text, and 3 to 1 for large text.

Pale buttons are the worst offenders. White text on a pastel background, or a light orange call-to-action, can fail badly, and the button is the one thing you want people to see.

Pictures with no description

A screen reader cannot see an image. It reads the image’s alt text instead, a short description stored with the picture. If the alt text is missing, the reader says the file name, something like “IMG underscore 4471 dot jpg”, or skips the image altogether.

Describe what a picture shows if it carries information: “Our van outside the Skipton workshop”, “Price list for 2026”. A purely decorative image, such as a divider or a background swirl, should have empty alt text so the reader skips it. The common mistake in the other direction is stuffing the alt text with search terms. That helps nobody.

A site that only works with a mouse

Some visitors cannot use a mouse. They move through a page with the Tab key, jumping from link to button to field, and press Enter to act. If your menu opens only when hovered, or a pop-up cannot be closed from the keyboard, those visitors are stuck.

The other half is knowing where you are. When you tab to a link, something should show which one has focus, usually an outline. Many themes switch that outline off because a designer thought it looked untidy. It is the only map a keyboard user has.

Forms with no labels

A form field needs a proper label tied to it in the code. Many forms use grey placeholder text inside the box instead (“Your name”), which vanishes the moment somebody starts typing and is not reliably read out by screen readers. Somebody with a poor memory, or somebody who gets interrupted, then cannot remember what the field wanted.

Error messages fall into the same trap. A red border alone does not tell a colour-blind visitor, or a screen reader user, that anything went wrong. The message needs words: “Enter an email address, for example name@example.com”.

A twenty-minute check

You need your own site, a phone and a cup of tea.

1. Unplug the mouse for five minutes. Open your home page, press Tab repeatedly and watch. Can you see where you are on every press? Can you reach the menu, the phone number and the contact form? Can you submit the form with Enter? If focus disappears or gets trapped in a pop-up, note the page.
2. Zoom to 200%. Press Ctrl and + until the browser says 200%. Text should reflow into a single column with nothing cut off and no sideways scrolling. If the menu now covers the content, that is a fault.
3. Check the contrast of your three main colours. Search for “WebAIM contrast checker”, type in your text colour and background colour, and read the ratio. Test your body text, your button text and your link colour.
4. Look at the images that matter. In most browsers you can right-click an image and choose Inspect to see its alt attribute. Check the logo, the main photo on the home page and any image that contains words, such as a price list or a menu. Words held in an image and nowhere else are invisible to a screen reader.
5. Fill in your own contact form wrongly. Leave a required field blank and submit. Does the page tell you in words which field needs fixing, and does it put you back there?
6. Switch on your phone’s screen reader. VoiceOver on an iPhone or TalkBack on Android, with the volume up. Listen to your home page for two minutes. It is humbling, and you will learn more from it than from any report.

Write down what you find, with the page and the problem. That list is the brief for whoever fixes it.

What to fix first

Start with whatever stops somebody completing the job your site exists for: the contact form, the booking page, the phone number. A site that looks a little plain but works for everybody beats a polished one that locks people out at the last step.

After that, work through contrast and focus outlines, which are usually a few lines of styling and take a developer under an hour. Alt text is slower on a big site, but a developer can do the images that matter on the main pages first.

Some faults sit deeper. A theme with no keyboard support in its menu, or a page builder that outputs a tangle of unlabelled boxes, may not be worth patching. If your site comes from a heavy template, it may be cheaper to rebuild the parts that matter than to chase every fault. We covered the wider question in whether you need WordPress at all.

Where to go from here

You are not expected to be perfect. You are expected to look, fix the faults that block people, and respond properly when somebody tells you about another one. The twenty-minute check above gets you most of the way.

If you would rather somebody else looked, ask for a free website review and mention accessibility. Ongoing fixes can sit inside our Care & Hosting service at £49 a month. You can also ring us on 01756 533453.