Practice — Accessibility and Inclusive Design (14 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?

A "Submit" control is built as a <div> with an onclick handler and CSS that makes it look pixel-identical to a real button. It happens to work in today's screen reader, but a different assistive-tech tool, or next year's release of the same one, might interpret it inconsistently or not at all.

Which WCAG POUR principle is this a violation of?

A design system's default body text renders at 14px regular weight — well under WCAG's "large text" size threshold.

Per WCAG 2.1 AA, what's the minimum contrast ratio this text must clear against its background?

A keyboard-only user visits a page with a large repeated navigation bar at the top, present on every single page of the site. Instead of tabbing through every nav link on every page load, a specific accessibility feature lets them jump straight to the main content.

What's this feature called, and which SC does it satisfy?

A developer builds a clickable element as a styled <div> with a click handler, then adds role="button" and aria-label to try to make it accessible.

Per the "first rule of ARIA" this subject describes, what's the better approach?

Curb cuts — the sloped ramps at street corners — were originally built for one specific population, but today they also benefit a much wider range of people who were never the intended audience: a parent pushing a stroller, a delivery worker with a hand truck, a traveler rolling a suitcase, a cyclist.

Who were curb cuts originally designed for?

A dashboard shows a row of status icons for each metric — no border, no shape difference, just a subtle color shift between a "pass" green and a "fail" red fill.

Who does this color-only signal fail to reach, and why?

A candidate says, "we design to AAA compliance across the whole site."

Per WCAG's own guidance on conformance levels, what's wrong with claiming full AAA conformance as a general policy?

WCAG 2.1 AA requires 4.5:1 contrast for normal text but only 3:1 for "large text."

Per the exact size threshold this subject cites, which of these qualifies as large text?

A team runs axe and Lighthouse on a new component and reports "zero accessibility errors found."

Per this subject's guidance on automated testing, what does that result actually prove?