Your team probably knows the product has accessibility gaps. A customer can’t finish checkout with a keyboard. A procurement form asks for your WCAG conformance level. Or a designer flags low contrast in a new component library. The web content accessibility guidelines give you a shared standard for fixing these problems. WCAG 2.2 Level AA is the target most product teams should build toward today. It covers the barriers that block the most people with disabilities, and it’s a strong current implementation target. Specific laws, regulations, procurement requirements, and contracts may still reference a different WCAG version or another standard.
At millermedia7, we treat digital accessibility as part of human-centered UX and clean engineering. We handle it the same way we handle conversion, performance, or scalability: in research, in design systems, and in code.
Keep reading to learn how WCAG is structured and which version and level to target. You’ll see what accessible patterns look like in a real interface and how to build them into delivery. You’ll also learn where the standard ends and legal duties begin, so you can make claims you can defend.
How Do Web Content Accessibility Guidelines Shape Product Decisions?
WCAG turns accessibility into testable requirements your team can design, build, and verify against. That makes it useful for product planning, vendor contracts, and QA, and it goes well beyond good intentions.
Who Defines WCAG and What Does It Cover?
The World Wide Web Consortium (W3C) publishes WCAG through its Web Accessibility Initiative (WAI). The Accessibility Guidelines Working Group writes and updates the documents. Governments, courts, and enterprise buyers reference the web content accessibility guidelines because they are stable, dated, and public.
WCAG covers web “content” in a broad sense. That includes text, images, and sound, plus the code and markup that define structure. The W3C’s WCAG 2 overview notes that WCAG applies to dynamic content, mobile web, and AI web interfaces. It can also guide native apps and documents through a companion note called WCAG2ICT.
For a VP of Product, this scope matters in one practical way. WCAG directly covers your marketing site and your logged-in SaaS dashboard, because both are web content. Your PDF onboarding guide is a non-web document, so WCAG2ICT guidance shows how to apply WCAG’s principles and criteria to it. That guidance doesn’t give the PDF the same conformance status as a web page, but it keeps the whole experience to one set of expectations. Accessibility can’t live only in the marketing team’s backlog.
How Do the Four POUR Principles Work?
WCAG 2.2 organizes 13 guidelines under four principles, often shortened to POUR:
- Perceivable: people can sense the content, whether they see it, hear it, or use a screen reader.
- Operable: people can use every control, with a mouse, a keyboard, touch, or voice.
- Understandable: content and behavior are clear and predictable, and errors are easy to fix.
- Robust: code works reliably with browsers and assistive technologies, now and as they change.
Guidelines themselves aren’t testable. Under each one sit success criteria, which are specific pass-or-fail statements. Your QA team tests against those criteria, and your design team uses them as acceptance rules.
Which WCAG Version and Conformance Level Should You Target?
Each success criterion sits at Level A, AA, or AAA. Level A removes the most severe blockers. Level AA adds criteria like contrast ratios and visible focus. AAA is the strictest, and the W3C itself advises against requiring AAA site-wide because some content can’t meet it.
Versions build on each other. WCAG 2.1 added 17 success criteria, and WCAG 2.2 added 9 more, including focus visibility and target size rules. Content that meets 2.2 also meets 2.1 and 2.0. So target WCAG 2.2 AA for new work, even if a contract names 2.1.
Picking a level is the easy decision. The harder work is making those criteria visible in screens people use every day.
What Does Accessible Design Look Like in a Working Interface?
Accessible design shows up in small, concrete decisions: a contrast token, a focus ring, an error message tied to its field. Each one removes friction for users with disabilities and usually helps everyone else too.
Make Text, Images, and Media Perceivable
Start with color contrast. WCAG AA asks for a 4.5:1 ratio for normal body text and 3:1 for large text. The fix belongs in your color tokens, so every button and label inherits a passing pair by default.
Never use color alone to carry meaning. A red border on a required field fails people who can’t tell red from gray. Add the word “required” or an icon with a text label.
Images need alt text that states purpose. A chart gets a short summary of its takeaway. A decorative flourish gets an empty alt attribute so screen readers skip it. Video needs captions, audio needs transcripts, and key visual action needs audio descriptions. Real headings, coded as headings, let screen reader users jump through a page the way sighted users scan it.
Support Keyboard, Touch, and Visible Focus
Keyboard navigation is the fastest test you can run. Unplug your mouse and try to complete a signup. If you get stuck in a modal or can’t reach a menu, keyboard and switch users hit the same wall.
Focus needs to be visible. Many teams remove the browser outline for looks and never replace it. WCAG 2.2 also requires that focused items aren’t hidden behind sticky headers or cookie banners.
For pointer input and mobile app accessibility, WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels, or enough spacing around smaller targets. Drag actions need a single-tap alternative. Content must also reflow on small screens and at 400% zoom without sideways scrolling. These choices echo the same rules strong ecommerce designers follow for mobile checkout.
Build Forms and Components People Can Understand and Complete
Forms are where accessibility and conversion meet. Every field needs a visible, programmatic label. Placeholder text alone disappears the moment someone types, which hurts memory and screen reader output.
Error prevention means catching problems early and explaining them plainly. Say “Enter a date as MM/DD/YYYY,” not “Invalid input.” Link the message to the field so assistive technologies announce it. For payments or legal submissions, give users a review step before final submit.
Custom components carry the most risk. A styled dropdown, tab set, or date picker needs the right roles, states, and keyboard behavior. Use native HTML where you can. When you can’t, follow established ARIA patterns and test with real screen readers.
Patterns like these don’t stay fixed by accident. They hold up only when your delivery process protects them.
How Can Teams Build Accessibility into Product Delivery?
Build accessibility into every stage where decisions get made: research, design systems, code, content, and testing. Fixing a barrier in a Figma component costs far less than fixing it across 40 shipped screens.
Set Requirements in Research and Design Systems
Write accessibility requirements into user stories from the start. “Users can complete checkout using only a keyboard” is a testable acceptance criterion. Add it next to the business goal, and it gets built.
Recruit people who use assistive technology into research sessions. They reveal friction that personas and heuristics miss. This fits naturally into the stages of UX design you already run, from discovery through validation.
Your design system is the biggest lever you have. When contrast-safe tokens, focus styles, and labeled form fields live in shared components, every team inherits them. Scaling design systems this way also speeds up SaaS product-led growth. Annotate components with focus order, heading levels, and alt text rules before handoff.
Carry Accessible Patterns into Code and Content
Developers need clear patterns and fast feedback. Add automated checks like axe-core or Lighthouse to your CI pipeline so contrast and missing-label errors fail the build. Treat those checks as a floor. Automated tools catch only part of the WCAG criteria.
Accessible web content also depends on writers and marketers. Meaningful link text, plain language, heading structure, and alt text all come from your CMS. Train content authors, and give them CMS fields that prompt for alt text on every upload.
Speed tools need guardrails too. When your team uses generative AI to draft screens or copy, humans still judge the result. The same balance applies in generative AI in UX, where speed helps and judgment decides. If your sprints follow agile and Lean UX, make accessibility part of your definition of done.
Test Real Tasks, Fix Barriers, and Retest After Changes
An accessibility audit should test tasks users care about, beyond isolated pages. WCAG itself says a multi-step process conforms only if every step conforms. One broken checkout page fails the whole flow.
A solid testing mix usually includes:
- Automated scans on every pull request
- Manual keyboard passes on critical flows
- Screen reader testing with VoiceOver, NVDA, or TalkBack
- Zoom and reflow checks at 200% and 400%
- Sessions with users of assistive technology
Log issues by severity and user impact, then retest after every release. A UX audit or design audit gives you a baseline, and task completion rates show progress. Tie results to UX metrics your leadership already tracks. Treat WCAG conformance as ongoing evidence you keep current.
That evidence matters most when someone asks whether your product is legally compliant.
Where Do WCAG Standards and Legal Duties Differ?
WCAG is a technical standard, and laws decide when you must meet it. The two overlap heavily, but they aren’t the same thing.
How Do U.S. Accessibility Rules Apply?
The Americans with Disabilities Act (ADA) covers state and local governments under Title II and businesses open to the public under Title III. Both must provide effective communication to people with disabilities, and the Department of Justice applies that duty to websites.
For government websites and apps, the rules are now specific. The DOJ’s 2024 rule requires state and local governments to meet WCAG 2.1 Level AA. The ADA web rule fact sheet sets compliance for governments of 50,000 or more people by April 26, 2027. Smaller governments have until April 26, 2028.
For private businesses, no DOJ regulation names a specific WCAG version. Whether and how accessibility obligations apply to a particular website depends on the relevant law, jurisdiction, organization, and context. WCAG is the technical standard teams build and test against; legal applicability is a separate question for counsel. Federal agencies follow the Section 508 standards, which build on WCAG 2.0 AA. If you sell SaaS to government, expect WCAG 2.1 Level AA or 508 language in your contracts.
What Should Teams Check Across Other Markets?
Global products face a patchwork. The European Accessibility Act (EAA) covers many private-sector products and services. Most companies meet it using EN 301 549, and the W3C’s EU policy summary lists WCAG 2.2 as the version tied to the EAA.
In Canada, the Accessible Canada Act applies to federally regulated sectors like banking and telecom and aims for a barrier-free Canada by 2040. Ontario’s Accessibility for Ontarians with Disabilities Act adds provincial duties for many organizations.
Before launching in a new market, check these points:
- Which law applies to your sector and company size
- Which WCAG version and level it references
- Whether you need a public accessibility statement or report
- Deadlines and how enforcement works
A legal review answers the compliance question. Your product process decides whether you can prove it.
Make Accessibility a Product Requirement, Not a Release Gate
When teams save accessibility for a pre-launch check, it becomes a rushed list of patches that breaks again next sprint. Moving it into requirements changes who owns it. Designers own contrast and focus. Engineers own semantics. Writers own alt text. Product owns the acceptance criteria.
That shift also improves website accessibility for everyone. Clear labels, strong user control over motion and timeouts, and forgiving forms reduce drop-off for tired, distracted, or mobile users. The same work that supports digital experience optimization supports people with disabilities, and web accessibility stops competing with growth goals.
If you’re unsure which flows would fail an audit today, start with your highest-revenue journey. Bring us a screen recording of it, and let’s map where keyboard, screen reader, and mobile users get stuck. Book a discovery call with millermedia7 to scope fixes your team can ship and keep.
Frequently Asked Questions
Does Meeting WCAG Level AA Guarantee Legal Compliance?
No. WCAG AA is a strong technical benchmark, but laws define scope, deadlines, and documentation separately. Pair conformance testing with legal review for each market you serve.
Should Our Team Target WCAG 2.1 AA or WCAG 2.2 AA?
Target WCAG 2.2 AA for new work. It includes every 2.1 criterion plus nine more, so you still meet contracts that name 2.1. Most added criteria, like target size and focus visibility, are cheap to build in early.
Is There a New WCAG Standard for 2026?
WCAG 3.0 remains a Working Draft, most recently updated in September 2026, and the W3C describes it as still years from completion. WCAG 2.2 is the current W3C Recommendation that teams can implement today, so keep building to WCAG 2.2 AA for now.
Can Automated Tools Prove That a Website Meets WCAG?
No. Automated scanners catch issues like missing labels and low contrast, but they can’t judge alt text quality or keyboard flow logic. Manual testing and assistive technology sessions fill that gap.
Do Third-Party Components and Mobile Apps Need Accessibility Testing?
Yes. Embedded widgets, payment forms, and chat tools can affect whether a page or process conforms, so they still need accessibility review and testing. Mobile apps need testing with VoiceOver and TalkBack, since the DOJ’s government rule explicitly covers apps.
