Re: Can Silver have normative technology specific requirements?

On 22/11/2018 16:22, David MacDonald wrote:
> 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 explorehow 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, withseparate 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 lookin 
> 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.

I thought the point of non-normative techniques was that what really 
counts is fulfilling a success criterion, and that to do that, there can 
usually be more than one particular way of doing that...hence the 
techniques being non-normative ("here's one way of doing it" versus 
"this is the one true way you HAVE to do it"). If anything, with more 
standards/technologies coming around now, this holds even more true than 
before. Unless I'm missing a nuance here?

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Thursday, 22 November 2018 18:24:41 UTC