WTA54: An Intro To Accessibility Testing

Posted by Albert Gareev on Sep 16, 2014 | Categories: AccessibilityWTAmericas

After somewhat a pause, I’m stepping back in as a facilitator in Weekend Testing Americas chapter.

The good occasion was recent session on Web Accessibility, initiated by Michael Larsen. This is the area I’m actively learning, professionally working in, and the idea I’ve grown to support. So I prepared a few exercises, and walked through them with my group.

And (as always) some takeaways for myself.

Learning new practice needs a foothold; tools don’t provide that

The session was centered on WAVE tool, scanning and checking web pages for potential accessibility issues. The tool finds a lot of them on a typical Web page, partly because of the lack of Accessibility support on the Web, partly because these requirements have lots of interpretation and must be evaluated in the context – which a tool can hardly do, so it raises a warning to draw your attention. And first time accessibility testers, swamped by all the findings, wouldn’t know how to interpret them either.

But after I set a focus on a single accessibility concern, demonstrated it’s meaning for use with Screen Reader, demonstrated a difference between properly implemented and mis-implemented accessibility support, the group went on and found more defects of this type on their own.

This should be a concern for companies assuming that acquiring of a tool may cover the skills gap – not gonna happen, doesn’t work this way.

Only through conscious practice testers (as well as programmers) can develop required skills, and only then employing tools may make their work further improved.

What is the purpose?

How many times you were told to “just test this functionality”? – I heard that too many times. Even as “I don’t care.. just have it tested [by deadline]”. And it wasn’t always easy to find out what the functionality was supposed to bring for users, or even to explain why it’s really important to know.

For many issues, accessibility support problems are not visually obvious, or even appear totally fine at sight. So it required an explanation and example on how the same text will appear for a non-sighted user, and what was causing the problem.

Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
This work by Albert Gareev is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported.