When this helps
You need to understand accessibility issues in selected pages, components or journeys. Agree the sample and evaluation methods before treating a report as evidence about the wider service.
What you receive
A documented sample and method, reproducible findings, relevant criteria, recommended corrections and a separately scoped retest.
Agree a meaningful sample
Pages alone do not describe coverage. A navigation menu, invalid form, confirmation message and expanded disclosure can expose different barriers on the same URL. We document the templates, interaction states, devices and methods included, alongside anything excluded or unavailable.
Automated checks can identify some detectable problems. Manual checks examine keyboard operation, visible focus, structure, accessible names, contrast and other agreed criteria. Assistive-technology checks and research with disabled participants need explicit coverage and the appropriate expertise; they must not be implied by a general audit label.
Make the report reproducible
Each finding describes the affected component, the steps to reproduce it, the observed result and the intended correction. Where a criterion applies, the report identifies it and explains the relationship rather than attaching a standards label without context. Screenshots support the explanation but do not replace a text description.
A developer should be able to reproduce the problem and understand the acceptance check. Retesting is scoped against the corrected implementation, with unresolved items and changed assumptions recorded. A fix in one component should be checked in the other places that use it.
Evaluation and compliance questions
We discuss the evaluation scope and the evidence it can provide. Legal applicability, procurement requirements and formal conformance claims require the relevant assessment and context. We do not offer a blanket compliance guarantee or imply that passing an automated scan makes a service accessible.
The W3C introductory checks explain why a preliminary review is only a starting point. Our own accessibility information states the checks and limits of this website.
How the engagement runs
- Discuss what you need to learn, who uses the service and what you already know.
- Agree the research activities, access requirements, deliverables and what is included in the proposal.
- Carry out the research and explain both what we observed and what we think it means.
- Walk your team through the findings, prioritise improvements and agree what needs a follow-up check.
Cost and timing
Templates and states, keyboard interactions, documents, assistive-technology coverage and specialist participation. The proposal states the scope, fee basis and dependencies. Recruitment, stakeholder availability or access to a test environment can affect the calendar; no fixed turnaround is assumed before these are understood.
What to bear in mind
Automated tools and sampled checks do not establish whole-site conformance. A report must describe the coverage and limitations.
Your team receives recommendations it can discuss and implement with its chosen supplier. Where another method would answer the question better, we explain why before proposing additional work.