Accessibility skills show up on an enormous number of frontend developer resumes now, "WCAG," "ARIA," "accessible components," listed alongside React and TypeScript as a standard bullet point. The gap between listing it and actually possessing it is unusually wide in this specific skill area, wider than for most other technical skills a resume claims, because accessibility is one of the few areas where a developer can write code that looks completely correct, uses the right terminology, references the right attributes, and still be functionally broken for the actual users it claims to serve, without anyone in a typical code review ever noticing.
Hiring managers evaluating this specific skill tend to default to questions that test vocabulary rather than practice: "what is ARIA," "what is WCAG AA," "name some accessibility best practices." These questions are easy to prepare for from a single blog post or a course completion certificate, and a candidate who has genuinely never tested a real interface with real assistive technology can pass them fluently. The question that actually separates real, hands-on experience from surface-level familiarity is narrower and much harder to fake convincingly: ask a candidate to describe, in specific detail, the last time they tested something with an actual screen reader, and what they found.
Why This Specific Question Works: Genuine hands-on accessibility testing produces specific, idiosyncratic memories, an unexpected announcement, a focus order surprise, a component that behaved differently than expected, that are extremely difficult to fabricate convincingly on the spot, unlike general terminology that can be memorized from documentation.
What a Real Answer Actually Sounds Like
Someone who has genuinely tested with a screen reader tends to describe something concrete and specific: a custom dropdown that announced its options but never announced which one was currently selected, a modal that trapped focus in a way they did not expect until they actually tried tabbing through it, a form error that displayed visually but produced total silence when they tried it with VoiceOver or NVDA running. They will usually mention which screen reader they used, often more than one, since different screen readers genuinely behave differently on the same markup, and they will often describe the fix they made and, notably, what they tried first that did not actually solve the problem, a level of specific, non-linear detail that is very hard to invent convincingly without having actually gone through it.
What a Rehearsed or Fabricated Answer Sounds Like
Candidates without real hands-on experience, even well-intentioned ones who have genuinely studied accessibility theory, tend to answer this question by falling back to general principles rather than a specific incident: "I always make sure to add ARIA labels," "I test with keyboard navigation," "accessibility is really important to me." These are not necessarily dishonest answers, but they answer a different question than the one asked. The interviewer asked for a specific real experience. An answer that stays at the level of general practice, without ever landing on one concrete tool, one concrete bug, one concrete surprise, is a reliable signal that the practical testing experience being described may not actually exist yet, regardless of how genuine the underlying interest in the topic is.
Why This Distinction Actually Matters for Hiring
This is not about gatekeeping or dismissing candidates who are newer to accessibility, who can be trained effectively and often become strong contributors once given real testing experience on the job. It is about accurately identifying, before an offer is made, whether a role that specifically requires accessibility experience is being filled by someone who already has it versus someone who will need to build it from scratch after starting. Both can be reasonable hiring decisions depending on the role and the team's capacity to mentor, but making that decision based on an accurate read of the candidate's actual experience, rather than a resume line that both candidates would have written identically, is the entire point of asking a better question.
This connects to a broader pattern covered in our piece on why accessibility specialist is one of tech's fastest-growing job titles: as demand for this specific skill set grows, the gap between genuine practitioners and resume-keyword matches grows with it, making a reliable screening method increasingly valuable for hiring teams trying to fill accessibility-focused roles accurately.
A Second, Related Question Worth Asking
A useful follow-up, once a candidate has described a real testing experience, is asking what they would test first on a page they had never seen before, given five minutes and no other context. A candidate with real practical instincts will usually name something specific and high-value: the primary form or checkout flow, keyboard operability of the main interactive component, whether focus is visible and moves logically. A candidate without that instinct tends to answer more generically, "I'd run an automated scanner first," which is not a wrong answer exactly, but is a notably different answer than one grounded in the understanding that automated tools only catch a portion of real accessibility issues, a distinction covered in more depth in our piece on why a perfect Lighthouse score still fails real users.
If your team is hiring for a role where real accessibility experience matters, this specific question, asked before any resume-review shortcut, is a more reliable filter than checking for the right keywords. Our team works with hiring managers building accessibility competency into their engineering interview process. Reach us at experts@wcag.world, or review the W3C's guidance on how people with disabilities actually use the web for grounding on what real testing experience is actually evaluating.
A practical review loop
Start with the task a person needs to complete, not with the score produced by a single automated scan. Write down the entry point, the expected focus order, the announcement a screen reader should receive, and the recovery path when something goes wrong. Then repeat that task with a keyboard and at least one assistive technology setup. This turns a vague accessibility concern into an observable acceptance test.
The useful evidence is specific. Capture the URL, the control label, the keystrokes, the browser state, and the expected result. Separate a defect from a design choice, and separate both from a limitation in the test environment. Give the product owner a short reproduction and a clear severity rationale. A developer can fix a named interaction. Nobody can reliably fix a general instruction to make a page more accessible.
Finally, put the check into the delivery process. Add the scenario to a pull request checklist, retest it after JavaScript changes, and keep a small set of representative pages available for regression testing. That routine protects the people who depend on the workflow and gives the team a defensible record of what was tested, when it was tested, and what happened.
For the next review, use these related resources: how to put accessibility on your resume, the referenced standard.
For the next review, use these related resources: request the relevant WCAG review.