It is the latest version of the W3C Web Content Accessibility Guidelines, adding success criteria such as focus not obscured, target size and accessible authentication.

Which conformance level should I target?

Level AA is the practical target for most legal and procurement requirements.

Can automated tools make my site accessible?

They catch many common issues like missing labels and low contrast, but manual testing with a keyboard and screen reader is still essential.

Where should a small team start?

Run an automated scan, complete your main user journey by keyboard, and fix issues in shared design system components first.

Do accessibility overlays work?

Overlays rarely fix underlying code problems and can introduce new ones, so fixing the actual markup and components is the better route.

WCAG 2.2 for SaaS and Web Apps: A Practical Startup Guide for 2026

Accessibility often arrives on a startup's roadmap through a painful door: a customer questionnaire, an enterprise procurement review, or a complaint from a user who could not complete checkout. By then the product has dozens of screens, a design system built without accessibility in mind, and a team that treats the topic as a compliance chore. It does not have to be this way. Building to WCAG 2.2 from the start is cheaper, produces a better product for everyone, and removes a common objection from sales conversations.

This guide explains what WCAG 2.2 is, which parts matter most for SaaS and web apps, and how a small team can build a realistic accessibility practice without hiring a dedicated specialist on day one.

What WCAG 2.2 Is and Why It Matters

The Web Content Accessibility Guidelines (WCAG) are published by the W3C. Version 2.2 extends the earlier 2.1 guidance with additional success criteria, many aimed at mobile users, people with cognitive disabilities, and people who rely on keyboards or assistive technology. Conformance is described at three levels: A, AA, and AAA. Most legal and procurement requirements around the world reference level AA, which is the practical target for most products.

The guidelines are organised around four principles, often shortened to POUR:

Perceivable: Users can perceive the content, for example through text alternatives and sufficient contrast.
Operable: Users can operate the interface using a keyboard, touch, or other input.
Understandable: Content and behaviour are predictable and errors are explained clearly.
Robust: Content works with current and future assistive technologies.

Beyond compliance, accessible interfaces tend to be easier to use in bright sunlight, on a slow device, with one hand, or while distracted. Many accessibility improvements are simply good usability.

What Changed in WCAG 2.2

Without reciting every criterion, several additions affect everyday product decisions:

Focus not obscured: When a keyboard user tabs through your page, the focused element must not be hidden behind sticky headers or cookie banners.
Target size: Interactive elements should be large enough to tap or click reliably, which matters on phones.
Dragging alternatives: Any action that requires dragging needs a simple alternative, such as buttons.
Consistent help: If you offer help or contact options, place them in a consistent location across pages.
Redundant entry: Do not force users to re-enter information they already supplied in the same process.
Accessible authentication: Login should not depend solely on cognitive tests such as memorising or transcribing codes, so allow password managers and paste.

Always check the official W3C text for exact wording, since success criteria have precise definitions and exceptions.

A Real-World Example: A B2B SaaS Dashboard

Consider an illustrative scenario. A small SaaS company sells a reporting dashboard to mid-sized firms. During a procurement review, a prospective customer asks for an accessibility conformance statement. The team has never tested with a keyboard or screen reader.

A quick audit reveals typical issues. Icon-only buttons have no accessible names. Modal dialogs trap neither focus nor escape correctly. Charts convey meaning only through colour. Form errors appear in red text without being announced to assistive technology. The sticky header covers focused fields when users tab down the page.

The team triages the findings by user impact. They fix the shared components first: buttons, form fields, modals, and menus. Because those components are reused everywhere, a small number of fixes improves dozens of screens at once. They add text summaries and data tables behind charts, set up automated checks in the build pipeline, and schedule a manual review with a screen reader before each release. In a scenario like this, the biggest gains often come from fixing the design system rather than individual pages.

Step-by-Step Process to Reach WCAG 2.2 AA

Set the target and scope. Decide on WCAG 2.2 level AA and list the key user journeys: sign up, login, core task, billing, and support.
Run an automated scan. Tools such as axe or Lighthouse catch many common issues like missing labels and low contrast. They cannot find everything, but they provide a quick baseline.
Test with the keyboard. Unplug the mouse and complete each journey using Tab, Shift+Tab, Enter, Space, and arrow keys. Note anywhere focus is invisible, lost, or trapped.
Test with a screen reader. Try VoiceOver on macOS or iOS and TalkBack on Android. NVDA is a free option on Windows. Listen for missing names, wrong roles, and confusing order.
Audit colour and contrast. Check text, icons, and focus indicators against the required contrast ratios, and make sure meaning is never conveyed by colour alone.
Fix the design system first. Repair shared components so improvements spread across the product. Document accessible patterns for developers and designers.
Add guardrails to the pipeline. Include automated accessibility checks in continuous integration and linting for common mistakes such as images without alt text.
Review with real users. Where possible, invite people who use assistive technology to test critical flows and listen to their feedback.
Publish and maintain. Write an accessibility statement, provide a contact route for reports, and re-test whenever you ship major changes.

Practical Techniques Developers Should Know

Use semantic HTML first

A real button element gives you keyboard support, focus handling, and the correct role for free. A clickable div needs all of that rebuilt by hand, and it is usually done incompletely. Prefer native elements and reach for ARIA only when no native option exists. Bad ARIA is often worse than none.

Manage focus deliberately

When a modal opens, move focus inside it, keep it there, and return it to the triggering element on close. When content updates dynamically, such as a search result list or a form error, make sure assistive technology is told through live regions or focus management. Single page apps need special care when routes change, because the browser no longer announces a new page automatically.

Write clear labels and errors

Every input needs a visible, programmatically associated label. Error messages should say what went wrong and how to fix it, and be linked to the field they describe. Avoid placeholder text as the only label.

Respect user preferences

Honour reduced motion settings, support browser zoom up to large sizes without breaking layouts, and avoid time limits that cannot be extended. These small touches help users with vestibular conditions, low vision, and slower interaction speeds.

Performance and accessibility often reinforce each other, since leaner, well structured pages are easier for assistive technology to handle. Teams working on responsiveness may also like our guide to improving INP in React apps.

Mobile and Cross-Platform Considerations

If your product also ships as a mobile app, the same principles apply with platform-specific tools. Our walkthrough of mobile app accessibility with VoiceOver and TalkBack covers testing on real devices. Keep naming, labels, and interaction patterns consistent between web and mobile so users do not have to relearn your product.

Key Benefits of Building Accessibly

Wider audience: More people can use your product, including those with permanent, temporary, or situational limitations.
Smoother enterprise sales: Accessibility questions in procurement are easier to answer when you have evidence and a statement ready.
Lower legal and reputational risk: Regulations and expectations around digital accessibility continue to grow in many markets.
Better SEO and quality: Semantic structure, descriptive links, and clear headings help search engines as well as assistive technology. See our technical SEO audit checklist for overlapping practices.
Cheaper development over time: Fixing a component once is far less costly than retrofitting an entire product later.

Common Mistakes to Avoid

Relying only on automated tools. Automated scans typically catch only part of the issues, so manual testing remains essential.
Using overlay widgets as a shortcut. Third-party overlays rarely fix underlying code problems and may introduce new ones.
Hiding focus outlines. Removing the outline for looks leaves keyboard users lost.
Treating it as a one-off project. Every new feature can introduce regressions, so build checks into your workflow.
Leaving it to one person. Designers, developers, writers, and QA all influence accessibility.

Accessibility is not a feature you add at the end. It is a quality of how you build, review, and ship every screen.

Getting Started Without a Big Budget

A small team can start this week. Run an automated scan, complete your main journey by keyboard, and fix the top five issues in your shared components. Add a short checklist to your pull request template. Over a few release cycles, these small habits compound.

If you want a partner to audit your product or build accessible interfaces from the start, our UI/UX design services include accessibility as part of the build.

Making Accessibility Part of Your Culture

Sustainable accessibility depends on habits, not heroics. Add an accessibility line to your definition of done so no story is complete without keyboard and label checks. Invite designers to annotate focus order and reading order in their mockups. Share short demos where someone navigates a new feature using only a screen reader, because hearing the experience is more persuasive than reading a report. Over time, the team builds intuition, and issues are caught while they are cheap to fix rather than after release.

Conclusion

WCAG 2.2 gives product teams a clear, testable standard for building software that more people can use. Focus on level AA, fix your design system before individual pages, test with a keyboard and a screen reader, and automate what you can. Treat accessibility as an ongoing quality practice rather than a certification to chase. The payoff is a more inclusive product, fewer procurement obstacles, and a codebase that is simply better built.

Frequently Asked Questions

What is WCAG 2.2?: It is the latest version of the W3C Web Content Accessibility Guidelines, adding success criteria such as focus not obscured, target size and accessible authentication.
Which conformance level should I target?: Level AA is the practical target for most legal and procurement requirements.
Can automated tools make my site accessible?: They catch many common issues like missing labels and low contrast, but manual testing with a keyboard and screen reader is still essential.
Where should a small team start?: Run an automated scan, complete your main user journey by keyboard, and fix issues in shared design system components first.
Do accessibility overlays work?: Overlays rarely fix underlying code problems and can introduce new ones, so fixing the actual markup and components is the better route.