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

+1 to supporting the techniques 

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Mon, 28 Mar 2016 15:10:27 +0300 Jonathan Avila<jon.avila@ssbbartgroup.com> wrote ---- 

+1 to supporting the techniques. 
 
Jonathan 
 
Sent from my iPhone 
 
> On Mar 27, 2016, at 2:58 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". 
> 
> 
> 
> 
>