A website accessibility checklist for a first review
Check a page with keyboard, zoom, form labels, contrast, and status messages using an original first-review worksheet.
For a first accessibility review, try the tasks on your website with a keyboard, enlarge the page, and inspect labels, contrast, and status messages. Record what you observe and what still needs specialist testing. Passing a short checklist or an automated scan does not establish full accessibility conformance.
Choose a page and a task
Start with work people need to complete: find a guide, submit a form, or download a file. Write the steps before testing. Looking at a screenshot will not reveal whether a keyboard user can reach a control or recover from an error.
Use the W3C WAI Easy Checks resource as a starting point for the categories below. This worksheet is an original way to record the review, not a substitute for the full standards or an expert assessment.
Try these checks
| Check | What to try | Record |
|---|---|---|
| Keyboard | Use Tab and Shift+Tab; activate controls with their expected keys | Unreachable controls, missing focus, unexpected traps |
| Enlarged page | Zoom in and repeat the task | Hidden text, overlapping controls, difficult scrolling |
| Labels | Inspect the visible and accessible names of form controls | Missing, unclear, or mismatched labels |
| Contrast | Check text and relevant control boundaries with an appropriate tool | Measured problem and affected state |
| Errors and status | Trigger an invalid form and a successful action | Whether the result is understandable without sight alone |
| Images | Consider each image's purpose | Needed description or decorative treatment |
Do not mark an untested item as passed. A visual review cannot establish how a particular screen-reader/browser combination announces every state.
A fictional issue record
Task: send a contact message. The submit button is reachable, but after an invalid email address the form clears all entries and shows an error at the top. Keyboard focus stays on the button below the error.
A useful issue says: “Invalid email clears the other fields. The error appears above the current focus position, and I did not notice it during the keyboard task.” It records the observed result and the task affected. “The form is inaccessible” is a broader conclusion that needs more evidence.
A proposed repair is to preserve valid entries, associate the email error with the field, and make the error or summary discoverable through an appropriate focus and announcement strategy. Test the chosen repair in the actual form.
Give your coding AI a bounded request
Review this page for the specified user task.
Inspect keyboard navigation, visible focus, semantic controls, labels,
error recovery, zoom behavior, contrast, and status updates.
Separate confirmed findings from checks requiring a real browser or
assistive technology. Propose the smallest relevant changes.
Do not add redundant ARIA or claim compliance from a code review.
Page code and task: [paste]Keep the evidence with the fix
For each issue, record the page, the step, the browser and input method, what happened, and what you expected. If you used an automated scanner, keep its result alongside the manual task. A scanner can find some problems while missing whether the flow makes sense.
After a change, repeat the failing step and the surrounding task. A focus fix that solves one screen may move focus unexpectedly on another. Check the relevant loading, error, and success states, not just the default form.
Decide what needs a deeper review
Complex dialogs, custom widgets, checkout, and other essential flows may need a more detailed assessment and assistive-technology testing. Keep those items in a review queue with a named owner. A first check is useful when it produces specific repairs and an honest account of what has not been examined.
References and further reading
The examples and templates above are original. These references support the definitions and documented behavior discussed in the guide.
What to read next
Audit a page using only the keyboard
Check order, focus visibility, activation, dialogs, and recovery with a repeatable task sequence.
Read the guide ↗
Check color contrast in the actual interface states
Review text, controls, placeholders, focus, and disabled states instead of testing only the brand palette.
Read the guide ↗
Write form errors that help people recover
Name the problem, keep entered data, and connect the error to the field instead of using vague blame.
Read the guide ↗