WTA-62 – Accessibility Development Tools

WTA-62 – Accessibility Development Tools

WTA-62: Accessibility Development Tools

Date: Saturday, June 13, 2015

Time: 10:00 a.m. to 12:00 p.m. PDT

Facilitator: Michael Larsen

Attendees: Michael Bolton, Sushma Kumar, Michael Larsen, Sorina Mateoc, nidhi1102, Goma Rai,  Raman Saxena

Mission: Continuing on from last months’ session on Screen Readers, this month I want to continue in that vein by showcasing and discussing a variety of tools that help with accessibility testing. There are a number of free tools available in the market that allow software testers to evaluate the accessibility of their sites. We will use this time to examine Chrome’s “Accessibility Development Tools”. Chrome will be a requirement. The extension can be downloaded from https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en

Experience Report:

We spend most of the time using the tool and getting familiar with it, and we made a goal to test the Weekend Testing site itself for Accessibility. As might come as no surprise, some areas were good and others certainly need improvement. On the whole, the bigger challenge was determining what these tools were actually telling us. Like all software tools, they are best suited for performing checks and validations. They are aids to testing, they do not take the place of testing itself.

A comment Michael Bolton made during the debrief I think deserves to be mentioned and provide some additional focus, whether it is with accessibility or anything else:

“As I start the tool and try it on any old Web page, I perceive that these tools check for certain conditions. (A strong heuristic: the “passing” stuff refers to checks, not to testing.) That is, they’re like syntax checkers and grammar checkers. They reveal obvious syntactical problems, but they don’t help much with semantics (meaning).”

As we progressed through the exercise, I shared that one of the things I encourage others to do is to actually put themselves into the position of needing Accessibility help. For this case, I mentioned my focus on what I call “the hat test”, where you pull a hat down over your eyes so that you cannot see the keyboard or the screen. By using a screen reader, you can actually “see” what the issues are, or in the case, “hear” the issues, since the regular approach to interacting with the system is no longer there.

During the session it was requested that I share some resources that can help with Accessibility Testing and learning more about it. There are several official channels and books that have been published on this topic, but below are some of the ones I’ve found to be helpful.

Standards and Design Guides:

Books:

Testing Guide:

Other Tools:

Ultimately, these resources will tell you about how to look at Accessibility and give you some ideas as to how systems should be designed, and may give you some tools to look at how you can check for issues, but as in all testing endeavors, there’s more than tools and checking. The tools can tell you what might be an issue, but your testing and puzzling through the results will help provide you with “why” these are issues, and why you should advocate for them in the first place.

The full chat transcript is here.

About the Author

I’m a software tester working with Socialtext in Palo Alto, CA. I have worked in a number of different fields and in a number of different capacities. I started my testing career in March of 1991. I am co-founder and primary facilitator for Weekend Testing Americas. I am a black-belt in the Miagi-do School of Software Testing, a member and Teacher in the Association for Software Testing, and the producer of Software Test Professionals' "This Week in Software Testing" podcast (now on hiatus).