Why pre-screen accessibility auditors before the interview
An automated tool will return a long list of contrast and label failures and miss the fact that a checkout cannot be completed with a keyboard. That gap is the whole discipline. Auditors worth hiring test manually with a screen reader, work through the flows that matter, and write findings a developer can act on. A short screen asks what a scan would have missed on their last audit.
What actually matters when screening Accessibility Auditor candidates
- 01
Technical depth
Check depth on WCAG 2.2 AA success criteria, ARIA authoring practices, and hands-on testing with NVDA, JAWS, VoiceOver, TalkBack, plus keyboard-only and zoom reflow checks.
- 02
Real incidents and findings
Probe actual audits shipped: sample sizes, page or component counts, VPAT and ACR documents authored, remediation reports, and any Section 508 or EN 301 549 conformance work.
- 03
Risk judgement
Assess how they triage findings: distinguishing blocking barriers for screen reader users from cosmetic contrast misses, and weighing legal exposure under ADA Title III or accessible Canada rules.
- 04
Getting things fixed
Look for evidence they drove fixes: pairing with developers on focus management, writing acceptance criteria into Jira, running design system audits, and retest verification cycles.
Pre-screening questions to ask Accessibility Auditor candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Audits on real products
3 questions01Can you describe a project where you identified and resolved accessibility issues?
Listen forA real product with specific barriers found, and evidence that fixes were released.
Audits described by findings count, or no knowledge of whether anything was fixed.
02What experience do you have auditing large or complex applications?
Listen forScope decided by the user flows that matter rather than page count, with the sampling approach explained.
Every page audited identically, or scope decided without reference to what users do.
03What methods do you use to test accessibility in a mobile application?
Listen forNative platform testing with the built-in screen readers, not web techniques applied to an app.
Mobile testing described as responsive checks, or no experience with native accessibility APIs.
Manual and assistive
4 questions04What role do assistive technologies play in your testing?
Listen forScreen readers used competently on more than one platform, with the differences understood.
Assistive technology mentioned but not used, or testing limited to one browser and reader.
05What is your experience with automated compared with manual testing?
Listen forA clear view of what automation catches and what it cannot, with manual testing as the main method.
Findings that all come from a tool, or automation treated as sufficient coverage.
06Why does keyboard accessibility matter, and how do you test for it?
Listen forFull journeys completed by keyboard, with focus order, traps and visible focus checked.
Keyboard testing limited to tabbing through a page, or focus visibility not checked.
07Describe your experience with accessible rich internet application attributes.
Listen forUsed sparingly and correctly, with a preference for native elements over added attributes.
Attributes added liberally, or no awareness that incorrect use makes things worse.
Prioritised by impact
2 questions08How do you prioritise accessibility issues when conducting an audit?
Listen forPrioritised by whether a person can complete the task, not by conformance level alone.
Findings ranked purely by success criterion level, or all issues reported as equally urgent.
09How do you incorporate feedback from people with disabilities into your audits?
Listen forTesting with disabled participants where possible, treated as evidence rather than a formality.
Audits based entirely on guidelines, or no contact with the people affected.
Fixes that shipped
3 questions10How do you document and communicate findings to a development team?
Listen forReproduction steps, affected users and a suggested fix, written so a developer can act immediately.
Reports that cite criterion numbers, or findings developers routinely push back on.
11What strategies do you use to advocate for accessibility within a team?
Listen forAccessibility built into design and definition of done, rather than audited at the end.
Advocacy described as awareness sessions, or involvement only after a release.
12What difficulties have you faced during an audit, and how did you handle them?
Listen forReal obstacles such as no test environment or a component library nobody owns, with the workaround.
Difficulties described as team resistance, or no obstacle they worked through.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical depth
35%5Cites specific success criteria by number, explains ARIA name/role/value failures, and describes real differences between NVDA and VoiceOver behaviour.
Real incidents and findings
30%5Walks through named audits with issue counts, severity breakdowns, and conformance statements they personally signed off and defended.
Risk judgement
20%5Ranks defects by user impact and legal risk, and explains when a documented alternative conformant path is acceptable.
Getting things fixed
15%5Shows closed-loop remediation with retest evidence, and describes teaching engineers patterns that stopped issues recurring.
A scan finds contrast failures and misses a checkout that cannot be completed with a keyboard. A one-way video screen asks what theirs missed.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish audits they ran, test their manual and assistive technology practice, and hear what got fixed.
How much should standards knowledge count?
It is the floor, not the job. Anyone can cite a success criterion. What matters is testing flows with assistive technology and knowing which failures actually block someone.
Evaluating answers
What is the strongest signal when screening this role?
What automated testing would have missed. Auditors who test properly answer instantly with a broken flow. Anyone whose findings all come from a tool is exporting a report.
How do I judge whether their findings get fixed?
Ask how they write up an issue. Real answers include the reproduction steps, the affected user and a suggested fix. Anyone who reports a criterion number gets ignored by developers.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
