In the series of reviews I went over WCAG level A / AA (Web Content Accessibility Guidelines) requirements from testing perspective. This is my second detailed take, as the first one was about 2 years ago when I started professionally performing (elements of) accessibility testing. And I took the second shot to futher sharpen my skill and depth of accessibility testing.

Why A /AA levels?

This is the scope of Ontario regulation – AODA – Accessibility for Ontarians with Disabilities Act.

Why making Accessible Internet is important for everyone? (IMO)

Because everyone is aging. While some are still lucky to keep fully functional vision, cognition, motorics, and hearing, most of people lose one or another with years. Or just don’t have it as sharp as before – and barriers to information control and access arise. We live in information processing era. People talk of not using Facebook for a week as a “greatest challenge”.. now imagine yourself fully deprived from every information source you’re used to.

The second reason is global, social, and economical. Simply put, quite cheap and easy methods of Web design and implementation enable access to fully productive work for those millions of people who are well educated and well motivated to work. Everyone should have a fulfilled right to work. And government and businesses will only benefit with this additional resource of qualified workforce.

What are my findings?

I found Accessibility Guidelines perfectly reasonable and reasoning. The most important information is in the “second layer” – “Understanding the requirement” articles, providing context and examples.

I also found Guidelines well aligned with the concept of heuristics. And being a scholar of heuristic-based and context-driven approach I felt very comfortable studying and applying the accessibility heuristics.

The actual implementation requirements may vary to a great extent. That makes scripted requirements-based testing approach extremely expensive and ineffective:

• accessibility implementation is very context-speicific and varies from page to page;
• same implementation might be valid for one page and invalid for another;
• test case documenting at such level of detail is very time consuming and expensive;
• without skilled understanding of the accessibility purposes and techniques scripted verification is very time consuming and expensive, and yet there’s a high chance of missing high severity defects unknown at the time of scripting.

And I have a whole lot to say about accessibility checking tools, their degree of assistance, and applicability. This will come in a separate blog post.