Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Accessibility Testing: Convincing Your Product Owner

Accessibility Testing: Convincing Your Product Owner

Leia em Português

Accessibility testing is just the right thing to do; the internet and e-services are a place for people to feel and interact equally, so our software should not exclude people, argued Martin Tiitmaa at TestCon Europe 2019.

In the context of software, accessibility testing is a process for evaluating the usability of software by people who are facing some type of restriction. These restrictions can either be permanent, like a disability, temporary like a broken finger, or situational, like using said software while holding a child, said Tiitmaa.

Tiitmaa mentioned that their assignment to do accessibility testing came from their product owner. As that’s not always the case, he provided three arguments that can be used to convince product owners about accessibility testing:

Firstly, it’s just the right thing to do. And that, I think, in any company’s policy should be the only argument needed. Internet and e-services are a great place for people to feel and interact equally and when designing and developing our software, we should keep that in mind and not design our things to exclude someone, and that should be part of every development company policy.

But if it isn’t, and making these changes will indeed take time away from other developments, and a company is afraid it will cost a lot of money, then my research shows that money-wise these changes are not expensive to make, and there are great resources already there teaching you how to make the changes to make your code more inclusive. So secondly, it will help you earn more money.

And thirdly, if you don’t do it today, you will have to become accessible in the very near future. In the U.S. it is also seen that the Americans With Disabilities Act also covers the Internet, and the U.S Supreme court just agreed with that. Based on the court cases that have come from this, it has been demanding companies to become compliant with the WCAG 2.1 AA standard.

In Europe, the European Commission has legislation ready to be introduced in 2021, or maybe even 2020 already, said Tiitmaa. So depending on where you operate, it either is or will be demanded very soon, he said.

Tiitmaa explained that in 2016 in the U.S., in the age group of 21-64, 10.9% of people were reported to be affected by some kind of disability. "That’s 10% of customers you have lost, when you are not accessible," he argued. "To be inclusive before your competitors will be great for your reputation, bringing even more customers."

We can combine modern testing and accessibility testing. Tiitmaa mentioned modern testing principle number one:

Our (testers’) priority is to improve for the business

By constantly improving on accessibility, we create a better product for everyone, said Tiitmaa. Using quick and clear keyboard shortcuts makes it faster for everyone, and by default it also helps with SEO (e.g. "title" and "alt" attributes on websites).

Tiitmaa stated that modern testing dictates that only the customer can judge the quality, and we can test whether we have provided it through data. He mentioned that they are planning to use more data to make their decisions, and part of that data would indicate whether their user, for example, used a screen reader. "This will help us to improve even further on our accessibility solutions and provide a better service to everyone," Tiitmaa said.

InfoQ interviewed Martin Tiitmaa after his talk at TestCon Europe 2019 about accessibility testing.

InfoQ: What approach did you take in your accessibility testing?

Martin Tiitmaa: I used the same approach as I do in most of my testing, and did the work in three phases – 1) Research, 2) Testing and 3) Results phase. In this case, what was special for me was that the research phase took most of the time.

The first problem was what to use as an oracle. In my research I found that the WCA (Web Content Accessibility) Guidelines 2.1 are something that are both recognized by the industry, and also for example by lawmakers. For example, in the U.S. there were court decisions mandating for a webpage to comply with WCAG 2.1 AA standard. As there are nearly 100 different guidelines to follow, I narrowed it down to the four main principles that the guidelines include: Perceivability, Operability, Understandability, and Robustness.

As a next step I looked into what kind of accessibility restrictions there are and what kind of tools help to conquer them. The main tools that are used are screen readers, operating software with keyboard only, and high contrast view. For my testing, I used the three most popular screen readers at the time, ran a test cycle using keyboard only, and did one test cycle with a high contrast view.

To cover most of our product, I chose to go through our user’s main path of operations, or a user lifecycle. The flows that I covered in my testing were creating an account, making a deposit, withdrawing money from the account and using promotional tools. Based on the test results I created a gap analysis compared to WCAG standards.

InfoQ: How did you follow up on this gap analysis?

Tiitmaa: The gap analysis had three categories. Firstly things that were ok, secondly things where small changes were needed, or where we did meet the A standard but should move to AA, and thirdly things where more work was needed to fix them. I color-coded these categories with green, yellow and red colors, so when planning the upcoming sprints we had an overview of how much one or various fixes would take.

InfoQ: What have you done to support developers in creating products that are accessible?

Tiitmaa: I gave a presentation to the whole development team, talking about what accessibility is, what I found in my research, what WCAG is and what it expects from us. As there are nearly 100 different guidelines, I summarized the main points for them. So while we were fixing the issues we had, we would not create any more inaccessible additions to our software.

For example:

1) Always add an element describing the feature you are adding.

2) Check if your added element is usable by keyboard only.

3) Add new elements into a logical path compared to other software elements.

4) Texts and images need to be readable with contrast ratio 3:1


InfoQ: If readers want to learn more about accessibility testing, where can they go?

Tiitmaa: I have mentioned the WCAG several times. It is a lot to take in at first, but they have descriptions of what is a good solution and a bad solution, and even some suggestions on how to fix it.

Microsoft inclusive design is a great resource to better understand how to make more accessible software.

Web accessibility in mind is a great place to get answers to any questions you might have about accessible software. They also have a survey every year which shows you the most popular screen readers being used.

Rate this Article