Digital Accessibility Consultant interview scorecard

Tool operator only; no understanding of the systems underneath.

Runs tooling but cannot explain findings or how the attack works.

Solid working knowledge; depth thins outside familiar tooling.

Strong command of the domain; explains attack and control chains clearly.

Cites specific success criteria by number, explains name/role/value failures, and describes real screen reader behaviour differences across NVDA and VoiceOver.

No hands-on work; knowledge is entirely certification or coursework.

Limited exposure; cannot describe their contribution to an incident.

Real casework with adequate detail; ownership sometimes vague.

Specific incidents with clear personal scope and what changed after.

Walks through named audit engagements with issue volumes, sampling methodology, and how findings mapped to a published conformance report.

Treats every finding as critical, or waves real risk through.

Follows severity scores mechanically; no business context.

Reasonable prioritisation; less confident arguing for risk acceptance.

Prioritises by exploitability and impact; can justify accepting a risk.

Separates blocking barriers from minor defects using user impact evidence, and defends prioritisation calls against both engineering cost and litigation risk.

Adversarial with engineering; findings never get fixed.

Reports are unactionable; no influence beyond raising tickets.

Adequate reporting; relies on mandate rather than persuasion.

Actionable findings and a real record of getting fixes shipped.

Names components or patterns rewritten with their input, plus mechanisms (linting, CI checks, design system rules) that stopped regressions returning.