If your small business serves customers through its website, accessibility should be part of the build — not a panic purchase after somebody sends you a scary compliance report.
For US businesses, the legal picture needs careful wording. The Department of Justice says Title III of the Americans with Disabilities Act applies to businesses open to the public and that the goods and services they provide online must be accessible to people with disabilities. But DOJ also says it does not currently have a regulation setting detailed web standards for private businesses in the way its newer Title II rule does for state and local governments.
So the useful business question is not, “Which badge makes my website compliant?” It is:
Can customers with disabilities actually understand the site and complete the important actions the business offers online?
This is practical guidance, not legal advice. If you need a legal determination for your business or jurisdiction, speak with a qualified lawyer.
What the ADA actually says about business websites
The US Department of Justice’s web accessibility guidance says businesses open to the public must provide full and equal enjoyment of their goods and services to people with disabilities, including services offered online.
That covers familiar businesses such as hotels, medical offices, banks, retailers and food establishments.
The same DOJ guidance makes an important distinction: private businesses have flexibility in how they meet the ADA’s general requirements. DOJ points to technical standards such as the Web Content Accessibility Guidelines (WCAG) as useful guidance, but its general Title III guidance does not impose one detailed WCAG version as a universal private-business web regulation.
Do not confuse that with the separate Title II rule for state and local governments. DOJ’s current small-entity compliance guide says covered state and local government web content generally needs to meet WCAG 2.1 Level AA, with compliance dates extended in 2026 to April 26, 2027 for larger public entities and April 26, 2028 for smaller entities and special district governments.
That distinction matters because many 2026 articles turn a government deadline into a blanket deadline for every private small business.
Where WCAG fits
WCAG is maintained by the W3C Web Accessibility Initiative. Its framework groups accessibility under four broad principles: content should be perceivable, operable, understandable and robust.
The W3C’s WCAG overview and WCAG 2 at a Glance are better starting points than treating accessibility as a mysterious legal checklist.
In practical website work, those principles show up as questions such as:
- Can somebody understand important images without seeing them?
- Can the navigation, forms and dialogs be used with a keyboard?
- Is text readable against its background?
- Do form fields have meaningful labels and useful error messages?
- Can a customer zoom the page without losing the journey?
- Are headings and page structure meaningful to assistive technology?
- Do videos that communicate important information have appropriate alternatives such as captions?
Accessibility is not a separate decorative layer. It is part of whether the interface works.
Test the business journey, not only the homepage
A homepage can score well while the action that makes the business money is unusable.
For a clinic, the important journey may be finding a service and requesting an appointment. For a hotel, it may be checking a room and reaching the booking flow. For a consultant, it may be understanding an offer and completing an enquiry form. For ecommerce, it is product selection through payment confirmation.
I would prioritise accessibility testing around those journeys first:
| Journey | What to inspect |
|---|---|
| Navigation | Keyboard access, visible focus, meaningful link text, mobile menu behavior |
| Enquiry forms | Labels, instructions, validation, error recovery, confirmation |
| Booking | Date controls, room/service selection, keyboard operation, third-party widgets |
| Checkout | Product options, address/payment fields, errors, confirmation |
| Content | Heading structure, contrast, zoom, image alternatives, readable language |
| Account/auth | Login, password reset, verification and error states |
| Documents | Whether important information is available in an accessible format |
This is the same systems principle I use when reviewing forms and product flows: a component working in isolation does not prove the customer can complete the outcome.
Automated accessibility scans are useful — but not proof
Automated tools are good at catching certain repeatable problems quickly. They can help flag missing labels, contrast problems, structural issues and other machine-detectable failures.
But DOJ explicitly warns in its guidance that automated checkers and overlays need to be used carefully. A “clean” automated report does not necessarily mean everything is accessible. DOJ recommends combining automated checking with manual review.
That makes sense operationally. A scanner may detect that a button has a label. It cannot always tell whether the label makes sense in context, whether a keyboard user gets trapped in a modal, or whether the booking journey becomes confusing after an error.
Treat the scan as evidence, not a certificate.
What to ask a web designer before you pay
If accessibility matters to the project, put it into scope before the site is built.
Ask the designer or developer:
- Which accessibility standard are you designing and testing toward? “Accessible” by itself is too vague.
- Which pages and journeys will you test? A homepage-only scan is not enough for a site with forms, booking or checkout.
- Will you test keyboard operation manually? Ask specifically about menus, dialogs, forms and interactive controls.
- Who owns content accessibility? Alt text, captions, PDFs and editorial structure can fail after the developer finishes the template.
- Are third-party tools included? Booking widgets, payment interfaces and embedded forms can sit inside the customer journey even when another vendor provides them.
- How are defects recorded and accepted? Accessibility should have a test-and-fix process, not just a promise in the proposal.
- What happens after launch? New content and features can introduce new barriers.
This is also why a good website maintenance plan should define what is actually monitored and tested instead of selling “support” as an undefined word.
Accessibility overlays are not a substitute for understanding the site
It is tempting to solve accessibility with one script, widget or badge because that turns a difficult design and testing problem into a purchase.
DOJ’s own guidance is more cautious: automated tools and overlays can be helpful, but they must be used carefully and a clean report is not proof that the website is accessible.
The safer operating model is to build accessible patterns into the interface, test important journeys, fix defects at their source where possible, and keep accessibility in the maintenance process as content and functionality change.
Accessibility is also a product-quality test
Even outside the legal question, many accessibility improvements are simply signs of a better-built interface.
Clear labels make forms easier to complete. Visible focus makes keyboard navigation understandable. Useful error messages reduce failed submissions. Logical headings make long pages easier to scan. Better contrast improves readability in difficult lighting. Captions help people who cannot play audio.
That is why I would not frame accessibility as a compliance tax. It is a constraint that exposes weak interface decisions earlier.
If you are already planning a rebuild, use the redesign vs rebuild guide to decide whether accessibility problems are isolated interface defects or symptoms of a deeper technical foundation problem.
A sensible first pass for a small business
You do not need to begin by pretending every business has the same risk, site complexity or legal situation.
Start with the customer journeys that matter most. Run an automated check. Then manually navigate those journeys using only a keyboard. Review headings, labels, contrast, zoom, images, errors and confirmations. Include mobile. Include the third-party tools the customer actually touches.
Document what failed and fix the highest-impact barriers first.
If you are commissioning a new website, accessibility is cheaper to reason about before the design system and components harden than after dozens of pages inherit the same mistake.
If you want a business website planned around the complete customer journey — including mobile behavior, forms, accessibility, ownership and post-launch operation — see my web design service or contact me with the current site and the outcome you need it to support.
