A website accessibility checklist should help people complete real tasks: read a service description, navigate a menu, use a form, and understand a result. It is not just a list of attributes to add for an audit score. Accessibility work is strongest when design, content, and development share the same requirements.
The checks below are a practical starting point. They are not a full WCAG evaluation, legal advice, or a compliance certificate. A website can pass automated checks and still contain barriers that require manual testing or feedback from people who use assistive technology.
Follow the main journey with a keyboard
Put the mouse aside and move through the site using the keyboard. Check whether the focus indicator is visible, the order makes sense, menus can be operated, and dialogs can be closed. A visitor should not become trapped in a decorative widget or lose track of their position.
Try the actual business task, not only the homepage links. Reach the service, open the contact page, fill the form, correct a mistake, and read the confirmation. Document where the journey stops and what input was required to reproduce the barrier.
Review structure and text alternatives
Headings should communicate the page's outline rather than being chosen only for their visual size. Link wording should make sense in context, especially where several cards use the same generic label. Provide meaningful alternatives for informative images, and avoid making a photograph the only place essential information appears.
W3C's Easy Checks covers initial reviews such as page titles, headings, text alternatives, keyboard focus, and zoom. Use it to start finding problems, not to declare that no other issues exist.
Check readability under real conditions
Review text and controls against their actual backgrounds, including hover, disabled, and error states. A hero over a photograph can be readable in one crop and disappear in another. Do not rely on color alone to distinguish an error, a selected option, or a required field.
Enlarge the text and zoom the page. Navigation, labels, and important content should remain available rather than being clipped behind fixed-height boxes. Test a narrow viewport and long content. The aim is usable reflow, not merely passing one screenshot at a convenient screen width.
Make forms understandable before an error occurs
Use persistent labels and explain unusual input requirements. Placeholder text disappears when a person starts typing, so it should not carry the only instruction. Ask only for information needed at this stage of the relationship.
When validation fails, identify the affected field and explain how to fix it without deleting other answers. After submission, provide a clear result that assistive technology can perceive. An animated button is not enough evidence that the enquiry reached the server. Review the W3C forms tutorial for accessible labeling and feedback patterns.
Respect motion preferences and media needs
Motion can clarify a relationship, but it should not be required to understand essential content. Provide a calmer experience for reduced-motion preferences, avoid unnecessary auto-opening overlays, and check whether a background video competes with readable text.
Where audio or video communicates information, plan appropriate alternatives and controls. A decorative visual can be omitted from the accessibility tree, but calling an informative video “decorative” does not remove its communication responsibility.
Turn findings into repeatable acceptance checks
Record the affected URL, component, reproduction steps, expected behavior, and proposed fix. Prioritize barriers that prevent task completion. Reuse the checks when shared components change so the same menu or form problem does not return across multiple pages.
Combine automated scans, keyboard reviews, assistive-technology checks, and user feedback where available. The WCAG 2.2 quick reference is a more detailed standards resource when moving beyond preliminary checks. Accessibility needs ongoing ownership as content and features change.
Common questions
Does an accessibility score of 100 prove the website is accessible?
No. It reports the checks that tool performed. Some important barriers are not automatically detectable, and usability still needs human review.
Should accessibility wait until the design is finished?
No. Navigation, typography, forms, and interaction decisions are easier to improve while they are being designed. Retrofitting can create avoidable rework.
Combine this review with responsive design testing and the UI/UX planning guide. If a critical customer journey is difficult to use, share the page and the barrier so the review can focus on a concrete task.