Why pre-screen accessibility specialists before the live audit exercise
A pre-screen protects the time your panel spends on the live audit exercise. Applicants arrive from QA, front-end development, UX research and disability advocacy, and a resume cannot tell you whether they ran NVDA and VoiceOver themselves or only forwarded axe reports to engineers. Ten minutes of recorded answers shows whether they cite specific success criteria, describe the barrier a criterion removes, and know how a remediation ticket gets prioritised against a release deadline.
What actually matters when screening Accessibility Specialist candidates
- 01
Portfolio
Check the audits and remediations they have done, plus command of WCAG and hands-on assistive technology use.
- 02
Craft and rationale
Test whether they can explain why a criterion exists in terms of the barrier it removes for a real person.
- 03
Feedback and iteration
Assess how they respond when a design that passes automated checks still fails a screen reader user.
- 04
Working with the brief
Judge how they get designers and developers to build accessibly rather than remediating after launch.
Pre-screening questions to ask Accessibility Specialist 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.
Portfolio and tooling
4 questions01What is your previous experience in the field of accessibility, and which products or sites have you audited?
Listen forNamed products or services, the conformance target (for example WCAG 2.1 AA), and whether they wrote the audit report, fixed the code, or both.
Only general awareness training or policy writing, with no product, site or app they personally tested.
02Which adaptive technologies do you use hands on, and how do you test with them? Walk us through one session with a screen reader or voice recognition tool.
Listen forSpecific pairings such as NVDA with Firefox, JAWS with Chrome, VoiceOver on iOS, TalkBack, Dragon or ZoomText, plus how they check focus order and accessible names.
They name screen readers but cannot describe navigating by headings, landmarks or forms mode in one of them.
03Share an example of an accessibility issue you discovered and how you got it fixed.
Listen forA concrete defect (unlabelled icon button, keyboard trap in a modal, missing captions), the criterion it violated, the ticket they wrote, and the shipped fix.
A vague story where the issue is described but nobody ever fixed it and they cannot say why.
04What specific accessibility certifications or formal training do you have?
Listen forNamed credentials such as IAAP CPACC, WAS or CPWA, DHS Trusted Tester, or Deque University coursework, with dates and how they applied it.
Claimed certification with no issuing body, or training listed that they cannot connect to any real testing work.
WCAG and rationale
3 questions05What is your understanding of the Web Content Accessibility Guidelines, and how do you explain a criterion to someone who has never read them?
Listen forPOUR principles, the A, AA and AAA levels, awareness of 2.1 and 2.2 additions, and a criterion explained through the barrier it removes for a real user.
Reciting criterion numbers or listing four principles with no example of who is blocked and why.
06What is the most challenging accessibility problem you have faced, and how did you solve it?
Listen forA hard case such as a complex data grid, custom combobox, canvas chart or third party payment iframe, with the ARIA pattern or vendor escalation they used.
The hardest problem is adding alt text or fixing colour contrast, suggesting shallow exposure.
07What is your approach to accessibility testing and evaluation on a new release?
Listen forA layered method: axe or WAVE for the automatable subset, then keyboard-only traversal, a screen reader matrix, zoom and reflow checks, and testing with disabled users.
Automated scans alone, or a clean Lighthouse score treated as evidence of conformance.
Feedback and iteration
2 questions08How do you handle feedback from users when a design that passes automated checks still fails them?
Listen forThey reproduce the report on the user's stack, log it with severity and impact, respond to the person, and change their own test script so it catches that class of issue.
Defensiveness, or closing reports as invalid because the scanner or the spec technically passed.
09How do you ensure new and updated content stays accessible after the initial remediation?
Listen forCMS-level controls: alt text fields and authoring guidance, heading templates, caption and transcript workflow, editor training, and periodic sampling of new pages.
Treating accessibility as a one-off audit with no plan for content published next quarter.
Working with teams
3 questions10How do you communicate the importance of accessibility to stakeholders who see it as a cost?
Listen forA mix of legal exposure (ADA, Section 508, EN 301 549, European Accessibility Act), market reach, and one specific user story that lands with product owners.
Moral lecturing only, or an inability to translate the case into roadmap and budget terms.
11How do you build accessibility into every phase of the product lifecycle rather than remediating after launch?
Listen forDesign annotations and component reviews, acceptance criteria in tickets, axe-core or pa11y in CI, accessibility in the definition of done, and release gates for regressions.
Their process starts only after code is written, with no involvement in design or QA.
12How do you keep up with changes to accessibility standards and assistive technology?
Listen forNamed sources: W3C working drafts, ARIA Authoring Practices Guide, WebAIM articles, TPGi or Deque blogs, screen reader release notes, or a11y community channels.
No named source, or knowledge frozen at WCAG 2.0 with no awareness of 2.1 and 2.2 criteria.
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.
Portfolio
35%5Audits with real assistive technology, not just automated scanners, and knows WCAG criteria by their intent.
Craft and rationale
25%5Explains each requirement through the barrier it removes, and prioritises by user impact over conformance score.
Feedback and iteration
25%5Trusts real assistive-technology testing over passing scans, and can name an issue no automated tool would catch.
Working with the brief
15%5Shifts teams to build accessibly up front, with evidence of defects falling rather than audits repeating.
Accessibility work is spoken work: you need to hear a candidate narrate a screen reader session and explain a barrier to a sceptical developer. Async video captures both in one recording, before you book panel time.
Try it on HirevireScreening FAQ
Process basics
How many questions should an accessibility specialist pre-screen include?
Eight to twelve is enough, with three or four asked as recorded audio or video so you can hear them explain a defect out loud. Keep experience, tooling and certification answers short and typed. Reserve the recorded slots for the audit walkthrough, the WCAG rationale and the stakeholder conversation, which is where candidates separate fastest.
Should I require an accessibility certification such as CPACC or WAS?
Treat IAAP certifications (CPACC, WAS, CPWA) and Trusted Tester as useful signals, not gates. Certification proves they have studied WCAG, Section 508 and the ADA; it does not prove they can operate JAWS or write a remediation ticket a developer can act on. Ask for both the credential and a shipped example.
Evaluating answers
How do I tell a real practitioner from someone who only runs automated scanners?
Listen for manual testing detail. Practitioners name a device and screen reader pairing (NVDA with Firefox, VoiceOver with Safari on iOS), describe keyboard-only traversal, focus order and accessible names, and note that automated tools catch a minority of issues. Scanner-only candidates quote Lighthouse scores and issue counts with no user impact attached.
What does a strong answer about a WCAG success criterion sound like?
A strong answer starts with the person, not the number. They explain that 1.4.3 contrast exists because low vision and older users lose text on pale backgrounds, or that 2.4.7 focus visible exists so keyboard users know where they are, then cite the level (A, AA, AAA) and the version. Rote recitation without a barrier is weak.
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
