A website may have readable text, appropriate image descriptions and formally correct controls, yet still leave some people without a practical way to request information. This happens when accessibility is checked element by element rather than as a complete experience: the landing page works, the menu appears usable and the form passes an automated test, but barriers emerge while moving between them and prevent the user from reaching the contact stage.
That is why technical checks should be complemented by an end-to-end journey audit. The aim is not to repeat a general checklist, but to observe whether a person can understand the service, decide where to go, consult the necessary information, complete the form, correct errors and recognise that the message has been delivered. For a broader introduction to semantics, contrast, keyboard navigation and multimedia content, the guide on how to use web design to create a website accessible to everyone remains a useful reference. Here, the focus moves to continuity across the experience.
Start with a real scenario, not an individual page
An effective audit begins by describing a concrete task. For example, a person arrives from a search engine, wants to understand whether the service addresses their needs, looks for information about the working method and eventually decides to send an enquiry. The scenario should include the entry point, the intermediate decisions and an observable outcome.
It is worth testing several entry points because not everyone starts from the home page. A service page, a blog article or a shared link may provide the first encounter with the website. From each of these points, visitors should be able to understand where they are, reach related information and identify a coherent next action without reconstructing the website structure through trial and error.
Define when the journey is genuinely complete
Clicking the submit button does not necessarily complete the journey. The audit should continue until a clear and perceivable confirmation appears. If the message has been received, users must be able to recognise this without relying only on a colour change, text displayed outside the visible area or a temporary notification that is easy to miss.
Before testing, it is therefore helpful to define the expected result: the form is submitted, confirmation is displayed, any following instructions are understandable and the user can return to the content without losing orientation. This makes the test repeatable and helps distinguish a minor inconvenience from an actual blocker.
Check whether the service is understandable before looking for contact options
Journey accessibility begins with content. Generic headings, ambiguous descriptions or calls to action disconnected from their context can make decisions difficult even when the page code is correct. A person should be able to identify the service, understand who it is for and find the essential information without interpreting slogans or opening numerous pages.
During the audit, consider whether headings and subheadings genuinely describe their content, whether links remain meaningful outside the surrounding paragraph and whether similar actions are named consistently. Phrases such as “learn more” may work in some contexts, but become uninformative when repeated without identifying their destinations.
For companies and professionals in Piacenza, this test can begin on the page dedicated to web and SEO services and follow the journey through to the contact request. The local reference should provide useful context for the service, rather than replacing concrete information about activities, methods and ways of working together.
Check orientation and continuity across navigation
Moving between pages is accessible when recognisable points of reference are maintained. Menus, breadcrumbs where present, headings and internal links should help users understand their current position and its relationship with the previous step. Less obvious states must also be checked, including open menus, expanded panels, modal windows and messages that update the page without reloading it.
The audit can follow the priorities established during the design process, as discussed in the article about a professional website and project priorities. If contact is the primary action, every piece of content does not necessarily need the same button, but it should provide a logical route towards further information or action.
Test the journey with a keyboard, browser zoom and a mobile screen
Keyboard navigation and focus
Start from the browser address bar and complete the entire scenario using Tab, Shift+Tab, Enter, the space bar and arrow keys where appropriate. Focus should be visible, follow a logical order and never become trapped inside a menu or dialog. If another element covers the active control, or the indicator disappears against some backgrounds, the user may lose track of their position.
W3C guidance on what is new in WCAG 2.2 helps frame topics such as focus not being obscured, target size, consistent help and accessible authentication. During an audit, these topics should become practical tests of the actual journey rather than isolated checklist entries.
Zoom, reflow and mobile interaction
With browser zoom and on narrow screens, text and controls should remain available without overlaps that prevent interaction. Menus, fixed buttons, banners, selectors and form fields should be checked in portrait and, where relevant, landscape orientation. A permanently visible contact button may be helpful, but not if it covers the last field, an error message or the submit control.
Mobile testing should also include opening the virtual keyboard. The active field must remain identifiable, labels should not disappear and suggestions should be readable without repeated scrolling or magnification.
Review the form as a sequence of decisions
Every field should communicate what users need to enter, whether the information is required and which format is expected. A placeholder should not replace a label because it disappears during input and may have insufficient contrast. The W3C tutorial on labelling form controls explains how visible instructions and accessible names can be associated with input elements.
During the end-to-end test, complete the form correctly once and then repeat it with intentional errors: leave a required field empty, enter an incomplete email address or omit a required consent choice. Errors should be specific, associated with the relevant field and understandable without relying exclusively on colour.
Check recovery from errors
A useful message does more than say that “something went wrong”; it identifies what needs to be corrected. After an unsuccessful submission, valid data should remain available where technically possible, while focus management and an error summary should help users reach the first issue. Check that correcting one problem does not create another barrier and that the form can be submitted without starting again.
Make confirmation perceivable
After a successful submission, the confirmation should be present in the content and communicated in a way compatible with assistive technologies. Its wording should clearly distinguish success from a loading state and explain, without rigid promises, what the person may expect next. The page title or focus management may also help make the change of state evident.
Record barriers according to their impact on the journey
The audit report should identify the scenario, step, device or input method, expected outcome, observed outcome and evidence needed to reproduce the problem. A practical classification may distinguish blockers, significant difficulties and improvements. An unclear label deserves attention; a field that cannot be reached from the keyboard directly prevents completion and requires greater priority.
Each issue should be connected to the part of the journey in which it occurs. This avoids producing a technical list disconnected from user goals and makes it easier to verify the correction by repeating the same scenario.
Combine automated tools with human evaluation
Automated tools can identify markup errors, missing accessible names, contrast problems and other testable conditions. They cannot independently determine whether a service is understandable, whether the order of information supports a decision or whether an error message genuinely helps recovery. An audit should therefore combine automated checks, code inspection and manual journey testing.
Where possible, involving people who use different interaction methods adds evidence that technical simulation cannot provide. Even without turning every check into a large research project, listening to how people interpret the journey may reveal ambiguity, unexpected assumptions and unnecessarily complicated steps.
Accessibility and search visibility: keep the distinction clear
Accessibility should not be presented as a direct ranking factor. Some choices can nevertheless make content easier to understand for both people and crawlers: consistent semantic structure, meaningful text in the DOM, descriptive links and navigation that does not depend on fragile interactions. Google’s technical Search guide for developers recommends pages that are accessible on all devices, semantic HTML and text content available in the DOM. These are quality and technical clarity benefits, not a guarantee of search position.
The audit should therefore verify that essential information does not exist only inside images, animations or components that make it difficult to reach. The path to contact should remain understandable even when some advanced functionality is unavailable.
When to repeat the journey audit
The check should be repeated after changes to menus, templates, forms, consent systems, interactive components or content that affects page hierarchy. It is also useful when new entry points are introduced, because a newly published page may create a different route to contact.
A periodic audit does not require an indiscriminate review of the entire website every time. A set of representative scenarios can be maintained and repeated after updates, extending the checks to changed areas. This makes accessibility part of ordinary quality assurance instead of a separate exercise performed only after the project is complete.
Test the complete journey before considering it finished
An accessible journey is not simply a collection of individual controls that pass checks. It is an understandable and usable sequence in which every step prepares the next, and errors can be corrected without losing completed work. Observing it from entry to confirmation helps focus improvements on the points that genuinely affect a person’s ability to make contact.
If you would like to review your website journey, from the presentation of services to the form confirmation, you can contact Marco Salvatori Design to define a focused assessment of the most important scenarios.
