Building a WCAG Conformance Roadmap for Product Teams

Accessibility conformance has moved from a nice-to-have to a procurement gate. Enterprise buyers submit security questionnaires, request VPATs, and increasingly include accessibility requirements in their master service agreements. For product teams, this means accessibility is no longer a design consideration — it is a revenue consideration.

The problem most teams face is not awareness. Product managers know accessibility matters. The gap is operational: how do you scope the work, sequence it against competing priorities, and keep it from decaying back into debt the moment the remediation sprint closes? This guide answers those questions with a repeatable framework built on WCAG 2.1 AA as the target standard.

What WCAG Levels Actually Mean in Plain Language

The Web Content Accessibility Guidelines are organized into three conformance levels. Understanding what each level requires — and why the market settled on AA — is the foundation of any honest roadmap.

Level A covers barriers so fundamental that, without addressing them, entire categories of users cannot use the product at all. Missing alternative text on images means blind users receive no information. Missing form labels mean screen readers cannot identify input fields. Keyboard traps — interactive elements that capture focus and do not release it — prevent keyboard-only users from navigating. Level A is a floor, not a standard. Meeting only Level A is insufficient for enterprise procurement and does not satisfy Section 508 or the European Accessibility Act.

Level AA is the target. It adds requirements that address the widest range of users across the broadest set of disability categories. The most commonly cited AA criteria include a contrast ratio of at least 4.5:1 for normal text, the ability to resize text up to 200% without loss of content or functionality, consistent navigation across pages, visible focus indicators, and captions for prerecorded video. AA is the baseline in most enterprise procurement checklists, legal frameworks, and the standard referenced in a well-formed VPAT.

Level AAA is aspirational. It includes requirements like providing sign language interpretation for all prerecorded audio content, achieving a contrast ratio of 7:1, and ensuring no content flashes more than three times per second at any threshold. The W3C itself notes in the WCAG specification that it is not recommended to require Level AAA conformance as a blanket policy for entire sites or applications, because some criteria cannot be satisfied for all types of content.

For SaaS product teams, the target is clear: WCAG 2.1 Level AA. Everything in the roadmap should be measured against that bar.

Scoping the Audit: Why Automated Tools Are Not Enough

Before sequencing remediation work, you need to know what you are actually fixing. The audit phase is where most teams underestimate effort, because they rely exclusively on automated scanning tools.

Automated tools — Axe, Lighthouse, WAVE, IBM Equal Access Checker — are fast, scriptable, and easy to integrate into CI/CD pipelines. They are also fundamentally limited. The WebAIM Million report, which analyzes the top one million homepages annually, found that the average page has more than 50 automatically detectable WCAG failures. Yet that figure only captures what automation can detect. Research from Deloitte's digital accessibility practice indicates that automated tools reliably identify approximately 30% of WCAG conformance issues.

The remaining 70% requires human judgment and direct interaction with assistive technologies. A screen reader user needs to navigate the application using only audio feedback to discover whether the tab order makes sense, whether modal dialogs are properly announced, and whether dynamic content updates are communicated. A keyboard-only user needs to tab through every interactive element to confirm that focus never gets trapped and that every action achievable with a mouse is achievable with a keyboard. A user with low vision needs to test the application at high zoom levels and with high-contrast modes enabled.

For the audit scope, work through three layers:

Automated scan. Run Axe or an equivalent against every major template and page type — not just the homepage. SaaS applications have distinct views: authentication flows, onboarding sequences, dashboard states, settings pages, data export flows. Each template type should be scanned independently. Capture failures with their WCAG criterion reference.

Manual keyboard and focus audit. A trained tester navigates the full task flows — creating an account, configuring a core feature, generating a report — using only a keyboard. Document any point where navigation breaks, focus becomes invisible, or a task cannot be completed.

Assistive technology testing. Combine at least two screen readers (NVDA on Windows with Chrome, VoiceOver on macOS with Safari) with a representative set of core user journeys. The goal is not exhaustive coverage but enough signal to catch systemic patterns — missing landmark regions, unlabeled icons, forms that do not announce validation errors.

The combined output is an issue log. Every entry should reference the WCAG success criterion it violates, the affected user journey, and the specific element or interaction.

Triaging Issues by Severity

An unweighted issue log is not a roadmap. Before sequencing work, every issue needs a severity rating that reflects user impact, not technical complexity.

Critical. The user cannot complete a core task at all. A checkout flow that cannot be navigated by keyboard is critical. A login form whose error messages are invisible to screen readers is critical. A data table with no row or column headers that renders as meaningless text strings in a screen reader is critical. Critical issues have zero workarounds that a disabled user could reasonably apply. These go to the top of the backlog unconditionally.

Major. The user can complete the task but only by using a significant workaround — one that sighted, non-disabled users are not required to use, or one that requires substantially more time and effort. An interface that can be navigated by keyboard but where the focus indicator disappears on certain components is major. A form that works but where error messages are only conveyed by color (red text, no icon or text label) is major. Major issues belong in the next one or two sprint cycles after critical issues are resolved.

Minor. The user experiences inconvenience but can complete the task without an unusual workaround. A button whose tooltip is slightly truncated for screen reader users, or a link that is technically operable but whose accessible name is verbose rather than clear, is a minor issue. Minor issues can be batched into later sprints or handled opportunistically when related components are touched.

This three-tier system maps cleanly to sprint planning language: critical issues are P0, major are P1, minor are P2. It also gives you an honest picture of where the product sits today relative to a defensible Section 508 conformance gate.

Sequencing the Roadmap

With a triaged issue log in hand, the sequence follows a principle: fix user barriers before optimizing user experience. Accessibility work that optimizes the experience for assistive technology users before removing the barriers that prevent them from using the product at all is misdirected effort.

Phase 1: Critical barriers (sprints 1–4). All critical issues, regardless of which product area they live in. This phase often surfaces systemic problems — a component library built without ARIA roles, a routing framework that does not manage focus on page transitions, a form validation system that relies on visual-only cues. Systemic fixes here pay compound dividends across the entire product.

Phase 2: Keyboard navigation completeness (sprints 3–6, overlapping with Phase 1 tail). Once critical barriers are down, conduct a full keyboard audit of every task flow. The goal is complete keyboard operability — every interactive element reachable, every modal manageable, every flyout and dropdown closable without a mouse. Focus management on dynamic content (modals, drawers, toasts, inline validation) is typically the most time-intensive work in this phase.

Phase 3: Color and contrast (sprints 5–8). Color contrast failures are among the most common findings in automated scans. The WebAIM Million data shows that low-contrast text appears on the majority of homepages surveyed. In a design system context, contrast fixes often cascade — updating a token in the design system propagates the fix across dozens of components. Work with design to audit the full token set before writing individual component fixes.

Phase 4: Screen reader optimization (sprints 7–10). With barriers removed and keyboard navigation complete, this phase refines the screen reader experience — ensuring that dynamic state changes (loading indicators, success notifications, error announcements) are communicated through live regions, that complex components like data tables and multi-select filters have appropriate semantic structure, and that custom interactive components carry correct ARIA roles and state attributes.

This sequencing is not rigid — a critical issue discovered in Phase 3 goes to the top of the backlog immediately. But the phases give the team a shared mental model of where the program is and what comes next.

Integrating Accessibility Into the Sprint Cycle

The most common failure mode in accessibility programs is the remediation sprint. A team runs an audit, identifies hundreds of issues, schedules a sprint (or three) to address them, closes the sprint, and then ships new features for six months — each one adding new debt. Eighteen months later, another audit, another remediation sprint.

The fix is to treat accessibility the same way mature engineering teams treat security: as a continuous discipline embedded in the delivery process, not a periodic cleanup. This requires three changes to how the team operates.

Accessibility acceptance criteria in user stories. Every user story that touches a user interface element should include explicit, testable accessibility conditions. These are written in the same format as functional acceptance criteria: "Given that a user navigates the form using a keyboard only, when they submit with required fields empty, then focus moves to the first invalid field and a screen reader announces the specific validation error." Criteria written this way give developers a clear pass/fail condition and give QA a test case to execute before the story closes.

Accessibility in the definition of done. Add accessibility to the team's definition of done. A story is not done until keyboard navigation works, color contrast meets 4.5:1, interactive elements have accessible names, and dynamic updates are announced. This shifts the question from "did we handle accessibility?" to "can this story even close without it?"

Automated accessibility tests in CI. Integrate Axe-core or a similar library into the component test suite and the end-to-end test suite. Automated tests will not catch everything, but they will catch regressions — a developer who removes an aria-label from an icon button, a color token swap that drops contrast below threshold. Regressions caught in CI cost orders of magnitude less than regressions caught in a quarterly audit.

These three changes, taken together, mean that the accessibility debt identified during the mapping phase does not regenerate as fast as the team pays it down.

Defining "Conformant" for an Honest VPAT

When a procurement team requests a VPAT, they are asking a specific question: does this product support the success criteria in WCAG 2.1 Level AA? The VPAT template requires the vendor to rate each criterion as "Supports," "Partially Supports," "Does Not Support," or "Not Applicable."

The definitions matter. "Supports" means the functionality of the product meets the criterion. It does not mean "we tried" or "it mostly works." "Partially Supports" means some functionality meets the criterion and some does not. A product that passes contrast checks in most views but has one high-traffic dashboard with contrast failures is "Partially Supports" for Success Criterion 1.4.3, not "Supports."

Common mistakes that create liability:

Claiming "Supports" based solely on automated scans. Automated tools do not detect all failures. A VPAT claiming "Supports" for keyboard accessibility without keyboard testing is not credible.

Claiming "Supports" for criteria that have never been tested. If the team has not verified that the product meets criterion 4.1.2 (Name, Role, Value) with a screen reader, the honest answer is "Not Evaluated," not "Supports."

Leaving the VPAT undated and unversioned. Enterprise buyers expect VPATs to reflect a specific product version and testing date. An undated VPAT signals that it was not generated from actual testing.

An honest VPAT is one where every "Supports" claim maps to documented test results — automated and manual — against a specific product version. This level of rigor is what enterprise buyers have begun to require, and it is the standard that separates credible accessibility programs from checkbox compliance. Teams working toward enterprise contracts should read the detailed breakdown of what enterprise buyers actually check in a VPAT before drafting their first version.

Conclusion

A WCAG conformance roadmap is not a one-time project. It is a program that requires audit infrastructure, issue triage discipline, sprint integration, and honest reporting.

The sequence is straightforward: understand what the three conformance levels actually require, scope the audit with both automated and manual methods, triage issues by real user impact, fix critical barriers before optimizing the experience, and embed accessibility into the sprint cycle so debt does not regenerate. Define "conformant" precisely enough to make an honest VPAT claim that survives enterprise procurement scrutiny.

Accessibility conformance built this way becomes a structural capability — one that maps directly to the kind of compliance as competitive moat that changes enterprise deal dynamics. Products that can hand a procurement team a credible VPAT, a documented conformance roadmap, and evidence of continuous accessibility governance close deals that competitors with accessibility debt cannot reach. The operational investment to get there is real, but so is the revenue impact of removing the barrier.

For teams working through the enterprise procurement process and building their compliance stack in sequence, accessibility conformance typically falls after foundational security certifications and before the specialized compliance frameworks required for regulated verticals. The compliance certification sequencing roadmap provides the broader context for where WCAG conformance fits in a multi-certification compliance program.