Accessibility for user experience designers

Reading time: 9 minutes

Getting started

Accessibility is usability for people who interact with products differently. Your role is to help the team approach accessibility as a facet of user experience rather than checklist of requirements.

How to use this guide:

If you have project-specific questions, ask your agency’s accessibility team.

Inclusive design

Adopt an inclusive design mentality

Celebrate accessibility requirements as a set of design constraints that help you create a better product for all users.
Gain a basic understanding of the main categories of disabilities, limitations, or constraints that affect how people use digital services:
- Vision disabilities – such as blindness, low vision, or color blindness
- Hearing disabilities – such as deafness, low hearing, or tinnitus
- Motor problems – such as hand tremors, physical deformities, or amputations
- Cognitive disorders – such as dyslexia, dementia, or being sleep deprived
Understand that almost everyone experiences some type of disability either permanently, temporarily, or situationally. For example: having only one arm is a permanent condition, having an arm in a cast is temporary, and holding a baby in one arm is situational – but in each case you’re restricted to completing tasks with one arm.
Look for ways that making your product easier to use for folks with disabilities also improves the experience for everyone.
Design for progressive enhancement by making sure every person is able to use your product using the most basic technologies, while layering on better experiences for those who can use them.
When conducting user research, make sure the diversity of your participants reflects the diverse abilities, circumstances, and backgrounds of your actual users.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

Assistive technology

Get familiar with the basic ways people use assistive technology (AT).

Some assistive technologies are likely only going to be used by people with specific, long-term disabilities. These include screen readers, switch devices, screen magnifiers, and others. Other kinds of assistive technologies may be more familiar to you and include voice control on your cell phone, ergonomic keyboards, or a browser’s native zoom function. People have different skill levels in how they use these technologies.
To get a baseline knowledge of accessibility, take an “Accessibility 101” class, such as Udacity’s Web Accessibility class.
Learn how to navigate a webpage using only your keyboard and learn how to use a screen reader, such as VoiceOver on your Mac so you can spot check new features when necessary. This can help you understand the technology itself, but keep in mind that folks who use it every day will often have their own strategies for using these tools.
Observe people using assistive technology (AT) on your product or others. In some cases you may be able to find videos demonstrating how people use different strategies to interact with digital products.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

Humanize accessibility

Humanize accessibility for your team:

Cover accessibility and inclusive design issues when conducting user research. Consider the native language, literacy, digital literacy, and digital access of your users as well as potential visual, hearing, motor, and cognitive disabilities.
Incorporate accessibility considerations in your personas, user archetypes, or user stories. This could take the form of swapping out accessibility issues in your personas or creating standalone user stories focused on accessibility.
Help your team learn about the experience of using your product with assistive technology. (Keep in mind that the way a person with a disability uses assistive tools may be very different from your experience of the tools.) This could include:
- Ask each person on your team to turn off their mouse and trackpad and navigate the product using only their keyboard.
- Under your computer’s settings, look for the accessibility settings to change the display (Mac) or color filters (Windows) and switch to grayscale to explore your site without color to simulate color blindness.
- Find an appropriate empathy prompt and walk your team through it.
When possible, include users with disabilities in user research. During usability testing, make sure to allow them to use their own equipment (which has their own settings already in place).

Resources

Personas for Accessible UX

Tab order

Do your wireframes or design mockups indicate a logical tab order for people using a keyboard, or other assistive technology, to navigate?

Why it’s important

Maria has tendonitis and is unable to use a mouse; instead, she uses the keyboard to navigate the web. When focus jumps randomly around the page she gets confused.

Here are some other best practices for tab order.

A user should be able to use the tab key to navigate to every interactive element on a page.
For links, users should be able to activate them with the enter key.
For buttons, users should be able to activate them with either the spacebar or the enter key.
Users should be able to tab through interactive items in a logical order, usually from left to right and top to bottom. Sometimes a logical order will be obvious to your front end team based on a simple layout, but in more complicated layouts you may need to identify the tab order in your wireframes or mockups.
Each interactive element should have a visible focus state, work with your visual designer to make sure you’ve accounted for these.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

Focus

Have you designed for logical focus behavior on interactive elements?

Why it’s important

Jiang is blind and uses a screen reader to navigate the web. When a modal pops up and doesn’t receive focus, he may not even know it’s there.

Steps to take

Work with your front-end designer to identify any interactions on the page that require JavaScript or that can’t be created using default HTML elements. You should intentionally design how focus flows through these interactions.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

Have you included navigation shortcuts for screen reader and keyboard users?

Why it’s important

Rasheed is blind and uses a screen reader to navigate the web; he uses landmark elements to quickly navigate through sections of a webpage.
Li’s vision is fine but has trouble using a mouse, so he navigates the web using only his keyboard – he hates having to tab through all the links in the header navigation to get to the main content of a page.

Steps to take

Work with your front end designer to identify the basic landmark elements in your wireframes, particularly for complex layouts. Landmark elements are identified either through HTML5 semantic markers or through ARIA roles when HTML can’t identify something. You don’t need to be an expert on HTML or ARIA, as long as you know the basics.
- header
- nav
- main
- footer
- search
- form
Include a “Skip to main content” link before the header for keyboard users. Keyboard users can’t take advantage of landmark navigation so a skip link helps them navigate more quickly. This link can be visually hidden but should become visible when it has focus.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

Forms

Can all users understand and fill out forms?

Why it’s important

Esther is beginning to show signs of dementia and has trouble with short term memory loss, she needs context clues and instructions to stay visible on the screen or she loses her place.
Jerome uses a screen magnifier and when validation messages are shown off to the side he can easily miss them.

Steps to take

Make sure all inputs have descriptive labels that remain visible even after a field has been filled in.
Try to use HTML form elements as much as possible, and test any custom interactions for use with screen readers and keyboard only.
Use a straw or make a narrow window with your fist and view the page through that, scanning vertically but not horizontally. This can help you discover if content is hidden from users using screen magnifiers.
Minimize the number of responses overall and that are displayed on a single page, but provide context clues throughout for people who might easily lose their place.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

Images

Have you identified which images are meaningful and which images are decorative in mockups?

Why it’s important

Carmen’s page didn’t load all the way and didn’t get to download the images.
Amanda is blind and uses a braille reader to understand the content of images.
John is looking for information with a search engine and needs help being directed to the right content (descriptive alt tags will improve search).

Steps to take

Images that are purely decorative shouldn’t be announced by the screenreader, work with your front-end developer to make sure they’re coded correctly.
Images that have meaning should include alt text and possibly a longer description, work with the content designer on your team to create these.
Making sure any text in images of text is at least 14 points and has good contrast.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

Touch targets

Are your touch targets large enough and easy to reach?

Why it’s important

Harold has gigantism due to a tumor on his pituitary gland during childhood. He has very large hands which makes small links, or links that are too close together difficult to tap on his phone.
Rosa checks the latest news on her phone during her morning commute on a jostling bus, often while sipping from the coffee cup in her other hand.

Steps to take

Make sure you can reach primary actions easily with either right or left thumbs, even on larger phones. Items on the bottom of the screen tend to be easier to reach.
Make touch targets at least 44 px (pixels) or 10 mm (millimeters). This will allow the target to be tapped by the average adult finger pad, which measures 10 mm. The icons may be smaller and you can work with your developer to extend padding past the icon. Pay particular attention to how line-height affects touch target size.

Resources

Web Content Accessibility Guidelines (WCAG) 2.0 references:

2.5.5 Touch Target (WCAG 2.1)

Mobile Accessibility: How WCAG 2.0 and Other World Wide Web Consortium (W3C) Web Accessibility Initiative (WAI) Guidelines Apply to Mobile:

Disclaimer: All references to specific brands, products, and companies are used only for illustrative purposes and do not imply endorsement by the U.S. federal government or any federal government agency.

Accessibility for teams

Sections