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

+1 for the techniques.

Admittedly, a challenge to design training courses around due to the volume of some of them but they spell out what is needed and how to meet their respective guideline. I often feel I’m not giving my students enough – or covering the material/topic completely - when I limit how many techniques I have for a given guideline. But, they can continue to go deeper on their own as need because the material is there in the WCAG documentation. It is a great body of work and requires the amount of information that current makes up the body of knowledge. 
Consider the Project Management Body of Knowledge (PMBOK) Guide. It is well over 400 pages long.

Alan

Sent from Mail for Windows 10

From: Sailesh Panchang
Sent: Sunday, March 27, 2016 2:58 AM
To: David MacDonald; Judy Brewer
Cc: WCAG; wai-eo-editors
Subject: Re: Proposal to get out of the techniques business on WCAG.NEXT

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