WCAG is the technical standard that defines web accessibility compliance, but treating it as a checkbox exercise misses the point. This roadmap shows decision-makers how to build WCAG into design systems, procurement, and QA workflows so accessibility becomes structural rather than remedial.
WCAG stands for Web Content Accessibility Guidelines, maintained by the W3C. It defines how digital content should behave for users with disabilities: visual, auditory, motor, cognitive, and neurological. The standard is organized into four principles (Perceivable, Operable, Understandable, Robust), each broken into guidelines, then testable success criteria rated A, AA, or AAA.
WCAG 2.2 became the recommendation in October 2023, adding nine new criteria around mobile interaction, authentication, and focus visibility. Most regulations reference WCAG 2.0 or 2.1, but procurement and new builds should target 2.2 to future-proof against enforcement updates. WCAG 3.0, announced as a draft, abandons the three-level conformance model for a scoring system and remains in early working-group phases. Planning around 3.0 today is premature; focus on 2.2 implementation and monitor W3C working drafts for signal when the shift becomes credible.
Level A is the baseline: if you fail here, the site is fundamentally unusable for many assistive technology users. Keyboard navigation, alt text for images, and proper heading hierarchy fall into this tier. Level AA adds contrast ratios, error identification, consistent navigation, and resizable text. This is the threshold in most legislation: ADA Title III cases in the U.S., Ontario's AODA, the European Accessibility Act, and Canada's Accessible Canada Act all reference AA.
Level AAA is not a blanket requirement. Specific criteria like sign language interpretation for video or extended audio descriptions apply to government, education, and healthcare in some jurisdictions. Trying to meet every AAA criterion is often impractical, but ignoring the ones that apply to your sector creates liability. Review your jurisdiction's regulations and your content types. If you publish video training or deliver services to vulnerable populations, certain AAA criteria become non-negotiable.
The costliest accessibility mistakes happen when WCAG is treated as a post-launch audit. Designers create mockups without checking contrast or focus states, developers build components that trap keyboard users, and content teams publish without alt text discipline. The remediation backlog becomes a project in itself.
Integrate WCAG earlier. Build color contrast and font-size ranges into your design tokens. Annotate Figma components with ARIA roles and keyboard behavior before handoff. Include accessibility acceptance criteria in user stories. Run axe DevTools or Lighthouse in local dev environments so violations surface during pull requests, not in QA. Establish a component library where each element has been validated once, then reused everywhere. This reduces the testing surface and ensures consistency. When accessibility is encoded in the system, individual contributors do not need to re-solve the same problems on every ticket.
Automated tools catch roughly 30-40% of WCAG issues: missing alt attributes, color contrast failures, duplicate IDs, improperly nested headings. They cannot evaluate whether alt text is meaningful, whether a custom dropdown is truly operable by keyboard, or whether a screen reader announces dynamic content changes correctly.
Manual testing requires navigating your site with keyboard only (no mouse), running NVDA or JAWS on Windows and VoiceOver on macOS/iOS, and testing with ZoomText or browser zoom at 200%. Check focus order, ensure modals trap focus and return it on close, confirm error messages are programmatically associated with form fields, and verify video captions are accurate and synchronized. If your team lacks in-house expertise, contract testers with disabilities. Their feedback will surface usability issues no checklist anticipates. This is especially critical for complex interactions: data visualizations, multi-step forms, chat widgets, and account dashboards.
Accessibility overlays are JavaScript widgets that promise one-click compliance through features like contrast toggles, text resizing, and screen reader modes. They are heavily marketed and inexpensive, which makes them appealing to non-technical decision-makers. They do not work.
Overlays cannot fix underlying markup problems. A screen reader user encountering an unlabeled button or a keyboard trap will not be helped by an overlay widget. In many cases, overlays introduce new barriers: extra navigation steps, conflicts with existing assistive technology settings, and false positives that mask real issues. Advocacy groups, including the National Federation of the Blind, have filed lawsuits specifically naming overlays as evidence of non-compliance. If you are considering an overlay to meet a deadline, recognize it as a short-term band-aid that defers the actual work. Invest in fixing the HTML, CSS, and JavaScript instead.
The Accessible Canada Act (ACA) requires federally regulated entities to meet WCAG 2.0 Level AA. Compliance deadlines are phased: June 2021 for new web content, June 2022 for existing public-facing sites. Crown corporations and federal agencies are subject to audits, and non-compliance can trigger orders and penalties.
Provinces have their own regimes. Ontario's AODA mandates AA for public sector and designated private organizations. Quebec has no standalone web accessibility law but applies accessibility through consumer protection and human rights frameworks. British Columbia introduced accessibility legislation in 2021 with regulations still being drafted. If you operate nationally, the safest posture is to meet WCAG 2.2 Level AA across all properties, document your conformance with a VPAT or ACR, and update it annually. For bilingual content, ensure accessibility in both English and French: alt text, transcripts, captions, and form labels. Accessibility is not exempt from language obligations.
Achieving compliance once is straightforward compared to maintaining it as the site evolves. New features, CMS updates, third-party integrations, and content migrations all introduce regression risk. Without governance, accessibility debt accumulates.
Establish a quarterly accessibility review cadence. Rotate responsibility for manual spot-checks across product teams. Maintain a public accessibility statement with contact information for users to report barriers. Track and triage accessibility bugs in the same backlog as other defects, not a separate wishlist. Integrate automated testing into CI/CD so regressions are caught before merge. Train content authors on alt text, heading structure, and link context. When evaluating vendors or SaaS tools, require VPAT documentation and test their interfaces with assistive technology before signing. Accessibility is not a project with an end date; it is a quality standard that applies to every release.
WCAG 2.2 builds on 2.1 by adding nine new success criteria focused on mobile accessibility, cognitive disabilities, and low-vision users. Examples include consistent help mechanisms, accessible authentication without cognitive tests, and improved focus indicators. All 2.1 criteria remain in 2.2, so meeting 2.2 means you also meet 2.1. New projects should target 2.2 to align with evolving regulatory expectations.
Compliance is measured at a level: A, AA, or AAA. Most regulations require Level AA, which includes all A and AA criteria. You do not need to meet every AAA criterion unless your jurisdiction or sector specifically mandates it for certain content types like video or specialized interfaces. Review the relevant law and your content inventory to determine which criteria apply.
No. Automated tools catch structural and programmatic issues like missing alt attributes, color contrast failures, and invalid HTML, but they cannot evaluate semantic meaning, keyboard usability in custom components, or screen reader experience. Manual testing with assistive technology is required to validate compliance, especially for interactive elements and dynamic content.
You remain responsible for the accessibility of all content on your site, including third-party embeds like chat widgets, payment forms, and map integrations. Vendors should provide VPAT documentation confirming their components meet WCAG. If they do not, either find an accessible alternative or build custom wrappers to remediate the gaps. Embedded content is a frequent source of compliance failures.
A VPAT (Voluntary Product Accessibility Template) is a document that maps a product's features to WCAG criteria and indicates conformance level for each. Government procurement, enterprise sales, and RFP processes often require a completed VPAT. If you sell software or services to public sector clients or large organizations, having an up-to-date VPAT demonstrates due diligence and accelerates contract approvals.
No. WCAG 3.0 is still in early draft and will take years to stabilize and be adopted by regulators. Current laws reference WCAG 2.x, and WCAG 2.2 is the actionable standard today. Waiting for 3.0 delays compliance and exposes you to legal and reputational risk. Focus on 2.2 implementation now and plan to adapt when 3.0 reaches candidate recommendation status.