Accessibility beta testing: a WCAG 2.2 starter checklist for product teams

Accessibility beta testing for product teams: a WCAG 2.2 starter checklist for keyboard, focus, contrast, labels, errors and the new 2.2 criteria. By betatest.ing team · October 13, 2026 · 7 min read.

Key takeaways

WCAG 2.2 Level AA is the practical target; most teams start with keyboard access, focus visibility, contrast, labels and error messages.
Automated scanners find roughly the mechanical issues (missing labels, contrast, structure); keyboard and screen reader testing finds the rest.
The new 2.2 criteria focus on focus appearance, dragging alternatives, target size, consistent help and accessible authentication.
Include at least one tester who relies on assistive technology; nothing else substitutes.
Fix accessibility bugs with the same severity scale as any other bug; a keyboard trap is a high.

Accessibility testing is often left until someone asks for a compliance statement. Beta is a better time: the product is nearly finished, real people are about to use it, and the fixes are still cheap. This checklist is a starting point for teams who have not done accessibility testing before. It is based on the Web Content Accessibility Guidelines (WCAG) 2.2, the W3C standard that most laws and procurement requirements reference.

What "WCAG 2.2 Level AA" means in practice

WCAG is organized into four principles (perceivable, operable, understandable, robust), each with success criteria at three levels: A, AA and AAA. Level AA is what most regulations and contracts require and what most teams aim for. WCAG 2.2, published by the W3C in 2023, added nine criteria to 2.1 and removed one (4.1.1 Parsing). If you are starting now, start with 2.2.

You do not need to audit all of it in a beta. The checklist below covers the criteria that account for most real-world failures, grouped the way you will actually test them.

Part 1: Keyboard and focus

Many users never touch a mouse: people with motor impairments, screen reader users, power users. If your product cannot be used with a keyboard alone, nothing else on this list matters.

Everything reachable and operable by keyboard (2.1.1). Tab through every page. Every link, button, form control, menu and custom widget must be reachable and usable with Tab, Shift+Tab, Enter, Space and arrow keys as appropriate.
No keyboard traps (2.1.2). You can always Tab out of a component. Modals must return focus to where it came from when closed.
Focus is visible (2.4.7) and, new in 2.2, focus is not obscured (2.4.11): the focused element is not hidden behind a sticky header, cookie banner or chat widget.
Focus order makes sense (2.4.3). It follows the visual reading order, and opening a dialog moves focus into it.
Skip link (2.4.1). A "skip to content" link as the first focusable element on each page.

How to test: Unplug the mouse for twenty minutes and complete your core flows. Note every place you got stuck or lost track of where you were.

Part 2: Text, contrast and zoom

Contrast of text at least 4.5:1 for normal text and 3:1 for large text (1.4.3). Light gray placeholder text on white is the classic failure.
Contrast of UI components and graphics at least 3:1 (1.4.11): input borders, icons that carry meaning, focus indicators, chart elements.
Text can be resized to 200% without loss of content (1.4.4), and the page reflows at 320 CSS pixels wide without horizontal scrolling (1.4.10). Test by zooming the browser to 400% at a 1280 pixel width.
Text spacing can be increased without clipping (1.4.12).
Do not use color alone to convey information (1.4.1): a red border with no message, a green dot with no label.

How to test: A contrast checker for the palette, then browser zoom at 200% and 400% through the core flows.

Part 3: Structure and names

Screen readers navigate by structure. If structure is missing, the page is a flat list of words.

One h1 per page and a logical heading hierarchy (1.3.1, 2.4.6). Headings are real heading elements, not styled paragraphs.
Page titles are unique and describe the page (2.4.2).
Landmarks: header, nav, main, footer (1.3.1). They let users jump around.
Images have alt text that conveys purpose, or are marked decorative (1.1.1). Icon buttons have accessible names.
Link text makes sense out of context (2.4.4). Not five links that all say "Learn more".
Form controls have labels programmatically associated with them (1.3.1, 3.3.2, 4.1.2). Placeholder text is not a label.
Custom widgets expose name, role and state (4.1.2): a toggle announces as a switch that is on or off; a dropdown announces its options.
Language of the page is declared (3.1.1).

How to test: An automated scanner catches most of these. Then turn on a screen reader (VoiceOver on macOS and iOS, NVDA on Windows, TalkBack on Android) and navigate by headings, landmarks and form fields.

Part 4: Forms and errors

Forms are where accessible products most often fail their users, and the fixes help everyone.

Errors are identified in text and describe the problem (3.3.1). "Enter a date in the format MM/DD/YYYY", not a red outline.
Labels or instructions are present for required fields and formats (3.3.2).
Error suggestions where possible (3.3.3).
Errors are announced to screen reader users and focus moves to the first error or to an error summary.
Redundant entry (3.3.7, new in 2.2): do not make users re-enter information they already provided in the same process, unless essential.
Accessible authentication (3.3.8, new in 2.2): no cognitive function test (like solving a puzzle or transcribing distorted text) is required to log in unless an alternative is offered. Allow paste in password fields; support password managers.

The form validation testing guide pairs well with this section.

Part 5: Pointer, motion and timing

Target size (2.5.8, new in 2.2): interactive targets are at least 24 by 24 CSS pixels, or have enough spacing from their neighbors. Small icon buttons in dense toolbars are the usual offender.
Dragging movements (2.5.7, new in 2.2): anything that can be done by dragging can also be done without it (reorder with buttons, resize with a field).
Motion can be paused or disabled (2.2.2, 2.3.3). Respect the prefers-reduced-motion setting; auto-playing carousels have controls.
No flashing more than three times per second (2.3.1).
Time limits can be extended or turned off (2.2.1), including session timeouts that lose a user's work.
Orientation is not locked (1.3.4) unless essential.

Part 6: Consistency and help

Consistent navigation and identification (3.2.3, 3.2.4): the same thing is called the same thing and lives in the same place across pages.
Consistent help (3.2.6, new in 2.2): if you offer help (chat, contact, FAQ), it appears in the same relative place on every page.
No change of context on focus or input without warning (3.2.1, 3.2.2): a dropdown does not submit the form when you arrow through it.

Part 7: Media

Captions for video with audio (1.2.2) and transcripts or audio description as appropriate (1.2.1, 1.2.3, 1.2.5).
Audio does not autoplay without a way to stop it (1.4.2).

Splitting the work: automated, manual, assistive-technology users

Automated scanners (browser extensions, CI tools, and AI beta testers that include accessibility checks) reliably find missing alt text, missing labels, contrast failures, heading structure, duplicate IDs and ARIA misuse. They are fast and they should run on every build. They cannot judge whether alt text is meaningful, whether focus order makes sense or whether an error message helps.

Manual testing by the team (keyboard-only, zoom, screen reader basics) catches most of the rest. Thirty minutes per core flow is enough to find the serious problems.

Testers who rely on assistive technology find what neither of the above does: the places where the product is technically compliant and still unusable. Recruit at least one screen reader user and, if your product involves fine pointer control, one user with a motor impairment. Pay them; this is expert work. Nielsen Norman Group's research on accessibility and usability is a good primer on why compliance and usability are not the same thing.

Reporting accessibility bugs

Treat them as bugs, with the same template and severity scale as everything else. Steps, expected vs actual, environment (including the assistive technology and browser combination), evidence, severity. Suggested severity mapping:

Critical: a core flow cannot be completed with a keyboard or screen reader at all; content flashes.
High: keyboard trap; focus lost on a core flow; form errors not identified in text; login requires a cognitive test with no alternative.
Medium: contrast failures on primary text or controls; missing labels on non-core forms; focus obscured by sticky elements.
Low: decorative images with unnecessary alt text; minor heading hierarchy issues; small targets in non-core areas.

Cite the WCAG criterion number in each report so developers can look up the exact requirement and technique.

A one-week accessibility beta plan

Day 1: Run an automated scan across every page, logged out and logged in. Fix the mechanical failures.
Day 2: Keyboard-only run through the core flows. File keyboard traps and focus issues as high.
Day 3: Zoom and reflow at 200% and 400%; contrast review of the palette.
Day 4: Screen reader pass on the core flows by a team member who has practiced for an hour first.
Days 5–7: Sessions with one or two assistive technology users on the core flows. Record (with consent) and watch.

Then fold the automated scan and the keyboard checks into your regular regression runs so they do not drift. The accessibility testing guide has a ready-made test task that covers steps 1 to 3.

Checking the basics in minutes

betatest.ing includes accessibility checks in every beta test: it tests your product in a real browser and on phones, flags missing labels, contrast failures, keyboard and focus problems, small targets and structure issues, and files each as a bug with the WCAG criterion, steps, severity and an annotated screenshot. For a quick look at a public page, the free website checker reports the most common accessibility issues alongside broken links and errors.

Start for $1 and get the mechanical accessibility bugs out of the way before your assistive technology testers arrive.

Related guides

Each ends with a test task you can send to your AI beta tester.

All beta testing guides

Keep reading

The 15 most common bugs found in beta tests (and how to catch them early) — Beta tests find the same bugs over and over: emails that never arrive, forms that accept nonsense, buttons that die after an error, layouts that break on small phones. Fifteen of them, with fixes.
How to beta test a SaaS app before launch: a 10-step checklist — SaaS products fail in beta in predictable places: signup, invitations, billing, permissions and the empty states nobody designed. This checklist walks through all ten steps in order.
From beta to launch: how to decide your product is ready — "Ready" is a decision, not a feeling. Write exit criteria before the beta, measure against them at the end, and launch with a known-issues list instead of waiting for zero bugs.

All articles