Define the limits of the checklist
This is an initial review for product, content, and QA teams. It is not a complete WCAG conformance assessment. Choose a representative task, record the product version, and note your browser and assistive technology. Use the results to prepare for a scoped WCAG audit, rather than publishing a compliance claim based on a short list of checks.
Navigate without a mouse
Move through interactive controls using the keyboard. Check that focus is visible, the order makes sense, and the controls can be operated. Open and close menus and dialogs, and verify that focus returns to a useful place. Try the main task from start to finish. Record any point where you become stuck or cannot tell which control is active.
Check forms and recovery from errors
Review labels, required-field instructions, and format hints before entering data. Submit invalid information and inspect how the error is communicated and how a user can correct it. Check the confirmation after a successful submission. A field that is announced correctly can still be difficult to complete if its instructions or feedback are missing.
Listen to structure and interactive updates
With a screen reader, inspect headings, landmarks, link names, and form controls. Follow a complete task instead of only reading the page from top to bottom. Check updates such as search results, cart changes, and validation messages. Keep manual and automated testing results distinct so a passing scan does not hide an interaction failure.
Review visual adaptation and non-text content
Check text enlargement and narrow layouts for lost content, overlap, and controls that become unreachable. Review contrast and whether color alone communicates important information. Examine image descriptions in their context. Check captions and other media alternatives where relevant. Include downloads and use the document planning guide when PDFs or Office files are part of the task.
Record findings and build a repeatable review
Write down the steps, expected result, actual result, and user impact for each barrier. Use remediation planning to assign owners and schedule retesting. Teams that need help applying these checks can use role-based accessibility training. Repeat the review when shared components and important workflows change.
Frequently asked questions
Can this checklist establish WCAG conformance?
No. It supports an initial review and repeatable practice, but it does not cover every applicable criterion, state, or conformance requirement. Use it to find issues and prepare a fuller evaluation. A scoped accessibility audit should define the target standard, coverage, methods, and reporting needed for a conformance assessment.
What should we check beyond pressing Tab through a page?
Try to complete the task with the keyboard. Check how controls activate, whether focus stays visible, what happens when dialogs open and close, and how errors can be corrected. Some controls use arrow keys or other expected keys, so Tab alone does not exercise their full behavior. Record the interaction and exact point of failure so someone else can reproduce it.
Why should we test error and empty states?
Those states can expose instructions, messages, and controls that do not appear in the successful path. A search with no results or a rejected form submission may leave a screen reader user without useful feedback. Include realistic invalid inputs and recovery steps in the test plan. Accessibility needs to hold when a task goes wrong as well as when it succeeds.
How should a team use the checklist between formal audits?
Assign the relevant checks to design, development, content, and QA work, and repeat them when components or workflows change. Record results and escalate questions instead of marking uncertain behavior as passed. Role-based accessibility training can help staff apply the checks consistently. Periodic scoped evaluations can then assess coverage beyond the team's routine review.