Accessible web design: build it into the brief

Start with the tasks people need to complete

Accessibility begins with a straightforward question: who could be prevented from doing what this website exists to support? For a professional services firm, the important tasks might be understanding the offer, reading a case study and sending an enquiry. For a venue, they might include comparing spaces, finding access information and requesting a date. Write those tasks into the brief. They make accessibility concrete enough to discuss alongside brand and commercial priorities.

Agree on a documented target, such as WCAG 2.2 Level AA, and define the pages, components and journeys included in the review. That target is a technical framework for the project; a claim of conformance requires a proper evaluation of its scope. A beautiful homepage does not tell you whether the booking service, downloadable brochure or form error messages work.

Give each part an owner. Designers address contrast, hierarchy and interaction states. Developers implement structure and behaviour. Content authors write useful headings, link labels and image descriptions. The business owner makes sure these responsibilities survive handover. When ownership is vague, accessibility issues tend to become someone else's unfinished work.

Build an expressive visual language people can read

A distinctive identity can have strong contrast, generous spacing and clear focus states. Begin with a small set of approved text and background combinations, then test them in actual components. A colour that works for a large display headline may fail when reused for a small caption. Photography, gradients and transparency make the effective background variable, so review the hardest visible combination.

WCAG's minimum text contrast criterion generally requires 4.5:1 for ordinary text and 3:1 for qualifying large text, with specified exceptions. Those are thresholds, not values to round up. The W3C explanation of text contrast sets out the details. Treat that as one part of the visual review: readable line length, useful spacing and a clear hierarchy also deserve attention.

Do not make colour carry the whole message. Pair a red form border with an explanation; pair an active filter colour with a visible state. Review hover, focus, selected, error and disabled states as deliberately as the default screen. For example, a subtle outline that disappears against a photograph is an incomplete interaction design, even when the original composition looks resolved.

Make the structure as clear as the surface

Visitors do not all explore a page by looking at it from top to bottom. A meaningful heading structure, navigation landmarks and descriptive controls provide other ways to understand it. Ask the team to demonstrate the page structure without its visual styling. The order should still make sense, and headings should describe the sections they introduce.

Keyboard use offers a useful practical review. Can someone reach the main content, open the navigation, follow a case study link and submit an enquiry without a mouse? Can they see which element is active? Do menus and dialogs behave predictably when opened and closed? WCAG's keyboard criterion requires functionality to be operable through a keyboard interface, with a limited exception for functions that depend on the path of movement.

Use links for destinations and buttons for actions. A project card can have an elegant visual treatment while still exposing a clear link name. Avoid repeated labels such as “Learn more” when the destination is unclear out of context. “Explore the restaurant project” tells a visitor something useful before they choose it. These small editorial decisions are part of the interface.

Treat content and forms as designed experiences

Images need an editorial decision, not an automatic description of every visible object. Ask what the image contributes in this context. A chart may need a short alternative and an explanation of its findings nearby. A purely decorative texture should not interrupt the reading experience. If the image contains essential words, consider whether those words belong in the page as actual text.

Forms deserve similar care. Give each field a persistent label, explain unfamiliar requirements before submission, and identify errors in words. Preserve valid answers when another field fails. A confirmation should make clear what happened and what the visitor can expect next, without pretending that an email was delivered merely because the button changed appearance.

Consider an enquiry form asking for a budget. A bare numeric field forces visitors to infer the currency and expected format. A labelled selection with an “I'm not sure yet” option may better support the conversation. That is a business and content choice as well as a usability choice. Test the actual form service, including validation and success states, because an accessible page shell cannot compensate for an unusable embedded form.

Use a review plan that combines evidence

Automated checks are useful for catching repeatable problems and preventing some regressions. They cannot decide whether every alternative description is appropriate or whether a complete task is understandable. W3C explicitly notes that evaluation tools cannot determine accessibility on their own. A clean scan is evidence from one method, rather than a certification.

For a meaningful review, choose representative templates and their difficult states. Include a long article, a busy listing, an empty search, a form with errors and an open menu. Ask an experienced reviewer to combine automated checks with keyboard testing and relevant assistive technology. Involve people with disabilities where possible, with clear tasks and fair compensation.

1. Record the page, task, browser and assistive technology used.
2. Describe the barrier and its effect on completing the task.
3. Assign an owner and a priority based on impact.
4. Fix the shared component when the issue repeats.
5. Retest the original scenario and related journeys.

The resulting issue log should explain what remains unresolved. That is more useful to a business owner than an unexplained percentage score.

Walk the complete inquiry journey at sign-off

Choose the task that matters commercially and test it without assuming a mouse. For an inquiry, start on a service page, locate the contact route, move through each field, make a deliberate error and recover from it. Check that the focus remains visible, field labels are persistent and the error explains what to change. Confirm that correcting one field does not erase the rest of the brief.

Then check what the final message actually means. Preparing an email draft, accepting a submission at the server and receiving the email are different events. The interface should describe the event it can verify. A confirmation that sounds reassuring but overstates what happened creates a usability problem for everyone.

Record obstacles against the task and the affected component, then retest the same journey after repairs. Add representative assistive-technology checks to the review plan rather than treating this keyboard exercise as complete conformance testing. The launch checklist connects those checks with delivery verification, and the motion guide covers interactions that need an alternative presentation.

Protect the work after launch

Accessibility can deteriorate through ordinary publishing. A new image arrives without context, a heading is chosen for its visual size, or a campaign introduces a third-party widget. Build guardrails into the content system: useful field labels, examples of good descriptions, constrained heading choices and reusable layouts that already handle responsive behaviour.

Give editors a short checklist tied to their own work. Before publishing, review heading order, meaningful link labels, image purpose, captions or transcripts where needed, and the page at a narrow width. Before adding a new tool, test its essential interaction. Schedule deeper reviews after significant changes, and provide an easy way for visitors to report a problem.

The quality to aim for is continuity. A visitor should be able to move from an inviting opening page through a detailed explanation to a working enquiry without encountering a different standard of care at each step. When the design system, code and publishing process support one another, accessibility becomes part of how the website is maintained and improved.