An Accessibility-First Website Review for Product Teams

Start with a task and a person’s access needs

Choose a representative task and consider how it works for people using a keyboard, screen reader, magnification, speech input, or reduced motion. Do not assume one disability profile represents everyone. Include disabled participants in research and consult applicable accessibility requirements for the product and region.

Run a keyboard pass

• Can you reach and operate every control without a pointer?
• Is focus visible and in an order that matches the task?
• Can you open and close menus and dialogs, and return focus to the trigger?
• Can you leave every component without becoming trapped?

Review structure and content

Check that page titles and headings explain the content, controls have names that make sense out of context, and links say where they go. Images that convey information need meaningful text alternatives; decorative images should not create redundant announcements. Color should not be the only way to communicate a state.

Test forms, zoom, and errors

Confirm each input has a label, instructions are available before entry, and errors identify both the problem and a path to fix it. Zoom the page and check that content remains available without forced horizontal scrolling for ordinary reading. These checks catch common issues but do not cover every WCAG success criterion or every assistive technology combination.

Use multiple kinds of evidence

Automated tools can detect some code patterns; manual checks expose interaction problems; assistive technology testing and research with disabled users reveal barriers that neither alone will find. Record the method, environment, and limitations in the finding. Treat a passing automated scan as one piece of evidence, not an accessibility certificate.

GOV.UK Service Manual: testing for accessibility

W3C WAI: Easy Checks