Accessible web design makes content and tasks usable through different ways of seeing, navigating and interacting. Begin with 5 checks: keyboard operation, contrast, structure, alternatives and task recovery. These checks identify important barriers, but a brief checklist or automated score cannot certify an entire website.
What should designers and developers check together?
Define the journeys people need to complete. Reading a service description, selecting an option and submitting an enquiry require different interactions. Include the information and error states that support each journey. Accessibility should be considered in the content and design brief as well as the code. A technically labelled control can still be confusing if the user cannot understand what the task expects.
Test keyboard operation from the beginning. W3C’s Keyboard criterion explanation states that functionality should be operable through a keyboard interface, subject to its specific path-dependent exception. Move through the actual page without a pointer and try the intended task. Record unreachable actions, unexpected focus order and controls that appear interactive but cannot be operated through the expected keyboard route.
Keep the exception narrow. The keyboard guidance distinguishes a function requiring movement along a path from ordinary tasks that merely happen to use a pointer in the current interface. Do not use a drag interaction as a blanket reason to omit keyboard access to a business task. Ask what the user needs to achieve and whether another supported interaction can accomplish it.
Check contrast against the applicable criterion, not personal preference. W3C’s Contrast Minimum explanation describes requirements and exceptions for text and images of text. Use an appropriate measurement tool on the actual foreground and background combination. A colour palette can look attractive in a style guide while producing a weak label on a real page, especially where photographs or state changes alter the background.
Inspect every relevant state. A button may have readable default text but an unclear disabled or focused state. An error message may be visible only after invalid input. Include these states in the design review and distinguish the applicable requirements for each. Do not infer complete accessibility from checking a single screenshot or one high-contrast heading at the top of the page.
How do you test accessibility as a real user task?
Use headings to express the content hierarchy. W3C’s heading tutorial explains how browsers and assistive technologies use headings for organisation and navigation. Inspect whether the sequence reflects the page’s subjects. A heading chosen only because its default size looks right may create a misleading structure. Presentation and semantic rank should be considered together without being treated as the same thing.
Write image alternatives according to purpose. W3C’s image tutorial distinguishes information, decoration and function. A linked image should explain its action or destination, while purely decorative imagery should avoid unnecessary spoken clutter. Complex information may need a fuller text equivalent. Do not assume every image needs the same kind of description or that a file name provides a useful alternative.
Test forms through errors and correction. Ask whether the person can identify the expected information, understand a failure and continue without losing valid work. Keep instructions near the relevant task and avoid relying only on colour to convey a problem. The precise implementation should be checked against the applicable standards; this guide identifies the task to inspect rather than certifying an unspecified form.
Combine evaluation methods. Automated tools can find certain technical issues, while keyboard inspection and testing with relevant users can expose different barriers. Record the method and scope of each result. A clean automated report should not be described as proof that every task works for every person. Likewise, one successful user session does not establish that every page or state has been evaluated.
Make findings actionable. Give each barrier an affected task, reproduction steps, expected result and responsible owner. Retest the actual correction and record the remaining scope. Avoid a vague accessible label attached to a changing site without evidence of what was checked. Keep content updates and component changes within the continuing review process because later edits can introduce new barriers.
Add a content-update test to the accessibility card. Replace a fictional short heading with a longer approved heading and inspect whether the page remains coherent. Add an error message and test whether the person can find the relevant control and correct the input through the keyboard. Then inspect a functional image without relying on its visual appearance. These variations test the actual content states rather than a single polished example. Record which methods were used and which were not. An honest review can identify useful corrections while retaining limits; it should not expand a small test into a claim of complete compliance across every page, device, assistive technology and future update.
Decision worksheet
Original contribution: an accessibility journey-evidence card. Use a fictional enquiry page and record the task from arrival through confirmation. Inspect the same journey with keyboard operation, semantic structure review and relevant visual checks. Add an invalid submission and a meaningful image. For every finding, write the method used, the observed barrier, the expected behaviour and the retest result. Keep unchecked states explicit. The card prevents a single score from obscuring the difference between a verified correction and a part of the website that has not been evaluated.
| Checkpoint | Evidence to retain | Decision or corrective action |
|---|---|---|
| Keyboard | Complete task and focus observations | Repair unreachable actions |
| Contrast | Measured foreground/background combinations | Check actual component states |
| Structure | Heading sequence and content relationship | Align hierarchy with meaning |
| Alternatives | Image purpose and equivalent information | Avoid generic descriptions |
| Recovery | Invalid input and correction journey | Preserve a usable next step |
As a worked prioritisation exercise, compare a decorative spacing issue with a control that prevents submission through the keyboard. Record how each affects the task rather than prioritising solely by how conspicuous it looks in a screenshot. Then test the correction in context. A control made reachable can still have an unclear label or an unusable error state, so retain the complete journey as the acceptance unit. This makes accessibility review more precise without inventing a universal severity score.
See web development for implementation context and WordPress for one platform route. To discuss an accessibility brief, get started with a fictional journey and the evidence card.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.