Combine automated and manual work, because automated tools catch only around a third of issues. Run an axe based scan in CI for contrast, missing labels, and structure problems. Then manually test keyboard only navigation, focus order and visible focus, screen reader announcements, form error association, and zoom to 200 percent. Judge against WCAG 2.2 AA as the usual target.
Why interviewers ask this
Accessibility is increasingly a legal requirement rather than a nice to have, and interviewers want to know you have a real method rather than a plugin. The key admission is that automated scanners find a minority of issues, so manual keyboard and screen reader testing is mandatory. Naming a WCAG level as the acceptance standard shows you can define done rather than testing by feel.
How to structure your answer
- State the automated and manual split, with the honest coverage limit.
- Name what belongs in CI and what does not.
- List the manual checks, starting with keyboard only.
- Name WCAG 2.2 AA as the standard you test against.
- Mention involving users with disabilities where possible.
Example answer
I split it into automated and manual, and I am upfront that automation only catches roughly a third of real issues. The automated part is an axe based scan wired into the pipeline, which reliably catches contrast failures, missing alternative text, controls with no label, and broken heading structure, and it costs nothing per run. The manual part is where the actual problems live. First I unplug the mouse and do the whole critical journey on the keyboard: can I reach everything, is the focus indicator visible, does the order follow the visual layout, does focus get trapped in a modal, does it return sensibly when the modal closes. Then a screen reader pass, because that is the only way to know whether a custom dropdown announces as something meaningful or as an unlabeled div. I check that form errors are announced and programmatically tied to their field rather than just turning red. Then zoom to 200 percent and a narrow viewport so nothing gets clipped. I test against WCAG 2.2 AA so pass and fail are defined, and where the organization will support it I push for sessions with users who rely on assistive technology.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- Which screen reader and browser combination would you test with, and why?
- How would you test a custom component that has no native HTML equivalent?
- How do you convince a team to fix accessibility bugs that no customer has reported?
Related qa engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions