Why pre-screen accessibility consultants before the engagement
Automated accessibility tools catch a minority of the barriers real users hit, and they produce a long report that looks like thoroughness. A keyboard trap in a modal, a form error announced to nobody, a control that a screen reader reads as a blank button: those need a person who knows how the technology behaves. The other half of the job is getting a development team to act on findings under deadline pressure. A short screen tests both.
What actually matters when screening Digital Accessibility Consultant candidates
- 01
Technical depth
Check depth on WCAG 2.2 AA success criteria, ARIA authoring practices, and hands-on testing with JAWS, NVDA, VoiceOver plus axe DevTools or ANDI.
- 02
Real incidents and findings
Probe actual audits shipped: VPAT or ACR authoring, ADA Title II or EN 301 549 conformance reviews, mobile app audits, defect counts and severity ratings.
- 03
Risk judgement
Assess how they triage: which barriers block task completion for keyboard or AT users versus cosmetic gaps, and how legal exposure shapes remediation priority.
- 04
Getting things fixed
Look for evidence they got fixes merged: pairing with developers on focus management, design system component remediation, accessibility acceptance criteria in tickets, training sessions delivered.
Pre-screening questions to ask Digital Accessibility Consultant 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.
Manual audits
4 questions01Have you conducted accessibility audits? If so, what is your process?
Listen forA manual pass through key journeys with keyboard and screen reader, and how findings are written so a developer can act.
Audit process that is running a scanner and exporting results, or findings with no reproduction steps.
02How do you approach evaluating the accessibility of a website or application?
Listen forEvaluation organised around user journeys rather than page-by-page checks, with focus order and error handling covered.
Evaluation reduced to a criterion checklist, or dynamic components never tested with a keyboard.
03What tools and software do you typically use for accessibility testing?
Listen forAutomated tools used as a first pass, named alongside the screen readers and browsers they test pairings with.
Tools listed with no assistive technology among them, or one browser tested and results generalised.
04Can you describe the automated accessibility testing tools you use, and how you handle their limitations?
Listen forClear awareness of what scanners cannot detect, with examples of barriers only manual testing surfaces.
Automated coverage treated as sufficient, or a clean scan reported as an accessible product.
Testing with real users
3 questions05What is your experience with user testing, particularly with people who have disabilities?
Listen forSessions run with people who use assistive technology daily, with participants paid and something learned that a checklist missed.
Testing simulated by the consultant closing their eyes, or no sessions with actual assistive technology users.
06What techniques do you use to ensure content is accessible to screen readers?
Listen forSemantic markup preferred over attributes bolted on, with an example of a fix that removed markup rather than adding it.
Accessibility attributes added everywhere as a default, or reliance on markup that has never been tested aloud.
07How do you address the needs of users with a wide range of disabilities?
Listen forCognitive, motor and low vision needs covered concretely, not only screen reader users, with an example for each.
Accessibility treated as screen reader support alone, or cognitive accessibility mentioned with no practice behind it.
Findings that got fixed
3 questions08Describe a situation where you identified and addressed accessibility issues in a digital project.
Listen forA specific barrier found, the fix that shipped, and confirmation that it was retested after the change.
Issues identified with no evidence anything shipped, or fixes never verified after deployment.
09How do you prioritise accessibility issues when working on a project with tight deadlines?
Listen forPrioritisation by whether the barrier blocks a task entirely, with a defensible line between now and next.
Every issue marked critical, or prioritisation by how easy something is to fix rather than user impact.
10How do you integrate accessibility reviews into the development lifecycle?
Listen forChecks placed in design and code review rather than an audit at the end, with what they added to a team's process.
Accessibility handled entirely as a pre-release audit, or no involvement before something is already built.
Prioritising honestly
2 questions11Can you describe your experience with digital accessibility standards such as WCAG, Section 508 and equivalent regulations?
Listen forCriteria applied to real findings, with an honest view on where conformance and genuine usability diverge.
Standards recited by number with no application, or conformance treated as proof the product is usable.
12Can you explain a time when you had to educate stakeholders on the importance of digital accessibility?
Listen forA case built on users and risk together, with a specific stakeholder who changed a decision because of it.
Advocacy that leans only on legal threat, or education described with no decision that changed.
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 name/role/value failures, and describes real screen reader behaviour differences across NVDA and VoiceOver.
Real incidents and findings
30%5Walks through named audit engagements with issue volumes, sampling methodology, and how findings mapped to a published conformance report.
Risk judgement
20%5Separates blocking barriers from minor defects using user impact evidence, and defends prioritisation calls against both engineering cost and litigation risk.
Getting things fixed
15%5Names components or patterns rewritten with their input, plus mechanisms (linting, CI checks, design system rules) that stopped regressions returning.
Automated tools catch a minority of real barriers and produce a report that looks thorough. A one-way video screen asks what they found by hand and what got fixed.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for an accessibility consultant take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish how they audit manually, check their assistive technology experience, and hear one set of findings that actually got fixed.
Should I ask for a sample audit?
Yes, redacted. It shows immediately whether findings are automated output pasted into a document or a tester's account of what broke, with the user impact and a concrete fix for each one.
Evaluating answers
What is the strongest signal when screening an accessibility consultant?
Findings that were fixed. Consultants who get results write issues a developer can act on and follow them through. Anyone whose engagement ends at report delivery has produced a compliance document, not an accessible product.
How do I test assistive technology knowledge?
Ask which screen readers and browser combinations they test with and where behaviour differs. Real testers name the pairings and the inconsistencies. Anyone who names one tool and no differences has not tested much.
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
