Re: Can Silver have normative technology specific requirements?

David,

Thank you very much for reminding us of some of the WCAG history. I
appreciate seeing it, and starting this conversation.

If the methods are loose, then maybe the general techniques might be able
to accommodate being normative. But, for the technology specific
techniques/methods I think we do need to leave them non-normative
(remembering the Italian issue).

That allows for newer technologies to be covered - and for organizations
and legislation that can continue to implement whatever version of the
standards they may choose for their own unique required timelines.

My 2 cents...:-)

On Thu, Nov 22, 2018, 1:25 PM Patrick H. Lauke <redux@splintered.co.uk
wrote:

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