Show me your accessibility process

Why ask for process

Accessibility is not a one-off task. It is a delivery habit. A supplier with a clear process gives you predictable outcomes and fewer surprises [2]Source 2 .

These questions help you move from claims to evidence [2]Source 2 .

Questions to ask before you buy

Scope and standards

• Which standard do you work to, and which level [1]Source 1 .
• Which pages and journeys will you test, and how do you choose them [2]Source 2 .
• Which third-party tools, widgets, or payment flows are in scope, and which are not.
• What does success look like in plain language, not only in WCAG terms [1]Source 1 .

Design and build approach

• How do you design components so they work with keyboard and screen readers [1]Source 1 .
• What are your default patterns for navigation, modals, tabs, accordions, and form errors [1]Source 1 .
• How do you handle focus, especially when content opens and closes [1]Source 1 .
• How do you prevent layout shifts and interaction lag in the name of accessibility features.

Manual testing

• What manual keyboard testing is included, and on which journeys [2]Source 2 .
• Do you test on mobile as well as desktop [2]Source 2 .
• Do you test at 200% zoom and reflow [1]Source 1 .
• How do you test forms, including error messages and success states [3]Source 3 .

Assistive technology checks

• Which assistive technologies do you use for checks [2]Source 2 .
• Which components do you always test with assistive tech [2]Source 2 .
• How do you verify announcements for dynamic updates, such as validation and notifications [4]Source 4 .

Automation and tooling

• Which automated checks do you run, and at what stage [2]Source 2 .
• How do you prevent common regressions, such as missing labels or duplicate IDs.
• Do you run checks in CI, or only at the end.

Reporting and evidence

• What does your report include. Issues, severity, steps to reproduce, and suggested fixes.
• Can you show a sample report from a recent project, redacted if needed.
• Do you provide a prioritised fix list linked to user journeys.
• What evidence do you provide after fixes, and how do you confirm closure.

Retesting and ownership

• Is retesting included after fixes [2]Source 2 .
• Who signs off, and what does sign-off mean.
• What happens when content editors publish new pages later.
• Do you provide a regression checklist or training for content authors.

Answers that should make you pause

• We use an automated tool and it gives a score [2]Source 2 .
• WordPress is accessible by default [1]Source 1 .
• We add an overlay and that solves it [1]Source 1 .
• We aim for full compliance, without scope details [2]Source 2 .
• We do not retest, or retesting costs extra without clarification [2]Source 2 .

What good answers sound like

• Clear scope and journeys [2]Source 2 .
• Specific testing methods, keyboard, zoom, forms, dynamic components [2]Source 2 .
• Evidence from real work, sample reports and closure notes.
• A plan for preventing regressions after launch.

Next step

Use these questions on one supplier call. You will know within minutes whether accessibility is part of their delivery process or an add-on [2]Source 2 .