Buyer brief
What should an accessibility assessment actually cover?
Define the critical journeys, representative sample, test methods and finding format before buying an accessibility assessment. Agree remediation and retesting separately.
Discuss your QA scopeShort answer
A useful assessment brief names the tasks, sample, criteria and methods, then asks for reproducible findings and a clear statement of what was not tested.
Best for
- Teams procuring an assessment before a rebuild or release.
- Product owners who need actionable findings and a retest plan.
Outside this guide
- Treating one automated score as evidence for the whole website.
- Buying a legal certification from a technical checklist.
Compare the options
Use this as a procurement checklist, not a test result.
Complete sign-in, form, payment or document tasks as relevant
Checking the homepage alone
Automated checks plus agreed keyboard and assistive-technology evaluation
Treating a scanner score as conformance
Impact, steps, environment, criterion and recommended action
An unprioritized list of tool warnings
Fix owner, retest sample and unresolved issues
Assuming fixes are included
Where Wavect lands on this
Start with the people and tasks. Include page templates, interactive states, error paths, mobile layouts and documents that a task depends on. A sample gives evidence about the tested scope; it does not establish that every page is accessible. Ask which browsers and assistive technologies will be used and who has the expertise to interpret the result.
W3C WAI explains that tools alone cannot determine accessibility . WCAG 2.2 provides testable criteria. Agree the target and evaluation scope; a technical assessment is not a legal opinion. Sources checked 19 October 2026.
Illustrative finding: a keyboard user opens a dialog but cannot reach its close control. Record the page and state, browser and keyboard steps, user impact, expected focus behavior, observed behavior, relevant criterion and proposed repair. Retest the complete task after the fix, including whether focus returns sensibly. This is a synthetic example, not an audited customer page.
Discuss the scope through Software QA and use the launch checklist for wider release risks. Specialist delivery capability, remediation and retesting must be confirmed before commissioning.
Build a sample around tasks and states
Write down a complete journey such as finding a service, completing an enquiry and understanding a validation error. Then include the templates and states that journey touches: navigation, a modal, an empty result, a failed submission and confirmation. Add representative documents and third-party components when they are required to finish the task. A page list alone can miss the interaction where a user gets stuck.
State why the sample is representative and what it excludes. Repeated templates, language versions and mobile layouts can behave differently. Record the browser, device, assistive technology and test date so a finding can be reproduced. Do not infer that an untested page passes because it shares a header with a tested page.
Turn the dialog example into a repairable finding
A useful finding says where the dialog is opened, how keyboard focus reaches it, which control becomes unreachable and what the user cannot complete. Include the reproduction steps, expected behavior, observed behavior, relevant criterion and supporting evidence. Distinguish the user impact from a project priority: a release team still needs to agree sequencing and ownership.
After a repair, repeat the original steps and adjacent states. Check opening, interaction, closing and the return to a useful place in the page. Retesting only the changed button can miss the same failure in another dialog state. Keep the original finding, repair reference and retest result together.
Ask for a result your delivery team can use
Require an issue register, a tested-scope statement, method and environment details, and a handover discussion of unresolved items. Agree how findings become implementation tickets and which repairs require specialist interpretation. Commissioning an assessment, fixing a component and verifying the repair are related but separately accountable tasks.
Where this usually goes wrong
- A crawler checks public pages but never reaches an authenticated form or its error state. Include access and test accounts in the agreed preparation.
- A report groups every warning under one severity without explaining who is blocked. Require task impact and reproducible evidence for prioritization.
- Repairs change the design system but nobody retests other instances. Agree a representative regression sample as well as the originally reported page.
The checklist
Use this to prepare your scope.
- List critical journeys, representative pages and documents.
- Agree criteria, browsers, devices and assistive technologies.
- Identify qualified evaluators and required user participation.
- Require findings with impact, reproduction steps and scope limits.
- Agree who fixes issues and how changes are retested.
- Name the person accepting the report and the person assigning repairs.
- Specify access to authenticated journeys and third-party components.
- Require an issue register linking original findings to repairs and retest results.
What this looks like in our work
MyMerch provides adjacent storefront-improvement context, not evidence of an accessibility conformance audit.
These are selected projects, not our full portfolio. We have shipped 75+ products since 2018.