How People With Disabilities Actually Use Your Website: A Plain-English Tour for Business Owners

Most accessibility advice starts with the rules: WCAG this, success criterion that, add an aria-label here. The rules matter, but they are the answer to a question most business owners have never actually been shown — who is on the other end of the screen, and what are they doing differently from me?

If you have never watched someone use a screen reader, an accessibility report can feel like a list of arbitrary chores. “Add alt text.” “Fix the contrast.” “Make it keyboard operable.” Why? For whom? Once you have seen how people actually navigate, every one of those fixes stops being a chore and starts being obvious. You stop asking “do I have to?” and start noticing the broken bits yourself.

So this is not a checklist. This is a tour. We will walk through the main ways people with disabilities use the web, what each method needs from your site, and the one or two things that break the experience most often. No code required to follow along.

First, a number that reframes the whole thing

Somewhere around one in four adults lives with a disability. Most of those disabilities are not the wheelchair-shaped icon we picture — they are vision that has faded with age, hands that tremble or tire, attention that scatters, hearing that needs captions, or a temporary cast on a dominant arm. The person who cannot use your booking form might be 68 years old, might be your most loyal customer, and might never tell you they left. They will just leave.

That is the part that makes accessibility a business problem rather than a compliance problem. Inaccessible sites do not announce their failures. They quietly lose people who had money to spend and reasons to stay.

1. Screen readers: browsing by ear

A screen reader is software that reads a web page out loud (or sends it to a refreshable Braille display). People who are blind or have very low vision use them, and so do some people with reading disabilities. On a computer the common ones are NVDA and JAWS on Windows and VoiceOver on Mac; on phones it is VoiceOver on iPhone and TalkBack on Android, and it is built right into the device.

Here is the crucial mental shift: a screen reader user does not see your page. They move through it in a line, element by element, listening. They cannot glance at the layout to find the menu. They cannot tell that a grey blob in the corner is a “close” button. They experience your site the way you would experience a long audiobook of its source — one item at a time, in whatever order the page is built.

To move faster, they navigate by structure. They jump from heading to heading to get the lay of the land, the way a sighted person skims. They pull up a list of all the links on the page. They jump between landmarks like “navigation,” “main,” and “footer.”

What this needs from you:

  • Headings that describe the page, in order. If your “headings” are just big bold text that was never marked as a heading, the screen reader user gets no map — they have to listen to everything. If your levels jump around (a main heading, then a tiny sub-sub-heading, then back up), the map is misleading.
  • Real text alternatives for images. A screen reader cannot interpret a photo. If your product image has no description, the user hears “image” or a filename like “IMG_4471” — or nothing. If your “Add to cart” is an icon with no label, they hear “button” with no idea what it does.
  • Links that make sense out of context. Because users pull up link lists, a page full of links that all say “click here” or “read more” is a page full of identical, meaningless options.
  • Status messages that get announced. When something happens without a page reload — “Added to cart,” “Your message was sent,” “3 results found” — the screen reader has to be told, or the user never knows the action worked.

If you only ever try one thing from this article, turn on the screen reader already built into your phone and spend five minutes on your own site with your eyes closed. It is the single most clarifying experience in all of accessibility.

2. Keyboard-only: no mouse at all

A large group of people cannot or do not use a mouse. Some have motor disabilities — tremors, paralysis, repetitive strain injuries, conditions that make the fine, steady movement of a pointer painful or impossible. Some are screen reader users (the two overlap). Some simply have a broken trackpad or a temporary injury. They all drive the web with the keyboard: Tab to move forward through the interactive elements, Shift+Tab to go back, Enter and the spacebar to activate things, the arrow keys inside menus and sliders.

For this to work, two things have to be true, and they are the two things sites break most often.

First, everything you can do with a mouse, you must be able to do with the keyboard. If a dropdown only opens on hover, or a slider only responds to dragging, or a “quick view” only opens on a mouse click that the keyboard can’t reach, that feature simply does not exist for these users.

Second, you have to be able to see where you are. As a keyboard user tabs through the page, the browser draws a focus outline — a ring or highlight — around the element currently selected. It is how they know whether they are about to click “Buy” or “Cancel.” A shocking number of sites deliberately remove that outline because a designer thought it looked untidy. The result is a keyboard user tabbing blind, pressing Enter and hoping. Removing the focus outline is one of the most common and most damaging things a site can do, and it is usually one line of styling.

The quickest gut-check you can run: click on the very top of your homepage, then press Tab over and over. Can you always see exactly where you are? Can you reach the menu, every link, the search box, and the form? Can you get out of a pop-up if one appears? If the highlight ever vanishes or gets stuck, you have found a real barrier. We go deeper on this in our guide to keyboard navigation testing.

3. Screen magnification: the web at 400%

People with low vision who do use their sight often magnify the screen — sometimes a little, sometimes to 400% or more, where only a small slice of the page is visible at once. Picture reading your website through a magnifying glass that only shows a few words at a time, while you push it around the page to find the next bit.

At that zoom level, layout decisions you never think about become make-or-break. Text that is locked to a fixed size and won’t grow is unreadable. Content that disappears or overlaps when the window gets narrow — because the page was only ever tested at full width — strands the user. A “the page must be at least this wide” design forces them to scroll both sideways and down to read a single sentence, which is exhausting.

A related group magnifies in a different way: they bump the browser’s default text size up in settings, or zoom the whole page with Ctrl/Cmd and the plus key. Your site should reflow gracefully when they do — text getting bigger, columns stacking, nothing clipped off the edge or hidden behind something else.

What this needs from you: designs that stretch and reflow instead of breaking, text that is allowed to scale, and no content that vanishes when the viewport gets small. If your site already works well on a phone, you are most of the way there, because a narrow phone screen and a heavily zoomed desktop have a lot in common.

4. Voice control: driving by speech

Some people navigate entirely by talking to their device — “click Sign up,” “scroll down,” “go back.” This includes people with motor disabilities and people with repetitive strain injuries, and the technology is built into modern phones and computers (Voice Control on Apple devices, Voice Access on Android and Windows).

Voice control works by matching what the user says to the visible labels on the page. When they say “click Submit,” the software looks for something on screen that is named “Submit.” This is why the name of a button matters so much, and why a button that is just an icon — a magnifying glass, a little cart, three lines — with no text label is so hard to operate by voice: there is no word to say. It is also why the visible label and the underlying accessible name need to match. If a button reads “Search” but is secretly labelled “find-products” in the code, the user says “click Search” and nothing happens.

What this needs from you: controls that have real, visible, sensible names — and labels in the code that match the words people would actually say.

5. Captions, transcripts, and the quiet web

Not every barrier is about navigation. People who are deaf or hard of hearing need your video and audio content to carry its information in text, too. That means captions on videos (especially anything with a spoken message — a welcome video, a product demo, a founder’s note) and transcripts for podcasts or audio.

And captions are not only for people who cannot hear. A huge share of video on the web is watched on mute — in an office, on a train, next to a sleeping baby. Captions are one of those accessibility features that quietly help almost everyone, which is a recurring theme: the “ramp” built for one group ends up being the convenient entrance for many.

What this needs from you: captions on meaningful video, transcripts for audio, and — please — not relying on auto-generated captions alone for anything important, since they mangle names, numbers, and exactly the words that matter most.

6. Cognitive and attention differences: the web that holds still

The largest and most overlooked group is people with cognitive, learning, and attention differences — dyslexia, ADHD, memory conditions, anxiety, or just the ordinary fog of being tired, stressed, or distracted. They are not using special software. They are using your site the normal way, but they need it to be calmer and clearer than most sites are.

What helps them is plain language instead of jargon, short paragraphs, clear and consistent labels, and — critically — a page that does not move, flash, blink, auto-play, or restart on a timer while they are trying to read it. A carousel that rotates every three seconds, a form that times out and wipes their answers, a pop-up that ambushes them mid-sentence: each of these is a small cognitive tax, and for some users it is a wall.

What this needs from you: clear writing, predictable layouts, generous time limits (or none), and motion that the user controls rather than motion that controls the user.

The pattern underneath all six

Look back at the list and you will notice the same handful of fixes keep coming up: real labels, a logical structure, visible focus, text alternatives, designs that reflow, content that holds still and announces its changes. That is not a coincidence. Accessibility is not six hundred unrelated rules; it is a small set of principles that show up over and over because they map to how real human beings perceive and operate things.

It is also why “we’ll add a widget that fixes accessibility automatically” does not work. None of the six people in this tour are helped by a bolt-on overlay — they are helped by your headings being real headings, your buttons having names, your focus being visible. Those live in the bones of the page. The good news is that fixing them for one group almost always helps the others, and helps your ordinary customers too: clearer labels, faster navigation, content that works on every screen.

You do not have to solve all of this at once. Start by meeting one of these users. Turn on the screen reader on your phone, or unplug your mouse for ten minutes, and visit your own site. You will feel the barriers before you can name them — and once you have felt them, you will never un-see them in your own product again.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.