User experience (UX) user personas are a helpful tool for understanding your target audience. Essentially, the user persona is a written representation of a single user that represents a much wider group of users with similar goals and characteristics.
Creating personas can help your team avoid one of the most common mistakes of product development: the assumption that everyone will use the website or app in the same way. This assumption can lead designers to design content for themselves — which inevitably leads to problems after the product launches.
Personas allow your product and user experience teams to gain important insights about users' habits, needs, and frustrations. If you’re using a persona-driven approach, you’ll need to add a few accessibility personas in order to get the best possible results. After all, about 1 in 4 U.S. adults have disabilities — if you’re not thinking about these users when developing content, you’re missing a major opportunity to optimize your product.
Below, we’ll outline some steps for creating personas with disabilities. For more guidance, read about the overlapping principles of inclusive design and accessible design.
Creating Useful Accessibility Personas
No user persona can represent the access needs of all people with disabilities. However, creating several personas with different skills and abilities can help you make decisions when adding or refining features.
Your goal is to enhance your products during the design and development stages by considering practical use cases. No product is 100% accessible for everyone, but by considering a few personas with disabilities, you can take an important step towards developing an accessible mindset.
A few tips for creating personas that will be useful for evaluating user experiences:
Consider the spectrum of disabilities.
Writing personas for every single type of disability is impractical (if not impossible). Instead, focus on users whose conditions will affect how they interact with your product. For instance:
- A user with significant visual impairments who uses a screen reader
- A user with low vision who doesn’t use a screen reader, but may have trouble perceiving certain visual-first content
- A Deaf user who cannot perceive audio content without text alternatives
- A user with mobility impairments who is unable to use a mouse.
It’s a good idea to build several user personas with disabilities. Don’t hyperfocus on a single group—remember, disabilities affect people in profoundly different ways, and a single persona won’t sufficiently represent all of your real-world users.
Related: Is Web Accessibility Only for People Who Are Blind?
Define the disability.
Every member of your team will need to think about how disabilities affect the user experience. That’s difficult when the disability is poorly defined.
Use data from reliable resources to describe each persona’s conditions; where possible, identify the prevalence of the condition among your target audience (for example, about 12 million Americans aged 40 years or older have vision impairment).
Explain how the disability affects the user.
Ask questions about how disabilities might affect behavior, then find relevant data to answer those questions as accurately as possible. For example:
- Does the user have an iPhone, an Android phone, or do they avoid mobile devices?
- Do they prefer using a laptop or a desktop?
- Do they use Google Chrome, Firefox, or another web browser?
- Do they use assistive technologies such as screen readers, and if so, what software might they use?
- Do they change their browser settings to magnify web pages or increase font sizes?
Define the user’s demographics.
Your persona should also include the user’s age, gender, goals, and challenges. Once again, you’ll need to ask relevant questions:
- What types of tasks are most challenging for the user?
- What is the user’s level of proficiency with assistive technologies, web browsers, and computers in general?
- Is the user employed, and if so, do they use different technologies at work?
- What is the user’s specific goal when accessing your product?
The United Kingdom Government Digital Service’s Accessibility team offers 7 pre-built accessibility personas with different abilities, along with documentation for setting up devices and browsers for each persona. These personas are an excellent starting point, particularly for teams who have limited experience with digital accessibility.
Use data to create accessibility personas (and avoid assumptions)
Let’s say you have a user persona who is visually impaired. They use a screen reader to access your website — but which screen reader do they use? Are they proficient with their screen reader? Do they switch from the screen reader to a screen magnifier when accessing certain types of content?
Your objective is to create a persona that encompasses a wide range of users. To that end, you’ll need accurate data, which you can often find with some quick research.
For example, WebAIM (Web Accessibility In Mind) publishes an annual screen reader user survey. The 2021 WebAIM survey has useful information that could address some of these questions:
- 79.5% of screen reader users were blind, while 21.9% had low vision or visual impairments.
- Only 57.5% of respondents described their screen reader proficiency as “advanced.”
- About 83% of respondents used either JAWS or NVDA as their primary screen reader.
- 38.3% of respondents were 21-40 years old
These statistics are limited — they’re confined to a single survey of a relatively small number of people. Even so, actual data provides much more useful insights than assumptions. By using WebAIM’s data, we can create a more accurate persona of a screen reader user, which might read:
Martha is 35 years old. She is blind and has intermediate proficiency with the JAWS screen reader. She considers herself proficient with the internet and is employed part time. She uses Google Chrome as her primary web browser, and she usually has JavaScript enabled.
Martha uses a laptop computer at work and at home; she also has an Apple iPhone, and she uses Apple VoiceOver when browsing the web on her mobile device.
Ultimately, your user personas should be based on research. Instead of saying, “our user persona probably uses Apple VoiceOver,” or “our user persona has hearing disabilities, so they don’t prioritize video content,” look for actual data from disability resources.
Be prepared to change your assumptions based on your findings. Otherwise, you’re guessing about the habits of your users — which is exactly what user personas are intended to prevent.
Remember, user personas aren’t a substitute for accessibility testing
Using accessibility personas can be extraordinarily helpful. However, by definition, user personas are fictional. They can’t provide feedback for remediation, and you certainly can’t demonstrate conformance with the Web Content Accessibility Guidelines (WCAG) Level AA by citing the experiences of users who don’t actually exist.
Make sure your strategy includes regular accessibility testing, preferably with the involvement of real users with disabilities. Set clear goals for WCAG conformance early in the development process. Keep testing throughout development and after your product launches.
The Bureau of Internet Accessibility offers resources for building (and maintaining) an accessible approach. Learn more by talking with us or by downloading our Ultimate Guide to Web Accessibility.
