# WCAG 2.2 AA checklist for SaaS products and web apps

Source: https://www.fixreports.com/blog/wcag-2-2-checklist-saas-web-apps

Updated 2026-10-26

A SaaS product has two accessibility surfaces: the marketing site that sells it and the application people use every day. The marketing site fails in the same ways as any website, with low contrast, missing alt text and unlabeled forms. The application adds its own problems: login flows that block password managers, dialogs that trap keyboard focus, single-page navigation that screen readers don't notice, data tables and charts without text, drag-and-drop with no alternative, and sessions that expire without warning. This checklist goes through WCAG 2.2 Level AA by the parts of a typical SaaS product.

**Key points**

- WCAG 2.2 became a W3C Recommendation in October 2023 and added nine success criteria, six of them at Level A or AA ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).
- Accessible Authentication (3.3.8, AA) means a login can't depend on remembering or transcribing a password unless people can paste it or use a password manager ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)).
- Interactive targets must be at least 24 by 24 CSS pixels, or have enough space around them (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)).
- Messages such as “Saved” or “3 results” must reach screen readers without moving focus (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)).
- Business and public-sector buyers often ask for an Accessibility Conformance Report, usually written on the VPAT template from the Information Technology Industry Council ([ITI](https://www.itic.org/policy/accessibility/vpat)).

## Why does accessibility matter more for SaaS than for a brochure site?

People use a SaaS product for hours, often because their employer chose it. A barrier on a marketing page loses a visitor; a barrier in the product can stop someone doing their job. That's why larger customers, universities and public bodies increasingly ask about accessibility before they buy, and why the answer needs to cover the application, not just the website.

It also matters because automated tests catch only part of the problem. Tools like axe-core find failures in the markup, such as missing labels and low contrast. They can't tell whether a dialog returns focus to the right place, whether a chart's data is available as text, or whether a workflow can be completed with a keyboard. An application needs both automated checks and manual testing.

## How do you make sign-up and login accessible?

Authentication is where WCAG 2.2 added the most important new requirement for SaaS.

- **Allow paste and password managers (3.3.8, AA).** Don't block pasting into password or code fields, and use `autocomplete="username"`, `autocomplete="current-password"` and `autocomplete="one-time-code"` so browsers and password managers can fill them.
- **Avoid puzzles as the only way in.** A CAPTCHA that asks people to transcribe distorted text or solve a puzzle is a cognitive function test. Offer an alternative, and prefer checks that don't need user action ([W3C](https://www.w3.org/TR/turingtest/)).
- **Label every field (1.3.1 and 3.3.2, A).** Use a visible `<label>` connected to its input; placeholder text disappears when someone types and isn't a label.
- **Identify errors in text (3.3.1, A) and suggest fixes (3.3.3, AA).** “Password must have at least 12 characters” helps; a red border alone doesn't.
- **Don't ask twice (3.3.7, A).** If a multi-step sign-up already asked for a company name or address, fill it in or let people select it instead of retyping.
- **Keep help in the same place (3.2.6, A).** If you offer chat, a help link or contact details, put them in the same relative position on every page of the flow.

## Which form and error patterns cause the most failures?

Forms are where most application failures live. WebAIM's 2026 survey of one million home pages found missing form labels on 51% of them ([WebAIM](https://webaim.org/projects/million/)), and applications have far more forms than home pages.

- Give each input a programmatic name, and group related controls, such as radio buttons, with `<fieldset>` and `<legend>`.
- Tell people about errors where they'll notice: move focus to an error summary at the top of the form, or to the first invalid field, and link each summary item to its field.
- Mark required fields in text, not with color alone (1.4.1, A).
- Don't submit or change context when someone just selects an option (3.2.2, A); wait for an explicit action.

## How should dialogs, menus and popovers behave?

Custom components are where keyboard and screen reader support breaks most often. The WAI-ARIA Authoring Practices Guide describes the expected behavior for each pattern ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)).

- **Dialogs**: move focus into the dialog when it opens, keep Tab inside it while it's open, close it with Escape, and return focus to the control that opened it. Use the native `<dialog>` element or `role="dialog"` with `aria-modal="true"` and a name.
- **No keyboard traps (2.1.2, A)**: every component must be leavable with the keyboard.
- **Visible focus (2.4.7, AA)** that isn't hidden behind sticky headers, cookie banners or chat widgets (2.4.11, AA, new in 2.2).
- **Tooltips and popovers (1.4.13, AA)** that people can dismiss with Escape, hover over without them vanishing, and that stay until dismissed.
- **Single-key shortcuts (2.1.4, A)**: if pressing a letter key triggers an action, let people turn shortcuts off or remap them, or make them active only when the relevant component has focus.

## How do you handle navigation in a single-page app?

In a single-page app the URL changes without a page load, so screen readers may not announce that anything happened.

- Update the document title on every route change, so each view has a descriptive title (2.4.2, A).
- Move focus to the new view's main heading, or announce the change in a polite live region; frameworks such as Next.js include a route announcer for this.
- Keep a logical focus order (2.4.3, A): after an item is deleted, focus should go to a sensible neighbor, not back to the top of the page.
- Provide a way to skip repeated navigation (2.4.1, A), such as a skip link or landmarks.

## How do you make dashboards, data tables and charts accessible?

- **Tables**: use real `<table>` markup with `<th>` and `scope` for headers, and a caption (1.3.1, A). Grids built from `<div>` elements need the full ARIA grid pattern, which is much harder to get right.
- **Charts**: give each chart a text alternative that states the main point, and offer the data as a table (1.1.1, A). Don't rely on color alone to tell series apart (1.4.1, A); add labels or patterns.
- **Contrast**: text needs 4.5:1 (1.4.3, AA), and chart lines, icons and input borders need 3:1 against their background (1.4.11, AA). Check dark mode separately. Our [color contrast checker](/color-contrast-checker) tests any pair of colors.
- **Status messages (4.1.3, AA)**: “Saved”, “Upload complete” and result counts should use `role="status"` or a live region, so screen readers hear them without losing their place.

## What do WCAG 2.2's new criteria change for web apps?

| Criterion | Level | What it means in an app |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Sticky toolbars, banners and chat widgets must not completely cover the focused element |
| 2.5.7 Dragging Movements | AA | Anything done by dragging, such as reordering a kanban board, needs a single-pointer alternative, for example a menu or up and down buttons |
| 2.5.8 Target Size (Minimum) | AA | Buttons and links at least 24 × 24 CSS pixels, or spaced so a 24-pixel circle around each doesn't overlap another |
| 3.2.6 Consistent Help | A | Help links, chat and contact details in the same relative place on every page |
| 3.3.7 Redundant Entry | A | Information already entered in the same process is filled in or selectable |
| 3.3.8 Accessible Authentication (Minimum) | AA | Login without memorizing or transcribing, unless paste, password managers or another method is allowed |

WCAG 2.2 also removed 4.1.1 Parsing, which no longer has a practical effect on accessibility ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)).

## What about timeouts, layout and zoom?

- **Session timeouts (2.2.1, A)**: warn people before a session expires and let them extend it with a simple action, unless the time limit is essential or longer than 20 hours. Saving work in progress avoids the worst outcome.
- **Reflow (1.4.10, AA)**: content must work at 320 CSS pixels wide (the equivalent of zooming to 400% on a 1280-pixel screen) without scrolling in two directions; data tables and similar content are exempt.
- **Text spacing (1.4.12, AA)**: increasing line height and letter spacing shouldn't cut off text, which fixed-height containers often do.
- **Orientation (1.3.4, AA)**: don't lock the app to portrait or landscape unless it's essential.

## What is an ACR, and do you need one?

An Accessibility Conformance Report (ACR) documents how a product meets each accessibility criterion: supports, partially supports or does not support, with remarks. Most are written on the VPAT template published by the Information Technology Industry Council, which has editions for WCAG, the US Section 508 standards and the European standard EN 301 549 ([ITI](https://www.itic.org/policy/accessibility/vpat)).

US federal agencies must buy accessible technology under Section 508 ([Section508.gov](https://www.section508.gov/)), and EU public bodies refer to EN 301 549, so B2B products selling to those customers are often asked for an ACR during procurement. An honest ACR, with known gaps listed, is more useful to buyers than one that claims full support. It should be based on testing the product, including manual testing; an automated scan alone can't fill it in.

If you sell to consumers in the EU, the European Accessibility Act may also apply to how you sell online; our [EAA guide](/blog/european-accessibility-act-online-stores) explains its scope. This isn't legal advice.

## How should a SaaS team test accessibility?

1. **Automate the basics.** Run axe-core or a similar engine in your end-to-end tests and on the marketing site, and fail builds on new violations. Our [free accessibility checker](/website-accessibility-checker) runs the same engine on any public page.
2. **Test with a keyboard.** Complete your main workflows, such as sign-up, creating a record and changing settings, using only Tab, Shift+Tab, Enter, Space, Escape and the arrow keys.
3. **Test with a screen reader.** NVDA on Windows and VoiceOver on macOS and iOS are free. Check that names, roles, states and messages are announced.
4. **Zoom and resize.** Check 200% text zoom and a 320-pixel-wide window.
5. **Fix in the design system.** Most failures come from shared components; fixing a button or dialog once fixes it everywhere.

## Frequently asked questions

### Does WCAG apply to logged-in parts of a web app?

WCAG applies to any web content, including pages behind a login. Whether a law requires a specific product to meet it depends on the jurisdiction and the customer, but buyers who ask about accessibility usually mean the whole product.

### Can an overlay make a SaaS product accessible?

No. Overlays don't change the underlying code of custom components, which is where application failures live. Our guide on [accessibility overlays](/blog/accessibility-overlays-ftc-order) covers the FTC's action against a leading overlay vendor.

### How much of WCAG can automated tools check?

Only part of it. Automated rules reliably find missing names, labels and contrast failures, but many criteria, such as meaningful focus order, useful alt text and understandable error messages, need a person to judge.

### Which WCAG version should we target?

WCAG 2.2 Level AA is the current version. Many laws and procurement rules still reference WCAG 2.1 AA; meeting 2.2 AA also meets 2.1 AA, apart from the removed Parsing criterion.

### Do we need to meet Level AAA?

W3C doesn't recommend requiring AAA for entire products, because some content can't meet every AAA criterion. Level AA is the usual target.

## Sources

- W3C: [What's new in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)