Re: Proposal to get out of the techniques business on WCAG.NEXT

I completely agree. Those documents are well structured and highly useful. 

Regards,
Srinivasu Chakravarthula
Deque Systems Inc.,
+91-709-380-3855
Sent from my iPhone - excuse typos. 

> On 27-Mar-2016, at 19:08, Gregg Vanderheiden <gregg@raisingthefloor.org> wrote:
> 
> +1
> 
> gregg
> 
>> On Mar 27, 2016, at 1:55 AM, Sailesh Panchang <spanchang02@yahoo.com> wrote:
>> 
>> No one expects one to read  2000 or whatever  pages from top to bottom. The content is organized in amanner that allows one to dig deeper into a particular  SC or topic of interest so that one's questions get answered.
>> The understanding / techniques or other informative / explanatory content cannot be lumped with normative WCAG2 to determine the length of the guideline or standard. 
>> 
>> The techniques play a very significant role  especially because: 
>> - they are grouped  generally by the situation to which they apply 
>> - they are more specific in terms of implementation details  with regard to a technology and convey when a technique has been implemented successfully. 
>> e.g. H44 explains that a label element needs to be visible in order to pass SC 3.3.2 or that
>> a title attribute should be relied upon  for labelling form controls only in certain situations (H65), or
>> H39 and H73 explain that the table summary should not duplicate information in the table caption, or 
>> G1, G123 and G124 convey which skip technique is appropriate in which situation  and so forth.  
>> 
>> Users of WCAG 2 including accessibility consultants rely on  such informative details as well as WG's  answers  to specific questions about techniques and understanding docs.
>> 
>> Without the authoritative albeit informative  (not normative)  documentation, there would be lots of different and conflicting  statements and opinions  put out by  different consultants / experts that will confuse  developers and clients. This is not good for WCAG2 or in other words, a Judy noted , the techniques help to increase confidence in WCAG2.
>> 
>> Thanks,
>> Sailesh Panchang
>> 
>> --------------------------------------------
>> On Sat, 3/26/16, Judy Brewer <jbrewer@w3.org> wrote:
>> 
>> Subject: Re: Proposal to get out of the techniques business on WCAG.NEXT
>> To: "David MacDonald" <david100@sympatico.ca>
>> Cc: "WCAG" <w3c-wai-gl@w3.org>, "wai-eo-editors" <wai-eo-editors@w3.org>
>> Date: Saturday, March 26, 2016, 9:34 PM
>> 
>> Hi
>> David, 
>> This sounds
>> like it might have been a paraphrase/tweet from the Viking
>> and Lumberjack session on Friday morning at
>> CSUN. 
>> It was good
>> humor -- it's hard to make a technical standard
>> entertaining, and they manage to do so. While I don't
>> recall their exact following comments, I'm pretty sure
>> they clarified at the time that the standard was short and
>> the supporting material was long. 
>> 
>> I don't know if there's a right or
>> wrong answer on writing techniques, but FWIW we do hear from
>> a lot of people -- (some people newer to accessibility, but
>> not exclusively so) that the techniques are useful,
>> including for understanding how to apply newer technologies
>> in accessible ways. The techniques seem to be one of the
>> things that gives some organizations the confidence to use
>> WCAG.
>> 
>> Most
>> groups periodically reprioritize their work and this may be
>> a useful question to look at. 
>> - Judy
>> On Mar 26,
>> 2016, at 12:04 PM, David MacDonald <david100@sympatico.ca>
>> wrote:
>> 
>> Hi All
>> CSUN has finished. I enjoyed
>> following it on Twitter, mostly. There was a Tweet from a
>> talk that went out:
>>  "WCAG is about 1/3 of a mile
>> long, when printed, I want to bungee jump off
>> WCAG". 
>> Whether or not it was an accurate
>> quote, I think it is a perception worth exploring. Its'
>> a familiar criticism of WCAG, that it is "2000 pages
>> long" Attempts to try to say "no it's 36 pages
>> printed with LOTS of help" seems to be drowned
>> out. 
>> Personally, I'd like to explore
>> this perception that "WCAG is too long" which
>> I've heard for years, and offer a way forward on
>> WCAG.NEXT and/or the extensions. 
>> In the early days of WCAG2 and
>> WCAG1, our committee and a small group of peripheral
>> colleagues were the only ones who knew how to make the web
>> accessible so it was necessary to document techniques along
>> with the standards. Today, things are different:
>> - We have a robust industry of
>> accessibility professionals writing books, blogs, tutorials,
>> and making a good living doing so. - We have a robust EO group working
>> along side us providing wonderful guidance on WCAG to the
>> world. - We have orgs like the Canada Gov.
>> saying developers can ONLY use OUR techniques to meet WCAG,
>> which limits developers- We have limited internal
>> resources on our committee because we are busy with our
>> careers helping people meet WCAG, and don't have time
>> for techniques. (and feeding a baby in my case).
>> Given this change in context, I
>> think it is worth considering a new way forward for our
>> future work. So here it is.
>> I think we should get out of the
>> techniques business. 
>> There I said it. 
>> We can write Success criteria,
>> Guidelines, principles, and offer a (short) Understanding
>> document for each new Success Criteria to help folks
>> understand it. We may include in the Understanding a couple
>> of examples, and of course we have to prove that each SC can
>> be met. But lets stop writing Techniques, and let the world
>> know we don't do that. We are a standards group.
>> Here's the advantages:
>> Then when we are done, people
>> won't be able to say "It's too
>> long".
>