Prompt and context
Tell me about a time you found an accessibility problem that affected users or created launch risk. How did you confirm impact, drive the fix, communicate with the team, and prevent a repeat?
A strong answer tells one real failure or near miss rather than reciting WCAG clauses. WCAG 2.2 provides testable success criteria, while the GOV.UK Service Manual recommends automated, manual, and assistive-technology testing. Use those sources to explain your evidence, but do not turn one automated scan into a complete conformance claim.
What the interviewer is testing
The interviewer is looking for user-centered judgment, fast fact-finding, ownership, cross-functional coordination, and measurable improvement. They also want to hear how you handled launch pressure, competing priorities, and incomplete evidence, and whether you turned an individual rescue into a team mechanism.
Questions to clarify first
- Which users, critical task, devices, or assistive technologies were affected?
- Did you find it through user feedback, manual testing, automation, or a production signal?
- Was it already live, and was there an alternative path or urgent mitigation?
- Which teams owned design, code, content, testing, and launch decisions?
- What timing, success rate, blocked step, or regression data can you share?
- What did you personally own, and what did other people do?
A 30-second answer
“I would choose a specific case that shows impact and change. I first used the affected user’s task and evidence to define the problem, provided a usable short-term path, and made the risk visible. I then worked with design, engineering, testing, and product on priorities and retested with assistive technology and real users. After launch, I added checks, owners, and regression signals to the normal process. I would quantify the change in task success, complaints, or regressions and state any remaining risk instead of hiding it.”
Step-by-step deep answer
Step 1: Describe impact instead of applying a label
Explain which task failed for which device and assistive-technology combination. Replace “the button was not friendly” with “a screen-reader user could not identify the submit control, so checkout could not be completed.” Give reproduction steps, sample size, or user language. Do not infer severity or legal liability without evidence.
Step 2: Confirm quickly and limit harm
Reproduce the issue and record page version, browser, assistive technology, and success and failure paths. If risk is growing, propose disabling the affected flow, offering a human alternative, pausing release, or adding a clear notice. Explain how affected users learned about the change rather than leaving it in an internal ticket.
Step 3: Coordinate with shared language
Break the problem into design, semantics, keyboard behavior, focus management, content, testing, and release steps. Invite colleagues or users who rely on assistive technology. Discuss priority using tasks and evidence; do not make accessibility one expert’s private responsibility or end the conversation with “we will fix it later.”
Step 4: Make the fix verifiable
Name the smallest fix, owner, date, dependency, and stop line. Combine automated checks, manual keyboard review, screen-reader testing, and real-user testing; automation finds only part of the problem. If several flows are affected, repair high-frequency or irreplaceable tasks first and schedule the rest.
Step 5: Communicate trade-offs under pressure
Tell the launch owner the user impact, risk, mitigation, and cost of delay. If a complete fix cannot land before launch, provide a bounded alternative, public explanation, and date instead of hiding the issue. Record who approved what so “unfinished” is not confused with “risk accepted.”
Step 6: Validate with users
Ask affected users to complete the original task with real combinations such as keyboard, screen reader, magnification, or speech input. Record task success, completion time, errors, help requests, and feedback. If users still fail after the fix, acknowledge it and iterate; one green scan does not prove a usable experience.
Step 7: Put the lesson into the process
Add concrete rules to design review, the component library, acceptance criteria, CI checks, release checklists, and regression tests. Assign an owner and exception path for each rule, and keep a defect trend and user-feedback entry point. The next teammate should be able to execute the improvement without relying on your memory.
Step 8: Close with results and reflection
Use before-and-after data and name metrics that remain weak. Reflect on what your judgment, communication, or prevention mechanism missed; if you misjudged impact, say how you corrected it. End with the next action: broader coverage, component updates, training, or another round of user research.
Trade-offs and boundaries
Speed versus complete repair
Urgent mitigation protects users but does not replace root-cause repair. Give both an immediate containment step and a durable plan, with an owner and expiry so the temporary path does not become permanent.
Automation versus human validation
Automation enables fast regression checks, while manual keyboard and assistive-technology tests reveal context, focus, order, and actual usability. Record their coverage and evidence separately.
Standards versus lived experience
WCAG success criteria provide shared language, but passing a criterion does not guarantee every user task is smooth. Connect the criterion to a task, device, and user feedback instead of presenting only a conformance score.
Failure drills and evolution plan
Users still cannot complete the task
Observe the full task chain again, ask users where they are blocked, and inspect content, focus, and error recovery instead of rerunning a scan only. Increase the sample and update acceptance criteria.
The team blames a legacy component
Acknowledge the component constraint, then propose a short-term wrapper or alternative and a long-term component fix. Record scope, owner, and date so responsibility does not bounce between teams.
Launch pressure returns
Use the agreed stop line, risk record, and alternative path. If a risk-bearing launch is approved, name the approver, user notice, monitoring, and rollback criteria, then review whether the gate should be higher.
Common mistakes and follow-ups
Mistake 1: Saying only “I fixed an aria attribute”
Follow-up: Which user task was blocked, and how did you verify before and after? Name the task, assistive technology, and result.
Mistake 2: Treating an automated score as user evidence
Follow-up: What manual and real-user tests did you run? Which problems could the automated tool not find?
Mistake 3: Leaving accessibility to QA or one expert
Follow-up: What changed for design, engineering, content, and product? Explain shared ownership and process guardrails.
Mistake 4: Telling a team-conflict story without your action
Follow-up: What did you propose, drive, or change? What would have happened without your action?
Follow-up questions and responses
How do you decide whether to block a launch with incomplete evidence?
State known impact, unknowns, and temporary mitigation, then recommend a path using criticality, affected scale, alternatives, and repair time. An authorized owner approves it with monitoring, user notice, and rollback conditions; uncertainty is not presented as certainty.
How do you prove the process change worked?
Compare later defect regression, critical-task success, assistive-technology coverage, user feedback, and repair time. Continue sampled manual checks so a lower report count is not mistaken for improvement.
How should you answer if your first judgment was wrong?
Name the incorrect judgment, impact, and new evidence. Explain how you communicated with the team and affected users and encoded the correction in a checklist or process. Ownership and learning are stronger than blaming a tool.