Usability testing asks real users to interact with a digital product to see what works and what doesn't. It provides valuable insights for fine tuning the user experience. If you want to build an inclusive digital experience (and you should!) then at least some of your testers should have disabilities.

You might be thinking: “can’t I just run accessibility tests myself?” It’s certainly a good idea to do that and fix as many issues as possible before putting your site in front of real users. But ticking off WCAG criteria isn’t enough. Accessibility is a complex, human-centered issue that can’t be boiled down to a simple checklist. Some challenges can only be identified by real users with disabilities.

Our team recently asked users with disabilities to test a website that we’re building for the Canada Lands Company, a federal Crown corporation specializing in real estate and development. The site will communicate important information about a project in the Downsview West District of Toronto. It’s essential for the site to meet high accessibility standards, as it needs to cater to a diverse audience and gain approval from the Government of Ontario.

Our work with the participants was eye-opening! We uncovered valuable opportunities to enhance the site, and I came away with a changed mindset towards accessibility. Curious to see what we learned? Read on to discover our best insights and tips.

An estimated 27% of Canadians aged 15+ have disabilities that impact their everyday life.


Recruiting Usability Testers With Disabilities

There are several ways to find participants, including:

  • Putting out a call to your existing users, if you have their permission to do so\Recruiting from your own team, if they represent your audience
  • Working with a professional body, charity, or community group
  • Using an agency that recruits usability testers

We partnered with Access Works to find testers for the new Downsview West website. They leveraged their network of testers with disabilities to help us recruit three participants: 

  • A user with low vision who uses a screen magnifier and contrast tools
  • A Blind user who uses a screen reader
  • A user with a motor disability who uses a keyboard (no mouse)

“Testing accessibility with real users is particularly important if you’re building something complex or custom.” 


Running a Successful Testing Session

We wrote a detailed script including questions and tasks. Here are some things that made our script successful:

  • Tasks around specific elements. For example: “there’s a subscription form at the bottom of the page. Can you use it to subscribe to the newsletter?” This helped us test things that we know are more likely to have accessibility issues.
  • Tasks with scenarios. For example: “imagine you need to search for information specifically about schools. You wonder if there’s a search bar somewhere on the page. Can you find it?” This gave us a clearer idea of how users would interact with the site in the real world.  
  • Subtasks. For example, after asking participants to use the search bar, we asked them if they could explore the search results. Breaking tasks into subtasks helped us explore user flows in greater detail. 
  • Flexibility. We allowed the participants to go off script at times, and our final task asked them to explore the site freely for 10 minutes. Letting them use the site naturally helped them uncover issues we didn’t think of.
  • Open-ended questions. We encouraged participants to describe everything they saw/heard, thought, and felt. Sometimes they needed prompting with questions. This allowed us to get to the root of issues and imagine effective solutions.

“Users with disabilities will definitely uncover things that your team can’t. They bring a unique perspective.” 
– Nour Bou Khalil, Project Manager, Evolving Web


What We Learned From Our Participants


The participants did a great job uncovering specific issues on the website, which we can now address. They also enhanced my understanding of accessibility in the real world. Here are some of the most important things I learned: 


Our in-house practices are working

I was pleased to discover that the site was already pretty accessible! This was valuable feedback because it confirmed that our practices are on the right track. What’s more, we made accurate predictions about some remaining issues, including the language feature and sticky header. 


But teams & tools can’t find every issue 

Although our team did a good job, the participants still found problems that we didn’t. Users with disabilities offer unique perspectives based on their complex needs and lived experience, which can’t be replicated. For example, even though I’m familiar with screen reader commands, I don’t use a screen reader in the same way as someone who relies on it everyday. 


Assistive technologies are used in various ways

It was enlightening to watch the real-world use of assistive equipment. The Blind participant used a screen reader with an incredible level of proficiency. Meanwhile, the participant with low vision used their tools more inconsistently. The participants’ experiences were therefore different to what our team could have simulated.


User experiences are as varied as disabilities

A page element that’s accessible for one user may present issues for another. This was the case for the carousel on the Downsview West site: the participant using a screen reader had a smooth experience, while the participant using a screen magnifier ran into difficulties. They got lost on the page while zoomed in due to there being too much white space. They also had issues accessing some interactive content, which would appear after they’d moved their zoomed view elsewhere. 


Accessibility is about removing barriers

As I watched the participants navigate the site, I saw that they enjoyed a smooth experience until something suddenly got in the way. It made me reframe my approach to accessibility. I now see that our job is not to add accessible features but to remove barriers that are in the way. 


Better accessibility is good for everyone 

Our participants highlighted a few issues that would have affected any user, no matter their ability. For example, one participant noticed that the “next” button on the carousel didn’t indicate when the carousel had reached its end. This goes to show that accessibility testing can benefit all users.

It was a privilege to work with the participants and learn from their diverse perspectives. We’re currently finetuning the DownsView West website to ensure a truly inclusive user experience before its launch. 


Additional Resources

Here are some more great topics to enhance your knowledge of accessibility:

Need training for your team? Check out our Drupal Web Accessibility course.

Looking for help with accessibility testing or inclusive design? Talk to our experts.