A website can look tidy while making a simple task unexpectedly difficult. A visitor may reach the contact form but lose track of the keyboard focus, or enlarge the text and discover that the submit button disappears behind another panel. You do not need to wait for a redesign to notice those problems.
Choose one task before you start: finding an opening time, reading a guide or sending a question. Write down the starting page and the point at which the task is complete. Testing a journey gives the individual checks a purpose.
Follow the task without a mouse
Put the pointer aside and use Tab to move between controls, Shift+Tab to go back and the appropriate keyboard controls to activate them. Look for a visible indication of focus. Record places where the sequence becomes confusing, an interactive control cannot be reached or a popup seems impossible to leave.
The W3C WAI preliminary accessibility checks cover keyboard access, headings, text alternatives, contrast and other useful starting points. WAI explains that these checks are limited: passing them does not establish that a website is fully accessible.
Enlarge the page and follow the same route
Try the browser’s zoom control and watch the content, not just the font size. Can you still read the instructions? Does the navigation cover the page? Is a two-column section now forcing you to move sideways to finish every sentence? Keep the test conditions in your notes so another person can reproduce the result.
For example, a hypothetical appointment page might work at the initial screen size but hide the time selector when enlarged. A useful issue report says which page, browser and zoom setting were used, and names the control that became unavailable. “The mobile layout is broken” leaves the developer guessing.
Give forms a small, deliberate challenge
On a test environment, try leaving a required field empty or entering a clearly invalid example. Read the message and check whether you can find the affected field again. Avoid submitting dummy enquiries to a live business simply to test its form. If you own the site, use a clearly controlled test and remove any resulting test records.
Ask whether the instructions explain the expected format before an error occurs. A short example next to a date field may be more useful than a red border after submission. Labels should remain understandable when a placeholder disappears during typing.
Turn observations into a short repair queue
For each problem, record the task, steps, expected behaviour and actual result. Prioritise barriers that prevent completion, then review confusing or tiring interactions. Keep a screenshot when it helps, but include written steps too.
After a repair, repeat the same journey rather than only looking at the edited component. This first pass creates a practical starting list. Broader evaluation, including appropriate assistive-technology testing and feedback from disabled users, remains valuable as the site develops.
Continue exploring: Before You Automate a Repetitive Task, Map the Exceptions.