Transcripted Summary
In this chapter, I’ll talk about:
- Why accessibility testing is important
- How automated accessibility tests can help us
- The importance of doing accessibility testing with actual users
In the previous chapter, we discussed what accessibility is, particularly Web Accessibility and a brief overview of the Web Content Accessibility Guidelines.
It’s a good start to know about the different accessibility rules and now we’ll look at why accessibility testing is important.
# Why accessibility testing is important
First of all, doing accessibility testing is just the right thing to do.
We need to be empathetic to our users with disabilities and put ourselves in their shoes.
As more and more information can now be accessed online, we need to start thinking about how all of our users will use our products.
It’s important to include everyone and this not only benefits individuals, but the society as a whole.
Better accessibility means better user experience.
For example, if you are testing a website that has great design, animations and all these exciting features but poor accessibility, this leads to bad user experience.
So your job as a tester is to help your team find different accessibility issues so you can help deliver a high quality product.
Oftentimes, accessibility testing is often seen as an afterthought, only after a product has been deployed to production.
Something that works functionally does not necessarily mean accessible so we need to make sure that we also consider user experience.
Better accessibility also means that you widen your reach to other audiences.
I remember when Microsoft released Edge years back and made it their default browser on Windows 10.
I was reading articles that the old Edge browser was not compatible with assistive technology devices, meaning that blind people at the time, could not access Edge browser during its initial release because it was not compatible.
Fast forward to now - both NV Access, a not-for-profit organisation who is responsible for bringing the NVDA screen reader software, and also Microsoft have been working closely together to make sure that the new Edge browser is accessible so they can also reach blind users.
If you want to know more about this story, I’ve added a link below to an article from NV Access, which you can find on the resources section that you might find relevant.
In the previous chapter, you learned about the Dominos Accessibility case.
The law on accessibility differs from one country to another, so it’s best to check the regulations in your country first.
It’s best to avoid lawsuits in the first place, as this will cause headaches and money wasted to whoever is being sued.
# How can automated accessibility tests help us?
With the amount of different accessibility checks that we need to do, it makes sense to automate some of the checks and get it added as part of our automated regression suite.
By automating some of the accessibility tests, we can catch basic accessibility issues earlier on and allows us to collaborate more with our design and development team.
This can also serve as a living documentation to your team.
For example, if your team is actively trying to reduce the number of accessibility issues your website has, having a dashboard which displays a report of the test run will serve as documentation and will make everyone aware of what issues are still outstanding.
The next benefit is I think one of the most important and that is it will prevent any regression issues related to accessibility from being deployed to production.
By having the automated tests in place, you have this safety net that issues your team have fixed in the past will not be deployed to production again since it’s now covered by an automated test.
It also frees up your time to do more complex testing activities, such as testing with screen readers or using the keyboard only to navigate a site.
Although automated accessibility tests will only catch a subset of the accessibility issues out there, it’s still beneficial to have them because it will help us speed up our testing process and they are cheap to run.
Lastly, having automated accessibility tests provides a fast feedback loop to your design and development team, especially if the tests are running as part of your continuous integration pipeline.
Your development team will know in an instant if the feature that they are working on has broken any accessibility rules.
Likewise, if there are any color contrast errors that got detected, the design team can be informed if they need to amend any of the color tokens they’ve chosen.
It’s not a silver bullet, of course, so you shouldn’t use all your accessibility testing efforts on just automated accessibility tests.
There is no automated accessibility tool out there that can catch all accessibility issues and just because your tool did not report an accessibility issue on a particular rule, doesn’t mean that it’s accessible.
I added a link to a blog post from the UK Government where they used different accessibility testing tools to test the least accessible web page, which they have created as part of this experiment.
You can find it under the resources section down below and I highly recommend that you give this a read if you haven’t done it yet.
Here, they use 10 different tools to help them detect accessibility issues, and only an average of 40% of the issues were caught by these tools.
This just proves that human intervention is still very much needed when it comes to accessibility testing.
# The importance of doing accessibility testing with actual users
With that said, nothing beats actual accessibility testing with real users.
You can have all the automated tests you need and even do some of the testing yourself, but there’s still a lot of benefit to gain if you invite real users with disabilities to test your website.
The reason being is that they probably use different third party assistive technologies and this way, you have that first hand understanding on how they use your product on a day-to-day basis.
Get them involved when your team is designing and developing a new feature.
They can provide valuable inputs on how to make your feature accessible.
With that said, if you are going to get user involvement, make sure that you involve different people with disabilities to get better results.
One person can use different assistive technology than others, so it’s best to not rely on one person’s input.
Doing accessibility testing with real users as well as doing an evaluation checklist, which can be achieved with having automated accessibility tests and checking it yourself is the best approach to make sure that your website or application is accessible to users with different disabilities.
The good thing is W3C has provided an evaluation report generator that you can use for your evaluation, which I’ve linked down below in the resources section.
Diving into accessibility testing can be challenging.
Even with myself, I’m still learning a lot about accessibility on a day-to-day basis and I hope that by taking this course, this serves as a starting point to your accessibility learning.
In the next chapter, we’ll look at some of the accessibility testing checks that you can introduce as part of your testing process.
