Can Silver have normative technology specific requirements?

Brainstorming has begun about what the next major version of the WCAG may
look like. This 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.0 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.

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 TPAC 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. 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.

So I'm suggesting we explore moving integrating the techniques with the SCs
to become *normative* methods that are updated using the regular 18 month-2
year cadence of the normative document cycle.  The general information such
as "Make code correspond to visual layout" would be guidelines under with
all of the methods rest.

There are risks but also opportunities in this approach which could be
explored.

Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Mobile:  613.806.9005

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>