Start with the things a customer must be able to do: find a product or service, understand the information, and contact you or complete an order. If a keyboard user cannot open your menu or a screen reader user cannot identify the fields in your enquiry form, those are concrete repairs to commission before another round of visual polish.
For an existing US small-business website, my starting point would be a working customer journey, a short list of reproducible barriers, and a written agreement about what will be repaired and retested. That is more useful than buying a badge with no explanation of what was checked.
This guide helps you scope that first round. It is not a complete accessibility assessment or a legal opinion about your business.
Understand the US guidance and set a technical target
The US Department of Justice takes the position that the ADA applies to goods and services offered online by businesses that are public accommodations. Its web accessibility guidance explains that inaccessible features can prevent people with disabilities from accessing those services. Whether particular obligations apply to your business is a legal question; this article cannot determine that from your company size or website address.
For the work itself, ask the supplier to name the standard and level being assessed. WCAG is a technical standard with testable success criteria. WCAG 2.2 Level AA is a useful target to discuss for a new remediation brief. Record the agreed version, level and scope rather than accepting the undefined phrase “ADA compliant.”
A technical target, a limited test report and a legal conclusion are different things. Do not borrow a government website deadline and assume it is your private business's deadline.
Test one complete customer journey
Choose a real route through your site: homepage → service or product → enquiry, booking or checkout. Include the steps after opening the form, not just the attractive first screen. Use a test environment or an agreed test submission so you do not create a real order.
The table below is a starting repair list. It does not cover every WCAG requirement.
| What to try | A barrier to record | What to ask for |
|---|---|---|
| Set the mouse aside. Use Tab and Shift+Tab, then the control's appropriate keys. | A menu, product option or enquiry button cannot be reached or operated. | Make the ordinary customer functions operable by keyboard. Retest the entire route, including opening and closing controls. |
| Watch where the keyboard moves. | You lose your place because the focused control has no visible indication. | Provide visible focus on links and controls, and check it against the actual page backgrounds. |
| Inspect each field before typing and after entering text. | The field's purpose disappears with its placeholder, or a screen reader cannot identify it. | Give fields clear, properly associated labels and instructions. A placeholder alone is a poor substitute for a persistent label. |
| Leave a required field empty or enter an invalid value in a controlled test. | Only a red border appears, or you cannot locate and correct the mistake. | Identify the error in text and make correction possible. Retest validation and error handling, not just successful input. |
| Check body text, prices and button labels with a contrast checker. | Pale text disappears into its background. | For WCAG AA, normal text generally needs 4.5:1 contrast; large text needs 3:1. These are text criteria with exceptions, not a universal rule for every graphic. |
| Enlarge the page and inspect a narrow viewport. | A fixed panel covers the form, or ordinary paragraphs require sideways scrolling. | Check reflow at a width equivalent to 320 CSS pixels, without losing information or functionality. Content that genuinely requires two dimensions, such as some tables, has specific exceptions. |
After those checks, have someone who knows assistive technology test the meaningful sequence with a screen reader. A control can look correct and still have the wrong name or announce no useful change after an action. Record the browser and assistive technology used so a developer can reproduce the finding.
Include the content and the tools you do not host
Product photographs, diagrams and banners need different treatment. An informative image needs an appropriate text alternative; a purely decorative image should not create unnecessary speech. W3C's images tutorial explains this distinction. If specifications or opening hours exist only inside an image, put the essential information into readable page text too.
For a spoken product demonstration, review the captions rather than assuming automatically generated words are accurate. Captions should also convey relevant non-speech audio. Check the media controls as part of the same customer task.
Now follow any external step: a booking widget, payment page, chat service or downloadable catalogue. Put these into the project inventory and identify who can change them. “That belongs to another provider” identifies an ownership problem; it does not give the customer a working booking route.
If a document or vendor step blocks access, agree an immediate usable way to obtain the information or service while the underlying repair is handled. Label that as an interim measure and keep the original issue open.
Turn observations into a repair list
Write findings so another person can repeat them. “Accessibility is bad” gives a supplier very little to act on. A useful record says:
- Page and task: the exact URL and what the customer was trying to do.
- Steps: the keys, input or settings used to reach the problem.
- Expected and actual result: what should have happened and what prevented completion.
- Evidence: a short recording or clear description, plus the browser and test setup.
- Owner and retest: who will repair it and what you will repeat to check the result.
My suggested order is to address blocked enquiries, bookings and purchases first; then shared menus, forms and templates; then the remaining content issues. A shared repair can help many pages, but retest representative pages instead of assuming every use is identical. This follows the practical idea of prioritizing interim repairs while keeping the broader accessibility work visible.
Do not convert an issue count into a severity score without looking at the task. One unusable enquiry form can matter more to your customers than many repeated low-impact warnings.
Commission a defined repair and accept evidence
A useful brief might read: “Assess our menu, product template and enquiry journey against the agreed WCAG target. Include keyboard and screen reader checks, the form's error state, and the external booking step. List the pages and states tested, implement the agreed repairs, and provide before-and-after evidence and remaining limitations.” This is an illustrative scope, not a promise that those items establish full conformance.
Separate assessment, implementation and retesting in the quote. Ask which templates, documents, languages and third-party tools are included. Agree who fixes a plugin or content problem, and how an item that cannot yet be fixed will be reported.
At acceptance, repeat the original failed steps. Request the tested URLs, methods, findings closed and issues still open. An automated scan can help locate some problems, but a clean score or installed overlay is not proof that the full journey works. W3C's introductory checks explicitly cover only part of accessibility.
Where possible, include people with disabilities in evaluation alongside a standards-based review. W3C cautions against generalizing from a limited user sample. One successful test does not represent every customer or establish whole-site conformance.
Keep the repaired journey working
Assign someone to receive accessibility reports and maintain a clear way to contact them. After changing a menu, form, product template or booking tool, repeat the affected journey. New content also needs review: an accessible template does not prevent an editor from uploading an image-only price list.
If you are still locating the problems, start with the broader business website audit checklist. If you are hiring help, use the web designer verification guide to agree scope and handover. Then bring a specific question to the supplier: “Can this customer complete this task, and can you show me the retest?”
