Re: Can Silver have normative technology specific requirements?

Hi Jason,
Just wondering how what you propose is different from what we have now - we have sufficient techniques which satisfy a success criterion OR another sufficient technique that can satisfy it (so no particular technique is mandatory). We also have combinations: use GXX AND use one of the following Techniques. 

The situation where there is a neutral requirement but no applicable technique is rare or does not even exist, I believe - there are SCs that have no failure techniques (because of the difficulty of pinning them down) but having an SC without any indication of how to meet it on a technical level appears a bit frivolous.  

Novel situations for which no requirements exist are an interesting case, and we may stumble into those when we all have our goggles on one day, stumbling through reality like Johnny England. In WCAG 2.1, we increasingly had SCs where the only technique we could think of basically had the form of „Don’t do something“ (e.g. don’t lock to one orientation) or simply "provide alternative (keyboard-accessible, pointer accessible) ways of doing something“ (motion actuation, pointer gestures).

I feel a bit wary about the idea about making the techniques-turned-methods normative - it would probably be „one of that lot is normative“ anyway -  which is not far removed from the current situation of having an SC and a choice of sufficient techniques. Still not sure what we win when we move the conformance to that method level. But having said that, I think we need to continue to draft the old SCs in the new scheme, and see what issues we run into - this type of thing just needs to be explored on the basis of cases.

Detlev

> Am 22.11.2018 um 20:02 schrieb White, Jason J <jjwhite@ets.org>:
> 
> It would be possible to set up a cascade:
>  
> If there is a technology-dependent technique that applies in a given situation, then implementing the technique correctly satisfies the WCAG requirement. Alternative approaches to meeting the requirement are permitted.
>  
> If there is no applicable technique, then fall back to the technology-neutral requirement, which must be satisfied – this would be akin to a WCAG 2.x success criterion.
>  
> If there is no specific requirement applicable to a given situation, then general accessibility principles (stated in the document) must be implemented.
>  
> Note that the “cascade” order is “bottom-up”, progressing from most specific to most general, while allowing for alternative implementation approaches. Developers of the typical Web site or application can proceed by implementing the technology-dependent requirements; those with more complex needs will have to go beyond this level.
>  
> I’m just floating an idea here, not necessarily advocating it.
>  
> From: Katie Haritos-Shea <ryladog@gmail.com> 
> Sent: Thursday, November 22, 2018 1:39 PM
> To: Patrick Lauke <redux@splintered.co.uk>
> Cc: Silver Task Force <public-silver@w3.org>; WCAG <w3c-wai-gl@w3.org>
> Subject: 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 <mailto: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://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.splintered.co.uk&data=02%7C01%7Cjjwhite%40ets.org%7C5a841ac594434eecc37b08d650a9f348%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636785088189778908&sdata=KXMa1yc0gN5qdPrOgPJ9pZ6bZnpCxve0hLtQd%2BKUjYQ%3D&reserved=0> | https://github.com/patrickhlauke <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpatrickhlauke&data=02%7C01%7Cjjwhite%40ets.org%7C5a841ac594434eecc37b08d650a9f348%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636785088189778908&sdata=KvvKkcSlmFN1TRGimiwX4kAsWXiGHZEprwCGl3RID3k%3D&reserved=0>
> http://flickr.com/photos/redux/ <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fflickr.com%2Fphotos%2Fredux%2F&data=02%7C01%7Cjjwhite%40ets.org%7C5a841ac594434eecc37b08d650a9f348%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636785088189788917&sdata=Q47u7bPAaxwYShzAV4G982EuF7Sbn6hreOIy5Bs%2BRLk%3D&reserved=0> | http://redux.deviantart.com <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fredux.deviantart.com&data=02%7C01%7Cjjwhite%40ets.org%7C5a841ac594434eecc37b08d650a9f348%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636785088189788917&sdata=j%2FcvMbFvcp%2FMN5SkZ6q9GpuWBtdp8Kttdb0e%2FE5FEmI%3D&reserved=0>
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> 
> 
> This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
> 
> 
> Thank you for your compliance.
>