An Accessibility Testing Checklist for Web Apps (WCAG 2.2)

Why a checklist, and why WCAG 2.2

The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility. WCAG 2.2 became a W3C Recommendation in October 2023, building on 2.1 with nine new success criteria, most aimed at keyboard users, people with low vision, people with cognitive disabilities and touch users. Level AA is the usual target in contracts, procurement and regulation.

Laws in many markets point to WCAG, from public sector rules to the European Accessibility Act, in force since June 2025, which applies to many products and services sold in the EU and references WCAG through the EN 301 549 standard. WCAG 3.0 is still a W3C working draft, so WCAG 2.2 Level AA remains the target to test against. This checklist is a practical testing guide, not legal advice; it helps teams catch the issues that matter most to real users.

1. Run automated scans, and know their limits

Automated tools such as axe DevTools, Lighthouse and WAVE find missing alt text, missing form labels, low contrast, invalid ARIA and similar issues quickly. Add axe-core to your end-to-end tests so regressions fail the build. But automated tools can only detect a portion of WCAG issues; they cannot judge whether alt text is meaningful, whether focus order makes sense or whether a custom widget works with a screen reader. Manual testing is essential.

2. Test with the keyboard only

Put the mouse away and use Tab, Shift+Tab, Enter, Space, Escape and the arrow keys. Many serious problems show up within minutes:

• Every interactive element can be reached and used, including menus, modals, date pickers and custom dropdowns
• Focus order follows the visual and logical order
• A visible focus indicator is always present; never remove outlines without a replacement
• No keyboard traps: focus can always leave a component
• A skip link lets users jump past repeated navigation
• Modals move focus inside when opened, keep it there and return it to the trigger when closed

3. Test with a screen reader

Use at least one screen reader per platform you support: NVDA or JAWS on Windows, VoiceOver on macOS and iOS and TalkBack on Android. Navigate by headings, landmarks and form fields, the way regular screen reader users do. Check that every control has a meaningful name, role and state, such as a toggle announcing whether it is on or off, and that images convey their purpose through alt text, or are hidden when decorative.

Prefer native HTML elements, such as button, a, input and select, over divs with click handlers. The first rule of ARIA is to avoid it when a native element does the job, because incorrect ARIA is worse than none.

4. Check color, contrast and zoom

Normal text needs a contrast ratio of at least 4.5:1 against its background, and large text 3:1. Icons, input borders and focus indicators need at least 3:1 against adjacent colors. Our color contrast checker gives the ratio for any pair of colors. Never rely on color alone to convey meaning, such as red for errors; add text or an icon.

• Zoom to 200%: all content and functions still work
• At a 320 CSS pixel wide viewport, content reflows without horizontal scrolling, except for things like data tables and maps
• Increased text spacing does not cut off or overlap text

5. Check forms and errors

Forms are where accessibility failures cost conversions. Every input needs a visible label tied to it programmatically. Required fields are indicated in text, not only with an asterisk color. Errors are described in text next to the field, announced to screen readers and include a suggestion for fixing them where possible. Inputs collecting personal data use the right autocomplete attributes, which helps people with motor and cognitive disabilities fill forms quickly.

6. Check dynamic content and motion

Single-page apps change content without a page load, which screen reader users may never notice. Announce important updates, such as "Item added to cart" or search result counts, with an ARIA live region, and move focus or update the page title on route changes. Respect the prefers-reduced-motion setting, and give users a way to pause anything that moves, blinks or auto-updates for more than five seconds. Provide captions for video and transcripts for audio.

7. Test the criteria added in WCAG 2.2

These are the WCAG 2.2 additions at levels A and AA, which older checklists built for 2.1 often miss:

• Focus Not Obscured (Minimum): a focused element is not completely hidden by sticky headers, footers or cookie banners
• Dragging Movements: anything done by dragging, such as reordering or sliders, also works with single clicks or taps
• Target Size (Minimum): pointer targets are at least 24 by 24 CSS pixels, or have enough spacing, with some exceptions
• Consistent Help: help options such as contact links or chat appear in the same relative place across pages
• Redundant Entry: information already entered in a process is filled in or selectable, not asked for again
• Accessible Authentication (Minimum): sign-in does not require a cognitive test like remembering or transcribing a code without support, so allow paste and password managers

Mobile and touch checks

Many people use web apps on phones with assistive technology. Check these on real devices:

• Pinch zoom is not disabled in the viewport meta tag
• The app works in both portrait and landscape orientation
• Gestures such as swipes have a simple tap alternative
• Touch targets meet the size or spacing requirement
• Content works with VoiceOver and TalkBack gestures, not just with a keyboard

Most common failures to look for first

If you only have an hour, test the issues that most often block users: images without useful alt text, form fields without labels, low-contrast text, buttons built from divs that keyboards cannot reach, missing focus indicators, modals that do not manage focus and error messages that only appear in red. Fixing these usually improves the experience for everyone, not only for people using assistive technology.

Record findings so they get fixed

For each issue, record the page, the WCAG success criterion, the impact on users, steps to reproduce and a suggested fix, then prioritize by severity rather than by order found. Publish an accessibility statement describing your target level and known issues. Business customers may also request an Accessibility Conformance Report, often based on the VPAT template, during procurement.

8. Build it into the process

Accessibility is cheapest when it is part of everyday work rather than an audit before launch. Include accessible components in your design system, add accessibility acceptance criteria to stories, run automated checks in CI and do a quick keyboard pass on every new feature during review. Schedule a full manual audit, ideally including testing with disabled users, before major releases.

Nexzem's accessibility testing service covers WCAG 2.2 audits, screen reader testing and remediation guidance for existing web apps.