Somebody is trying to book an appointment with you right now and can’t. They aren’t going to call to complain. They’ll go to the next business on the list, and you will never know they were there.
That person might be blind. They might have a tremor, or a broken wrist, or be holding a baby in one arm. They might be sixty-eight and have the text on their phone turned up as far as it goes. They might be standing in bright sun, or on one bar of signal in a parking lot. A site that works for the first person on that list works for all of them, and that’s the whole argument of this article. My business cards have raised Braille on them for the same reason. It isn’t charity. It’s the cheapest way I know to build something that works.
How people actually use the web
Plenty of people don’t use a website by looking at it and pointing, and each of the ways they get around breaks on something specific.
A screen reader reads the page aloud, or sends it to a refreshable Braille display. Every phone and computer has one built in: VoiceOver on iPhones and Macs, TalkBack on Android, Narrator on Windows. NVDA is a free one for Windows, and JAWS is a long-standing paid one. Experienced users don’t listen to a page from top to bottom. They jump. They pull up a list of headings and skip to the one they want, or a list of links, or go straight to the first form field. A page with no real headings is a page they have to listen to in full, at speed, hoping they catch the part they need.
What a screen reader can read is text. It can’t read a picture of text. It reads a photo only if someone wrote a description of it (the “alt text”). It reads a button as whatever the button’s label says, and if the button is an icon with no label, it says “button” and nothing else.
A keyboard is how many people with motor disabilities get around, along with a lot of power users. Tab moves to the next link or control, Shift+Tab goes back, Enter follows a link, the space bar presses a button. If a menu only opens when you hover over it with a mouse, none of these people can reach what’s inside it.
Zoom is the most common one, and the one people don’t think of as a disability tool at all. Text at 200% has to rearrange itself, not spill off the side of the screen.
Captions get used by deaf and hard-of-hearing people, and by everyone watching your video in a waiting room with the sound off.
A shaky hand, or a big thumb, or a bus going over a pothole, needs buttons that are big enough to hit and far enough apart that you don’t hit the wrong one.
None of this needs special software from you. The browser and the phone already do the work. Your site only has to not get in the way.
The mistakes small business sites keep making
WebAIM, a nonprofit at Utah State University, scans the home pages of the top million websites every year. The same handful of problems sits at the top of their list year after year: low-contrast text, images with no alt text, links and buttons with no text in them, form fields with no labels, and pages that don’t say what language they’re in. None of these are exotic. All of them are on small business sites I look at every week.
Photos with no description. The fix is a sentence. Describe what the picture is there to tell someone. Not “image” or “photo123.jpg”, and not a paragraph of keywords. For a bakery’s front page:
A tray of cinnamon rolls fresh out of the oven, icing still running down the sides.
If a picture is pure decoration, a swirl or a background texture, it should have empty alt text so a screen reader skips it. If a picture contains words, like a flyer for your event, those words need to be on the page as real text too. Most website builders have an “alt text” or “description” box on every image. It’s usually empty.
Light gray text on white. It looks clean in a design mockup. It’s hard to read for anyone with low vision, anyone over fifty, and anyone outdoors. WCAG asks for a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text. You don’t need to calculate that yourself. Free contrast checkers (WebAIM has one) take two colors and tell you pass or fail. Text on top of a photo is the usual offender.
Menus that need a mouse. Dropdowns that open on hover, sliders you can only drag, “click here” areas that are pictures with a click handler instead of real links. Tab through your site and you’ll find them in a minute.
The menu is a PDF. I understand why: the file already exists. But a PDF menu is miserable on a phone even with perfect eyesight, and if it was scanned or exported as an image, a screen reader gets nothing at all. Google can’t read prices out of a picture either. Put the menu on the page as text. Keep the PDF as a “download to print” link if you like.
Forms with no labels. A field that says “Email” in faint gray inside the box, which disappears as soon as you start typing, is a field with no label. The screen reader user may hear nothing, and everyone else forgets what the box was for halfway through. Every field needs a visible label outside the box. Error messages need to say what went wrong in words (“Phone number is missing a digit”), not only by turning the box red.
Things that start on their own. Video with sound that plays on load talks over the screen reader, so the person trying to use your site can’t hear it. Carousels that slide every few seconds move the text before slow readers finish it. If anything plays or moves by itself, there has to be a way to stop it, and sound should never start without being asked.
Tiny, crowded tap targets. Phone number, email and directions links squeezed into one line of small text. WCAG 2.2 asks that touch targets be at least 24 by 24 pixels, or spaced so that a near miss doesn’t land on the neighbor. Bigger is kinder.
No headings, or fake ones. Text made big and bold to look like a heading, without being marked as one, looks fine and is invisible to the heading list a screen reader user relies on. In most editors, use the “Heading 2” style rather than making text bold and bigger.
What WCAG 2.2 is, in one paragraph
The Web Content Accessibility Guidelines are published by the W3C, the body that sets standards for the web. Version 2.2 came out in October 2023 and is the current one. It’s a list of testable requirements arranged under four ideas: people have to be able to perceive your content, operate it, understand it, and it has to work with the tools they use (perceivable, operable, understandable, robust). Each requirement has a level: A is the minimum, AA is the level that laws, contracts and courts usually point to, and AAA is the stricter one hardly anyone meets across a whole site. If someone asks whether your site “meets WCAG”, they almost always mean 2.1 or 2.2 at level AA. Version 2.2 added a few things that matter for small businesses in particular: tap targets big enough to hit, a keyboard focus you can actually see, and not forcing people to solve a puzzle or remember a code to log in.
The legal side, in plain words
I’m not a lawyer, and this isn’t legal advice. Here is what is solid.
The Americans with Disabilities Act was written in 1990, before business websites existed. Title III of the act covers “public accommodations”: shops, restaurants, offices, gyms, the places the public walks into. US courts have applied it to websites. The best-known example is Robles v. Domino’s Pizza, where a blind man couldn’t order through Domino’s website and app. The Ninth Circuit Court of Appeals ruled in 2019 that the ADA applied, and the Supreme Court declined to hear Domino’s appeal. Courts in different parts of the country don’t all agree on the details, especially for businesses that exist only online. But “the ADA doesn’t cover websites” isn’t a safe assumption for a business with a door customers walk through.
There’s no federal regulation that sets a technical standard for private business websites. The Department of Justice did adopt WCAG 2.1 AA as the standard for state and local government websites in 2024. That rule covers governments, not your shop, but it tells you which yardstick people reach for.
In practice, what a small business is most likely to meet isn’t a trial. It’s a demand letter: a letter from a law firm saying your site has accessibility barriers and proposing a settlement. These letters are real and they do go to small businesses. Some come from people who were genuinely shut out. Some come from firms that send a lot of them. Either way, the sensible response is to call your own lawyer, not to ignore it and not to pay it on the spot.
Why “one line of code” won’t fix it
You’ve probably seen the ads: paste one script into your site and an accessibility widget appears, a little person icon in the corner, and your site is now compliant. These are called overlays.
They don’t work. An overlay can’t write a good description of your photo, because it doesn’t know why the photo is there. It can’t turn a scanned PDF menu into text. It can’t make a hover menu work with a keyboard if the menu was built wrong. What it adds is a toolbar of settings (bigger text, different contrast) that duplicates what people’s own devices already do, set up the way they need. Some overlays get in the way of screen readers.
Hundreds of accessibility practitioners have signed a public statement, the Overlay Fact Sheet, saying overlays don’t make sites accessible. Businesses with overlays installed have still received demand letters and been sued. And in January 2025 the Federal Trade Commission took action against accessiBe, one of the best-known overlay companies, over its claims that the tool could make any website compliant.
If you’re paying for one, you aren’t protected by it. The money is better spent fixing the handful of real problems on your pages, which usually isn’t many.
The fifteen-minute self-test
Do this today. You need your site, a phone, a computer, and a quarter of an hour. Write down everything that goes wrong. That list is your to-do list.
1. Put the mouse away (four minutes). On a computer, open your home page, click once in the address bar, and press Tab over and over. Watch for:
- Can you always see where you are? There should be a visible outline or highlight on whatever is selected. If it disappears, that’s a failure.
- Does it go in a sensible order, top to bottom, left to right?
- Can you open the menu and reach every page in it?
- Can you get to your contact form, fill it in, and press Enter to send it?
- Do you ever get stuck inside something, like a popup or a map, and can’t Tab out?
2. Turn up the zoom (two minutes). Press Ctrl and + (Cmd and + on a Mac) until the page is at 200%. Does everything still fit, or do you have to scroll sideways to read a line? Does text overlap or get cut off? Then on your phone, go to the accessibility settings, make the text size as large as it goes, and look at your site again.
3. Listen to it (five minutes). On an iPhone, open Settings, then Accessibility, then VoiceOver, and turn it on. On Android, it’s TalkBack, under Settings and Accessibility. The gestures change while it’s on: tap once to hear something, double-tap to activate it, swipe right to move to the next thing. Learn how to turn it off before you turn it on. (On an iPhone you can set the side button to switch it on and off with a triple-click.) Open your site and swipe through the top of the home page. Do you hear your business name and what you do? Do your photos say something useful, or “image”? Do your buttons say what they do? Can you find your phone number?
4. Check your images and contrast (two minutes). Run the free WAVE tool from WebAIM on your home page (wave.webaim.org), or the Accessibility section of Google’s PageSpeed Insights. Both will flag missing alt text, low contrast and missing labels. Automated checkers only catch the problems a machine can measure, so a clean result is a good sign, not a certificate.
5. Look for the PDFs and the autoplay (two minutes). Is your menu, price list, or intake form a PDF? Does anything play sound or move by itself? Does your video have captions?
If you wrote nothing down, you’re ahead of most sites I see.
What to fix first
Not everything matters equally. If you can only do a few things, do these, in this order:
- Your phone number, address and hours as real text on the page, not inside an image.
- Every form field with a visible label, and a submit button that says what it does (“Send message”, “Book”).
- Alt text on every photo that carries meaning, and empty alt text on the decorative ones.
- A menu that works with a keyboard.
- Text dark enough to read.
- The PDF menu or price list put on a web page as text.
Most of that you can do yourself in your site builder’s editor in an afternoon. Item 4 sometimes needs whoever built the site. If they tell you it can’t be done, they’re wrong.
The honest version
Accessibility isn’t a project you finish and file away. Every new photo needs a description, every new page needs headings, every new form needs labels. That sounds like a burden, and it’s mostly a habit. After a month you stop noticing you’re doing it.
I’m not going to tell you this will double your sales. I don’t know that, and nobody does for your business. What I’m sure of is the overlap. A page a screen reader can understand is a page Google can understand. A page that works at 200% zoom is a page that works on a small phone. A form with clear labels is a form fewer people give up on. You don’t have to choose between doing right by the blind customer and doing right by your business. It’s the same work.