Usability testing with people with disabilities

Acknowledgement of country

I'd like to acknowledge the Traditional Owners of the lands on which I am presenting today.

In my case, this is the Cammeraygal people of the Guringai tribe of the Eora nation.

I'd like to pay my respects to Elders past and present, and extend that respect to all First Nations people present today.

Some introductions

My name is Russ Weakley:

• 1995 - 2003: Web designer
• 2003 - 2020: Front end to Design systems
• 2020 - 2025: Accessibility specialist
• Passionate about accessibility since 2003

Some family:

• A father who is profoundly deaf.
• A brother who is legally blind.
• A son on the ADHD/Autism spectrum.
• I have Dyslexia/Dyscalculia.

Some initial thoughts

The importance of observing people in action

One of the most important things you can do if designing or building a product is to spend time observing people.

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

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

But what does this engagement actually mean?

Discussions and interviews

• Talk to diverse groups of people.
• Find out how they interact with the digital world.
• Find out their needs and frustrations.

User testing

• Observe them in their own enviroments, using their own setups.
• Observe them doing "real world" tasks.

It is perfectly acceptable to combine different methods into one session, but user-testing should be formalised to allow for non-skewed results.

No matter what processes you use, you will realise:

1. Everyone is unique.
2. Everyone approaches tasks in their own way.
3. It is dangerous to assume a group of people will all act in the same way.

I was luck enough to work with a mentor who totally believed in this approach.

So, from early 2003 onwards, we met with may people with a wide range of disabilities.

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

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

Side note: In most of these stories, I’m using fake names so as to protect the innocent!

1. Barry and colour

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 some hunting around.

Take aways

• Focus management is critical for all users.
• Do not use colour alone to signify anything critical - links, error states etc

2. Mary and the flyout menu

Let’s look at ZoomText (Screen magnifier software) in action.

Problem

Mary did not notice a flayout menu that would slide in from the right side of the screen because her screen magnitication did not show this portion of the screen.

Result

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

Take aways

• As before, focus management is critical for all users.
• Be aware that proximity is important and users may only see a portion of the screen.

3. Mary and the invisible form fields

Problem

Mary had her ZoomText on a yellow and black colour setting - which radically altered the colours on screen. Some softer colours, like form field borders, were not displayed at all.

Result

Mary was not able to determine that the page contained form fields and could not complete the task.

Take aways

• Colour contrast also also critical for UI components, like inputs!

4. Judith and tabbing

Let’s look at a Head wand in action.

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.

5. 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.

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?