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

I tend to agree with David and the defenders of techniques. Techniques are
a wildly unmanageable business, and that being said, they are useful.

I find 2000 page argument silly. Any technical document of this scope takes
space. It probably needs enormous space, but does WAI need to do it all?
Can WAI we do it?

WAI is at an important nexus between understanding disability needs and
knowing what can be realizable at a given time. Sometimes we get it wrong,
but few get it better.

We should define standards, but solutions are pretty intractable for a
group of our size and funding level.

We should come up with a cutoff date for WCAG 2 techniques. Then maybe
develop WCAG 3 and decide if we can support technique. More and more I
think WCAG 3 is needed. Technology has moved far since WCAG 2, and we
haven't even started with the impact of web components.

A new guideline that incorporates new technology and the findings of the
task forces seems like the real direction. Then we can reassess the method
to support it.

Wayne


On Sun, Mar 27, 2016 at 9:05 AM, Srinivasu Chakravarthula <
srinivasu.chakravarthula@deque.com> wrote:

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