# WCAG Testing Checklist for Developers and QA

Traditional Chinese version: [https://accesserty.com/ai/guides/wcag-testing-checklist.md](https://accesserty.com/ai/guides/wcag-testing-checklist.md)

Page version: [https://accesserty.com/en/guides/wcag-testing-checklist/](https://accesserty.com/en/guides/wcag-testing-checklist/)

Last updated: 2026-09-28

Check names, keyboard access, focus, forms, contrast and reflow with concrete steps and expected results. Record review items and untested scope; this is a preliminary checklist, not a full WCAG audit.

## Summary

- A WCAG checklist should be actionable, not only a list of success criteria numbers.
- Development and QA should check semantics, names, keyboard access, focus, errors, and contrast first.

## Record scope before results

This is a preliminary checklist of common items, not every WCAG 2.2 AA success criterion. Completing it does not establish conformance. Use the linked pre-launch workflow first if you have not selected pages to test.

For each item, record the page, state, date, version and method. Use checked with no issue found, issue found, needs review, not tested, or not applicable with a reason. Missing environments or assistive technology mean not tested, not passed because a scanner was silent.

## Structure, names and images

Compare actual content with the semantics exposed by the browser; a name being present does not make it useful.

- Page and headings: inspect the tab title, headings and major regions. Expected: the current page, content groups and main content are identifiable; heading levels express structure rather than font size.
- Control names: inspect accessible names for buttons, links and fields against visible wording and purpose. Expected: the action is identifiable and the name includes the visible label. Verify actual announcements separately with a screen reader.
- Images: review alternatives in their paragraph and link context. Expected: informative images convey needed information while decoration avoids redundant speech; do not judge only whether an alt attribute exists.

## Keyboard, focus and state

Complete the task without a mouse. Keyboard patterns differ between components; not every item needs its own Tab stop.

- Reach and operate: use Tab/Shift+Tab, Enter/Space on native buttons, and the pattern’s arrow keys for composite widgets. Expected: required actions work, the order makes sense, and there is no inescapable trap.
- Visible focus: check headers, sticky toolbars, popups and narrow screens. Expected: you can identify the current control and focus is not entirely obscured by other content.
- Open and return: open a dialog or menu, use it, then close it. Expected: focus enters and returns to a sensible place for that pattern. A modal dialog’s focus loop is not itself a trap, but a keyboard way to close it is needed.
- State: expand, collapse, select and trigger loading or errors. Expected: visible state matches accessible roles and states, and necessary result feedback is available to assistive technology. Leave speech verification not tested if it was not performed.

## Forms and error recovery

Use an authorized test environment and fictional data. Use test mode for payments, email and orders to avoid side effects for real users.

- Before input: inspect labels, required information and format instructions. Expected: users need not guess or rely only on a disappearing placeholder.
- After an error: omit a required value or enter invalid data and submit. Expected: the affected field and a correction path are identifiable, errors do not rely only on color, and messages are semantically associated with fields.
- Through completion: correct the input and submit again. Expected: relevant entries are preserved, focus remains usable, and success, failure or progress can be identified. For authentication, also check password-manager use and paste.

## Contrast, enlargement and reflow

Check actual page states, not just design files. These are starting checks; apply the relevant success criterion and its exceptions.

- Contrast: measure actual foreground and background in body text, links, errors and selected states. Expected: applicable text or non-text contrast requirements are met. Inactive controls have contrast exceptions; do not apply normal-text thresholds indiscriminately or rely on color alone.
- Reflow: for a normally vertically scrolling page, test at 320 CSS pixels wide or equivalent browser zoom. Expected: information and functions remain available without side-to-side reading of ordinary text. Necessary two-dimensional content such as a table or map does not exempt the whole page.
- Operate again: enlarge content and adjust text spacing, then open navigation, form errors and dialogs. Expected: text is not clipped and actions remain available. A mobile screenshot alone does not verify desktop zoom.

## Keep untested scope visible

Record untested browsers, assistive technology, sign-in states, documents and media, with an owner for follow-up. No video can be not applicable; an unchecked video’s captions cannot be marked passed.

This preliminary list does not cover every requirement for target size, time limits, moving content, media or complete authentication flows. Arrange a full assessment against the applicable standard and scope when a conformance evaluation is needed.

## Related pages

- [Plan the scope: pre-launch testing workflow](<https://accesserty.com/en/guides/accessibility-testing-before-launch/>)

- [W3C WAI: Easy Checks](<https://www.w3.org/WAI/test-evaluate/preliminary/>)

- [W3C: Reflow and exceptions](<https://www.w3.org/WAI/WCAG22/Understanding/reflow.html>)

- [W3C: Contrast (Minimum)](<https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html>)

- [Understand WCAG check results](<https://accesserty.com/en/wcag-compliance-tool/>)

- [Focus path review guide](<https://accesserty.com/en/guides/how-to-check-keyboard-focus-path/>)

- [Color contrast: text and non-text requirements](<https://accesserty.com/en/glossary/color-contrast/>)

- [Target size: AA, AAA and exceptions](<https://accesserty.com/en/glossary/target-size/>)

- [Accessible authentication glossary page](<https://accesserty.com/en/glossary/accessible-authentication/>)

- [Accesserty DevCheck](<https://accesserty.com/en/devcheck/>) — Run browser-based checks on local builds, staging pages, authenticated screens, and interactive states.

- [Web accessibility checker](<https://accesserty.com/en/web-accessibility-checker/>) — Check real pages, authenticated states, and interactive states before release.

- [Accessibility practice and maintenance guides](<https://accesserty.com/en/guides/>) — Browse guides by practical task: public signals, pre-release checks, post-launch maintenance, and standards limits.