I checked a contractor's site last month using a keyboard instead of a mouse.
The main menu never took focus. Neither did the quote form. Someone who can't use a mouse would land on that homepage and stop there.
That's an accessibility failure. It's also a legal one. The Americans with Disabilities Act covers websites now, even though the law was written long before websites existed.
What The Law Actually Requires
Title III of the ADA bars discrimination at places of public accommodation. Courts have ruled for years that a website counts, especially one that sells or books something.
The Department of Justice said the same thing directly in 2022 guidance. Title III applies to websites. It still has not published a technical rule, so there is no single checklist with the force of law behind it.
In practice, courts and settlements point to WCAG 2.1 AA, a set of accessibility guidelines built for exactly this question. It is not the law itself. It is the closest thing anyone has to a target.
Why Small Sites Get Targeted
Large companies mostly fixed this years ago, after enough lawsuits landed. Small business sites did not, because nobody told them to and the fix never made it onto a punch list.
That gap is why plaintiff firms test small business sites specifically. A demand letter costs little to send and a lot to ignore, so most businesses settle rather than fight a legal question with no fixed answer.
I am not saying that to sell fear. I am saying it because the legal exposure is one more reason the fix is worth doing, not the only one.
What I Check First
Keyboard navigation first. Can every link, button, and form field be reached and used without a mouse, in a sane order. Most template sites fail this on the main navigation alone.
Color contrast second. Light gray text on white looks clean to a designer and reads as nearly invisible to a lot of real visitors, not just a screen reader.
Form labels third. A field with a placeholder and no label looks fine to a sighted visitor and tells a screen reader nothing about what to type where. Every input needs a real label, not a hint that disappears the moment someone clicks into it.
Video captions fourth, for anything with sound. A caption file does for a video what alt text does for a photo, as our post on alt text and image metadata covers. It gives a machine, and a person who cannot hear, text where there was only sound.
The Fixes That Hold
- Alt text on every image that carries real information, not just the ones someone remembers to write.
- Visible focus states, so a keyboard user can see exactly where they are on the page.
- Real heading structure. One h1, nested h2s and h3s, not bold text pretending to be a heading.
- Labeled, named form fields, the same fields our post on contact forms covers from the lead side.
- Checked color contrast on body text and buttons, not guessed by eye.
None of this is exotic. Most of it is a few hours of disciplined work on a site that already exists.
What Compliance Is Not
It is not an overlay widget bolted onto an existing site. Several of those products have been named in the same kind of lawsuits they are sold to prevent, because they can make a site harder to use with a screen reader, not easier.
It is not a one-time fix either. A new blog post with no alt text, a new form with no labels, a new button with no focus state, undoes the work one page at a time.
It is a standard a build gets held to from the first page, the same way a site gets held to a load time standard or a mobile standard. Fixed at launch. Checked again after every real change.
A site that works for a keyboard and a screen reader also reads cleaner to an AI crawler. The structure that helps a person who cannot see the screen is close to the structure that helps a machine that never could. Building a custom website to that standard from day one costs less than retrofitting one later. That is Web Experiences work, not an add-on.