- From: Mike Elledge <melledge@yahoo.com>
- Date: Sun, 27 Mar 2016 19:10:18 +0000 (UTC)
- To: Wayne Dick <wayneedick@gmail.com>, Srinivasu Chakravarthula <srinivasu.chakravarthula@deque.com>
- Cc: Gregg Vanderheiden <gregg@raisingthefloor.org>, Sailesh Panchang <spanchang02@yahoo.com>, David MacDonald <david100@sympatico.ca>, Judy Brewer <jbrewer@w3.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>, wai-eo-editors <wai-eo-editors@w3.org>
- Message-ID: <1923762442.654343.1459105818437.JavaMail.yahoo@mail.yahoo.com>
Hi Everyone-- I've found the techniques to be very useful and I know our developers look to them for guidance. I also am sympathetic that they take time and effort to create. Maybe we could adopt a new model for developing them? What if we asked developers to submit sample techniques, including a review against AT/Browser combinations? Could that lighten the load, while providing a mechanism for including new or updated techniques? Then giving credit to the submitter might be all the encouragement needed. Mike On Sunday, March 27, 2016 1:56 PM, Wayne Dick <wayneedick@gmail.com> wrote: 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 ChakravarthulaDeque Systems Inc.,+91-709-380-3855Sent 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".
Received on Sunday, 27 March 2016 19:13:58 UTC