Accessibility testing with real users: a WCAG 2.2 practical guide

An automated scanner can tell you a button has no label. It cannot tell you that a blind user gave up on your checkout after four minutes of hunting. This practical guide shows you how to run accessibility testing with real users against WCAG 2.2, which criteria to focus on, which assistive technologies to cover and how to turn findings into fixes.

Why accessibility testing needs real users

Automated tools are fast and cheap, so start with them. However, they can only check what is machine-detectable: missing alt attributes, contrast ratios, empty links and some ARIA errors. They cannot judge whether alt text makes sense, whether focus order is logical or whether an error message is understandable.

Expert audits go further. A trained auditor walks through each criterion manually. Still, an expert who uses a screen reader for testing is not the same as someone who uses one eight hours a day. Daily users move faster, rely on shortcuts and abandon sooner when something is confusing.

As a result, the most reliable programs combine all three layers. Scanners catch regressions in CI, audits map compliance and real users reveal whether the product actually works.

The three layers compared

WCAG 2.2 criteria that matter most in accessibility testing

WCAG 2.2 became a W3C Recommendation in October 2023. You can read the full standard at the W3C’s WCAG 2.2 specification. Most organizations target Level AA. Below are the criteria that most often fail in real sessions, including the new ones.

New in WCAG 2.2

Long-standing criteria that still fail often

• 1.1.1 Non-text Content: icons and images without useful text alternatives.
• 1.3.1 Info and Relationships: headings, lists and form labels not exposed to assistive tech.
• 1.4.3 Contrast (Minimum): body text below 4.5:1, often in gray placeholder text.
• 1.4.10 Reflow: content that requires horizontal scrolling at 320 CSS pixels wide.
• 2.1.1 Keyboard and 2.1.2 No Keyboard Trap: modals and date pickers that trap or skip focus.
• 2.4.3 Focus Order and 2.4.7 Focus Visible: focus jumping around or invisible.
• 3.3.1 Error Identification: errors shown only in red, or not announced.
• 4.1.2 Name, Role, Value: custom controls with no accessible name or state.
• 4.1.3 Status Messages: “Added to cart” or “Saved” messages not announced.

Which assistive technologies to cover

Your users choose their tools, so your coverage should follow them. Build an assistive technology matrix, just as you would a device matrix. For example:

In addition, include system settings that many people use without thinking of them as assistive tech: largest text size, bold text, reduce motion, high contrast and dark mode. These settings break layouts often, so they belong in every round of accessibility testing.

Planning accessibility testing sessions with real users

Good sessions are built around tasks, not pages. A user does not “test the header.” They try to buy a train ticket, book an appointment or reset a password. Therefore, write tasks that mirror your most important journeys.

A step-by-step plan

1. Pick three to five critical tasks. For example: create an account, find a product, complete checkout with Apple Pay, contact support.
2. Define participant groups. Screen reader users, low vision users, keyboard or switch users, and people with cognitive or motor disabilities.
3. Recruit five to eight people per group. Match devices and assistive tech to the matrix above.
4. Prepare accessible materials. Consent forms, instructions and test accounts must themselves be accessible.
5. Run sessions remotely on participants’ own setups. Their configured device reflects real use far better than a lab machine.
6. Observe and record. Capture screen, audio from the screen reader and the participant’s comments, with consent.
7. Debrief and map findings to WCAG. Note the criterion, the assistive tech and the severity.

Moderated or unmoderated?

Moderated sessions let you ask why a user hesitated, which is valuable for complex flows. Unmoderated sessions scale better and capture natural behavior. Many teams use both: moderated rounds for new features, then unmoderated checks after fixes. For more on the trade-offs, read our guide to remote usability testing at scale.

Reporting accessibility issues developers can fix

An accessibility bug needs more context than a typical bug. The developer often cannot reproduce it without the same assistive technology and settings. Consequently, every report should include:

• A title with area, symptom and assistive tech, for example “[Checkout] TalkBack reads ‘button’ with no name for Apple Pay on Pixel 8.”
• The WCAG criterion and level, such as 4.1.2 Name, Role, Value (A).
• Assistive technology, version, browser and device.
• Exact steps, including gestures or keys used, such as “swipe right three times” or “Tab, Tab, Enter.”
• What the assistive tech announced, quoted word for word.
• User impact, for example “User cannot complete purchase without sighted help.”
• A suggested fix where obvious, such as adding an accessible name.

Prioritizing accessibility fixes

Prioritize by task impact, not by count. A single unlabeled “Pay” button that blocks checkout outranks twenty decorative images with missing alt text. Use a simple scale:

• Blocker: the user cannot complete a critical task.
• Serious: the task is possible but with major effort or help.
• Moderate: friction or confusion, with a workaround.
• Minor: small inconsistencies that do not affect task success.

Then, fix blockers before release, and schedule serious issues for the next sprint. Similar triage rules apply to all crowd findings, as covered in our bug triage guide.

Common accessibility testing mistakes to avoid

Teams new to accessibility testing tend to repeat a few predictable errors. Each one wastes budget or, worse, creates false confidence.

• Treating a clean scan as a pass: a zero-error report from an automated tool says nothing about whether a screen reader user can finish checkout.
• Testing only on desktop: many assistive technology users rely on phones first, so VoiceOver on iPhone and TalkBack on Android deserve equal weight.
• Testing pages instead of journeys: each page may pass on its own, yet the flow fails when focus is lost after a modal closes.
• Ignoring third-party widgets: chat bubbles, cookie banners, payment iframes and map embeds frequently break focus and announcements.
• Skipping retests: a fix for one screen reader can break another. Therefore, verify every fix with the assistive tech that found it.
• Running accessibility testing only once a year: by the time the annual audit arrives, dozens of releases have shipped untested.

In short, accessibility testing works when it is continuous, task-based and grounded in how real people use their own tools.

Building accessibility testing into every release

One-off audits decay. New features ship, components change and regressions slip in. Therefore, make accessibility testing a habit at every stage.

• Design: check contrast, target size and focus states in design files before handoff.
• Development: add automated checks to CI, and use accessible components by default.
• QA: include keyboard and screen reader checks in your release checklist.
• Release: run real-user sessions on new or changed critical flows.
• Production: give users an accessible way to report barriers, and route those reports to an owner.

Over time, track the number of blockers found per release and the time to fix them. If blockers keep appearing in the same component, invest in fixing the component library rather than each instance.

Legal and market context

Accessibility is also a market requirement. The European Accessibility Act applies to many digital products and services sold in the EU from June 2025, and many public sector and enterprise buyers require WCAG conformance. In addition, accessible products are simply easier for everyone to use, including older users and anyone on a small screen in bright sunlight.

TestGate’s accessibility testing service combines expert review with real assistive technology users on real devices, and every finding is reproduced and mapped to WCAG before it reaches your backlog.

Frequently asked questions

Is automated accessibility testing enough for WCAG compliance?

No. Automated tools reliably detect only a portion of WCAG issues, such as missing alt attributes or low contrast. Keyboard flow, screen reader meaning, focus order and cognitive clarity need manual checks and real users.

What is new in WCAG 2.2?

WCAG 2.2 added nine success criteria, including Focus Not Obscured (2.4.11), Dragging Movements (2.5.7), Target Size Minimum (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7) and Accessible Authentication (3.3.8). It also removed 4.1.1 Parsing.

Which assistive technologies should I test with?

At minimum, cover VoiceOver on iOS and macOS, TalkBack on Android, NVDA or JAWS on Windows, keyboard-only navigation, zoom and magnification, and voice control. Choose versions and browsers based on your users.

How many users with disabilities should take part in testing?

For a focused round, five to eight participants per assistive technology group usually reveals the main barriers. Repeat rounds after fixes rather than running one very large study.

Make your product work for every user

Run your next accessibility round with real assistive technology users and WCAG-mapped results: talk to us.

#accessibility testing #inclusive design #screen readers #usability #wcag 2.2