Accessibility basics to check during a website review

A quick accessibility review can identify obvious barriers, but it cannot certify that a website is accessible. Test a small set of important tasks with a keyboard, inspect labels and text, and record where a visitor may be blocked. For a fuller assessment, use knowledgeable human evaluation alongside tools. W3C WAI explains why no tool alone can determine accessibility.

Choose representative pages and tasks

Include a homepage, a service or product page, a form and a page with complex navigation. Try to complete a task, such as finding a service and sending an enquiry, without a mouse. Can you see where keyboard focus is? Can you reach and activate controls in a sensible order? Note the exact step where a task fails.

A quick pass across one page may miss barriers elsewhere, so record the sample you checked.

Check content and controls

Look at whether headings describe the page, links make sense out of context and images that carry information have an alternative description. On forms, ask whether labels explain the field and error messages tell a person how to recover. Inspect text contrast and whether zooming makes content disappear or overlap. These are screening checks, not a complete technical audit.

Avoid reporting “passes accessibility” because you could use the page yourself. People have different needs and tools.

Use tools as evidence, not verdicts

An automated scan can highlight some issues, but it cannot judge every task or the meaning of content. Record the tool, page and date, then manually examine important findings. A problem that prevents a booking or enquiry deserves priority even if a summary score looks acceptable.

The accessibility work proposal guide can help a site owner assess the scope of a specialist review.

Record and retest barriers

For each issue, capture the page, device or input method, steps, expected result and actual result. Assign an owner and retest after a fix. Share the finding with the people who write content as well as the people who write code; barriers can arise in both.

Example: describe one keyboard barrier precisely

If the focus indicator disappears when a menu opens, write down the page, browser, keystrokes and the control where you lost track. Do not merely say “keyboard accessibility failed”. Try to complete the task and note whether another route exists. A developer can use the steps to reproduce the issue, while a reviewer can explain the visitor impact. After a fix, repeat the same steps and check another menu or form so the change has not shifted the barrier elsewhere. Keep the result labelled as an initial check, not an accessibility certification.

Frequently asked questions

Can an automated score tell me a site is accessible?

No. It may identify some problems, but a fuller evaluation needs human judgement and tasks relevant to the site's users.

Should I test with a keyboard if the site is mostly mobile?

Yes. Keyboard access still matters for many users and can reveal interaction problems that are not obvious by touch. Try the menu, key links and form controls before treating the journey as usable.

Is a quick check enough before launch?

It is a useful start, not a complete assurance. Plan further evaluation proportionate to the site's purpose and risk. Record what was tested and arrange a deeper review for important or complex journeys.