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 Source 1 .
- 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 Source 8 Source 9 .
- 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 Source 3 Source 4 .
- 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 Source 5 Source 7 .
- 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.
Sources
- [1] W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Back to article
- [2] W3C WAI. Evaluating Web Accessibility Overview. Back to article
- [3] The A11Y Project. Should I use an accessibility overlay?. Back to article
- [4] Scope. Why accessibility overlays and widgets do not improve your website accessibility. Back to article
- [5] W3C. WCAG 2.2, Guideline 3.3 Input Assistance. Back to article
- [6] W3C WAI. Forms tutorial. Back to article
- [7] GOV.UK Design System. Error message component. Back to article
- [8] GOV.UK. Make your website or app accessible and publish an accessibility statement. Back to article
- [9] W3C WAI. Accessibility Statement Generator. Back to article