A booking form can look straightforward and still prevent someone from completing it. A date picker may require a mouse, an error may be communicated only through colour, or a timeout may erase information before a person has finished entering it. Accessibility examines those barriers as part of the product’s functioning.
The W3C’s introduction to web accessibility centres people with disabilities while recognising wider benefits. The work extends across content, interaction, implementation, and the technologies people use to access them.
Evaluate both the implementation and the experience
Technical checks can identify issues such as missing accessible names, insufficient contrast, or incorrect structure. Research with disabled participants shows how the experience works in the circumstances of use. These approaches complement one another: a small study cannot cover every requirement, and an automated scan cannot establish that the whole journey is usable.
The Web Content Accessibility Guidelines provide testable criteria organised around perceivable, operable, understandable, and robust content. Define the relevant standard and scope for an evaluation, then combine automated checks with appropriate manual assessment. Legal obligations vary by context and need their own verification.
For the illustrative booking form, this might involve keyboard operation, screen-reader output, zoom, focus behaviour, error recovery, and the time allowed to complete the task. Testing only the opening screen would miss barriers later in the journey.
Recruit for the experience being studied
People with the same disability may use different devices, settings, strategies, and assistive technologies. Plan recruitment around the product and research question, and avoid treating one participant as a representative of everyone with that disability.
Make the research itself accessible. Invitations, consent information, scheduling, test materials, and communication formats can all affect participation. Ask about access needs and allow people to use familiar arrangements where the study permits them.
A prototype may not expose the semantics or interaction behaviour of the eventual product. Be explicit about what its fidelity allows you to assess, and test the implemented experience when those details matter.
Follow the barrier through to a verified fix
Document what prevented progress, the relevant environment, and the consequence for the participant. “Could not select a date using the keyboard” gives a team more to investigate than “accessibility issue”.
Retest the fix and look for related occurrences elsewhere. A corrected control may share a pattern with many others, while a complete journey can still contain independent barriers. Accessibility is sustained through those design and development decisions, with research helping the team understand the human consequences of getting them wrong.