How do people with disabilities use the web? Assistive tech explained

Three people try to book a table on the same restaurant website. Amira is blind and listens to the page through VoiceOver on her iPhone. Tom has rheumatoid arthritis and uses the keyboard, because the mouse hurts. Margit is 78 and zooms to 200% to read the menu. If the menu is a photo of a printed page and the date picker only responds to a mouse, all three give up and book somewhere else.

This guide explains how people with disabilities actually use the web, with current figures. A note on words: we use “people with disabilities”, as EU institutions do, while many people, particularly in the UK, prefer “disabled people”. When you write about a specific person, use the words they use.

How many people have a disability?

About 1.3 billion people, 16% of the world's population or 1 in 6, experience significant disability, according to the World Health Organization (opens in a new tab) (fact sheet, March 2023). In the EU, 23.9% of people aged 16 and over reported a long-standing limitation in everyday activities in 2024, roughly one adult in four, according to Eurostat (opens in a new tab).

National figures range from 12.7% in Bulgaria to 41.2% in Latvia, and the measure is self-reported, so compare countries with care. The age curve matters more. The share is ten times higher (opens in a new tab) among people aged 85 and over (72.3%) than among 16- to 24-year-olds (7.1%), and 22.0% of the EU population (opens in a new tab) is 65 or over. Many of them wouldn't describe themselves as disabled.

What is assistive technology?

Assistive technology is any software or hardware that lets a person use a computer, phone or website in a way that suits their body and mind. Screen readers, magnifiers, speech recognition, switches and braille displays are the best-known examples. People also rely on simpler adjustments, such as larger text, a slower pointer or captions switched on by default.

The W3C calls those simpler adjustments “adaptive strategies”, which its overview of tools and techniques (opens in a new tab) describes as “techniques that people with disabilities use to improve interaction with the Web”. Most people combine both.

Much of this comes built in: VoiceOver and Voice Control on Apple devices, TalkBack and Voice Access on Android, Narrator and Magnifier on Windows. Many Windows users add JAWS, which is paid, or NVDA, which is free.

How do blind people use websites?

Most blind people use a screen reader, software that turns the page into speech or braille, and move through it with keyboard commands or touch gestures rather than a mouse. They rarely listen from top to bottom. In WebAIM's 2024 survey, 71.6% of screen reader users said they first navigate a long page by its headings.

WebAIM's Screen Reader User Survey #10 (opens in a new tab) collected 1,539 responses in December 2023 and January 2024. It's a self-selected sample, not a census. Some findings:

• On desktop, 40.5% mainly use JAWS, 37.7% NVDA and 9.7% VoiceOver.
• 91.3% use a screen reader on a phone or tablet, and 70.6% mainly use Apple devices.
• 38% use braille output, through a display that raises pins to form characters.

Picture a screen reader user on a product page. They pull up a list of headings and jump to “Reviews”. They never experience your layout, only the structure underneath it: if your headings are just bold paragraphs, that list is empty, and three buttons called “Add to basket” sound identical.

• Headings that are real heading elements, in a sensible order.
• Alt text that says what matters: “Navy wool coat, knee length, front view”, not “IMG_4471.jpg”. Decorative images get empty alt text so they're skipped.
• Form labels on every field, and error messages that are announced, not only shown in red.
• Link and button text that makes sense alone: “Read our returns policy”, not “Click here”.

How do people with low vision use websites?

People with low vision usually make things bigger or clearer rather than switching to audio. They zoom the browser, use a screen magnifier, enlarge system text, turn on high contrast or dark mode, or add spacing. It's a large group: WHO estimates that at least 2.2 billion people have a near or distance vision impairment.

At high zoom, a magnifier user sees a small part of the screen at a time. A “Basket updated” message in a top corner is easy to miss, and so is an error summary placed far from the faulty field.

The Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab) cover this with three Level AA success criteria: text must resize to 200% without losing content (1.4.4), content must reflow at a width of 320 CSS pixels so nobody scrolls in two directions (1.4.10), and pages must survive extra line, letter and word spacing (1.4.12). For contrast, see our guide to colour contrast. As for the photographed menu: rebuilt as a web page with headings, it works for Margit and Amira alike.

How do deaf and hard-of-hearing people use the web?

Deaf and hard-of-hearing people use the web like anyone else until sound carries information. Then they need captions on video, transcripts for audio, and a way to contact you that isn't a phone call. WHO estimates that 430 million people, over 5% of the world's population, need rehabilitation for disabling hearing loss.

For many Deaf people (the capital D often signals Deaf culture and sign language), a national sign language comes first and written language second. Plain writing helps them as it helps anyone reading in a second language.

• Caption every pre-recorded video with speech (WCAG 1.2.2, Level A). Check automatic captions: they can garble names, product terms and numbers.
• Offer contact routes besides the phone. “Call us to cancel” shuts some customers out entirely.
• Don't autoplay sound. Audio that plays for more than 3 seconds needs a pause or stop control (WCAG 1.4.2), and screen reader users need it too.

How do people with motor disabilities navigate websites?

People with motor disabilities often don't use a mouse at all. They use a keyboard, a switch, voice control, an eye-gaze system, a head pointer or a trackball, sometimes while managing tremor, pain or fatigue. All of these depend on the site working without precise pointing: every control reachable by keyboard, focus always visible and targets big enough to hit.

WCAG starts with the keyboard: everything must work without a mouse (2.1.1, Level A). What typically gets in the way:

• Invisible focus. Remove the focus outline for looks and a keyboard user loses their place (WCAG 2.4.7).
• Long trips. A switch user steps through controls one at a time. A mega menu with 60 links and no “Skip to main content” link can mean 60 presses before reaching the product.
• Labels that don't match. A voice user says “click Book now”, but the button is called “Submit form” in the code, so nothing happens (WCAG 2.5.3, Label in Name).
• Tiny targets and drag-only sliders. WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels (2.5.8) and asks for a click alternative to dragging (2.5.7). Our WCAG 2.2 guide explains both.

How do people with cognitive disabilities, dyslexia or ADHD use the web?

People with cognitive and learning disabilities, including dyslexia, ADHD, memory loss and brain injury, use a mix of tools and tactics: text-to-speech, spell checkers, reading rulers, password managers, reader mode and extra time. What helps most is on your side of the screen: clear language, predictable layouts and processes that don't punish mistakes.

The W3C's guidance on cognitive and learning disabilities (opens in a new tab) includes the objectives “Help users focus” and “Ensure processes do not rely on memory”.

A login that asks for the third and fifth characters of a memorable word is the kind of memory test the second warns against. A carousel that moves every few seconds works against the first. We look at what helps, including the research on dyslexia fonts, in Designing for dyslexia, ADHD and cognitive disabilities.

What built-in settings do people use, and where does an on-page panel fit?

Most people adjust their own devices long before they touch anything on your page: browser zoom, larger system text, dark mode, reduced motion, high contrast, captions, reader mode and the phone's own screen reader. Your site's job is to respect those settings. An on-page accessibility panel is one more option, not a replacement.

• Zoom and text size: use relative units and never block pinch-to-zoom on mobile.
• Reduced motion: sites can read this preference (the prefers-reduced-motion media query), so honour it for parallax, carousels and big transitions.
• High contrast and forced colours, such as Windows contrast themes: check that icons and focus outlines stay visible.
• Reader mode works best with real headings and paragraphs.

An on-page panel, like the one SiteAccessible adds, gives visitors buttons for contrast, text size, spacing, a reading guide, read aloud and stopping animations without hunting through device settings. That helps some people, such as someone on a work computer they can't configure, or someone with a migraine who wants a calmer page for an hour.

It doesn't help a screen reader user find an unlabelled button, and it doesn't make a site meet WCAG. That's why our panel deliberately has no profile for blind visitors: a visual panel can't stand in for the screen reader someone already knows. If a page fails people's own tools, fix the page.

What breaks the experience most often?

The same basic barriers turn up again and again. In the WebAIM Million 2026 (opens in a new tab) scan, 95.9% of the top one million home pages had detectable WCAG failures, an average of 56.1 errors per page, led by low-contrast text, missing alt text and unlabelled form fields. Screen reader users rank CAPTCHA as the most problematic item on the web.

Scans miss a lot. Screen reader users' own top five problems:

1. CAPTCHA
2. Menus, tabs and dialogs that don't behave as expected
3. Links or buttons that don't make sense
4. Screens or parts of screens that change unexpectedly
5. Lack of keyboard accessibility

None of these needs special technology to fix. To find them, try your own site: book something with the keyboard only, zoom to 400% and read your checkout, then listen to your headings with VoiceOver or NVDA. Our guide to testing your website's accessibility walks through these checks. They won't replace testing with people who use these tools every day, but they show you where to start.