How to Review Website Accessibility With Real Users

Accessibility review is most useful when it reveals where people experience difficulty, not simply where a tool reports a technical warning.

Automated testing has an important role. It can identify missing alternative text, poor colour contrast, form labelling problems and some structural issues quickly. Manual review adds another layer by checking how a page behaves with a keyboard, browser settings and assistive technology. Feedback from real users then helps you understand whether the website is clear, predictable and practical in everyday use.

No single method provides the complete picture. A reliable review combines all three.

Why automated accessibility checks are only a starting point

Automated tools are useful because they can scan pages consistently and highlight issues that might otherwise be missed. They are particularly helpful during development, when a website contains many templates or when you need to check whether a known problem has been fixed.

However, automated results have limits. A tool may identify that an image has alternative text, but it cannot reliably decide whether that description is useful in context. It may confirm that a form field has a label, but not whether the label explains what information the visitor needs to provide. It may detect a heading structure, but not whether the page is organised in a way that makes sense to someone trying to complete a task.

Treat automated reports as a prioritised list for investigation rather than a final accessibility certificate.

A sensible first pass should look for:

• Missing or unhelpful alternative text
• Insufficient colour contrast
• Form fields without clear labels
• Empty links or buttons
• Heading levels used inconsistently
• Missing page language information
• Duplicate or unclear page titles
• Keyboard focus problems that a tool can detect
• Elements that may not be announced correctly by assistive technology

Record the page, issue, likely impact and recommended action. This makes it easier to separate repeated template problems from one-off content problems.

Build a practical review scope

You do not necessarily need to test every page at the beginning. Start with the journeys that matter most to customers, patients, parents, buyers or other users.

A useful review scope might include:

1. The home page
2. The main navigation
3. A key service, product or information page
4. The contact or enquiry page
5. A form or booking journey
6. Search results or filtering, where relevant
7. A downloadable document or resource
8. Any page receiving significant traffic
9. A page that has recently been redesigned
10. A page used by a particular audience with access needs

Choose representative page types as well as individual URLs. If every service page uses the same template, one detailed review may reveal an issue affecting the entire group.

Define the tasks before testing begins. For example, a participant might be asked to find a relevant service, understand what happens next, complete an enquiry form or locate opening information. The purpose is to observe whether the website supports a realistic goal, rather than to test whether someone can find an arbitrary button.

Carry out a manual review

Manual testing helps you examine behaviour that automated checks cannot fully understand. It should be a normal part of reviewing a website, not an emergency step only used after a complaint.

Test with a keyboard

Move through the website without using a mouse or trackpad. Check whether you can:

• Reach every interactive element
• See where keyboard focus is located
• Open and close menus
• Use sliders, tabs, accordions and pop-ups
• Complete and correct forms
• Submit an enquiry
• Escape from overlays or dialogs
• Move through the page in a sensible order

A visible focus state is particularly important. If you cannot tell which link or control is selected, keyboard navigation becomes unnecessarily difficult.

Also check whether opening a menu or dialog moves focus appropriately and whether focus returns to a sensible location when it closes. A visitor should not become lost in a complicated interaction.

Check headings, landmarks and reading order

Review the page structure. Headings should describe the content that follows and should be arranged in a logical hierarchy. Navigation, main content, complementary information and footer content should be distinguishable where appropriate.

Then consider the reading order when content is accessed without its visual layout. Does the sequence still make sense? Are important instructions presented before the control they describe? Are decorative elements being announced unnecessarily?

A visually attractive layout can still create confusion if the underlying structure does not reflect the intended meaning.

Test zoom and text resizing

Increase the browser zoom and check whether content remains usable. Look for text that overlaps, buttons that become inaccessible, navigation that disappears or important information that is clipped.

Do not assess only whether the page still looks tidy. Ask whether a visitor can still complete the relevant task. Some visual changes are acceptable if the content remains clear and functional.

Consider motion, timing and dynamic content

Review carousels, animated sections, auto-updating content, timed forms and notifications. Can motion be paused? Does important information disappear too quickly? Are updates announced in a way that makes sense for someone who cannot see the visual change?

A moving banner may look harmless during a visual review but become distracting or difficult to operate for other visitors. If an animation does not support the task, consider removing it or making it optional.

Use assistive technology where possible

A screen reader review can reveal problems with headings, link names, form instructions, buttons, status messages and hidden content. You do not need to treat this as a specialist exercise that replaces every other check. Even a focused review of the main customer journey can identify issues that would not be visible on screen.

Test the experience rather than merely checking whether a technical feature exists. A button labelled “click here” may be technically exposed to a screen reader but still provide little useful information. A form may have labels but fail to explain errors clearly.

Involve real users carefully

Real-user feedback is valuable because accessibility is experienced in context. People may use a website with a screen reader, magnification, voice control, keyboard navigation, alternative input device, captions or other settings. Their experience can highlight barriers that are difficult to predict from a design or development perspective.

Recruit participants whose experience is relevant to the journey you are reviewing. Depending on the website, this may include people with visual, hearing, motor, cognitive or learning disabilities. It may also include people with temporary impairments, older users or visitors working in a distracting environment.

The aim is not to ask people to represent every disabled visitor. One person’s experience cannot stand in for an entire audience. Instead, treat each session as valuable evidence about how a particular person approaches a particular task.

Make participation respectful and straightforward:

• Explain the purpose of the review clearly
• Ask for consent before recording notes, audio or video
• Allow participants to use their usual device and settings where possible
• Avoid asking for unnecessary personal or medical information
• Pay participants appropriately where a formal study is being conducted
• Give people control over breaks, pacing and stopping the session
• Do not treat accessibility barriers as the participant’s fault
• Protect personal data and remove identifying details from reports

A facilitator should avoid leading the participant towards the expected answer. Instead of asking, “Was that button easy to find?”, ask, “What would you do next?” or “What are you looking for here?” This reveals the person’s understanding without suggesting a judgement.

Observe tasks, not just opinions

At the start of a session, explain that you are testing the website, not the participant. Then give a realistic task and let the person work through it.

Observe:

• Where they begin
• Which information they notice or ignore
• Whether labels match their expectations
• Where they pause or change approach
• Whether they can recover from an error
• What they expect to happen next
• Which parts of the journey require help

A participant may say that a page is “fine” while still taking a long route to complete a task. Another may describe a particular feature as frustrating but provide a useful clue about the underlying problem. Combine what people say with what they do.

After each task, ask open questions such as:

• What were you expecting to find?
• What, if anything, was unclear?
• Was there a point where you felt unsure what to do?
• What would have made that easier?
• Is there anything you would change about this journey?

Turn findings into improvements

A review is only useful if findings lead to practical action. Avoid producing a long list where every issue has the same priority.

Group findings into themes such as:

• Content clarity
• Navigation and orientation
• Keyboard operation
• Forms and error handling
• Visual presentation
• Screen reader experience
• Mobile interaction
• Documents and downloadable resources
• Ongoing content management

Then prioritise each issue according to its impact, frequency and effort to resolve. A missing form label on an important enquiry journey may deserve attention before a minor issue on a rarely visited page. A repeated template problem may also be more valuable to fix than an isolated content error.

For each finding, record:

• The page or journey affected
• What the user experienced
• The likely barrier
• Evidence from automated, manual or user testing
• The recommended improvement
• The person responsible
• The proposed priority
• How the change will be checked

Be specific. “Improve accessibility” is not an action. “Add a visible focus style to navigation links and test the main menu using only a keyboard” is clearer and easier to assign.

Repeat the review after changes

Accessibility review should be part of ongoing website improvement. Re-test after a redesign, template change, content migration, new form, plugin update or significant change to navigation.

Use the original tasks where possible so you can compare experiences. Also run automated checks again and confirm that a technical fix has not created a new usability problem elsewhere.

The most effective approach is continuous and proportionate: automated checks during routine updates, manual review of important journeys and regular feedback from people with relevant lived experience.

A website does not become accessible because it passes one scan. It becomes more inclusive when technical quality, clear content and real-world use are considered together.

Related News / Insights / Articles