Accessibility work should help people complete real tasks on a website. Contrast, keyboard operation, readable content and usable authentication are connected parts of that work. A successful automated scan is useful evidence, but cannot establish the accessibility of the whole service.
Set the review scope and priorities
List the important journeys, templates and interactive components. Include enquiries, navigation, booking, account recovery and any documents customers need. Agree the applicable accessibility standard and who will evaluate it.
Prioritise barriers by their effect on users, the importance of the affected task and their reach across the website. Correcting a shared component can improve many pages. Record the problem, evidence, proposed correction and a retest owner rather than relying on a general accessibility score.
Check text and meaningful visual cues
WCAG 2.2 Level AA specifies at least 4.5:1 contrast for ordinary text and 3:1 for large text, subject to defined exceptions. Large text means at least 18 point, or 14 point when bold, approximately 24 or 18.7 CSS pixels respectively. A heading does not qualify merely because it is called a heading.
Relevant non-text visual information, such as cues identifying controls and their states or graphics needed to understand content, has a 3:1 requirement against adjacent colours, again with defined exceptions. This is not a rule that every decorative shape needs the same contrast. Measure the applicable colours and avoid rounding a failing value into a pass.
Do not rely on colour alone to communicate an error, selection or important distinction. Add appropriate wording, shapes or other understandable cues. Test links and focused controls against their actual backgrounds, including imagery and changed states.
Test the full keyboard route
Move through the page with the keyboard, including Tab and Shift+Tab where appropriate. Activate links, buttons, menus and forms using the expected controls. Check visible focus, a logical order and a usable way to leave each component.
This is an initial practical check, not a complete assessment of assistive technology compatibility. Test the relevant combinations and realistic tasks. Record where an overlay, sticky header or expanded panel hides a focused control.
Allow reading and layout adjustments
Check that text can be enlarged and content can reflow into a narrow viewport without losing information or functionality. Some content genuinely requires a two-dimensional layout, so evaluate the applicable exceptions rather than treating every horizontal scroll as identical.
Review font sizes, line spacing and line length together. A type scale borrowed from another organisation does not prove that the site's content is readable. Look for clipped labels, overlapping text and controls that disappear when the user changes their reading conditions.
Give controls sufficient space
WCAG 2.2 includes a Level AA target size criterion of at least 24 by 24 CSS pixels, with specific exceptions for spacing, equivalent controls, inline targets, unmodified user-agent controls and essential presentations. Assess the actual criterion rather than applying a universal minimum to every inline link.
Larger, well-spaced controls can still improve use beyond the minimum. Test frequent actions on the actual mobile layout, including adjacent icons and destructive options. A generous-looking graphic may have a smaller active area than its appearance suggests.
Make sign-in and recovery usable
Allow password managers and relevant copy-and-paste behaviour. Blocking these mechanisms can create an authentication barrier unless an appropriate alternative is provided. Use suitable field semantics and input-purpose information so browser and assistive tools can support the task.
Check the whole account journey: sign-in, verification, failure messages, password recovery and returning to the original task. Test with realistic accounts and without exposing credentials in recordings. Security decisions and accessibility decisions need to work together.
Keep explanations and assistance clear
Use familiar words, short coherent sections and specific instructions. Explain unfamiliar terms when they matter to the decision. Clear copy helps many readers, but does not replace the other accessibility requirements.
Where customers need assisted support, make the actual route discoverable. Research whether telephone, web chat or another suitable channel addresses the barrier. Sending someone to a second inaccessible form does not solve the original problem.
Keep evidence and retest changes
- Combine automated checks with informed manual evaluation.
- Test important tasks, shared components and error recovery.
- Measure applicable contrast and target requirements.
- Review keyboard, zoom and authentication behaviour.
- Record corrections, owners and verification evidence.
Our accessible forms guide covers labels and recovery. Use the user research guide to include realistic customer tasks in the review.
