An accessibility review is most useful when it begins with a task a visitor actually needs to complete. Finding a contact address, reading an article or sending a question gives you a path through the website. Test that path using different ways of interacting, then record the barriers you encounter and what they prevent someone from doing.
Pick representative pages and tasks
Choose the homepage, a typical content page and an interactive page such as a contact form. Add pages with unusual elements, including tables, menus or embedded media. Write the expected result for each task. “Find the support email” is more useful than “look around,” because it lets you decide whether the structure helps or obstructs the visitor.
W3C's preliminary evaluation guidance presents easy checks as a starting point. A quick review cannot establish complete conformance or cover every assistive technology combination. Use it to find issues and guide further evaluation. If accessibility is critical to the service, combine practical testing with a more comprehensive review by people with relevant expertise and experience.
Follow the keyboard path
Move through the chosen task using the keyboard. Check whether links, buttons and form controls are reachable in a sensible order. Notice whether you can see which element has focus. Open and close menus or dialogs without relying on a mouse, and check that focus does not become trapped unexpectedly or disappear behind an overlay.
For an article, the keyboard path should not require traversing a long wall of repeated navigation before reaching the content. For a contact form, you should be able to move from each field to the submit button and then understand the result. Record the exact point where the task breaks so a developer can reproduce it.
Examine structure and text
Read the page title and headings as an outline. Do they identify the page and group the content meaningfully? Headings should communicate relationships, rather than being selected only for their visual size. A page that looks neatly divided can still have an unhelpful structure for someone navigating through headings with assistive technology.
Check link text outside its surrounding paragraph. “Privacy policy” communicates a destination better than several repeated links labelled “here.” Review images according to their purpose: an informative chart needs its message available in text, while purely decorative imagery should not interrupt the reading experience with irrelevant descriptions. Keep captions, alternatives and surrounding explanations consistent.
Check readability and resizing
Increase text size or zoom and inspect the task again. Content should remain readable and controls should remain usable without important information being hidden. Test a narrow viewport as well. A form button that disappears off-screen or a table that cannot be understood on a phone is a concrete usability problem worth documenting.
Look for information conveyed through colour alone. A red field border may indicate an error visually, but the page should also explain what needs correction in text and associate that feedback with the relevant field. Charts need labels or another way to identify categories. Use suitable tools to assess contrast rather than relying only on how colours look on your screen.
Turn findings into fixes
Record each issue with the page, steps, expected outcome and observed result. Prioritise barriers that prevent a task from completing, then address confusing or inefficient behaviour. After a fix, repeat the original task rather than merely checking that the code changed. Ask people who use assistive technology to test relevant journeys where practical.
Keep this review in the publishing routine. New articles, images and forms can introduce barriers after the original design is improved. The valuable outcome is a site people can use to accomplish its real tasks, supported by ongoing checks and a clear understanding of what has and has not been evaluated.
Sources and further reading
This original guide was prepared with AI assistance. Examples are illustrative. The edition date is an assigned date in this 2026 catalogue. See our editorial policy and report a correction.