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

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

Received on Monday, 28 March 2016 12:10:57 UTC