An ADA-related website accessibility review should tell you whether customers can complete the important jobs on your site, where they get blocked and whether the remedy is a small repair, a broader template and content programme, or a platform decision. It is not a legal certification, and it should not begin with a generic score.
Start with the routes that produce an enquiry, booking, payment or service delivery. A customer who cannot use a decorative image has had a poor experience; a customer who cannot submit the form to request an appointment has been shut out of a core business process. Both matter, but they do not carry the same operational priority.
What a credible accessibility review examines
A useful website accessibility audit maps the journeys a customer actually takes. For a service business, that may mean finding a service, checking availability, completing an enquiry form and receiving confirmation. For an online seller, it may mean searching, selecting a product, adding it to a basket, entering delivery details and paying. A client portal may need separate testing for sign-in, document access, messages and account changes.
The reviewer should test the pages, templates and components used in those journeys, rather than treating every URL as an unrelated problem. One inaccessible navigation menu or form field pattern may affect dozens of pages. Conversely, a one-off PDF or campaign landing page may need a targeted correction without requiring a site-wide rebuild.
The review normally looks at issues such as page structure and headings, meaningful text alternatives for images, readable labels and error messages on forms, colour contrast, visible keyboard focus, clear link wording, accessible tables and whether content still works when enlarged. The point is not to collect a long checklist. It is to identify what prevents or makes it unnecessarily difficult for people to use the site.
Automated checks find patterns, not the whole customer experience
Automated testing tools are useful early on. They can quickly identify repeated problems such as missing form labels, poor contrast in particular components, empty links or invalid page markup. They are particularly helpful for finding a pattern across a large site and confirming that a known fault has been removed.
They cannot reliably decide whether a button name makes sense, whether instructions are understandable, whether focus moves sensibly after opening a pop-up, or whether an error message tells a customer how to correct a failed submission. A clean automated report is therefore not evidence that a customer can complete a journey.
Use automated results as an inventory for investigation, not as the final verdict on ADA website compliance.
Where accessibility findings belong
Manual keyboard and screen-reader testing exposes the blocking faults
Manual testing should follow the priority journeys from start to finish. Keyboard testing checks whether someone can reach every interactive item using standard keys, see where they are on the page, operate menus and pop-ups, and leave a component without becoming trapped inside it.
Screen-reader testing checks what a customer is told as they move through the page. For example, a visually clear enquiry form can still fail in practice if a screen reader announces several fields only as “edit text”, or if a validation error appears on screen but is never announced.
Consider an illustrative booking journey. A customer selects a date, chooses a time, enters contact details and confirms. If the date picker cannot be operated by keyboard, or its selected date is not announced clearly, the booking process is unavailable even when the rest of the website is well built. That is a high-priority finding because it affects a value-generating action directly.
Third-party tools need their own risk assessment
Booking systems, payment pages, live chat, embedded maps, cookie notices and forms often come from suppliers. They should be tested separately, including the hand-off between your website and the supplier tool.
A site owner can usually improve the surrounding page, instructions and route into an embedded tool. They may not be able to correct inaccessible controls inside a supplier’s widget. The remediation plan should say which issues your team controls, which require supplier action and whether a replacement is the practical answer.
Do not assume an accessibility overlay resolves this. An overlay may offer individual display adjustments, but it does not repair unclear form labels, broken keyboard behaviour or inaccessible content in a booking supplier’s software. It can also add another interface that customers must navigate.
From Accessibility Review to Reliable Customer Journeys
Choose key journeys
Start with finding, enquiring, booking, paying or accessing a client area.
Check for patterns
Use automated checks to spot repeated issues across pages and components.
Test real blockers
Use keyboard and screen-reader tests to find faults that block customers.
Repair and retest
Fix by priority, retest the journey, then give publishers a clear standard.
How findings should be prioritised and turned into a plan
A useful report groups duplicate findings and explains each one in plain language: the affected journey, who may be blocked, the pages or components involved, the likely cause, the recommended fix and who owns it. It should distinguish between an urgent journey blocker and a lower-risk improvement, rather than sorting work only by a technical severity label.
Review the actions that generate value or complete a transaction first, such as finding a service, submitting an enquiry, booking, paying or accessing a client area.
From there, the plan can separate work into sensible streams:
- quick repairs to labels, headings, contrast, links and content;
- shared template or component changes that improve many pages at once;
- supplier conversations or replacement decisions for third-party tools; and
- larger platform work where the current website makes accessible behaviour difficult to maintain.
Retest the repaired journeys manually after changes are made. Then give the people who publish pages, upload documents or add products a simple standard to follow, so the same problems are not reintroduced next month.
If the site already supports the core customer journey and its faults are concentrated in a few shared patterns, repair those patterns before considering a rebuild. A rebuild is justified when the platform or its essential plugins repeatedly prevent accessible forms, navigation, content editing or third-party integrations, and those limits make ongoing repair unreliable.
For a wider view of the design and technical choices involved, see website design and development.
Need to work out what needs fixing on your website?
Show us the pages where customers enquire, book, pay or access services, plus the forms and third-party tools connected to them. We can identify practical accessibility fixes, separate quick repairs from larger platform issues, and plan the work around the journeys your customers rely on.