Choose one real customer journey
Pick a task your website is meant to support: finding a service, understanding an offer or reaching the enquiry page. Write down the starting page and the expected result. Include the menu, any expandable content and the final action. Reviewing a complete journey gives isolated observations a practical context.
Choose a manageable sample of pages rather than declaring the whole site checked after looking at the homepage. Record the browser, device and date alongside your findings. Keep customer information out of screenshots and test notes. Use this first pass to decide what needs a closer review, not to award a compliance badge.
Try the journey without a mouse
Use the keyboard to move through the page. Watch where focus goes and whether a visible indicator makes the selected control clear. Check that important menus, links and controls can be reached and operated. If a menu opens, confirm there is a workable way to leave it and continue.
Describe any problem as a repeatable sequence: the page, the control and the point where progress stops. For example, note that focus disappears after opening a menu rather than writing that the menu is bad. W3C guidance covers both keyboard operation and visible focus; a developer may need to inspect the underlying controls to repair the cause.
Make the page understandable out of context
Read the page title, section headings and link labels. They should explain the page and its destinations without requiring a visitor to interpret a visual layout. Replace vague labels with words that describe the action or destination. A service page should remain understandable when someone scans only its headings.
Check that headings are marked as headings in the website editor, rather than being ordinary text made larger. Give a developer specific examples when the visible layout and the document structure disagree. For informative images, consider what information or function needs a text alternative; decorative images require different treatment.
Check reading and controls together
Enlarge the page and inspect important content again. Look for text or controls that overlap, disappear or become difficult to use. Then compare the main text, buttons and feedback against their backgrounds. W3C recommends sufficient contrast and clear visual treatment for interactive elements.
Do not use colour as the only explanation for a state or instruction. A required field or an error also needs an understandable cue. If an issue appears only in a particular menu state or viewport, capture that context. A screenshot of the normal page alone can hide the problem a developer needs to reproduce.
Turn findings into a small repair plan
Keep one row per finding: affected page, customer task, steps, observed result, expected result and owner. Separate a content edit from a theme or component change. Prioritise obstacles that prevent the task from being completed, then address confusing labels and presentation issues. Save unresolved questions instead of guessing their cause.
After a change, repeat the same journey and record the result. Check other pages using the same component, because a shared header or button style can affect more than the original example. Keep the scope concrete enough that the person implementing it and the person checking it agree on what a successful repair looks like.
Know what this first review leaves unchecked
W3C describes easy checks as an introduction, not a comprehensive accessibility evaluation. Passing a short checklist can still leave substantial barriers. A broader assessment may need specialist testing and input from people with disabilities, particularly before making claims about the accessibility of a complete service.
Keep the review record honest: name the pages, tasks and methods covered, and list what remains untested. Bring that record to your website support discussion so the next stage has a defined starting point. The useful outcome is a prioritised set of improvements and evidence of retesting, rather than an unsupported assurance that everything is accessible.