· product-managers Editorial · Career · 6 min read
Product Accessibility Wcag Compliance Guide
A PM's practical guide to WCAG 2.2/2.3 compliance, legal risk, and how accessibility questions show up in 2026 interviews.
Why Accessibility Is Now a Core PM Competency, Not a Compliance Afterthought
Accessibility questions have moved from “nice to know” to a standard component of PM interviews in 2026, driven by three converging forces: the European Accessibility Act’s enforcement deadlines taking full effect across EU markets, an increase in ADA-related digital accessibility litigation in the U.S. (plaintiffs’ firms filed thousands of web accessibility lawsuits in 2025 alone, a trend that has continued into 2026), and a broader industry recognition that accessible design frequently improves usability for all users, not just those with disabilities. PMs are now expected to know WCAG at a working level the same way they’re expected to know basic SQL — not as a specialist skill, but as baseline literacy.
Interviewers test this in two ways: direct questions (“how would you prioritize an accessibility remediation backlog”) and embedded probes inside unrelated case studies, where a strong candidate proactively raises accessibility as a design constraint without being asked.
WCAG 2.2 and the Move Toward 2.3: What PMs Actually Need to Know
WCAG 2.2 became the baseline standard referenced in most legal and procurement contexts by 2025, and WCAG 2.3 work (focused on additional cognitive accessibility and mobile-specific criteria) has continued through 2026, though 2.2 remains the enforceable standard most companies target. PMs don’t need to memorize all success criteria, but should understand the four core principles, often remembered by the acronym POUR:
- Perceivable — content must be presentable in ways users can perceive (alt text for images, captions for video, sufficient color contrast).
- Operable — interface components must be operable via keyboard alone, with no time limits that can’t be extended, and no content that triggers seizures.
- Understandable — text must be readable, and interfaces must behave predictably (no unexpected context changes on focus).
- Robust — content must work reliably across assistive technologies, current and future, which in practice means clean semantic HTML and correct ARIA usage.
Understanding POUR at this level lets you reason about tradeoffs in an interview without needing to cite specific success criterion numbers, though naming a few (like 2.4.11 Focus Not Obscured, added in 2.2) signals genuine familiarity.
Compliance Level Comparison
| Conformance Level | Requirement Bar | Typical Use Case | PM Implication |
|---|---|---|---|
| Level A | Minimum accessibility, addresses the most severe barriers | Rarely sufficient alone for legal defensibility in 2026 | Should be treated as an absolute floor, not a target |
| Level AA | Addresses major barriers for most users; the de facto legal and procurement standard | Standard target for most commercial products, required by EAA and most U.S. settlement agreements | This is the level most roadmaps should target explicitly |
| Level AAA | Highest level, addresses barriers for the widest range of users including some cognitive disabilities | Rarely mandated in full; some criteria are impractical for all content types | Selectively adopt high-value AAA criteria rather than pursuing full AAA compliance |
| No formal target (“best effort”) | Ad hoc fixes without a defined bar | Common in early-stage startups, high legal risk | A red flag PMs should proactively flag and remediate, not defer indefinitely |
Interviewers frequently ask which level a candidate would target and why — the correct answer for the overwhelming majority of commercial products is AA, with a clear rationale (legal defensibility, achievability, industry norm) rather than defaulting to “as accessible as possible” without a defined bar.
A Framework for Prioritizing an Accessibility Backlog
When given a prompt like “Our accessibility audit found 200 issues, how do you prioritize the fixes,” use this three-factor scoring approach:
- Legal/severity risk — issues that block core functionality entirely for assistive technology users (unlabeled form fields, keyboard traps, missing alt text on transactional images) carry the highest legal and usability risk and should be fixed first regardless of engineering cost.
- User volume affected — an issue on your primary conversion flow affects more users than one buried in a rarely visited settings page.
- Fix cost and blast radius — some fixes are cheap and isolated (adding alt text), others require systemic changes (rebuilding a custom dropdown component to be keyboard-operable across the entire design system). Systemic fixes should be planned as design-system-level investments, not one-off tickets, because they prevent regression.
A candidate who proposes fixing the 200 issues in the order they appear on an audit report, without this three-factor triage, will read as inexperienced with how accessibility remediation actually gets resourced and shipped in a real organization.
Accessibility as a Business Case, Not Just a Compliance Obligation
The strongest 2026 interview answers frame accessibility with a business case alongside the compliance case: roughly 15-20% of the global population has some form of disability, aging populations increase the addressable market for accessible design over time, and accessible patterns (clear focus states, sufficient contrast, captioned video) measurably improve usability metrics for the general population too — a phenomenon sometimes called the “curb-cut effect.” Citing this dual framing (legal risk reduction plus market expansion plus general UX improvement) signals a PM who can sell accessibility work internally, not just describe it academically. This is exactly the kind of cross-functional framing covered in the accessibility and inclusive-design chapter of The 100x Product Manager Interview Playbook (Amazon link), which includes sample stakeholder-alignment scripts for getting accessibility work prioritized against feature roadmaps.
Practical Steps to Prepare
- Run an automated accessibility scan (axe DevTools, WAVE, or Lighthouse) against a product you use daily and note the top three issue categories — having a concrete, current example ready is more convincing than reciting theory.
- Practice navigating a familiar website using only a keyboard (no mouse) and note where you get stuck — this is a common interview exercise interviewers ask candidates to describe having done.
- Learn the difference between accessible and merely “technically compliant” — e.g., alt text that says “image123.png” passes an automated scanner but fails a real screen reader user.
- Be ready to discuss how AI-generated content (increasingly common in 2026 products) introduces new accessibility risks, such as AI-generated alt text that is inaccurate or AI chat interfaces that aren’t fully keyboard-navigable.
FAQ
Q: Do PM candidates need to know how to code ARIA attributes? A: No, but you should understand what ARIA roles and labels do conceptually and be able to have an informed conversation with an engineer about whether a custom component is properly exposed to assistive technology.
Q: How do I answer if I’ve never worked on an accessibility project directly? A: Be honest about limited direct experience, but demonstrate framework knowledge (POUR, WCAG levels, the triage model above) and cite a specific product you’ve personally audited using free tools, even informally, before the interview.
Q: Is accessibility only a legal risk topic, or does it actually affect product metrics? A: Both. Legal risk is real and growing in 2026, but accessible design changes (better contrast, clearer focus states, captions) also measurably reduce support tickets and improve task completion rates for the general user base, which is the framing that resonates best with product-metric-focused interviewers.