Website accessibility: start with a real user journey

Website accessibility means people can perceive content and complete tasks using different devices and assistive tools. A score from an automated checker can reveal some defects, but it cannot prove a store or service journey is usable. Start with one real task, such as finding a product and completing checkout, and test it with more than a mouse.

Choose a representative task

Select a journey that matters to visitors: find a service, compare products, ask for a quote, buy an item or retrieve an order. Write its starting page, required steps and successful end state. Include a mobile screen and at least one common error case, such as an invalid form field.

Pick pages representing the templates used along that route. If a shared navigation menu fails, the issue may affect the whole site. If one manually edited article has a missing heading, its scope may be local. Keep exact URLs and device details so another person can repeat the check.

The W3C Web Accessibility Initiative provides easy checks for an initial review and explains that they are not a complete assessment. Use them to find a starting set of issues, then expand the test where the same component appears elsewhere.

Navigate with a keyboard

Put the mouse aside. Use Tab and Shift+Tab to move through links, buttons and form controls; use Enter or Space where the control expects it. Can you see where focus is? Does it move in a meaningful order? Can you open and close menus, choose variants, submit forms and escape dialogs without getting trapped?

A clickable <div> may work with a pointer but fail as a keyboard control. A carousel may hide its buttons or move focus to content that is no longer visible. Record the exact step and browser where progress stops. Fix the underlying control, then retest the full journey.

Do not treat a keyboard check as proof that screen-reader users are served. It finds one class of barriers. A fuller review needs assistive technology testing and, ideally, feedback from people who use it.

Check text, headings and images

Read the page with styles reduced or zoomed. Is text still legible? Does the heading order explain the page? Can a person identify the product, price and next step without relying only on color or position? Test at a narrow viewport, not only at a desktop width.

For informative images, the text alternative should communicate the image's role. A product photo may need a concise description; a complex chart needs its conclusion in nearby text. Decorative images can use an empty alternative. The W3C image tutorial explains how purpose changes the appropriate text.

Do not fill every image's alt field with a keyword. A screen reader would then read repetitive noise. Likewise, an icon-only button needs a clear accessible name for its action, not just “icon.”

Test forms and errors

Open a form and identify each field without relying on placeholder text that disappears while typing. Submit it empty or with invalid data. Does the error explain what to fix and point to the affected field? Can you correct it without starting again? Does success produce a confirmation that is visible and understandable?

The W3C forms tutorial covers labels and instructions. A visible label helps many people, including those using voice input or cognitive support, not only screen readers. Test required fields and password managers where relevant.

For checkout, verify that price changes, shipping choices and final order confirmation are announced in a usable way. A technically valid input field does not help if the buyer cannot understand the total or complete the purchase.

Use automated tools as one source of evidence

Run an automated check on representative pages to catch issues such as missing names or contrast concerns. Review each flagged issue in the rendered page. Some warnings are false positives; some serious usability failures are invisible to the tool. W3C notes that human evaluation is required for a meaningful assessment.

Prioritize by task blocked, number of pages affected and ability to fix a shared component. A purchase button unreachable by keyboard deserves immediate attention. A redundant alt phrase on a rarely used illustration can follow later.

Retest with people and keep the result current

After a fix, repeat the same journey from the first step. Test at least one page using the corrected template elsewhere. Ask a person unfamiliar with the site to attempt the task, and listen for where instructions are unclear. Do not claim conformance to a standard from a small set of checks; a formal assessment has a broader scope.

Add accessibility checks to releases of menus, forms, product selectors and checkout. A later theme or plugin update can reintroduce a barrier. The practical goal is that more visitors can finish the task they came to do.

Example of a complete issue record

Imagine a product page where keyboard focus reaches a color selector but cannot move to the “add to cart” button. Record the public URL, browser, viewport, starting step, keys pressed, expected result and actual result. Add a short screen recording if it can be shared without personal data. This gives a developer a defect to reproduce, not a vague request to “improve accessibility.”

After the selector is repaired, run the same steps again. Then test a different product with the same component and complete checkout. The original defect may be gone while a second barrier remains. Close the issue only when the customer task, not just the individual button, works. Keep the test steps in the release checklist so future component changes do not silently undo the fix.