Accessibility Testing Checklist (WCAG 2.2)

An accessibility testing checklist turns good intentions into repeatable quality work. Teams often say they care about inclusion, then ship forms you cannot complete with a keyboard, modals that trap focus, or errors that never get announced. WCAG 2.2 gives you a shared standard. A practical checklist gives you a way to apply that standard on real web apps.

This guide provides a WCAG 2.2 AA oriented accessibility testing checklist, explains A vs AA vs AAA, shows an accessibility audit process for web apps, and helps QA engineers write functional accessibility test cases. You will also get severity guidance, evidence tips, and common mistakes that create false confidence.

Accessibility Testing Checklist Overview

This accessibility testing checklist is built for working QA engineers who need WCAG 2.2 AA coverage on real product journeys. It is intentionally practical: define scope, scan, keyboard test, screen reader test, visual check, file impactful defects, then prevent regressions. You can copy sections into tickets, test plans, and release gates without rewriting the entire WCAG standard each time.

Use the full detail below as your handbook, then keep the short smoke card at the end for every front end change.

Why Accessibility Testing Belongs in QA

Accessibility is not only a design concern or a legal afterthought. It is product behavior:

• Can people perceive the content?
• Can people operate the interface?
• Can people understand the system responses?
• Does the UI work robustly with assistive technologies?

If a user cannot complete checkout with a keyboard, that is a functional failure. If a screen reader user cannot identify form errors, that is a functional failure. Treat these as quality bugs with user impact, not cosmetic nits.

WCAG Basics for Testers

WCAG means Web Content Accessibility Guidelines. Version 2.2 is the current reference for many teams in 2026. Criteria are organized under four principles:

Principle	Meaning	Example QA focus
Perceivable	Users can sense the information	Text alternatives, contrast, captions
Operable	Users can control the UI	Keyboard, focus, targets, timing
Understandable	Users can comprehend UI and content	Labels, errors, consistent navigation
Robust	Content works with current and future AT	Valid names, roles, states, markup

WCAG A vs AA vs AAA

Level	Role	Typical product target
A	Minimum barrier reduction	Necessary but usually not sufficient alone
AA	Strong common compliance and quality target	Most organizations aim here
AAA	Highest, often not practical for every page of complex apps	Selective enhancement

When stakeholders ask for accessibility, clarify the target. "Make it accessible" is not a requirement. "Meet WCAG 2.2 AA on all authenticated customer journeys" is a requirement.

If the team is debating conformance scope, use WCAG AA vs AAA to separate practical release criteria from aspirational enhancements.

Accessibility Audit Process for Web Apps

Use a process, not random spot checks.

Step 1: Define Scope and Target

• Product areas and templates in scope.
• WCAG version and level (commonly 2.2 AA).
• Platforms: desktop web, mobile web, native wrappers if any.
• Assistive tech matrix: for example NVDA plus Firefox or Chrome, VoiceOver plus Safari.
• Critical user journeys ranked by risk.

Step 2: Inventory Templates and Components

List page types and shared components:

• Global navigation.
• Auth screens.
• Search and filters.
• Forms.
• Tables.
• Modals and drawers.
• Toasts and alerts.
• Media players.
• Admin dense UIs if relevant.

Component level bugs multiply across pages. Finding a bad modal pattern once can fix dozens of screens.

Step 3: Run Automated Scans

Use tools such as axe based scanners in browsers and CI. Automation is excellent for:

• Missing form labels.
• Some contrast issues.
• Duplicate accessible names.
• Certain ARIA misuses.
• Empty buttons and links.

Automation is weak at:

• Focus order sense.
• Keyboard traps in complex widgets.
• Whether alt text is meaningful.
• Whether instructions are understandable.
• Dynamic live region quality.

Follow up with a dedicated automation guide when you implement CI: automated accessibility testing with axe-core.

Step 4: Manual Keyboard Pass

Unplug from the mouse mentality. For each critical journey:

• Tab and shift tab through interactive elements.
• Use Enter and Space where expected.
• Use Escape for dismissible layers.
• Arrow keys for appropriate composite widgets.
• Confirm focus visibility at every stop.
• Confirm no trap without recovery.

Deepen this later with keyboard navigation testing.

Step 5: Screen Reader Pass

Test realistic tasks, not only page open announcements. Example tasks:

• Sign in.
• Find a product.
• Submit a form with errors, then correct them.
• Complete checkout.
• Open and close a modal dialog.
• Read a data table summary if tables are critical.

Use a practical matrix and task scripts from screen reader testing.

Step 6: Visual and Sensory Checks

• Contrast for text and essential icons.
• Focus not relying on color alone.
• Zoom to 200 percent and reflow behavior where required.
• Motion and flashing risks if relevant.
• Captions and transcripts for media.

For contrast detail, see color contrast and visual accessibility testing.

Step 7: Log Defects with Impact and Mapping

Each bug should include:

• User impact.
• Steps with keyboard or AT notes.
• Expected accessible behavior.
• Actual behavior.
• Screenshot or recording.
• Suspected WCAG success criteria.
• Severity.

Step 8: Retest and Prevent Regression

Accessibility fixes often break again when components change. Add:

• Automated rules in CI for stable checks.
• Component stories with accessibility assertions.
• Manual checklists for high risk releases.
• Design system guidance so teams stop reintroducing bad patterns.

WCAG 2.2 AA Testing Checklist

Use this as a practical QA checklist. It is not a substitute for the full WCAG text, but it covers high frequency product failures.

A. Page Structure and Navigation

• Page has a descriptive, unique title.
• Main landmark or main content region exists.
• Heading hierarchy is logical (no random level jumps for style only).
• Skip link or equivalent way to bypass repeated navigation exists where needed.
• Navigation order is consistent across similar pages.
• Breadcrumbs or location cues are available in complex apps when needed.
• Links have meaningful names, not "click here" alone.

B. Keyboard and Focus

• All interactive controls are reachable by keyboard.
• Focus order matches visual and logical order.
• Focus is always visible.
• No keyboard trap in menus, modals, widgets, or embeds.
• Modal opens move focus into the dialog.
• Modal close returns focus to a sensible trigger.
• Escape closes dismissible dialogs unless a strong reason prevents it.
• Custom widgets support expected keys (arrows, home/end where relevant).
• Target sizes meet WCAG 2.2 expectations for pointer targets where applicable.

C. Forms and Errors

• Every input has an accessible name (label, aria-label, or aria-labelledby).
• Required fields are programmatically indicated.
• Instructions are available before errors when needed.
• Error messages identify the field in text.
• Error messages describe how to fix the problem.
• Errors are associated with fields programmatically when possible.
• Focus or announcement strategy helps users find the first error.
• Success confirmations are perceivable by AT users.
• Timeouts provide accessible warnings and extension options where required.

D. Name, Role, State, and Dynamic Updates

• Buttons are real buttons or have correct button roles and keyboard support.
• Links navigate, buttons act. Do not confuse them without care.
• Expand/collapse controls expose state (expanded/collapsed).
• Selected tabs and options expose selected state.
• Loading indicators are announced or otherwise accessible.
• Toasts and status messages use appropriate live regions when needed.
• UI updates after filtering or sorting are understandable without sighted context.

E. Images, Media, and Non Text Content

• Informative images have appropriate alternative text.
• Decorative images are hidden from AT.
• Complex images provide longer descriptions when needed.
• Icons that convey meaning have accessible names.
• Video has captions where speech or essential audio exists.
• Audio only content has transcripts when required.
• Media players are keyboard operable.

F. Visual Design and Contrast

• Text contrast meets AA thresholds for normal and large text.
• UI components and graphical objects that convey state meet contrast expectations.
• Information is not conveyed by color alone.
• Focus indicators have sufficient visibility.
• Content reflows and remains usable when zoomed.
• Text spacing and clipping do not hide meaning under user text settings where relevant.

G. Consistency, Help, and Robustness

• Repeated components appear in consistent order.
• Help mechanisms are consistently located if provided.
• Accessible names match visible labels closely enough to avoid speech control confusion.
• Markup and component semantics remain valid after client side rendering.
• No critical function depends on a single unsupported input modality alone.

H. WCAG 2.2 Focused Additions Worth Explicit Testing

WCAG 2.2 adds and strengthens criteria that hit modern product UI. Explicitly test:

• Focus not obscured by sticky headers or cookie banners.
• Dragging alternatives for drag only actions.
• Help consistency.
• Accessible authentication considerations for cognitive load and non memory based auth barriers where relevant.
• Target size adequacy for pointer interactions.

Map each product risk to the exact success criterion during formal audits.

Functional Accessibility Test Cases

Write accessibility cases with the same discipline you use for any functional suite.

Example Case Format

Test Case ID: A11Y-FORM-004
Title: Keyboard user can submit contact form after validation errors
Preconditions: Keyboard only, no screen reader required for this case
Steps:
  1. Open the contact form.
  2. Tab to Submit without filling required fields.
  3. Activate Submit with Enter.
  4. Observe error messaging and focus behavior.
  5. Tab to the first invalid field.
  6. Correct all required fields using keyboard only.
  7. Submit again.
Expected Result:
  - Errors are visible in text and associated with fields.
  - Focus or a clear path leads to the first error.
  - User can correct fields and submit successfully without a mouse.
  - Success message is visible and not only a color change.

More High Value Cases

ID	Case	Why it matters
A11Y-NAV-001	Skip link moves focus to main content	Saves repetitive tabbing
A11Y-MODAL-002	Dialog traps focus until closed, then restores focus	Prevents context loss
A11Y-MENU-003	Top nav works with keyboard and announces expansion	Core navigation barrier when broken
A11Y-SR-005	Screen reader announces form errors on submit	Error recovery for blind users
A11Y-TBL-006	Table headers are announced with cell values	Data comprehensibility
A11Y-TOAST-007	Status message is announced without stealing focus badly	Feedback without disruption
A11Y-ZOOM-008	Page usable at 200 percent zoom	Low vision usability
A11Y-DRAG-009	Drag only board has keyboard alternative	WCAG 2.2 dragging risk

These are functional accessibility test cases because they assert operable outcomes, not only static properties.

Severity Guidance for Accessibility Bugs

Severity	Examples
Blocker	Cannot complete critical journey with keyboard or screen reader
High	Major information missing from AT, focus trap, unusable form errors
Medium	Confusing headings, inconsistent labels, partial contrast failures on secondary UI
Low	Minor naming polish, non critical redundant announcements

Legal and contractual context can raise severity. A medium contrast issue on a marketing page and a medium contrast issue on a medical results screen are not equal business risks.

Evidence That Helps Developers Fix Fast

Include:

• Browser and OS.
• Assistive technology and version when used.
• Input method: keyboard only, SR plus keyboard, pointer.
• URL and auth role.
• Exact control that failed.
• What was announced versus what should be announced.
• Short video for focus order or SR speech issues.
• Suspected component in the design system.

Bad report: "Page not accessible."

Good report: "In checkout shipping form, required ZIP field has no accessible name. NVDA announces 'edit blank'. Keyboard submit shows red border only, no text error. Blocks completion for SR users."

How Far Automation Should Go

A healthy split:

Layer	Use for	Do not rely on for
Unit/component a11y tests	Name/role/state regressions	Journey realism
axe in CI	Quick blocking rules	Full WCAG compliance
Manual keyboard	Operability	Color contrast math alone
Screen reader tasks	Real comprehension and flow	Every pixel on every page every time
Periodic formal audit	Coverage and legal confidence	Day to day regression speed

Automation is mandatory for scale. Manual testing is mandatory for truth.

Team Workflow for Continuous Accessibility

1. Design reviews include accessible interaction notes.
2. Components ship with keyboard and semantics acceptance criteria.
3. PR checks run automated rules on changed templates where feasible.
4. QA executes checklist items on touched journeys.
5. Release gates block critical accessibility regressions.
6. Production feedback from users is triaged with the same severity model.
7. Lessons become design system fixes, not one off page patches.

Accessibility debt compounds when fixes stay local and patterns stay broken.

Common Mistakes in Accessibility Testing

Mistake 1: Only Running an Automated Scanner

A clean axe run can still hide a keyboard trap. Scanners are a start.

Mistake 2: Testing Only the Homepage

Critical failures often live in auth, checkout, account settings, and admin tools.

Mistake 3: Checking Contrast but Ignoring Focus Order

A beautiful palette does not help if users cannot reach the control.

Mistake 4: Writing "Works with Screen Reader" Without Tasks

Always define the task and expected outcome.

Mistake 5: Filing Bugs Without WCAG or Impact Context

Developers prioritize better when user impact and criteria are explicit.

Mistake 6: Treating AAA as the Default Everywhere

Ambitious goals are fine, but unfocused AAA demands can stall delivery. Choose AA as the reliable baseline unless requirements say otherwise.

Mistake 7: No Retest After UI Library Upgrades

Component upgrades are a classic source of focus and ARIA regressions.

Mistake 8: Assuming Mobile Apps Need No Web A11y Thinking

Mobile web and hybrid apps still need operable, labeled controls and readable structures.

Practical Starter Plan for a QA Engineer This Week

Day 1: Pick one critical journey. Map steps and components.

Day 2: Run automated scan. File obvious defects.

Day 3: Keyboard only pass. Record focus issues.

Day 4: Screen reader pass on the same journey.

Day 5: Convert findings into regression cases and share a one page risk summary.

This starter plan builds skill quickly without waiting for a perfect enterprise program.

Journey Based Coverage Matrix

A checklist becomes powerful when mapped to journeys.

Journey	Keyboard	Screen reader	Forms/errors	Modals	Contrast	Automation
Sign up	Required	Required	Required	If used	Required	Required
Search and filter	Required	Required	If applicable	Facet drawers	Required	Required
Checkout	Required	Required	Required	Address widgets	Required	Required
Account settings	Required	Sampling	Required	Session dialogs	Sampling	Required
Marketing landing	Sampling	Sampling	Lead forms	Cookie banner	Required	Required

Mark each cell as pass, fail, or not run. This matrix prevents the false comfort of "we tested accessibility" when only the homepage was scanned.

Authentication, CAPTCHA, and Session Edge Cases

Modern apps create accessibility debt in security flows:

• CAPTCHA alternatives must be usable.
• One time password fields need clear labels and paste support where allowed.
• Session timeout warnings must be operable and understandable.
• Error states for locked accounts should not rely on color alone.
• Password managers and browser autofill should not break accessible names.

Test auth journeys explicitly. They are high impact and easy to overlook because specialized widgets sit outside the main design system.

Checklist Card You Can Copy into Tickets

Accessibility smoke for this change:
[ ] Keyboard can complete the changed flow
[ ] Focus visible and order sensible
[ ] Labels present on new inputs
[ ] Errors identified in text and linked to fields
[ ] Modal/drawer focus handling correct if used
[ ] Status messages perceivable
[ ] No new contrast regressions on text/controls
[ ] Automated scan clean on changed views
[ ] Screen reader task pass on critical path if interaction semantics changed
[ ] Sticky headers or banners do not hide focused controls

Attach this to front end tickets until it becomes habit.

Final Guidance

A strong accessibility testing checklist is a working agreement between design, engineering, and QA. Anchor on WCAG 2.2 AA unless your market requires more. Use an audit process that mixes automation, keyboard testing, screen readers, and visual checks. Write functional accessibility test cases with observable expected results. File defects with impact and evidence. Prevent regressions through components and CI.

Accessibility quality is product quality. When someone can complete the journey without sight, without a mouse, or with different cognitive needs, your product is more robust for everyone.

If you want structured practice writing precise expected results and risk based checks, train in the QABattle arena and convert each observation into a reusable accessibility case.

If you remember one rule, remember this: if a user cannot perceive it, operate it, or understand it, the feature is not done, no matter how polished it looks on a designer's laptop.