How to handle accessibility in product design interview answers

Start with a real accessibility decision

Suppose you’re asked how to redesign a video player for a streaming platform. A tempting mistake is to mention 'add captions and keyboard support' without specifying why, for whom, or how you’d prioritize among competing needs. Instead, recognize that accessibility is not a checklist but a set of choices affecting user experience, compliance, and business outcomes.

For example, if your player lacks audio descriptions, screen reader compatibility, and adjustable color contrast, you must decide which to address first. The answer depends on understanding who is most impacted and how. Avoid jumping straight to implementation details—frame the accessibility challenge as a user problem, not a technical fix.

Segment users by accessibility needs

Accessibility is not one-size-fits-all. Segment users based on specific impairments—such as vision, hearing, or motor limitations—and consider situational limitations (e.g., users in noisy environments). For the video player, you might identify:

- Users who are deaf or hard of hearing and need captions. - Users who are blind and rely on screen readers or audio descriptions. - Users with low vision who benefit from high-contrast modes. - Users with limited mobility who depend on keyboard navigation.

This segmentation clarifies whose experience is most hindered by current barriers and helps prioritize changes that unlock the product for the largest or most underserved groups.

Prioritize by impact and feasibility

Once needs are identified, weigh the impact of each accessibility improvement against the effort required. For instance, adding high-contrast modes may be technically straightforward, but producing high-quality audio descriptions for thousands of videos could be resource-intensive.

In a time-constrained setting, explain your logic: 'Based on our user data (assumed for this exercise), 7% of our viewers rely on captions, while 0.5% require audio descriptions. Captions are also used situationally (e.g., watching in public), so the impact is broader. Therefore, I would prioritize robust caption support before audio descriptions.'

Explicitly call out assumptions and invite correction: 'If we learned that a significant portion of our audience is blind, I’d revisit this order.'

Make a specific product choice

Suppose you recommend prioritizing captioning. Articulate the tangible change: 'I would redesign the player to ensure captions are available for all content, can be toggled via keyboard shortcuts, and support multiple languages.'

Justify this with user and business reasoning: 'This addresses both regulatory requirements and a key user need, reduces legal risk, and benefits a broad segment, including non-native speakers.'

Be clear about what you are not prioritizing yet—such as full audio descriptions or advanced screen reader support—and why. This shows you recognize trade-offs and can defend them based on real constraints.

Discuss a competing option and trade-offs

An alternative is to focus first on screen reader compatibility, benefiting blind users. This has the advantage of making basic navigation accessible, but may serve a smaller audience initially.

Acknowledge the trade-off: 'While screen reader support is critical, our assumed data suggests captions benefit more users and help us meet imminent legal deadlines. However, omitting screen reader improvements risks excluding a vulnerable group.'

Demonstrate respect for both needs and explain how you’d mitigate the downside, such as planning a follow-up release or seeking external partnerships for screen reader enhancements.

Identify risks and validation steps

Every accessibility improvement carries risk—technical debt, missed needs, or unintended exclusion. For captioning, a risk is that auto-generated captions may be inaccurate, alienating users who rely on them.

To validate your decision, propose a practical experiment: 'We’d launch improved captions on a subset of content, recruit users who are deaf or hard of hearing (assumed available through advocacy groups), and collect feedback on accuracy and usability.'

If feedback reveals persistent errors or unmet needs, be ready to adjust—perhaps by investing in manual captioning or shifting focus to another barrier.

Weak reasoning versus strong reasoning

A weak answer says, 'Accessibility is important, so I’d add captions and screen reader support.' This lacks prioritization, ignores feasibility, and treats accessibility as a generic checkbox.

A stronger approach explicitly segments users, weighs trade-offs, and ties decisions to user outcomes and business context: 'Given our data and legal requirements, I’d prioritize captions for broad impact, while planning for screen reader support in the next phase. I’d validate with target users and revisit if our assumptions prove wrong.'

Strong reasoning shows deliberate choices, readiness to adapt, and respect for all users’ needs even when not everything can be solved at once.

Worked example: Video player accessibility

Let’s walk through the video player scenario in detail. Assume your platform has 10 million users. After segmenting, you estimate:

- 7% (700,000) regularly use captions (assumption: usage analytics) - 0.5% (50,000) rely on screen readers (assumption: industry benchmarks) - 1% (100,000) have low vision and benefit from high-contrast modes

Your team can deliver one major accessibility improvement per quarter. You must choose between:

- Adding captions to all videos - Launching full screen reader compatibility - Deploying high-contrast UI settings

Given the numbers, you recommend focusing on captions first. This maximizes direct impact (700,000 users) and also benefits users in noisy settings. The main risk is that captions are only as good as their accuracy. You propose piloting auto-generated captions, measuring user satisfaction, and setting a threshold: if more than 5% of users report errors, invest in manual correction.

If, after rollout, feedback from blind users (screen reader segment) indicates major usability barriers persist, you’d escalate screen reader improvements for the next quarter. If caption uptake is lower than expected or legal requirements change, you’d adjust priorities accordingly. This approach demonstrates clear reasoning, explicit assumptions, and a plan for gathering evidence to refine your choices.

Self-review and practice strategies

Practice answering accessibility scenarios under time pressure. Use a timer and give yourself five minutes to read, segment users, prioritize, and defend one specific change. Afterwards, check if you:

- Identified distinct user needs - Prioritized based on impact and feasibility - Articulated a concrete product change - Addressed a trade-off and explained your reasoning - Proposed a way to validate or adjust your decision

A realistic cadence is to run two practice cases per week, reviewing your answers against this checklist. PMMockr can provide scenario prompts, but self-assessment is key: aim for clarity, specificity, and reasoned trade-offs in every answer.

FAQ

How detailed should my accessibility answer be in a short interview?

Focus on identifying main user segments, explaining your priorities, and proposing one concrete improvement with a validation plan. Avoid generic statements—show you can make a reasoned, defensible choice under time constraints.

What if I’m unfamiliar with accessibility regulations?

Acknowledge regulatory risk and explain how you’d investigate requirements as part of your process. Don’t guess at legal details—show you understand the business and ethical importance, and that you’d validate compliance before launch.

Should I always prioritize the largest user group?

Not necessarily. Prioritize by impact, feasibility, and urgency (such as legal deadlines or severe exclusion). Sometimes addressing a smaller group is critical to avoid legal or reputational harm. Justify your choice clearly in context.

Related guides

• How to make tradeoffs in product design interview cases
• Product design interview practice plan for first-time PM candidates
• How would you improve Google Maps? A worked PM interview answer
• How to answer product design interview questions without jumping to solutions