Accessibility basics every small business website should meet

Most small business websites are checked on one screen: the owner’s laptop. Then a customer arrives who uses a keyboard, zooms text to 200% or listens through a screen reader. If the site was never tested for that, it stops working for them, and they leave.

The reference standard for fixing this is the Web Content Accessibility Guidelines (WCAG), published by the W3C. Version 2.2 was published on 5 October 2023. You do not need to read all of it. This guide covers the parts a small business can check without a specialist, plus a test routine you can run this week.

What WCAG 2.2 is, in plain words

W3C describes WCAG as an international standard that explains how to make web content more accessible to people with disabilities. It is organised under four principles, often shortened to POUR:

• Perceivable: people can take in the content, whatever senses they use. Text alternatives for images and captions for video belong here.
• Operable: people can use every control, including with a keyboard alone and without precise mouse movements.
• Understandable: content and behaviour make sense. Forms say what they need and explain what went wrong.
• Robust: the site works with the browsers and assistive technologies people use, such as screen readers.

Under the principles sit testable success criteria. Each has a number, such as 1.4.3, and a level.

Levels A, AA and AAA, and why AA is the usual target

There are three levels and each one includes the one below. W3C calls Level A “the minimum level of conformance”. Level AA means meeting every A and AA criterion. Level AAA means meeting all of them.

AA is the level most organisations work towards. In the UK, GOV.UK guidance says public sector websites and apps must meet WCAG 2.2 AA under the Public Sector Bodies Accessibility Regulations 2018. Most private businesses are outside those regulations. The same page notes, though, that all UK service providers must consider reasonable adjustments for disabled people under the Equality Act 2010 (or the Disability Discrimination Act 1995 in Northern Ireland). If you are unsure what applies to you, GOV.UK suggests asking a legal adviser.

AAA is a stretch. W3C itself says it is not recommended that AAA be required as a general policy for entire sites, because some content cannot meet every AAA criterion.

The checks that catch most problems

Colour contrast

Criterion 1.4.3 (AA) asks for a contrast ratio of at least 4.5:1 between normal text and its background, and at least 3:1 for large text. Large text means 18 point or bigger, or 14 point bold, which W3C puts at roughly 24px and 18.5px. The ratios are thresholds and are not rounded, so 4.499:1 fails. Look first for pale grey body text on white and white text on light brand colours, using the exact hex values from your theme in a free contrast checker.

Alt text for images

Every image needs an alt attribute. If the image carries information, the alt text should give that information in context. An example (illustration only): on a jewellery shop, “Silver hoop earrings, 20mm, worn by a model” tells a screen reader user far more than “product image”. If an image is purely decorative, give it empty alt text (alt="") so screen readers skip it.

Keyboard access and visible focus

Put the mouse to one side and press Tab. You should be able to reach every link, button and form field in a sensible order, and move away from each one again. A visible focus outline should show where you are at every step. WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum) at AA: when something has keyboard focus, it must not be completely hidden by content such as a sticky header or a cookie banner.

Form labels and error messages

Each field needs a proper label tied to it in the code. Placeholder text that vanishes as soon as someone starts typing does not count. Mark required fields in a way that does not rely on colour alone, and put instructions before the field that needs them. When something goes wrong, the error should be clear and easy to find, and the form should keep what the person already typed.

Headings structure

Screen reader users often skim a page by jumping between headings. Use real heading elements rather than bold text made to look large. Start with one main heading and avoid skipping levels, for example jumping from a level two heading straight to a level four.

Target size

New in WCAG 2.2, criterion 2.5.8 Target Size (Minimum) at AA asks for pointer targets of at least 24 by 24 CSS pixels. A smaller target can still pass if it has enough space around it that a 24 pixel circle centred on it would not overlap another target. There are exceptions, including links inside a sentence. Tiny close icons, crowded rows of social icons and quantity buttons on product pages are where small sites tend to fail.

Captions and other media

Video with speech needs captions. W3C’s quick checks ask for captions that are not only automatic, since auto-generated captions often mangle names, prices and product terms. Offer a transcript for audio, make media controls work by keyboard, and do not play sound automatically without a way to stop it.

Other WCAG 2.2 changes worth knowing

WCAG 2.2 added nine success criteria. Beyond focus and target size, three matter to most small sites:

• 3.3.8 Accessible Authentication (Minimum), AA: a login step cannot depend on a memory or puzzle test unless there is an alternative or some help. Letting password managers fill the field and allowing paste both count as help.
• 3.3.7 Redundant Entry, A: if people must give the same information twice in one process, fill it in for them or let them select it. An example (illustration only): offer “same as delivery address” for billing.
• 3.2.6 Consistent Help, A: if you offer help on several pages, such as contact details or a chat option, keep it in the same relative order on each page.

One criterion went the other way. 4.1.1 Parsing was removed in 2.2 because W3C considers it obsolete.

A quick test routine

Set aside about half an hour and work through three pages: your home page, one product or service page, and your contact or checkout form.

1. Look at the browser tab. Each page should have a short title that differs from the others.
2. Run your body text, link and button colours through a contrast checker.
3. Tab through each page without the mouse. Note anything you cannot reach, cannot see focus on, or that a banner hides.
4. Zoom text to 200%. Look for text that overlaps, gets cut off or forces sideways scrolling.
5. Check that each image has sensible alt text, using a free browser extension or your browser’s inspect tool.
6. Submit the form empty, then with one mistake. Read the error messages as if you could not see the layout.
7. Play a video with the sound off and check the captions are accurate.
8. On your phone, tap every button and icon with your thumb.

W3C is clear about the limits of quick checks: a page can seem to pass them and still have significant barriers. Treat this routine as a first sweep, then add an automated checker and, when you can, feedback from disabled users.

Where to start if you find problems

Fix whatever stops someone finishing a task first: a form that cannot be submitted by keyboard, a checkout button hidden behind a banner, a login that blocks paste. Contrast and labels come next, because they affect many people and are usually quick changes in your theme settings. Then work through alt text, headings and captions page by page, and rerun the routine whenever you change theme.