Could the next major version of the accessibility guidelines be technology specific instead of technology agnostic?
Brainstorming has begun about what the next major version of the WCAG may look like. This post is an attempt to contribute to that process, with its historical perspective as a consideration. The universal response to the WCAG appears to be that it has made an amazing impact on global accessibility and is a unified standard around which the global community can rally. However, it is difficult to understand and it’s technology agnostic language sometimes seems cryptic to those who are implementing it on their sites. Almost all of the criticisms of the WCAG 2.x can be boiled down to “its hard to understand” and “it needs to make room for soft requirements that are hard to test”.
To explore how we got here, let’s go back to 1999, with the release of WCAG 1.0. It was a breakthrough standard in which design concepts such as colour, and HTML specific requirements were all mixed together in a very flat level standard. It was a huge success and began to get legal recognition. One of the things that led to its quick adoption was that it was easy to understand, and it made a big difference for people with disabilities. However, it was very prescriptive on designers and was also vulnerable to changes in technology. Legal frameworks and standards historically move much slower than technology.
We endeavoured to solve this problem in WCAG 2.0. The W3C process was that normative documents went through a long rigorous process to become a standard (years). There is also a category of supporting documents that were non normative and easier to update. WCAG 2.0 extractacted the characteristics of the 1.0 requirements into technology agnostic normative success criteria, with separate non normative technology specific techniques to meet those success criteria. It was a huge success and WCAG 2.0 has survived 10 years. But its longevity and stability came at a high cost. It had 4 layers, 3 layers were normative (Principles, Guidelines, Success criteria) an one layer (technology specific techniques) that were non normative.
New more frequent updates required by W3C standards could help standards keep up with technology
In the last few years the W3C has evolved in its approach to standards for a more iterative approach perhaps inspired by AGILE. There is a requirement now for standards to be frequently updated on 18 month - 2 year cycles. No more 10 year development cycles such as we had in WCAG 2.0. At first I was concerned that this change in approach would cause problems for future of WCAG.
However, during WCAG meetings in France, I realized that frequent updates to the standard could solve the dilemma of separation of normative success criteria and non normative technique where users had to look in 2 places.
How this could help us in the next version of the Accessibility Guidelines
Frequent published standards could keep up with technology. So we might be able to integrate the techniques into the normative part of the standard and merge them with the testable/measurable Success Criteria, into what the Silver Task Force is calling “methods”. These would be normative. The WCAG 2.0, 12 guidelines would expand in their role and become general guidelines under which these methods could be grouped. So instead of 4 layers of guidance which cause the reader to look in several places to know what to do, there would be only 2 layers (Guidelines and Methods).
It would overcome the problem of having to have technology agnostic success criteria which are hard to understand. The methods would say what to do and how to do it and also be the unit of measurement of conformance. There would be only one place to look in order to know what to do to meet the requirement. The general information such as "Make code correspond to visual layout" would be guidelines under which the methods are found.
There are risks but also opportunities in this approach which could be explored.
Feel free to comment on this article on Twitter @davidmacd
David MacDonald is a 17 year WCAG veteran and co-editor of Using WAI ARIA . Opinions are my own.
For a quote or just to chat about your organization's needs