A website accessibility checklist should cover keyboard navigation, meaningful headings, form labels, text contrast, image alternatives and motion controls. Go beyond the homepage by finding a service, reading a document and submitting a form. Combine automated findings with manual task testing; completing this checklist does not by itself certify conformance.
Define the tasks and the assessment target
List core tasks such as finding a service, selecting a product, reading a document and submitting a form. Include the pages and states involved: an expanded menu, an error and the submission result all matter. A clear opening screen does not establish that the whole journey is usable.
WCAG provides success criteria for web content accessibility. Specify the version and conformance level adopted for the project. Do not equate a tool score with standards conformance; describe what was assessed and which checks remain outside the review.
Review the information carried by text and images
Check that heading levels describe section relationships rather than merely choosing a visual size. A screen reader’s heading list should explain the main topic and its subsections. Evaluate links such as “Read more” in context, and ensure a list of different destinations provides enough information to distinguish them.
An informative image’s alternative text should convey its purpose on that page. Do not add unnecessary descriptions to decorative images, and do not communicate a chart’s key result through colour alone. Measure text contrast against its actual background, including hover states, text over images and faint supporting copy.
Check navigation, forms and motion
Put the mouse aside and use Tab, Shift+Tab and the appropriate activation keys through menus, forms and disclosures. Keep focus visible, make dialogs dismissible and avoid trapping users in a component. Enlarge text on mobile and check whether controls or error messages become clipped.
Check that activating a field label selects the correct input, errors are understandable and entered values survive correction. Test pause controls for automatic motion or sliders, and inspect the interface with the operating system’s reduced-motion preference enabled. Turning motion off should not remove essential content or navigation.
| Area | Practical review | Finding to record |
|---|---|---|
| Text | Read when enlarged and on a narrow screen | Missing or overlapping information |
| Images | Understand the message without the image | Missing meaning or unnecessary repetition |
| Keyboard | Complete the task without a mouse | Unreachable or invisible controls |
| Forms | Submit incomplete information and recover | Unclear fields or error guidance |
| Motion | Read the content and pause when needed | Automatic changes without usable control |
Record user impact and assign the correction
Replace a general issue such as “contrast problem” with the specific text and condition in which it cannot be read. Distinguish a blocked task, a difficult interaction and a smaller improvement. Name the content, design or development owner responsible for the next action.
Imagine a hypothetical contact form displaying an error only through a red border. The person cannot identify what needs changing. The message and focus behaviour need to be considered together. This shows why an accessibility issue may require more than one discipline to resolve.
Combine automated checks with task-based review
Tools can accelerate discovery of some issues; practical use checks and specialist evaluation should be planned where needed. W3C's evaluation resources provide a starting point for selecting methods. Avoid turning a limited review into an unqualified claim that the site is completely accessible to everyone.
Repeat the same task after a correction and record the result. Establish when checks will be repeated as components, content and imagery change. Accessibility needs to remain part of the website's operation after the initial release.