A beautiful website can still leave a customer unable to use it. The barrier may be a menu that requires a mouse, text that disappears against a photograph, or a form error that is visible but never announced by assistive technology. These failures are easy to miss during a design review because the team already knows where everything is and often uses similar devices. Accessibility asks a different question: who can complete the task independently, including people whose interaction differs from the designer's?
This guide examines an illustrative service website with navigation, pricing information, and an enquiry form. The walkthrough is a practical testing framework, not a claim that the site has received an accessibility certification. It combines standards-based questions with ordinary task observation. The objective is to give a business a useful starting point while making clear why a quick automated scan cannot establish the experience of every visitor.
Begin with a journey rather than a badge
Choose a task that matters, such as finding a service and requesting a quote. Start at a realistic landing page and follow the entire route. Record where a visitor needs to identify a control, understand information, enter data, and recover from a mistake. This approach reveals barriers that can disappear when individual components are tested in isolation. A button might be accessible by itself while becoming unreachable inside a poorly managed dialog.
Avoid making the first objective a perfect-looking report. Reports help organize findings, but the customer needs to complete the task. Give each issue a description of the consequence: a keyboard user cannot reach the submit control, a visitor using zoom cannot see the error, or someone using speech input cannot identify an unlabeled button. A consequence is easier for a project team to prioritize than a vague instruction to improve accessibility. It also makes the retest more concrete.
Use standards as a shared reference
WCAG 2.2 provides testable accessibility success criteria and organizes the subject around making content perceivable, operable, understandable, and robust. The standard is broader than a visual checklist and does not claim to address every individual need. It gives teams a common vocabulary for specifying requirements and discussing findings. The relevant conformance target should be chosen for the project's context with appropriate expertise. Read the W3C recommendation.
Translate that reference into acceptance criteria for the actual interface. A project brief can require visible keyboard focus, usable error recovery, meaningful headings, and appropriate alternatives for informative images. The team should know which criterion each test addresses and what evidence supports a pass. Do not present a standards reference as proof that the whole website conforms. Conformance is a conclusion requiring scope, evaluation, and evidence, not a graphic that can be added to a footer after a single scan.
Put the mouse aside and keep your place
Use a keyboard to move through the page from the beginning. Observe whether the current focus is visible, whether the sequence follows the task, and whether every relevant control can be activated. Open the mobile menu, a dialog, or a date picker and confirm that focus behaves predictably. Closing an overlay should not strand the visitor at an unrelated place or leave controls behind an invisible layer.
Consider a quote form opened inside a modal panel. If the panel appears visually but keyboard focus remains on the page underneath, a visitor can become unsure which interface is active. If focus cannot leave the panel after it closes, the site may be unusable without reloading. These are behavioral problems that a screenshot cannot reveal. Document the exact sequence that reproduces a failure, including the starting point and the keys used. That allows the developer to test the same condition after a repair.
Review content at the size people need
Small text and tightly packed layouts can make a polished design difficult to read. Increase browser zoom and inspect whether important information remains available without overlapping controls or disappearing content. Test narrow widths with longer headings, not only the short labels used in the original design. If a sticky header occupies a large share of the screen, consider how much usable space remains for someone reading with magnification.
Color should support meaning without carrying it alone. An error indicated only by a red outline may be unclear to a visitor who cannot distinguish the color or who never sees the outline. Add a useful explanation and associate it with the relevant field. For charts, provide a text interpretation that communicates the important conclusion. For promotional panels, check the actual text over the actual image rather than evaluating a brand color in isolation. Readability can change dramatically when a photograph changes behind the same heading.
Give controls names that match their purpose
A row of identical links labeled Learn more requires visitors to infer their destination from the surrounding visual layout. A more descriptive label can communicate the actual subject. Similarly, an icon-only button needs an accessible name that describes its action. The name should remain consistent with what the visible interface suggests so people using assistive technology or voice interaction are not forced to learn a separate vocabulary.
Forms deserve particular attention. W3C's forms guidance explains the importance of properly labeling controls. A placeholder is not a complete substitute for a persistent label because it can disappear as soon as someone enters text. Describe what information is needed and which fields are required. See the WAI labeling tutorial. In a project review, inspect both the visible presentation and the relationship exposed by the interface. A label that merely looks close to a field may not actually identify it programmatically.
Make mistakes recoverable
People mistype email addresses, miss required fields, and misunderstand instructions. The interface should help them continue rather than punish them with a generic failure message. For the enquiry example, explain which information needs attention, preserve appropriate input, and make the next step clear. If a server cannot accept the request, distinguish that condition from a mistake in the person's data. Telling someone to correct a field when the service is unavailable sends them in the wrong direction.
Test the unsuccessful routes deliberately. Submit an empty form, a partially completed form, and a valid form while simulating an unavailable service in a controlled environment. Observe what the visitor is told and where focus moves. Include the confirmation state in the review: a success message should communicate what happened and what to expect next. Avoid assuming that an animation or a color change is enough to convey receipt of an important request.
Include people whose experience differs from yours
Automated tools can identify some technical problems, but task-based evaluation with people can expose difficulties that are harder to reduce to a rule. Plan participation respectfully, compensate participants where appropriate, and explain what is being tested. Ask participants to attempt realistic tasks rather than approve the design in general. Observe where they hesitate or need assistance, and avoid steering them toward the intended answer.
One participant does not represent everyone with a particular disability or access requirement. Differences in tools, experience, and preferences matter. Treat a session as evidence about the conditions observed, not as a universal endorsement. Combine findings with expert review and technical testing. When the team cannot evaluate a particular interaction confidently, record that limitation and arrange the relevant expertise rather than silently marking the area complete. Honest uncertainty is more useful than a false claim that a website works for everyone.
Prioritize barriers and protect the fixes
Create a backlog that connects each finding to its customer consequence and the components affected. A shared navigation problem may appear across many pages, while a confusing sentence may affect one service description. Fixing a shared component can improve several journeys at once, but the change still needs a regression check. Confirm that the repair works at different widths and does not create a new obstacle for another mode of interaction.
Make accessible behavior part of the design system and editorial process. Document how labels, errors, headings, and focus states should work so future pages inherit the improvements. Content editors need examples of useful image alternatives and descriptive link text, not just a reminder to be accessible. Schedule checks after major theme changes, new widgets, or altered forms. The work becomes sustainable when accessibility is included in routine decisions instead of being deferred to an expensive inspection just before launch.
Define what a meaningful review can conclude
A useful review states its scope. Identify the pages, components, browser and assistive technology combinations, and tasks examined. Distinguish confirmed failures from areas that were not evaluated. If the review covers a representative sample, explain how that sample was selected and why additional content might behave differently. A dated record helps future teams decide whether a new feature or template falls outside the earlier evaluation.
The outcome should be a clearer path for customers and a more accountable process for the business. That can include resolved barriers, a documented backlog, and better requirements for the next release. It should not become an unsupported promise of legal compliance or universal usability. A website earns trust when its team can explain how it was evaluated, what was improved, and what still needs work. Visual appeal remains valuable, but the experience becomes stronger when more people can actually use the design to reach their goal.
Review downloadable information too
A customer journey can leave the main website. A price list, application document, or instruction sheet may introduce a new barrier after the visitor has successfully navigated the page. Include important downloads in the scope and establish who maintains them. If a document contains the only explanation of a service condition, consider providing an accessible web version as well. An accessible navigation system does not compensate for essential information being trapped in a difficult file.
Inspect links that open documents and explain the destination clearly. A visitor should know whether they are opening a web page or downloading a file. Keep the document's title, version, and relationship to the current service understandable. When a downloadable resource changes, update the referring pages and remove misleading references to previous conditions. The review should follow the information wherever the task requires it, instead of stopping at the edge of the site's visual template.
