Why pre-screen front-end accessibility experts before the technical interview
The common failure is over-application. A developer learns that accessibility attributes help, adds them everywhere, and produces markup that a screen reader announces as nonsense while every automated check passes. The fix is usually less code rather than more, using elements the browser already handles. Experts know this and can name a case where they deleted markup to fix a problem. A short screen surfaces that instinct, which a scanner never will.
What actually matters when screening Front-End Accessibility Expert candidates
- 01
Technical proficiency
Check depth on WCAG 2.2 AA success criteria, ARIA authoring practices, focus management, roving tabindex, and hands-on testing with NVDA, JAWS, VoiceOver and keyboard-only flows.
- 02
Systems and trade-offs
Probe how they weigh remediation against redesign in a component library, when to ship a documented known issue in a VPAT, and how they handle third-party widgets.
- 03
Evidence and rigour
Assess how they verify fixes: axe-core or Pa11y in CI, manual audit scripts, assistive technology test matrices, and usability sessions with disabled participants.
- 04
Collaboration and communication
Look for evidence of upskilling designers and developers, writing accessibility acceptance criteria, and negotiating with product owners or legal on Section 508 or EN 301 549 exposure.
Pre-screening questions to ask Front-End Accessibility Expert 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.
Interfaces they built
3 questions01Can you discuss a project where you improved accessibility during front-end development?
Listen forSpecific barriers fixed in code that shipped, with confirmation they were retested after the change.
Improvements described as audits delivered, or fixes recommended but never implemented by them.
02What is your level of experience with HTML, CSS and JavaScript for accessible content?
Listen forReal depth including focus management and how CSS choices affect what assistive technology announces.
Accessibility knowledge that is separate from their coding, or no awareness of how styling can hide content.
03Can you discuss a particular challenge you faced in making a site accessible and how you solved it?
Listen forA genuinely difficult component such as a custom widget or a complex table, with the approach they settled on.
Challenges described as convincing stakeholders only, or no technically difficult case they can name.
Semantics over attributes
4 questions04Do you have a clear understanding of semantic markup and how it relates to accessibility?
Listen forA strong preference for native elements, with a case where they removed markup rather than adding to it.
Semantic elements treated as interchangeable with styled containers, or headings chosen for appearance.
05What knowledge do you have about accessibility attributes and their proper use?
Listen forClear awareness that these attributes override what the browser provides and are often the wrong first answer.
Attributes added by default to be safe, or roles applied to elements that already carry them.
06Can you explain the importance of keyboard accessibility in web design?
Listen forFocus order, visible focus and keyboard traps covered concretely, with a trap they found and fixed.
Keyboard access assumed to work, or custom controls built with no keyboard handling at all.
07Explain the importance of colour contrast in designing an accessible front end.
Listen forRatios known for text and interface elements, with a case where they pushed back on a brand colour.
Contrast treated as a design preference, or brand colours accepted regardless of legibility.
Components and forms
3 questions08How do you approach developing accessible forms and interactive components?
Listen forLabels, error association and status announcements handled properly, with validation errors reaching a screen reader.
Errors shown visually only, or placeholders used in place of labels.
09How familiar are you with front-end frameworks and how they affect accessibility?
Listen forFramework-specific problems named, such as focus management after navigation or content updated without announcement.
Frameworks assumed to handle accessibility, or route changes that leave focus and announcements broken.
10What is your process for ensuring images, video and other media are accessible?
Listen forAlternative text written for purpose rather than description, with captions and transcripts treated as required.
Alternative text generated or duplicated from filenames, or decorative images given descriptions.
Tested with assistive tech
2 questions11Describe your experience using automated testing tools to test accessibility.
Listen forAutomated checks used as a first pass with clear awareness of the majority of issues they cannot detect.
A clean automated report treated as an accessible product, or no manual testing described.
12What experience do you have with assistive technologies and how they relate to your work?
Listen forSpecific screen reader and browser pairings tested, with inconsistencies between them described from experience.
One tool named with no differences noted, or no hands-on testing with a screen reader at all.
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 proficiency
35%5Cites specific success criteria by number, explains native HTML over ARIA, and describes real screen reader behaviour differences across NVDA, JAWS and VoiceOver.
Systems and trade-offs
25%5Argues trade-offs with cost, risk and user impact; fixes at the design system layer rather than patching individual pages repeatedly.
Evidence and rigour
25%5Treats automated scans as partial coverage, pairs them with manual and AT testing, and quotes defect counts or audit findings closed.
Collaboration and communication
15%5Describes turning audit findings into prioritised tickets developers accepted, plus training or documentation that reduced repeat issues across teams.
Attributes added everywhere pass every automated check and announce as nonsense. A one-way video screen asks about a fix that removed code.
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, with code links. Enough to establish what they built, test their markup instincts, and check whether they test with assistive technology.
How does this differ from an accessibility consultant screen?
This role builds rather than audits, so weight markup depth, component implementation and framework behaviour heavily. Audit methodology and stakeholder advocacy matter less here, because someone else usually raises the findings this person then fixes in code.
Evaluating answers
What is the strongest signal when screening this role?
A fix that removed code. Experts know that a native element usually beats a custom one with attributes added. Anyone whose fixes always add markup has learned the rules without understanding what they are for.
How do I verify assistive technology experience?
Ask which screen reader and browser pairings they test and where behaviour differs. Real testers name the combinations and the inconsistencies immediately. A single tool named with no differences means limited testing.
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
