From identified barriers to verified fixes
I start with the actions people need to complete and the ways they use the product. Tests connect each obstacle to its impact and the fixes to verify. I personally lead the specialist discussion; the appointed team implements the changes.
- What you receive
- Scope, evidence, priorities and the status of fixes for activities included in the engagement.
- How you work
- With a specialist contact and your product contacts, sharing decisions and limitations.
Five steps, with clear outcomes
The steps can be adapted to the project. Retesting and support are defined in the engagement, not assumed to be included in every assessment.
- 01
Understand the product
I define goals, journeys and constraints with you. We agree on pages, components, content, environments and excluded activities.
Agreed scope and activities
- 02
Assess the journeys
I combine automated checks, manual tests and assistive technology. Each finding includes evidence, reproduction steps and a technical reference.
Findings with reproducible evidence
- 03
Set priorities
I assess impact, frequency and dependencies. The team receives a prioritised list to decide which issues to address.
Prioritised list of actions
- 04
Support the people fixing issues
I clarify findings and discuss solutions with design and development where agreed. Your team implements changes and provides the version for assessment.
Agreed solutions, if support is included
- 05
Reassess
Retesting checks fixes against the agreed findings. It records the result, environment and unresolved areas, distinguishing a verified fix from a change that has only been reported.
Correction outcomes, if retesting is included
Designing with people and contexts in mind
Accessibility focuses on barriers experienced by people with disabilities. Inclusive design also considers the variety of contexts and modes of use.
Different ways of perceiving and interacting
Keyboards, magnification, screen readers, voice commands and touch interactions reveal different needs. In the agreed journeys, I assess controls, content and status messages.
Temporary difficulties and context
An immobilised hand, a noisy environment or a limited connection can change how someone uses a service. Considering these contexts helps identify requirements without replacing attention to disability.
Involving people
Technical assessments and research with people answer different questions. Participant involvement, objectives and arrangements for any usability testing require a dedicated, agreed activity; they are not implicit in an audit.
Evidence that can be revisited
Another team member must be able to understand the issue and repeat the test.
In the report
URL or screen, build, browser and assistive technology, action performed, observed result, impact and remediation guidance. Screenshots and recordings accompany the text where useful and authorised.
In the backlog
Identifiable findings, priorities and dependencies connect evidence to design and development work. Format and tools are agreed with your team.
In the retest
The result refers to the version and configurations tested. New content and subsequent changes may require further assessment.
What the results allow you to state
Transparency about scope is part of the deliverable.
Sample and coverage
We declare the pages, journeys, states and environments actually assessed. Results from a sample do not automatically demonstrate that the entire product is free of barriers.
Standards and decisions
Applicable references are selected according to the product and context. Documentation describes the assessments performed: it is not an absolute guarantee of conformance or a substitute for the owner's legal decisions.
See the method in practice
Let's define the work on your product
Describe the journey to assess and who will use the results. We will agree an initial useful scope.