An accessibility review you can actually repeat.

Start with the task, not a score

Accessibility is about whether people can understand and operate an interface, not whether a scanner displays a reassuring number. Choose a real journey: finding an article, changing a preference, or completing a purchase. Review that journey from start to finish, including errors and confirmation states. A usable landing page does not compensate for an inaccessible final step.

This checklist is a starting point, not a certification or a complete WCAG audit. Automated checks can reveal some issues quickly, while manual review and testing with disabled people reveal barriers that rules cannot reliably detect. Keep both kinds of evidence separate in your notes.

Read the page through its structure

Inspect the document title, main heading, heading sequence, and landmarks. The page should have a clear topic and a logical outline without relying on type size to communicate structure. Use native HTML elements for their actual purpose: links navigate, buttons perform actions, and lists group related items.

Check that images have appropriate alternatives. An informative diagram needs an explanation of its meaning, not a list of colors. A decorative flourish can have an empty alternative. Look for link labels that remain understandable when read out of context; repeated “click here” labels make navigation harder.

If the same navigation appears on every page, provide a working skip link to the main content. Verify the destination exists and that focus is not hidden behind a sticky header.

Put the mouse aside

Move through the whole journey using the keyboard. Confirm that every interactive control is reachable, focus is visible, and the order follows the reading flow. Activate buttons and links with the expected keys. Where a component uses a specialized interaction pattern, check its documented keyboard behavior instead of inventing a new one.

For dialogs, review focus on opening, movement within the dialog, dismissal, and return to the triggering control. Do not trap someone in an interface they cannot leave. Avoid removing focus outlines just because they do not match the visual design; style an equally visible replacement.

For forms, check visible labels, instructions, error messages, and how errors are announced. A red border alone does not explain what went wrong. Preserve entered information where practical and provide specific recovery instructions. Review status updates that happen without a page load, because visual changes may otherwise go unnoticed by assistive technology.

Stress the presentation and record the findings

Zoom the page and narrow the viewport. Text should reflow without hiding controls or forcing horizontal scrolling for ordinary prose. Check contrast for text, controls, and focus indicators, and do not use color alone to communicate meaning. Test longer labels and larger default font sizes, not just the designer’s sample copy.

Honor reduced-motion preferences where animation exists, and avoid making motion necessary to understand content. Try high-contrast settings where available and inspect whether important boundaries or indicators disappear.

Write each finding as a reproducible barrier: the page, the action, the expected behavior, and what actually happened. Prioritize blocked tasks before minor polish, fix the underlying component when possible, and repeat the same journey after changes. Keep the checklist in the release process so accessibility is maintained rather than treated as a one-time cleanup.