Define the scope before testing
Start by recording the pages, states, components, browsers, input methods, and content types included in the review. Include representative templates as well as critical tasks such as navigation, search, account flows, checkout, and contact forms. WCAG 2.2 organizes testable success criteria under perceivable, operable, understandable, and robust principles, and it expects a combination of automated testing and human evaluation.[1]
A quick review is useful for finding obvious barriers, but it is not a complete evaluation. W3C’s Easy Checks explicitly covers only a few issues and notes that a page can pass those checks while still containing significant barriers.[2] Describe a limited review as a limited review; do not present it as certification or proof of conformance.
Scope record
- List the URLs, templates, dialogs, menus, forms, media, and authenticated states in scope.
- Identify primary user tasks and the start, error, success, and recovery states for each.
- Note the browsers, viewport sizes, zoom levels, keyboard paths, and assistive technologies used.
- Record the WCAG version and target level only when a formal evaluation requires them.
- Save findings with reproducible steps, expected behavior, actual behavior, and affected components.
Work through the page-level checks
1. Use the page with a keyboard
Start at the browser chrome and move through every interactive element without a pointer. Focus should be visible, follow a meaningful order, reach every control, and never become trapped. Test menus, dialogs, carousels, accordions, tooltips, validation messages, and any control that appears only after another action. Confirm that a skip link reaches the main content and that sticky headers or overlays do not obscure the focused item.
2. Review headings, landmarks, and page language
Confirm that the page has one clear main heading and a heading structure that describes the content rather than its visual size. Check that header, navigation, main content, complementary material, and footer regions are represented appropriately. Set the page language and mark changes of language where needed. W3C’s Easy Checks highlights headings, skip links, page language, and zoom as practical first-review items.[2]
3. Check images, icons, audio, and video
Meaningful images need concise alternatives that communicate their purpose; decorative images should not add noise. Controls represented by icons need an accessible name. Verify captions for prerecorded speech, transcripts where appropriate, and audio description when essential visual information is not otherwise available. Do not judge alternatives from the presence of an alt attribute alone—read the page with images unavailable and decide whether the same task remains understandable.
4. Test color, contrast, reflow, and zoom
Measure text and interface contrast rather than estimating it by eye. Check that meaning is not conveyed by color alone. At narrow widths and up to 200% zoom, content and controls should remain readable, reachable, and usable without clipped text or avoidable two-dimensional scrolling. Test text spacing overrides and high-contrast or forced-color settings where relevant.
5. Inspect forms and status changes
Every field needs an associated label, instructions should appear before they are needed, and required fields should be identified in more than one way when necessary. Trigger each validation path and confirm that errors are explained in text, associated with the relevant controls, and announced when the interface changes dynamically. Then complete the flow and verify that the result is clear without depending on color, motion, or a visual-only notice.
Expand from pages to a representative sample
For a broader evaluation, explore the product before selecting the sample. Include common pages, substantially different page types, essential functionality, repeated components, and pages generated from different templates or systems. WCAG-EM describes a structured process: define the evaluation scope, explore the product, select a representative sample, evaluate that sample, and report the findings.[3]
Release gate
- Automated scans have been run across the full available URL set, with duplicates grouped by component.
- Representative pages have been reviewed manually with keyboard-only interaction.
- Headings, names, labels, alternatives, contrast, zoom, reflow, errors, and status messages have been checked.
- Critical tasks have been completed through normal, error, and recovery paths.
- Reusable component failures have been fixed at the source and retested wherever they appear.
- Results distinguish confirmed failures, items needing expert review, and checks that passed in the tested scope.
Report evidence, limitations, and follow-up
Prioritize findings by user impact, task criticality, frequency, and the reach of the affected component. A useful ticket names the page and control, provides exact reproduction steps, states the observed barrier, identifies the relevant success criterion when appropriate, and defines a testable expected result. Add screenshots or recordings as supporting evidence, not as a substitute for a written description.
State what was not tested. Automated tools cannot judge every relationship, instruction, alternative, focus sequence, or interaction. A preliminary checklist is not a compliance determination, and even a structured evaluation depends on defined scope, evaluator expertise, and documented methods.[3] Retest corrected components and critical journeys, then schedule recurring checks for templates and content that change frequently.
Related checklist
Sources
These W3C and WAI references informed this guide and provide the standards and evaluation context behind the checklist.
Need an accessibility testing plan?
Share the site, critical tasks, and release scope. I’ll help turn them into a practical review with clear evidence and follow-up priorities.
Start the conversation