Accessibility Personas: How People Use Interfaces

If an issue entry sent you here, you're in the right place. Every issue entry in this knowledge base has an Affects box, which lists the groups of people the issue can block. This page describes each of those groups: who they are, how they use websites and mobile apps, which obstacles they commonly meet, and what helps. No prior experience with accessibility is needed.

Before you start

A persona is a group, not a person

Each persona on this page describes a group of people who share a way of using interfaces. People within a group differ widely in what they can do, which tools they use, and how skilled they are with them. Treat each persona as a starting point for understanding, not as a description of every user.

People and tools

Some personas describe people with a particular disability, like Low Vision or Dyslexia. Others describe a way of operating a device, like Screen Reader or Keyboard. One person often fits several personas. For example, someone who is blind may use a screen reader on their phone, a braille display at their desk, and the keyboard to move through a web page.

Permanent, temporary and situational

Disability isn't only permanent. A broken wrist makes someone a one-handed user for a few weeks. Bright sunlight makes a low-contrast screen hard to read for anyone, and a noisy train makes a video without captions useless. Fixing an issue for one persona usually helps many more people than the persona describes.

Assistive technology reads the code, not the screen

Screen readers, voice input, switch devices, and other assistive technologies don't look at the pixels on the screen. They work with the information your code exposes in the accessibility tree: each element's name, role, and state. That's why an interface can look perfect and still be unusable: an issue that's invisible to a sighted mouse user can completely block someone else.

Vision

People who are blind, have partial sight, or perceive colors differently. Some don't use the screen visually at all, while others use it with adjustments.

Who and how

People who are blind or have very low vision use a screen reader, and so do some people with reading or cognitive disabilities. A screen reader reads the interface aloud, or sends it to a braille display. On a computer, users control it from the keyboard: NVDA, JAWS and Narrator on Windows, and VoiceOver on Mac. On a phone, they use touch gestures with VoiceOver on iOS or TalkBack on Android: swipe to move from one element to the next, and double-tap to activate.

Screen reader users rarely listen to a page from top to bottom. They skim it, jumping by headings, landmarks, links, or form fields, the same way sighted users scan a page with their eyes. For each element, the screen reader announces its name, its role (button, link, checkbox), and its state (checked, expanded, disabled).

Common obstacles

Buttons, links, and icons without an accessible name, announced only as "button" or "image"
Custom controls built from generic elements, with no role or state. A custom checkbox may be announced as plain text, with no way to tell whether it's checked
Images with missing or meaningless text alternatives, like "IMG_2048.jpg"
Missing or misused headings and landmarks, which take away the shortcuts users rely on to skim
A reading order that doesn't match the visual order
Content that changes without any announcement, like an error message or an updated cart total
Dialogs that don't move focus into them, or let focus escape into the page behind

What helps

Use native HTML elements and platform controls, which come with the right role and state built in
Give every interactive element and every meaningful image a clear, concise name
Structure content with headings and landmarks, and keep the code order the same as the visual order
Manage focus when dialogs open and close, and announce important changes
Hear the result for yourself. The practical guides for using screen readers take you through a first test step by step

Braille

Who and how

People who are blind or deafblind can read the interface with a refreshable braille display: a device with a row of small pins that rise and fall to form braille characters. It connects to a computer or phone and shows what the screen reader would otherwise speak, one line at a time, with short abbreviations for roles, like "btn" for button. Most displays also have keys for moving around and typing. For people who are deafblind, braille is often the only way to access digital content.

Because the display shows the same information the screen reader collects, almost every issue that affects screen reader users affects braille users too.

Common obstacles

Everything listed for screen reader users
Long or repetitive names and text alternatives. A typical display shows about 40 characters at a time, so every extra word means more reading and scrolling
Text inside images, which has no characters to display
Information that's only available as sound, like an audio alert or a video without captions or a transcript
Symbols, emoji, and decorative characters that get spelled out cell by cell

What helps

Everything that helps screen reader users
Keep names and text alternatives short and to the point
Use real text instead of images of text
Provide captions and transcripts for audio and video content

Low Vision

Who and how

People with low vision have partial sight that glasses can't fully correct. This can mean blurry vision, loss of central or peripheral vision, sensitivity to glare, or difficulty telling similar shades apart. Many older adults are in this group.

Most people with low vision still use the screen visually, but adjust it to their needs. They zoom the browser to 200% or more, use a screen magnifier that enlarges a small part of the screen (Zoom on Mac and iOS, Magnifier on Windows, Magnification on Android), increase the system font size (Dynamic Type on iOS, Font size on Android), or turn on high-contrast or dark modes. Some combine magnification with a screen reader.

Common obstacles

Low-contrast text, icons, and form field borders
Text that doesn't grow when the user increases the font size, or layouts that overlap, cut off, or break when it does
Content that requires scrolling in two directions when zoomed in, or an app that's locked to one screen orientation
A faint or missing focus indicator. When the screen is magnified, users easily lose track of where they are
Related information placed far apart. When the magnified view shows only the form field, an error message at the top of the page goes unnoticed

What helps

Meet the contrast minimums: 4.5:1 for normal text, and 3:1 for large text, icons, and the borders of controls
Support text resizing, and let layouts reflow instead of scrolling sideways
Show a clear, high-contrast focus indicator
Place labels, hints, and error messages close to the content they belong to

Color Vision Deficiency

Who and how

People with a color vision deficiency, often called color blindness, see some colors differently or can't tell certain colors apart. The most common type makes red and green hard to distinguish. It affects about 1 in 12 men and 1 in 200 women. Most people with a color vision deficiency use the screen as anyone else does, sometimes with color filters turned on in the operating system's display settings. The same problems also affect anyone using grayscale mode, a low-quality screen, or a phone in bright sunlight.

Common obstacles

Information conveyed by color alone: a red border as the only sign of an error, a green or red dot as the only status indicator, or required fields marked only in red
Charts and maps whose legend relies only on color
Links that differ from the surrounding text only by color
Color pairs that look distinct to most people but have too little contrast for others

What helps

Pair color with a second cue: text, an icon, a pattern, or an underline
Check the design in grayscale. If something stops making sense, color is carrying too much meaning
Meet the contrast minimums, which don't depend on how colors are perceived

Hearing

People who can't hear audio content, or can hear only part of it.

Deaf and Hard of Hearing

Who and how

This group includes people who are deaf, with little or no hearing, and people who are hard of hearing. Some use hearing aids or cochlear implants. For many deaf people, a sign language is their first language and written language is a second one. Anyone in a noisy place, or with their phone muted, is in a similar situation for a while.

People in this group rely on captions, transcripts, and visual or vibrating alerts. Phones and computers can generate live captions for any audio, but automatic captions often contain errors, especially for names and technical terms.

Common obstacles

Videos without captions, or with inaccurate auto-generated captions
Audio content, like podcasts, without a transcript
Alerts and notifications conveyed only by sound
Support or verification available only by phone call
Long, complex written text, which is harder for people who read it as a second language

What helps

Provide accurate captions for video and transcripts for audio
Add a visual cue for every sound that carries information
Offer more than one way to get help, like chat or email in addition to phone
Write in plain language

Physical and motor

People who move, reach, or control their hands differently, and the input methods they use instead of a mouse or a touch screen.

Motor and Mobility

Who and how

People with limited reach, strength, dexterity, or muscle control. This includes conditions like paralysis, cerebral palsy, multiple sclerosis, Parkinson's disease, arthritis, and repetitive strain injury, as well as missing limbs. Temporary injuries and everyday situations, like holding a child in one arm or riding a bumpy bus, cause similar difficulties.

Some people in this group use a mouse or touch screen with effort. Many use other input methods, described in the next three personas: a keyboard, switch devices, or voice input. Others use a head pointer, eye tracking, a trackball, or a mouth stick. Operating system settings help too, like Sticky Keys for pressing key combinations one key at a time, or touch accommodations that ignore repeated or accidental taps.

Common obstacles

Small targets placed close together, or controls that overlap, so it's easy to tap the wrong one
Actions that need a precise or complex gesture, like dragging, pinching, or a multi-finger swipe, with no simpler alternative
Content that appears only on hover
Time limits that don't allow for slower input
Controls that work only with a mouse or touch, and not with other input methods

What helps

Make targets large enough and space them apart: at least 24 by 24 CSS pixels on the web, and 44 by 44 points on iOS or 48 by 48 dp on Android, following the platform guidelines
Offer a single tap or click as an alternative to every complex gesture
Avoid time limits, or let users extend them
Make sure everything works with a keyboard and with assistive technologies

Keyboard

Who and how

Anyone who operates the interface with a keyboard instead of a mouse or touch. This includes blind people using a screen reader on a computer, people with motor disabilities who can't use a mouse precisely, and many power users. Switch devices and voice input software often work like a keyboard behind the scenes, so keyboard problems usually affect their users too. On phones and tablets, some people connect an external keyboard, using Full Keyboard Access on iOS or keyboard navigation on Android.

Keyboard users press Tab and Shift+Tab to move focus from one interactive element to the next, Enter or Space to activate, arrow keys to move inside components like menus, tabs, and radio groups, and Escape to close.

Common obstacles

Interactive elements that can't receive focus, like a clickable div that isn't in the tab sequence
A keyboard trap: focus enters a component and can't get out
An invisible focus indicator, so users can't see where they are
A focus order that jumps around the page instead of following the layout
Focus that's lost after a dialog closes, sending the user back to the top of the page
Non-interactive elements in the tab sequence, which add extra stops
Custom components that don't respond to the keys users expect

What helps

Use native interactive elements, like button, links with an href, and form controls, which are focusable and keyboard-operable by default
Keep a clearly visible focus indicator
Make the focus order follow the visual layout
Move focus into dialogs when they open, and back to the trigger when they close
Follow the keyboard conventions in the ARIA Authoring Practices Guide for custom components

Switch Access

Who and how

People with significant motor disabilities, like ALS, high-level spinal cord injury, or severe cerebral palsy, who may be able to make only one or two reliable movements. A switch is a large button pressed with a hand, foot, head, or chin, or activated by a puff of breath or a blink. A phone's camera can also detect a head movement and use it as a switch.

The device highlights items on the screen one at a time, or in groups, which is called scanning. The user presses the switch when the item they want is highlighted. With two switches, one moves the highlight and the other selects. Switch support is built into iOS and macOS as Switch Control, and into Android as Switch Access.

Common obstacles

Every extra stop costs time and physical effort, so long sequences of focusable elements and redundant focusable wrappers are tiring
Elements that aren't exposed as interactive, which the scanning skips completely
Focus traps, which can leave the user stuck with no way out
Time limits, and content that moves or advances on its own, like a carousel that changes slides while the user is scanning
Gestures with no single-action alternative

What helps

Everything that helps keyboard users
Keep the focus sequence lean: only interactive elements, with related content grouped together
Give controls the correct role, so switch software recognizes them as actionable
Avoid time limits, and let users pause moving content

Voice Input

Who and how

People who can't use their hands easily, like people with repetitive strain injury, paralysis, or arthritis, control their devices by speaking. Some people with dyslexia also prefer speaking to typing. Speech recognition software is built into most devices: Voice Control on iOS and Mac, Voice Access on Android and Windows, and the Dragon software on Windows.

Users speak commands like "Tap Send" or "Click Search," using the name they see on the screen. When a control has no usable name, they can ask for numbers or a grid to appear over the screen, and say a number to pick the target. This works, but it's much slower. Text is entered by dictation.

Common obstacles

A visible label that doesn't match the accessible name. A button shows "Send" but its code name is "submit-btn-2," so "Tap Send" does nothing
Icon buttons with no name, which can only be reached by the number overlay
Several controls with the same name, like three "Edit" buttons, which make the software ask the user to choose
Controls that aren't exposed as interactive, or custom controls that respond only to mouse or touch events

What helps

Make the accessible name start with, or at least contain, the visible label
Give icon buttons a name that matches their tooltip or the word people would naturally say
Make names unique, or add context, like "Edit address" and "Edit payment"
Use native controls, which voice input software recognizes automatically

Cognitive and learning

People who process, remember, or focus on information differently. This is one of the largest disability groups, and one of the least visible. There's no single assistive technology for it: people in this group depend mostly on clear, predictable design.

Cognitive

Who and how

People with intellectual disabilities, memory impairments, brain injury, dementia, or autism, among others. Stress, fatigue, illness, medication, and reading in a second language affect anyone's thinking in similar ways.

People in this group use the same devices as everyone else. Some use text-to-speech tools that read content aloud, reader modes that simplify the layout, or browser extensions that remove distractions. Many need more time, and depend on familiar patterns, consistent navigation, and recognizable icons.

Common obstacles

Complex language, jargon, and long sentences
Navigation and layouts that change from page to page
Vague labels and instructions, like "Click here," or icons without text
Error messages that say something went wrong but not how to fix it
Unexpected changes, like a new window opening or content changing when a field gets focus
Long processes with no indication of progress, or ones that require remembering information from earlier steps
Time limits

What helps

Write in plain language, and explain terms that can't be avoided
Keep navigation, layout, and naming consistent across the site or app
Use descriptive labels, headings, and page titles
Write error messages that explain what happened and how to fix it
Avoid unexpected changes, and let users review and undo their actions
Avoid time limits, or let users extend them

Attention and Focus

Who and how

People with ADHD, and others who find it hard to keep their attention on a task or are easily distracted, including from anxiety, fatigue, or brain injury. Some reduce distractions with reader modes, ad blockers, focus modes, or reduced motion settings.

Common obstacles

Video or audio that starts playing on its own
Animations, auto-advancing carousels, and blinking or scrolling text
Pop-ups and overlays that interrupt a task
Cluttered pages, and long blocks of text with no structure
Forms that lose the user's input after an interruption or a time-out

What helps

Never autoplay media, and let users pause, stop, or hide anything that moves
Break content into short sections under clear headings
Keep pages focused on one main task
Save the user's progress, and avoid time limits

Dyslexia

Who and how

Dyslexia is one of the most common learning disabilities. It affects reading, spelling, and processing written words, but not intelligence. People with dyslexia often use text-to-speech to listen to content, customize fonts, spacing, and colors with reader modes or browser extensions, rely on spell checkers, or use voice input instead of typing.

Common obstacles

Dense text: long lines, justified alignment, small or tightly spaced letters
Text spacing that's locked in the code, so the user's own spacing settings have no effect
Text inside images, which can't be read aloud by text-to-speech tools or restyled
Inputs that require exact spelling, like a search with no suggestions or tolerance for typos
Long, complex words and sentences

What helps

Use left-aligned text, short paragraphs, and clear headings
Let users adjust text spacing without content getting cut off or overlapping
Use real text instead of images of text
Accept spelling variations, and offer suggestions in search and inputs
Write in plain language

Flashing and motion

People who can have a physical reaction to flashing or moving content.

Seizures and Physical Reactions

Who and how

People with photosensitive epilepsy, for whom flashing content can trigger a seizure. Also people with vestibular disorders (problems with the balance system of the inner ear), migraines, or motion sensitivity, for whom animation like parallax scrolling, zooming, and large movements on screen can cause dizziness, nausea, or headaches that last for hours.

Many people in this group turn on the reduced motion setting in their operating system: Reduce Motion on iOS and Mac, Remove animations on Android, and Animation effects on Windows. Websites can detect this setting with the prefers-reduced-motion media query, and apps can read it from the platform's accessibility settings.

Common obstacles

Content that flashes more than three times per second, especially large areas of saturated red
Parallax effects, animated page transitions, and content that zooms or moves as the user scrolls
Videos with strobe effects that start playing on their own
Interfaces that ignore the user's reduced motion setting

What helps

Never make content flash more than three times per second
Respect the reduced motion setting, and replace large movements with simple fades or no animation
Let users pause or stop any animation
Warn users before content that contains flashing or intense motion

One fix, many people

Most accessibility fixes help several personas at once. A clear accessible name on a button helps screen reader and braille users understand it, lets voice input users say it, lets switch users recognize it, and helps people with cognitive disabilities know what it does. This is why the Affects box on most issue entries lists more than one persona, and why fixing even a single issue can make a real difference to many people.