Practice — Accessibility and Inclusive Design (5 questions)

A stakeholder pushes back on your accessibility review of an analytics dashboard: "The light-gray text on white background looks clean and modern — I don't see the problem, and nobody's complained." The body text is #999999 on a #FFFFFF background at 14px regular weight. A row of small status icons (no visible border, just a subtle fill color shift) indicates pass/fail state for each metric.

1. Is the body text likely to pass WCAG 2.1 AA, and how would you determine this definitively rather than arguing about how it looks?
2. Does the icon-based status indicator raise a separate contrast concern from the body text, and if so, which WCAG requirement applies to it?
3. How would you respond to "nobody's complained" as a justification for leaving it as-is?
4. Propose a concrete fix for both the text and the icons.

You're reviewing a rich-text editor's toolbar: a row of icon-only buttons (bold, italic, underline, insert link, insert image) with no visible text labels, built as <div> elements with onclick handlers and custom CSS to look like buttons. A tooltip shows the button's name on mouse hover.

1. List the concrete accessibility gaps in this toolbar as built.
2. For each gap, name the specific fix.
3. Why doesn't the hover tooltip solve the labeling problem on its own?

Your team is prioritizing features for a video-conferencing product's next quarter. Two proposals are on the table: (A) live automatic captioning during calls, and (B) a "raise hand" visual indicator so participants can signal without interrupting.

1. For each feature, use the Microsoft Inclusive Design framework's permanent/temporary/situational model to name at least one user in each of the three categories who benefits from it.
2. Based on this analysis, how would you pitch these features to a stakeholder who sees them purely as "accessibility features for a small population," in a way that reframes the investment?

A teammate built a custom tabbed interface (Overview / Pricing / Reviews) for a product page: three visually styled <div> elements side by side, each with an onclick that swaps which content panel is visible below. Clicking a tab changes its background color to indicate it's active. There is no keyboard support, no ARIA attributes, and the currently active tab is indicated only by the background color change.

1. Walk through this component against the four WCAG POUR principles and identify at least one violation under each.
2. Which specific ARIA roles and attributes would you add to fix the semantic gaps (not the keyboard gaps)?
3. Prioritize your fixes: which one should ship first if the team can only address one before a deadline, and why?

A product manager says: "Legal told us we just need to hit WCAG 2.1 AA to avoid liability. Let's scope accessibility work as a checklist against the AA success criteria and call it done."

1. Where would a compliance-only, checklist-driven approach likely fall short of what the Microsoft Inclusive Design framework would push you toward, even if every AA criterion technically passes?
2. Give a concrete example of a design decision that could pass a literal WCAG AA audit while still being a poor experience for a real user in one of the three impairment categories (permanent, temporary, situational).
3. How would you argue for going beyond the compliance checklist without making it sound like scope creep to a deadline-driven PM?