A Website Isn't Finished If Customers Can't Use It

Imagine a customer reaching the final step of a booking. The available dates appear in a custom calendar that cannot be operated from the keyboard. The rest of the page loads quickly, the payment service is healthy and the design matches the approved artwork. The customer still cannot book.

That is a failed product journey. Describing it only as an accessibility issue can accidentally move it away from the people responsible for the product's success.

The same applies when a form identifies an error by colour alone, a crucial instruction disappears at increased text size or a control has no useful name for someone using a screen reader. These are concrete obstacles with consequences for the task. They should be recorded in terms a designer, developer and business owner can investigate together.

Begin with the journeys on which customers depend. For an SME, these may include comparing a service, submitting an enquiry, completing a purchase and retrieving an existing order. Staff tools deserve attention as well. An inaccessible system can prevent a colleague from carrying out their role independently.

W3C's business case for digital accessibility connects access with broader usability and participation. A business does not need to attach a speculative revenue figure to every improvement to recognise its value.

The first useful question is specific: can someone complete this task using a different way of seeing, hearing, navigating or entering information? The answer should influence what the team considers ready to release.

A requirement to make a site accessible leaves too much interpretation until late in the project. Agree the technical target, the scope of evaluation and the evidence expected from delivery.

WCAG 2.2 provides testable criteria, including keyboard access, labels, contrast and error handling. It is a technical standard; applicable legal requirements still depend on the organisation and the markets it serves. Conformance also does not mean every possible user need has been met.

Translate the agreed target into decisions on actual components. A designer selecting a calendar, navigation menu or authentication flow should know how that component will be operated and assessed. Content authors need to know what makes an instruction understandable when its visual position is unavailable.

For a hypothetical quotation form, the team might agree that a customer can identify each field's purpose, understand what information is required and recover from an invalid entry without losing useful work. The technical review then checks how the implementation supports those outcomes.

These criteria should be considered alongside security, reliability and the business rules of the form. They should not be left in a separate document that no one uses during acceptance.

A practical brief should also identify third-party steps. A site may hand the customer to an external booking tool, payment service or document portal. Ask suppliers for relevant evidence and inspect the actual journey. A carefully built front end cannot make an inaccessible next step usable by itself.

Resolve responsibility before procurement where possible. Once a critical process depends on a component the business cannot change, remediation becomes a commercial decision as well as a design task.

An automated scan can identify certain technical problems quickly and consistently. It is useful for catching regressions as a site changes. Its output is evidence about the checks performed, not a verdict on the entire customer experience.

W3C's evaluation guidance makes the limitation clear: tools need knowledgeable human evaluation. It also recommends evaluating during development and involving people with disabilities.

Build an evaluation around a small number of representative tasks, then expand the coverage according to the agreed scope. A useful initial review asks the team to:

• Complete the journey using keyboard navigation and inspect where focus moves.

• Increase text size and examine whether instructions and controls remain usable.

• Assess the structure, names and feedback with appropriate assistive technology.

• Trigger errors deliberately, then attempt to recover and finish the task.

• Check the same journey when content is longer or a usual assumption is missing.

These activities do not replace a full conformance assessment. They help reveal how technical findings connect to the experience of completing work.

Use people with the relevant evaluation skills. A colleague opening a screen reader for the first time may discover an obvious problem, but that exercise should not be presented as expert testing. Equally, one participant's successful experience cannot stand for everyone with a disability.

Record the conditions of each finding: the task, page state, input method and observed failure. Include enough detail for the team to reproduce it. A vague ticket saying the checkout is inaccessible is much harder to resolve than a description of the precise point at which a customer loses control.

An audit may produce a long list. The immediate challenge is to turn it into a repair plan without treating every finding as equivalent.

Start by understanding which barriers prevent essential tasks and which affect repeated components across the site. A defective shared navigation control may deserve a different response from an isolated content issue. Severity, reach and the availability of a workable alternative all matter.

A task that excludes some customers should not be assigned low priority simply because analytics show few completions from those customers. The barrier may be part of the reason the business sees little activity. Low observed usage is not proof of low need.

Group related findings where a common fix is possible. Correcting a shared form component can be more useful than patching individual pages while leaving the underlying pattern unchanged. The team should still retest each affected context, because the surrounding content and behaviour can introduce additional problems.

Assign an owner and acceptance evidence to each repair. For a third-party dependency, identify the supplier action required and the business's options if that action is unavailable. For content, give the editor guidance that prevents the issue from recurring.

Temporary assistance can help a customer complete urgent work while a repair is underway. It should be dependable and easy to find. It should also remain visible as a workaround with an owner, so the existence of a phone number does not quietly become the reason a digital barrier remains unresolved.

A repair is complete when the relevant behaviour has been checked again, not merely when the code has changed.

Accessibility changes when the product changes. A new campaign page, embedded widget, content upload or component release can reintroduce a barrier after a successful review.

Give routine contributors a manageable share of the responsibility. Editors should know how to structure content and describe meaningful images. Designers should assess interaction and visual decisions. Developers should preserve supported behaviour when changing components. The product owner should ensure that unresolved findings remain part of delivery planning.

Build repeatable checks around the journeys that matter most. Keep automated checks where they are useful and schedule human evaluation when a change warrants it. Retain the test conditions and known limitations so a future team understands what was actually examined.

Procurement should carry this learning forward. When replacing a form provider or choosing a customer portal, ask how accessibility is evaluated, how issues are reported and what control the business has over remediation. A supplier's broad assurance is less useful than evidence relevant to the service being purchased.

Our approach to design and software development is to make the intended task and its acceptance criteria explicit. Accessibility fits naturally into that discussion because it changes whether the intended customer can use the result.

Accessibility belongs in the definition of a working product. Treating it that way gives the business a practical place to begin: choose one important journey, examine it carefully and make its failures visible to the people who can fix them.