SaaS Accessibility: Forms, Contrast and Focus
Accessible SaaS is easier for everyone to use: clear labels, readable contrast, visible focus and forms that explain errors. It is also increasingly a requirement in enterprise and public-sector buying.
What does accessibility mean for a SaaS product?
For a SaaS product, accessibility means people using keyboards, screen readers, zoom or voice can sign up, log in and complete every core task. In practice, most teams start with WCAG 2.2 Level AA: sufficient contrast, labelled fields, described errors, visible focus, keyboard access, adequate target size and login without puzzles. WCAG 2.2 was published in October 2023 with nine new success criteria (W3C on what’s new in WCAG 2.2).
What does an accessible form look like next to an inaccessible one?
The inaccessible form uses faint placeholder text instead of labels, low-contrast borders and an error shown only in red. The accessible version has visible labels, readable contrast, an error in text, and a visible focus ring.
Placeholders that disappear while typing are a common problem: users forget what the field was for, and many placeholders fail contrast requirements.
What contrast does WCAG require?
WCAG 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, which it defines as at least 18 point, or 14 point bold (W3C on contrast minimum). Check text, placeholder text, disabled-looking buttons and text on coloured backgrounds, and never use colour alone to show status: pair it with text or an icon.
What should a SaaS accessibility checklist cover?
Start with the checks that affect the most users on the most important flows: signup, login, onboarding and billing. Fix those flows first, then extend to the rest of the product.
| Check | What to look for | WCAG |
|---|---|---|
| Contrast | Text 4.5:1, large text 3:1 | 1.4.3 |
| Labels | Every field has a visible, programmatic label | 1.3.1, 3.3.2 |
| Errors | Errors identified and described in text | 3.3.1 |
| Keyboard | Every action works without a mouse | 2.1.1 |
| Focus | Focus visible and not hidden by sticky headers | 2.4.7, 2.4.11 |
| Target size | At least 24 by 24 CSS pixels | 2.5.8 |
| Login | No puzzles or memory tests without alternatives | 3.3.8 |
| Redundant entry | Don’t make users re-type information already given | 3.3.7 |
Fix the components, fix the product.
Accessible buttons, fields and dialogs in your design system make every new screen accessible by default.
How do you build accessibility into the process?
Build it into design and review: check contrast in the design system, test every new screen with a keyboard, run an automated checker, and test key flows with a screen reader before release. Fixing accessibility in components once fixes it everywhere they are used. Related pages: error messages, login UX and mobile UX. Accessibility is part of the UX audit checklist.
Frequently asked questions
What accessibility standard should SaaS products meet?
WCAG 2.2 Level AA is the common target for SaaS and in many procurement requirements.
What contrast ratio does WCAG require?
At least 4.5:1 for normal text and 3:1 for large text under success criterion 1.4.3.
What changed in WCAG 2.2?
Nine new success criteria, including focus not obscured, target size minimum and accessible authentication.
Are placeholders enough instead of labels?
No. Use visible labels; placeholders disappear while typing and often fail contrast.
What is the minimum target size in WCAG 2.2?
24 by 24 CSS pixels at Level AA, with some exceptions.
Can automated tools check accessibility?
They find some issues. Keyboard and screen reader testing on key flows is still needed.
Sources & further reading
Standards and platform rules change. These sources let you verify the current requirements directly. All screens shown are mock-ups of fictional products.