Usability testing with people with disabilities

The importance of observing people in action

One of the most important things you can do when designing or building products is to watch how people actually use them.

In the digital world, this means observing people interact with web content, web apps, native apps and documents.

You should engage with a diverse range of people, including those with disabilities.

From early 2003 onwards, a colleague and I worked with people with a wide range of disabilities.

We went to their houses or offices, asked them questions about their experiences, and observed them in action.

For this presentation, I’m going to share some different stories from over the years.

1. Barry and colour

Background

Barry has protanopia, which means he has trouble identifying red colours.

Problem

Barry did not notice a series of error messages in a complex form because the errors were flagged using colour alone.

Result

Barry was frustrated that the form would not submit and had to “discover” the error messages after hunting around.

Take aways

• Focus should have been sent to the first field in error, or an error message placed above the form.
• Do not use colour alone to signify important information such as error states.

2. Mary and the flyout menu

Background

Mary has low vision and uses ZoomText (screen magnification software).

Because her magnification is set so high, she only sees a portion of the screen at a time.

Problem

When Mary triggered an “Add your bank details” button, a flyout menu slid in from the right side of the screen.

She never saw this because her screen was magnified and she was focused on the left side.

Result

Mary was not able to access her banking details and could not complete the task.

Take aways

• Focus should have been sent to the flyout menu as soon as it was triggered.
• Ensure actions appear in close proximity to their trigger.

3. Mary and the invisible form fields

Problem

Mary had ZoomText set to a yellow-and-black colour scheme, which radically altered colours on screen.

Some softer colours, like form field borders, were not displayed at all.

Result

Mary could not tell that the page contained form fields and could not complete the task.

Take aways

• Colour contrast must be at least 3:1 for important UI components such as form field borders.

4. Mary and right-aligned buttons

Problem

.

Result

Mary was presented with an email containing a long list of upcoming events. She was asked to find and then book a specific event. However, all of the booking buttons were right aligned, so Mary took a long time before she discovered the relevant button.

Take aways

• for English speaking languages, left align important information.

5. Judith and tabbing

Judith has Cerebral Palsy and has no hand movement. She uses a head pointer to interact with the keyboard.

Problem

On a complex site, Judith needed to navigate to some content within the page, but there was no skip link. This meant that she had to TAB hundreds of times to get to the desired content.

Result

Judith had to TAB hundreds of times to get to the desired content.

Take aways:

• Use skip links to allow users to bypass blocks of content that are repeated on multiple Web pages.

6. Judith and the missing focus states

Problem

Judith relies on keyboard navigation, and therefore needs to see which element is currently in focus. Unfortunately, the site was designed without an identifiable focus states for interactive elements.

Result

Judith was not able to identify when focus was on links or buttons and could not use the site.

Take aways:

• Make focus states clearly visible.

7. Judith and issues with a touchscreen device

Problem

Judith was asked to test a new touch screen devices. However, the touch sensitivity was not tested.

Result

Judith was not able to perform any tasks on the device.

Take aways:

• Test early, with the real users to identfy potential issues.

8. Judith and endless scrolling

Problem

Judith was trying to get to the footer of a site, use the TAB key to move through focusable items. But the site had an endless scroll so she could never get to the footer.

Result

Judith was not able to perform the task of getting to the footer.

Take aways:

• Allow mechanism for bypassing complex live components.

6. Screen reader users and data tables

Some years ago, a colleague and I conducted user testing sessions with a range of screen reader users, to observe how they would interact with complex tables.

Take aways:

• People used different methods to navigate pages.
• People may not be able to afford the latest technologies.
• People have a wide range of technical competency.

7. Steve and Dragon

Let’s look at Dragon Naturally Speaking in action.

Recently, I observed Steve performing some user testing tasks on a Government website.

Take aways:

• Steve can do everything that any other user could do, he just may need extra time.

8. Bruce and his refreshable braille device

Let’s look at a Refreshable braille display in action.

Bruce was able to perform some user testing tasks more quickly and efficiently than fully-sighted users.

Take aways:

• While many people with disabilities may need additional time to complete tasks, this is not true for everyone.

9. Damien and face tracking

Let’s look at a Controlling your mac with head movement and facial gestures.

During a user-testing session, Damien expressed frustration at having to type information rather than use a dropdown or have autocomplete available, as typing is much harder for him.

Take aways:

• Be aware that some users cannot easily type.
• Autocomplete, dropdowns and date pickers are good for some users.

10. Jeff and head trauma

Jeff had issues with short-term memory, and emotional regulation. This meant that complex processes were extremely hard, and he would sometimes become frustrated.

Take aways:

• Be aware that some people may have trouble understanding or remembering complex tasks.
• Breaking complex tasks down into simpler tasks, and use clear instructions

Final thoughts

If you are designing or building any digital product, you should test it as early and often as possible.

Preferrably with real users and preferrably in their own environments.

Make sure to include a wide range of diverse audiences - gender, sexuality, identity, ethnicity, socio-economic status etc.

Thier lived experience could provide you with valuable insights.

Questions or discussion?