Accessibility for Product Managers: What WCAG Compliance Actually Requires
Why Accessibility for Product Managers Is Not a Design Nice-to-Have
A blind user opens your signup form, and their screen reader announces “button” three times in a row with no label telling them which button does what. That’s not a visual polish issue a designer will get to eventually. It’s a product that a paying customer cannot use, and increasingly, it’s a legal exposure the PM who shipped it didn’t know existed.
The regulatory picture shifted hard in 2026. The Department of Justice extended the ADA Title II deadline requiring state and local government sites to meet WCAG 2.1 Level AA, pushing large-jurisdiction compliance to April 2027 and smaller entities to April 2028. But ADA.gov’s own guidance is explicit that the extension changes only the enforcement date, not the underlying obligation — the ADA has banned disability discrimination for years, and courts have used it to support web accessibility claims long before any technical standard existed. People can sue over an inaccessible product right now, deadline or not.
That’s the part most product teams miss. Accessibility for product managers isn’t a checkbox that gets exercised once a year before an audit. It’s a requirement that behaves like any other functional requirement — it belongs in the PRD, the acceptance criteria, and the definition of done, not in a QA pass three days before launch.
What Does WCAG Compliance Actually Require?
WCAG is not itself a law. It’s a technical standard published by the W3C, and laws like the ADA and Section 504 are what make conformance to it mandatory for covered organizations. The current legal baseline that regulators point to is WCAG 2.1, Level AA, organized around four principles: content must be perceivable, operable, understandable, and robust — POUR, in the shorthand everyone uses once they’ve sat through one training session on it.
In practice, “Level AA” translates into concrete, testable requirements a PM can actually write acceptance criteria against: sufficient color contrast, every interactive element reachable and operable by keyboard alone, form fields with programmatically associated labels, meaningful alt text on informative images, and content that doesn’t rely on color alone to convey information. None of this requires a redesign. Most of it requires decisions that are cheap to make correctly the first time and expensive to retrofit.
A common trap: teams run an automated scanner, get a clean report, and call it compliant. Automated tools catch roughly 30 to 40% of accessibility issues — they can verify contrast ratios and missing alt attributes, but they cannot tell you whether a screen reader user can actually complete your checkout flow in a sensible order, or whether your custom dropdown component traps keyboard focus. Manual testing with real assistive technology is not optional if you want to know whether the product actually works, not just whether it passes a linter.
In practice, that means budgeting time for someone on the team to navigate the feature using a keyboard only, no mouse, from the first screen to the last. It means testing with at least one screen reader that maps to your actual user base — NVDA or JAWS on Windows, VoiceOver on Mac and iOS — because behavior differs meaningfully between them, and a component that announces correctly in VoiceOver can still fail silently in NVDA. It’s also worth remembering that accessibility isn’t only about blindness: motor-impairment testing (can this be operated with a switch device or without fine motor control), and cognitive-load testing (is the error messaging clear enough for someone with a reading or attention disability) matter just as much and get skipped even more often, because they’re harder to simulate quickly.
Where Accessibility Requirements Belong in the Product Lifecycle
Accessibility fails most often not because engineers can’t build it, but because nobody wrote it down as a requirement before the ticket was scoped. If it’s not in the spec, it competes for attention against everything that was written down, and it loses.
The fix is mechanical: accessibility criteria belong in the same place your other acceptance criteria live. When you’re writing a PRD, add a section that states the WCAG conformance level the feature must meet, not as boilerplate but tied to the specific interaction — “the comparison table must be operable via keyboard, with visible focus states on every sortable column header” reads very differently to an engineer than “must be accessible.” The same discipline applies when you write a user story: acceptance criteria that name the actual assistive-technology behavior expected, not a generic reference to a standard nobody on the team has read closely.
This is also a design collaboration problem, not just an engineering one. When you’re working with a designer, accessibility constraints need to show up during the design review, not after the component is built — a color palette that fails contrast requirements or an interaction pattern with no visible focus state is far cheaper to catch in a Figma file than in a pull request. Entire color systems have gotten approved and shipped before anyone ran a contrast check — rework that costs weeks, against a check that takes five minutes during review.
A Worked Example: Retrofitting a Checkout Flow for Screen-Reader Users
A mid-market e-commerce platform received a demand letter over its checkout flow. Not a class action, not a regulator — a single user’s attorney, citing specific, reproducible failures: the shipping-method radio buttons had no associated labels, so a screen reader announced them as unlabeled “radio button” elements with no way to tell Standard from Express apart; the “Apply Coupon” button had no accessible name at all, just an icon; and the order summary updated dynamically with no ARIA live region, so screen reader users had no way of knowing the total had changed after applying a discount.
None of those three fixes required a redesign. The radio buttons needed proper <label> associations tied to their inputs, which took an engineer an afternoon. The coupon button needed a visually-hidden accessible name added via aria-label, a one-line change. The order summary needed an aria-live="polite" region so assistive technology would announce the updated total automatically. Total engineering time: under three days. Total cost if it had been specified correctly the first time: zero, because none of these decisions added complexity to the original build — they were omissions, not tradeoffs.
The actual expensive part was retroactive: a full manual audit of the rest of the site to find every other instance of the same three patterns, because if the shipping-method radio group had missing labels, other radio and checkbox groups almost certainly did too. That’s the real lesson. A single reported issue is rarely an isolated bug — it’s usually a pattern that got baked into a component library and then reused everywhere.
The team’s actual fix, after the audit, wasn’t to patch every instance individually. It was to correct the base radio-button and button components in the design system once, then re-run every feature built on top of those components through automated regression checks. Six months later, a new engineer joining the team couldn’t easily build an inaccessible form even by accident, because the components they were reaching for did the right thing by default. That’s the difference between fixing a symptom and fixing the actual defect.
WCAG Success Criteria PMs Actually Need to Know
Most PMs don’t need to memorize all 50-plus success criteria in WCAG 2.1 AA. A working knowledge of the ones that show up constantly in product work covers most of the risk.
| Requirement | What It Means in Practice | Common Failure | Who Owns the Fix |
|---|---|---|---|
| Color contrast (1.4.3) | Text needs a 4.5:1 contrast ratio against its background (3:1 for large text) | Brand colors chosen for aesthetics fail contrast at normal text size | Design, verified in Figma before build |
| Keyboard operability (2.1.1) | Every interactive element must be reachable and usable without a mouse | Custom dropdowns and modals trap or skip keyboard focus | Engineering, tested manually |
| Labels and instructions (3.3.2) | Form fields need programmatically associated, visible labels | Placeholder text used as the only label, which disappears on input | Design and engineering jointly |
| Name, role, value (4.1.2) | Custom components must expose their state to assistive technology | Custom checkboxes or toggles built as styled divs with no ARIA role | Engineering, using semantic HTML first |
| Status messages (4.1.3) | Dynamic content changes must be announced to screen readers | Cart totals, form errors, and loading states update silently | Engineering, via ARIA live regions |
The pattern across every row: accessibility failures cluster in custom-built interactive components, not in plain text and images. If your design system reuses accessible components correctly, most of this risk resolves itself once, instead of getting re-litigated on every feature.
Where Accessibility Efforts Break
A handful of mistakes account for most of the accessibility debt that accumulates on product teams.
Treating a VPAT or accessibility statement as proof of compliance. A Voluntary Product Accessibility Template documents a vendor’s self-reported conformance; it is not independent verification, and procurement teams increasingly know that. Recovery: back any accessibility statement with an actual audit trail — automated scan plus manual testing plus assistive-technology testing — and be honest in the statement about known gaps rather than claiming full conformance you haven’t verified.
Scoping accessibility as a separate epic instead of embedding it in every ticket. A dedicated “accessibility remediation” epic signals to the rest of the team that accessibility is optional overhead rather than a normal part of building a feature correctly, and it creates a permanent backlog that competes with everything else for prioritization. Recovery: fold accessibility criteria into the definition of done for every ticket touching UI, the same way you’d treat browser support or responsive layout.
Assuming third-party components and embedded tools are already accessible. Title II’s rule makes clear that if content lives on your site, it counts, even if a vendor or third-party widget built it — a chat widget, a payments modal, or an embedded scheduling tool with poor accessibility becomes your liability the moment it’s on your page. Recovery: add accessibility conformance requirements to vendor contracts and procurement checklists, not just feature checklists, especially for products selling into enterprise or public-sector buyers where procurement teams will ask for this directly.
Confusing “no lawsuits yet” with “compliant.” Plenty of teams treat the absence of a complaint as evidence the product is fine, right up until a demand letter arrives. This has the same shape as other product decisions that quietly cross an ethical or legal line before anyone notices — the kind of rationalization worth reading about in what product managers should never ship. Recovery: run a manual accessibility audit on a cadence, the same way you’d run a security audit, rather than waiting for an external signal to force the issue.
Deprioritizing accessibility fixes because they don’t move a growth metric. Accessibility work rarely shows up in an A/B test as a conversion lift, because it’s removing a hard blocker for a minority of users rather than optimizing an experience most users already have. Recovery: track accessibility defects as a distinct, non-negotiable category in the backlog, evaluated against legal and ethical risk rather than against RICE-style scoring built for growth features.
Accessibility for product managers stops being abstract the moment a real user can’t complete a task your product exists to let them complete. The teams that treat it as a standing requirement, not a periodic scramble, are the ones who won’t be reading a demand letter to find out where their component library went wrong.
