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.
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:
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:
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?
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).
Ask questions about how disabilities might affect behavior, then find relevant data to answer those questions as accurately as possible. For example:
Your persona should also include the user’s age, gender, goals, and challenges. Once again, you’ll need to ask relevant questions:
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.
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:
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.
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.