7 Simple Ways You Can Improve Your Accessibility Testing

CODEX

One of the benefits of my role within organizations is the ability to observe teams (and their operations) from both a “boots on the ground” and 50,000 foot view. I empathize with the challenges individual QA teams have when they hear “check accessibility” and are simply pointed to the WCAG. That statement is usually followed by something like “go figure it out” and endless browsing of various tools, assistive technologies, bookmarklets or plugins and downloading every one you can find.

Unfortunately, each tool or auditing plugin comes with an opinionated ruleset which was interpreted from the WCAG or the HTML specification. Sometimes these even conflict. What a pain!

I’d like to share 6 practical tips that any QA team can implement immediately to simplify their testing process for accessibility.

TL;DR list first, explanation after.

NVDA, JAWS, Colour Contrast Analyzer, Orca, Wave, Axe, Voiceover, Talkback, DAP, Equal Web, Nu Validator, SiteImprove, Lighthouse. These are just some of the many tools that you can use to QA the web. Let me tell you that you don’t need them all. As previously mentioned, some of these tools sound different (in the case of screen readers), have vastly different rulesets (auditing tools), or need a bit of knowledge on how to use effectively.

Did you know that most accessibility defects are just simple HTML issues that can be detected by most of these tools? That’s why when I talk to teams I really reduce their scope of work and reassure them that they can always add more later.

The shortlist:

That’s it!

“But Cam! We’re going to miss a bunch of accessibility defects! What about Orca and Opera browser? We need a matrix!”

Yes, you do. But not before you can tell me that the above is fixed. Why should a QA test two (or three, or four) screen reader and browser combinations when they’ve already found issues on one device? It will most certainly be there on the other devices as well.

I love seeing a ticket that goes something like this:

“Input sounds different in Safari-iOS than Chrome with Voiceover. Please advise”

Does it sound different? Then there might be a problem. Do they sound the same? Then maybe that’s just how that screen reader sounds.

If there’s anything you can remember from this article, it’s this point. Don’t ever start your testing with a screen reader. Start with an auditing tool (like Wave, axe, DAP, etc). Those will find all of your basic, HTML issues first. Raise all those issues in your ticketing system initially because that will find a good 80% of the basic coding issues.

The actual strategy to good accessibility testing is:

I hear so many QA teammates (and developers before they take my training) who get so bogged down listening to how a screen reader sounds that they’re bound to make mistakes.

I’m big on automation, but we all know that accessibility can’t be fully automated, so this is as good as we’re going to get. Raise these tickets individually in your defect tracking system to help find out where the devs are having issues.

After all that’s done, you then move on to screen reader testing. Why now? Well what if the submit button on screen wasn’t usable with a keyboard? You’re darned sure that it won’t work with a screen reader either (or, if it does, that feature won’t pass a test case anyways).

This is to save you time. If you need to check an entire page starting with a screen reader, you’re in for a lot of testing…

This only recently made it to my training because of some fantastic updates that came to browsers dev tools in recent times. Shoutout to Firefox for allowing you to check accessibility with two clicks as well.

All the information you need to know about labels in generally right here. You don’t even need to use a tool. This is especially important for multilingual sites where you may not understand the other language on the site. The example in the previous graphic shows the content of the link, as well as any other properties which may be on that element, such as an aria-label or aria-describedby (leave a comment at the end if you’d like me to write more about those).

This is one of the big differentiators when it comes to ALL the clients I’ve worked with. When there is one person who holds the accessibility knowledge, it really helps the team as a whole.

This one person gets all the accessibility tickets and develops a mastery around the speciality as a whole, your team will have a reference point and a growing knowledge base.

I try to look for people who are curious about this subject and empathetic towards the persons with disabilities as a whole.

Where to now?

You’ve tested, checked and double checked. Something still doesn’t feel right. It sounds funny, it doesn’t act the way you want it to, things are weird.

Well, you can always ask your questions over at our Discord server where we’re building a community of accessibility experts and healthy (and friendly) discussions on how to test, develop and create accessible items for the digital world.

What are your biggest challenges in the world of testing accessibility?

Do you have any other techniques that have worked well for you or your team?

Leave a comment! I’d love to read it.

Related posts:

This is a journey about one of my project in my internship period which is a creating Android quiz game App using Ionic framework. I wanted to share my story of working on this app so it would help…

We can meet up with our friends without missing the time or the place by using email on our smartphone. We think that is very natural for our lives but if you are over forty, you might remember at…

Newly elected Representative Jamaal Bowman (D-NY) was in the Capitol building on January 6. He was not on the House floor that day, however, for he had been warned to remain in his office as…