Why this matters
Many suppliers say a website is accessible. Some mean it. Others mean they ran an automated scan and moved on.
You do not need to become an expert. You need a short set of checks that reveal whether accessibility is part of delivery, or a marketing line.
What to ask on the first call
- Which accessibility standard do you work to. WCAG 2.2 AA is a common target.
- Which pages and journeys will be tested, and how they choose them.
- Which manual testing is included, keyboard, zoom, and form behaviour.
- Which assistive technology is used for checks, and on which journeys.
- What the output looks like. Report, fixes, and retest evidence.
- Who owns accessibility decisions, and who signs off.
Evidence you should request
Ask for artefacts from a recent project. If they cannot show these, treat it as a risk.
- A sample audit report showing issues, severity, affected templates, and steps to reproduce.
- Examples of fixes, with notes on how they were tested after the change.
- A test plan showing which journeys were tested and why.
- An accessibility statement for their own website.
- One case study with measurable outcomes, such as fewer issues, faster journeys, fewer support tickets.
Red flags
- They rely on automated testing as the main proof.
- They recommend an accessibility overlay as a shortcut.
- They cannot explain keyboard testing, focus order, or focus visibility.
- They treat accessibility as optional or charge extra to do it properly.
- They avoid explaining what their report contains.
Quick checks you can do yourself
You can run these checks on any page in minutes. You do not need special tools.
- Use Tab to move through the page. You should reach all controls in a sensible order.
- Look for a visible focus indicator. If you cannot see where you are, it is a problem.
- Try the main navigation with keyboard only, including submenus.
- Trigger a form error. The error message should explain what to fix.
- Zoom to 200%. Content should remain readable and usable without sideways scrolling on typical pages.
What good looks like
- They describe a repeatable process, not a one-off effort.
- They show evidence from real work, not opinions.
- They test key journeys, not random pages.
- They prioritise issues by user impact and business risk.
- They retest after fixes, and provide proof of closure.
Next step
If you want an independent view, start with a short accessibility triage on your top journeys. You get a prioritised fix list and a practical plan.