Accessibility often arrives as a checklist at the end of a website project. The more useful starting question is simpler: can different people actually use the website?
That includes someone reading with a screen reader, navigating without a mouse, enlarging the text, or finding a small touch target difficult to press. It also includes ordinary situations such as glare on a phone screen or a temporary injury that changes how someone uses a computer.
For a business website, the task is usually practical. Visitors need to understand the service, assess whether it suits them and make contact. Accessibility asks whether the design and implementation let them do that.
The UK legal position needs a careful distinction
UK public-sector websites and apps are covered by specific accessibility regulations, subject to exemptions. GOV.UK’s guidance sets out WCAG 2.2 AA and an accessibility statement as the expected route to meeting those requirements.
An ordinary private business is not automatically subject to those same public-sector regulations. It would be inaccurate to say that every private UK website has a blanket legal requirement to achieve WCAG 2.2 AA.
That does not remove wider duties towards disabled customers. The Equality Act 2010 applies to service providers in England, Scotland and Wales, including duties to make reasonable adjustments. Northern Ireland has separate provisions under the Disability Discrimination Act 1995. What is reasonable depends on the circumstances; a technical score alone does not settle that question.
This is general information about website accessibility, not legal advice.
Use WCAG as a practical benchmark
The Web Content Accessibility Guidelines, version 2.2, provide testable criteria for making web content accessible. Level AA is a strong design and development benchmark for a business website, whether or not the public-sector regulations apply.
The criteria include keyboard access, visible focus, meaningful headings and labels, readable contrast, text resizing and reflow. For most text, the AA minimum contrast ratio is 4.5:1; qualifying large text has a 3:1 minimum. There are defined exceptions, so checking the actual design matters.
A benchmark gives the project something concrete to work towards. Ask which pages and interactions will be checked, what manual testing is included, and how any remaining problems will be recorded. “Accessible” without a scope or evidence is an incomplete handover description.
Start with the route through the page
Clear page structure reduces the effort needed to understand a site. Visitors should be able to identify the main content, follow descriptive headings and find navigation that behaves consistently.
Proper semantic HTML helps expose that structure to assistive technology. A visual heading should also be marked up as a heading, rather than being an ordinary paragraph made larger. Heading levels should describe the relationship between topics.
Check the reading order as well as the visual layout. A desktop design might place a useful explanation beside a form. On mobile or when read in document order, that explanation should still arrive before the point where someone needs it.
Try the site without a mouse
Put the mouse aside and use Tab, Shift+Tab and the appropriate activation keys to move through the page. Can you reach the menu, follow a service link, operate any expandable content and complete the enquiry form?
You should be able to see which control has focus. The indicator needs to remain visible against its background, and sticky headers or banners should not completely obscure the focused control. A tidy design is not a reason to remove this feedback.
Watch for controls that respond only to hovering, menus that cannot be closed, and decorative elements that unnecessarily enter the tab order. The route should follow the task, without making someone step through every visual detail to reach the next useful action.
Make reading and touching comfortable
Contrast, type size and spacing work together. A technically adequate colour pair can still be tiring when the text is tiny or the lines are too long. Read the longest service description and the smallest supporting note, rather than judging only the main heading.
Enlarge the text and narrow the browser. Content should reflow without clipping essential information or requiring horizontal scrolling for ordinary prose. A fixed-width card that looks neat in a desktop screenshot may become a barrier when the reader changes those conditions.
On a phone, give buttons and links enough space to select reliably. Closely packed targets can make an otherwise straightforward task fiddly. Test the real contact route, including the on-screen keyboard, rather than looking only at a resized preview.
Performance belongs in that review too. A menu that takes time to respond or content that moves as it loads adds uncertainty. Our guide to Core Web Vitals explains how to investigate those problems.
The form deserves as much care as the homepage
Every field needs a meaningful, associated label. Placeholder text can show an example, but it disappears as someone types and is not a substitute for the label. Required and optional fields should be understandable before submission.
An error should explain what needs correcting near the relevant field. A red border alone is not enough. If an email address is incomplete, say what is wrong and let the visitor fix it without re-entering everything else.
Check what happens after submission. A waiting state should be clear, a failure should allow retry, and confirmation should be available to assistive technology as well as visible on screen. The visitor should not have to infer whether their enquiry went anywhere.
A good automated score is a starting point
Automated checks are useful for repeatable problems such as missing labels or some contrast failures. They cannot decide whether an explanation makes sense, whether alternative text describes the important part of an image, or whether a person can complete the whole task comfortably.
W3C’s Easy Checks guidance makes clear that an initial review is not a comprehensive evaluation. Combine tools with manual keyboard, zoom, screen-reader and mobile testing, and involve disabled users where possible.
Good access belongs in good design
Accessibility here is also conversion design. Clearer labels, readable typography, a logical hierarchy and lower friction usually improve the experience beyond the people a particular adjustment first helps. That is a design rationale, not a promise of a particular conversion increase.
There is no requirement for an accessible website to look plain or ugly. Strong typography, careful contrast and predictable interactions can make it feel more considered. They also support the small details that make a business website trustworthy.
Include accessibility in the brief, review it during the build and keep checking it as content changes. It is easier to design a clear route from the beginning than to repair a confusing one at the end.