“These requirements are not testable”, “These requirements are subjective”, and even “These requirements are not feasible” – all that I heard recently.
You see, in Ontario, Canada, Accessibility compliance requirements is a big thing now, and not only for software. Accessibility for Ontarians with Disabilities Act (AODA), sets the bar aligned with Web Content Accessibility Guidelines (WCAG), an evolving set of recommendations. For now, government web-sites and large public sector web-sites are obliged to comply, but it sets a precedent and sets an expectation. But the unexpected (well, I think of it as so) challenge comes not from a technical side, but from a technical mindset.

Complains come from programmers, and come from testers as well. A programmer thinks: “I code some requirement and tell testers to verify it”. Tester thinks: “I will verify what I’m told to verify”.

Now, let’s take a quick look at the guidelines.

• Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
• Operable – User interface components and navigation must be operable.
• Understandable – Information and the operation of user interface must be understandable.
• Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

All makes sense, right? Heck, any user would expect that… but often instead “get trained” by programs to behave the way programs expect him to.
And now it has to change.

No surprise, that /some/ programmers consider accessibility requirements “subjective”, “not testable”, and “not feasible”.
First, it requires change of a mindset in order to successfully create such software. Earlier, all design and implementation were totally ruled by geeks, and “Invalid user.. replace and press any key” was considered a cool joke, then there was “RTFM” joke… but those are not tolerated anymore, neither by business stakeholders nor by end-users.
Second, programmers have to give up the initiative to testers, who get the freedom to explore, find out, investigate, and conclude – all that without “expected results”. Focus gets shifted from questions “does it meet functional requirement A” to questions “does it meet the purpose? does it solve the problem? does it add value?”

This scares /some/ programmers, as well as /some/ testers, and it also scares (ok, “raises concerns”) some managers. “Without structured approach, how would we know what testers do, and whether they did it right or did anything at all”. It forces to get away from narrow thinking of testing and get away from claims like “any guy from the street can test”.

Luckily, there’s another kind of testers on a rise.

They don’t demand requirements to start testing, but will proactively use all sources of information, from requirements to support tickets, and everything in between.
These testers can manage a heavy test suite, or can do without test cases, but they won’t do flat “execute as much test cases as possible” job. They’d go with a risk-based approach and be smart applying testing effort.
Those testers may feed any kinds of metrics as required by the organization, but they also find a way to deliver really meaningful information to stakeholders, because they know what kinds of answers they’re looking for.

Of course, I’m talking about context-driven testers. They are ready for the move. Rest assured, they’ll find requirements like accessibility guidelines perfectly testable.