Need to perform accessibility testing on your mobile and web apps? Or maybe you want to check your website’s accessibility score? Perhaps you’re not even sure how accessibility fits into the quality assurance world and want some more information about it. Whatever it is, you’re in the right place.

One of the essential things in the accessibility world, or a11y world for short, is WCAG – Web Content Accessibility Guidelines. In our guide to building accessible digital products, you can find a detailed breakdown of WCAG levels and principles. You can also find out how the initiative started at Infinum and, hopefully, become inspired to introduce it in your workplace.

In short, WCAG is the gold standard for anyone who needs a list of recommendations to make web content more accessible. It can be a little intimidating when you see it for the first time. It can be downright scary if you are a software tester who needs to go through the guidelines and implement them. No worries, we’re here to help you break down WCAG and figure out where to start.

If your team still hasn’t started with a11y, and you think it’s high time to do so, you can always do a quick review with one of these tools and estimate your app’s state. There are many accessibility testing tools, and they are all quite similar but present the results differently.

Some of the tools that we have tried are:

All of these tools can find accessibility issues or rather, specific errors regarding WCAG compliance. However, they sometimes struggle with finding logical problems or flows. Because of that, accessibility testing tools do not guarantee 100% compliance, and you should still manually check the guidelines in your app.

WCAG outlines guidelines for three levels of accessibility, A, AA, or AAA, across four categories, perceivability, operability, understandability, and robustness. Explore the breakdown of the levels to understand what each of the levels entails.

Here are some things to keep in mind when deciding upon the WCAG level you will be conforming to:

If nothing here applies to you, have a chat with your team, check out the descriptions of the WCAG levels, and then decide.

When testing and reviewing the guidelines, note down all your findings. Agree with your team about how you will report the bugs you find. Will every screen/page have its task? Will every bug go into a separate task? Will you have one document detailing everything? Find out what makes the most sense to your way of working and open the tasks accordingly.

After you decide on a WCAG level, your next step is to go through the guidelines and figure out how to actually perform accessibility testing. There are no shortcuts here. You’ll have to invest time to understand the guidelines (and test them later).

An example from WCAG guidelines:

This one is self-explanatory. The way to test this is to go through the whole app using only a keyboard, ensuring you can navigate through the page using the tab, arrow, enter, and escape keys, checking that it behaves as it should. In our handbook, you can find a detailed explanation of how to do this for mobile apps. 

After you understand how to test everything, write some test cases to help you.

You can go into different levels of detail:

In some cases, it’s clear what the expected result is. But there are some cases when we’re unsure how something should behave. Imagine you have some animated text that changes every few seconds.

For example: “Our company can help you with design.” The word “design” changes to “development,” “planning,” “managing projects,” and so on. Is the screen reader supposed to stop and read everything? Only the first option? Skip the section altogether?

Sometimes we’re unsure of what is expected, which is completely normal. If that happens, talk to the project team, especially the developers. What are our options? What are we able to do in this case? Talk to clients. What would they like to happen? Is there a perfect flow to tackle this? Find out.

During the testing process, you may find yourself in a situation where you’re unsure about who’s responsible for solving a particular issue.

For example, we’re building a website and find that the alternative text is missing. A content manager or copywriter would normally be your go-to person for this, but what if you don’t have anyone in those roles? Whose responsibility is it? This is something you should agree on within your team.

Or what if you encounter a bug? Is it a bug in our app? Or could it be a browser bug? Since I was using a screen reader, it could also be a screen reader bug. Some investigation would be needed, and it would probably require more profound development skills. If you’re not that tech-savvy, always talk to developers. They can help you dig around and find the source of a bug.

If your app or website is done, and the client is responsible for content input, you should talk to them and provide some guidelines on how to go about that. For example, do you have a field for inputting alternative text with every image? Explain to them how it works and why it’s important. Sometimes, even when you feel like you’ve covered everything, it won’t be perfect at first. That’s completely normal and a part of the process. Do your best, but accept that sometimes things will be out of your hands, and that’s ok.

Accessibility is a team effort. Everyone should be on the same page about making an app accessible for us to start testing it and reporting bugs. If we’re not aligned in our expectations, there is no point in reporting issues no one will fix.

The process comes with a steep learning curve, so don’t feel bad if it takes you some time to learn how to perform accessibility testing and how to operate the tools. It’s normal not to have all the answers, but we have to help each other if we want to embrace this initiative.

After all, we all have the same goal – to improve the product and the user experience for all.