Baking Accessibility Into Every Spec: A PM's WCAG Field Guide

Accessibility belongs in the spec, not in a pre-launch audit. A PM can catch most WCAG issues by writing five things into every spec's acceptance criteria: color contrast ratios, keyboard operability, visible focus order, form labels, and alt text for meaningful images. Treat these as done-criteria, the same way you'd treat error states or empty states.

Quick answer: Accessibility in product specs means writing WCAG's four principles — perceivable, operable, understandable, robust — into acceptance criteria before design starts, not auditing for compliance after it ships.

Most teams treat accessibility as a specialist's problem: something an auditor flags in a spreadsheet three weeks before launch, usually too late to fix without a scramble. That's backwards. Accessibility bugs are requirements bugs. They happen because nobody wrote "focus must be visible" or "this icon-only button needs a label" into the spec in the first place. The fix isn't hiring more auditors — it's changing what counts as "done."

What WCAG Actually Asks Of a Product Spec

WCAG (Web Content Accessibility Guidelines) organizes every requirement under four principles: content must be perceivable, interfaces must be operable, everything must be understandable, and the code must be robust enough for assistive tech to parse. For a PM, this reframes accessibility from "compliance checklist" into four questions every spec should already answer.

The W3C, which maintains WCAG, publishes three conformance levels — A, AA, and AAA. Level AA is the practical target for almost every commercial product; it's also the level referenced by the ADA Title II rule and the EU's European Accessibility Act, both of which now apply enforcement pressure to digital products, not just physical spaces.

You don't need to memorize all ~50 AA success criteria. You need to know which ones recur in every UI review.

The 80/20 of WCAG for PMs

A small number of criteria account for the large majority of real-world accessibility bugs found in audits by groups like WebAIM, whose annual scan of the top million home pages consistently finds low-contrast text, missing alt text, empty links, and missing form labels as the top offenders, year after year.

That's seven line items. Bake those into your spec template and you've addressed the criteria responsible for most reported issues — without needing a WCAG certification.

Why "Audit Later" Fails, Structurally

Auditing after launch fails because it treats accessibility as a QA pass instead of a design constraint, which means fixes require rework instead of a spec revision. The later a11y is caught, the more it touches: visual design, component code, copy, and QA regression, all at once.

Think of it like technical debt. A missing focus state caught in spec review costs one sentence. The same gap caught in a pre-launch audit costs a design ticket, an engineering ticket, a re-test, and a delayed release. This is the same economics that make design tokens valuable — fixing something once, upstream, beats fixing it many times, downstream.

There's also a trust cost. Users who rely on screen readers, switch devices, or high-contrast modes don't file a ticket when something's broken — they leave. Accessibility bugs are silent churn, and silent churn doesn't show up in your usual funnel metrics.

The Compliance Argument Is Real, But It's Not the Best Argument

Legal exposure is genuine: the Department of Justice's 2024 ADA Title II rule set a firm timeline for public-facing digital services to meet WCAG 2.1 AA, and private litigation under Title III has been rising for years against retail and SaaS sites. That's worth knowing.

But leading with compliance fear makes accessibility feel like a tax. Leading with "who actually uses this feature" makes it feel like product work. Roughly 1 in 6 people globally live with a significant disability according to the World Health Organization — a population larger than most market segments you'd build a roadmap around deliberately.

Turning WCAG Into Spec Language, Not Legal Language

The shift PMs need to make is linguistic: stop writing "must comply with WCAG 2.1 AA" and start writing testable, specific acceptance criteria that an engineer or designer can check without opening the WCAG spec itself. Vague compliance language gets skipped; specific criteria get built.

Compare the two styles directly:

Notice the pattern: each specific version is something a reviewer can verify in five minutes without special tooling. That's the bar. If a criterion needs a lawyer or a specialist to interpret, rewrite it until a generalist engineer can check it.

A Copy-Paste Accessibility Checklist for Specs

Drop this block into any spec template as a required section, the same way you'd require a rollback plan or a metrics section.

Perceivable

• Text contrast is 4.5:1 (normal) or 3:1 (large text, 18px+ bold or 24px+ regular)
• Informative images have descriptive alt text; decorative images have empty alt
• Color is never the only signal (add icon/text/pattern alongside color-coded states)
• Video/audio content has captions or a transcript

Operable

• Every interactive element is reachable and usable via keyboard alone
• Tab order matches the visual/logical reading order
• Focus indicator is visible on every focusable element
• No keyboard traps (modals, dropdowns must be exitable via keyboard)
• Interactive targets are at least 24x24px (44x44px preferred on touch)

Understandable

• Every form field has a persistent, associated label (not placeholder-only)
• Error messages state what's wrong and how to fix it, in text (not color alone)
• Navigation and component behavior are consistent across the product

Robust

• Custom components (dropdowns, tabs, sliders) expose correct role/state via ARIA
• Page uses semantic HTML landmarks (headings, nav, main, button vs div)
• Dynamic content changes are announced to assistive tech (aria-live where relevant)

Numbered as acceptance criteria, not prose, this becomes a checklist an engineer marks off the same way they'd mark off "handles empty state" or "handles error state."

Building Accessibility Into Your Workflow, Not Just Your Template

A spec checklist only works if it's paired with a workflow that treats accessibility gaps the same as any other blocking bug — caught before build, not after. This means threading a11y thinking through discovery, design review, and definition-of-done, not just the spec document itself.

Three structural changes make this stick:

1. Add it to Definition of Ready. A story isn't ready for sprint planning if it lacks contrast, focus, label, and alt-text criteria where applicable — same discipline as requiring a JTBD statement in discovery, as covered in the complete guide to jobs-to-be-done.
2. Review it in design crit, not just QA. A designer catching a 3.2:1 contrast ratio in Figma costs a token swap. The same catch in QA costs a re-export and re-test cycle.
3. Make it a trio conversation. Accessibility sits at the intersection of what's desirable, feasible, and viable — exactly the kind of cross-functional call the product trio operating model is built to make well, rather than leaving it to one function to catch alone.

Where This Fits Alongside Design Systems

If your org has a design system, most of this work is already half-done — a well-built system encodes contrast-safe color pairs and focus states at the component level, so individual specs inherit them rather than re-litigating them. The PM's job becomes checking that new components extend the system's accessible patterns rather than introducing bespoke ones, similar to how component API thinking asks you to design a component's contract before its visuals.

Custom components are where accessibility debt concentrates fastest. A native <button> is keyboard-operable and screen-reader-friendly for free; a <div onClick> styled to look like a button is neither, and someone has to notice and reject it in review.

How Prodinja Approaches This

Spec Studio, Prodinja's living-PRD tool, includes accessibility prompts inside the spec-writing flow itself — surfacing contrast, keyboard, and labeling considerations while intent is still being drafted, rather than as a checklist bolted on before launch. The idea is to model raising a11y questions at the moment requirements are written, the same moment you'd raise an edge case or a metric, so it's a normal part of defining "done" rather than a separate audit step someone remembers to schedule later.

Key Takeaways

• Accessibility bugs are requirements bugs — they happen because a spec never said "focus must be visible," not because engineers ignored a guideline.
• WCAG's four principles (perceivable, operable, understandable, robust) reduce to about seven recurring criteria that catch most real-world issues: contrast, alt text, keyboard operability, focus order, focus visibility, labels, and correct semantic roles.
• AA is the practical target, referenced by both the ADA Title II rule and the EU Accessibility Act — AAA is rarely required for commercial products.
• Specific spec language beats compliance language — "4.5:1 contrast" is buildable; "must be accessible" gets skipped.
• Catching gaps in spec review is dramatically cheaper than catching them in a pre-launch audit, because fixes upstream touch one document instead of design, code, and QA simultaneously.
• A copy-paste checklist, added to Definition of Ready, turns accessibility into a normal acceptance criterion rather than a specialist gate.