Prompt and context
The company wants core workflows to work for keyboard users, screen-reader users, people with low vision, and people with cognitive disabilities. Feedback covers contrast, focus order, form errors, and dynamic status, but there is no shared baseline. Design a two-quarter plan from users and standards through audit scope and release governance.
What the interviewer is testing
The interviewer is looking for product decisions that turn “compliance” into user outcomes. A strong answer separates WCAG success criteria, legal applicability, and product experience, and does not treat an automated scan as completion. WCAG-EM asks evaluators to define scope, representative pages, and test environments; Digital.gov advises product managers to include accessibility in requirements, research, design, and acceptance.
Clarifying questions to ask first
Users and critical tasks
Confirm affected users, regions, and assistive technologies, then list sign-in, creation, export, payment, and other critical tasks. Prioritize task blockage and affected users, not defect counts alone.
Standard and ownership
Confirm WCAG 2.2 AA or a contract-specified version, applicable Section 508 or local law, and owners for product, design, engineering, QA, legal, and customer communication.
Current state and delivery constraints
Check the design system, component library, automated tests, manual-test budget, and customer deadlines. The roadmap must handle both new-feature gates and legacy-page debt.
30-second answer framework
“I start with target users, critical tasks, and the applicable standard, then establish a baseline using representative pages and assistive technology. I prioritize issues that block sign-in, forms, navigation, errors, or status feedback, and add accessibility acceptance to the Definition of Done for new work. Success includes task completion, keyboard and screen-reader defect closure, manual audit pass rate, and complaint trends. Automated scanning is triage, not proof. After two quarters, the product keeps a governance mechanism rather than a one-time report.”
Step-by-step deep answer
Step 1: Define scope and outcome
Break “the whole product” into users, page templates, critical tasks, and the target standard. Commit first to completing critical workflows, then expand to low-traffic pages; record out-of-scope risk.
Step 2: Establish an evidence baseline
Select representative pages and states, combining automated scans, keyboard walkthroughs, screen readers, zoom, contrast checks, and user interviews. Record criterion, environment, reproduction, impact, and severity instead of screenshots without consequences.
Step 3: Rank blocking risk
Prioritize inability to sign in or submit, lost focus, unannounced errors, silent dynamic status, and unadjustable time limits. Treat legal or contract dates as constraints, not as the sole substitute for user impact.
Step 4: Plan design and engineering changes
Fix shared components and design tokens before page exceptions. Add keyboard behavior, visible focus, accessible names, error association, and status announcements; require new code to pass lint, automated checks, and manual sampling.
Step 5: Put acceptance into delivery
Add user tasks and success criteria to requirements, inspect interactions in design review, and run automated and manual tests in pull requests and staging. High-risk work needs accessibility sign-off; an exception has an owner and expiry date.
Step 6: Define metrics and communication
Track blocking defects, time to repair, regressions, manual-audit coverage, complaints, and support tickets by task, assistive technology, and release. Publish scope, known limits, and a feedback route instead of claiming “fully accessible” beyond the evidence.
Step 7: Govern continuously
Sample audits quarterly, refresh component baselines and training, and review new browsers and assistive technologies. Put accessibility debt into product planning and risk review so budget, owners, and escalation remain after the roadmap.
High-quality sample answer
I would set a two-quarter goal of completing sign-in, core forms, navigation, errors, and dynamic status with the target assistive technologies, then expand page coverage. In week one I would confirm WCAG 2.2 AA, legal and contract boundaries, and create a baseline from representative templates and tasks using automated scans, keyboard, screen reader, zoom, and user feedback.
Prioritization would use task blockage, affected users, and repair leverage rather than scanner count. I would fix shared components first and add acceptance gates to new work; high-risk exceptions need an owner and expiry. Weekly metrics cover blocking defects, repair time, regressions, manual coverage, and task completion; monthly customer communication states supported scope and limits. The deliverable is durable governance, not a one-time “scan passed” report.
Common mistakes
- Mistake: Treating a 100% automated scan as conformance. → Why it fails: Scanners miss keyboard order, semantic experience, and task blockage. → Fix: Combine automation with manual, assistive-technology, and user testing.
- Mistake: Ranking by defect count rather than task impact. → Why it fails: Many small issues can hide one sign-in blocker. → Fix: Score critical tasks, affected users, and repair leverage.
- Mistake: Fixing only new pages. → Why it fails: Shared failures repeat across workflows. → Fix: Repair the design system and components before page exceptions.
- Mistake: Promising “fully accessible” externally. → Why it fails: Standards, assistive technology, and untested scope change. → Fix: Publish support scope, evidence, limits, and feedback channels.
Follow-up questions and answers
Follow-up 1: If capacity covers one class of issues, what do you choose?
Choose a shared issue blocking the most critical tasks, such as keyboard submission or perceivable errors. Explain the tradeoff with user evidence, contract dates, and repair scope, and register the remaining risk for the next quarter.
Follow-up 2: What if engineering says manual audits are too slow?
Use automation for repeatable triage and focus manual time on high-risk templates and real tasks. Run component fixes and sampling in parallel, then show value through discovery rate, regression rate, and task completion rather than arguing manual versus automated.
Follow-up 3: Does WCAG conformance equal legal safety?
No. WCAG is a technical standard; legal scope, contract duties, and interpretation have separate boundaries. Legal should confirm obligations while the standard and user evidence guide product priority.
Follow-up 4: How do you prevent regression after the roadmap?
Make component baselines, PR checks, manual sampling, quarterly audits, owners, and exception expiry part of normal delivery. New work cannot enter stable release without the accessibility gate unless an approved remediation date exists.