- From: Gregg Vanderheiden <ez1testing@gmail.com>
- Date: Thu, 13 Sep 2012 20:32:05 -0400
- To: Peter Korn <peter.korn@oracle.com>
- Cc: public-wcag2ict-tf@w3.org
- Message-Id: <EFA9B4CE-3C1F-4955-8344-D9A60FBE8F26@trace.wisc.edu>
On Sep 13, 2012, at 8:12 PM, Peter Korn <peter.korn@oracle.com> wrote: > Gang, > > Maybe it would help if I stated my thoughts "from a 10,000 foot view". In flowchart form with 5 steps/decision questions: > 1) Does all of WCAG 2.0 A/AA apply to non-web ICT with a few, global word substitutions? If yes: make them, add notes where needed. You are done. If not.. GV: I think we established that this was not true some time ago. It does for a lot of them but not all. > 2) For each WCAG 2.0 A/AA SC, does it apply to non-web ICT with a few, SC-specific word substitutions? IF yes: make them, add notes where needed. You are done. If not.. GV: I think this is where we are with all but two and we are still working on those two > 3) For each WCAG 2.0 A/AA SC that cannot be made to apply to non-web ICT with a few word substitutions, does it apply to non-web ICT if you craft losely related language that addresses the non-web ICT accessibility challenge(s) closely related to the underlying web accessibility challenge(s) described in INTENT? [NOTE: this may require getting the OK from WCAG WG] If yes, craft that language. You are done. If not... GV: don't understand this one > 4) For each WCAG 2.0 A/AA SC that cannot be made to apply by crafting closely related language that addresses the non-web ICT accessibility challenge(s) closely related to the underlying web accessibility challenge(s) described in INTENT, can you reach consensus on a statement that it doesn't apply? [NOTE: this may require getting the OK from WCAG WG] If yes, make that statement. You are done. If not... > GV: Don't know. Saying something doesn’t apply is specifically "out of scope" in our charge. So far we haven't needed to even go there. And we have only a couple items left. > 5) For each remaining WCAG 2.0 A/AA SC that you couldn't address via steps #1-4 above, state that "we couldn't reach consensus on how to apply <SC name> to non-web ICT. You are done. GV: This we can do. Hopefully we won't have to go there. If we do then we get to go home but just kick the can down the road. Who picks it up? Probably we would put the opposing points in the doc and let the next group figure it out or make the call. But I think we are very close. Failing to reach consensus is always an option I guess. > > To my mind M376 draft #5 is essentially going the path of step #1, with a few step #4 items for SCs they don't believe apply. Meanwhile we've moved pretty directly to step #2, though we have managed to find language substitutions that are common to many SC. And for a few SCs we're still working on #2 - finding language with a few word substitutions + added notes. > > What we are NOT doing is looking at the underlying problem the SC is crafted to address and considering crafting closely related language that addresses the closely related problem in the non-web world. > GV: we have no grounds for going outside of the boundaries of the WCAG SC and crafting related SC. > And it is my understanding of what I hear from Gregg that "that is outside of our charter". If true, then I say there should come a time when - if we are still not at "You are done" - we approach WCAG WG and talk with them about trying option #3 and if that fails, option #4. Because I think either of those are better than option #5 - reporting only a failure to reach consensus > GV: don't know. I think we can finish up with #2's. I don't understand #3. #4 is not something anyone charged us with (creating guidance that is outside of but related to a WCAG SC). And #5 is I guess what happens if we fail. But we have a good group. We have made AMAZING progress in record time - over a summer - and I think we can get through the last couple. > > Peter > On 9/13/2012 4:07 PM, Peter Korn wrote: >> Gregg, >> >> On 9/13/2012 3:13 PM, Gregg Vanderheiden wrote: >>> >>> On Sep 13, 2012, at 11:37 AM, Peter Korn <peter.korn@oracle.com> wrote: >>> >>>> <PK> Perhaps I wasn't sufficiently clear. The constraint is in the limitations we are placing on ourselves in "describing how to apply". Based I believe primarily on statements from Gregg (who is arguably our best authority here, given that he is a WCAG WG co-chair), we are not to do more than single word or phrase replacements in our "describing how to apply" work. That constraint isn't found in such wording in our charter. >>> >>> <GV> I'm not sure where the " we are not to do more than single word or phrase replacements in our "describing how to apply" work. " came from but it was not from me. >>> >>> And we have done more that that of course, in multiple places, where it was needed and or helpful. >>> >> >> <PK2> I guess I'm not clear as to what the precise constraints are. >> >> Multiple times I have suggested we look at INTENT and the purpose of a given challenging SC, and apply (or perhaps to better use Alex's term, "interpret") that in the software context in ways that change more things than terms like "web page". >> >> For example, for 2.4.1 Bypass Blocks, I looked at the larger challenge of which repeated blocks was the common web page instance, and suggested this should apply to software by allowing effective ways to navigate to the content region and other key parts of the UI. But I did so using a lot of text, and our successive iterations got bogged down into precise analogs of "blocks of content" and finding a substitution for "on multiple Web pages" to allow us to do what we (many of us) wanted to do: address the issue in the software context that the web language was addressing more explicitly & precisely for web content. >> >> So... given your statement above Gregg, I don't feel I understand what your bright line is of what you feel we can do (beyond direct substitution for terms & addition of explanation/notes), and what you feel we cannot (which I recall basically as being "cannot write new SCs"). Mind you, I'm not arguing for us to write generic SCs for software. BUT... where we are continuing to run into difficulty, I - yet again - suggest we need to consider doing something differently than we are doing. >> >> >> Peter >> >> -- >> <Mail Attachment.gif> >> Peter Korn | Accessibility Principal >> Phone: +1 650 5069522 >> 500 Oracle Parkway | Redwood City, CA 94065 >> <Mail Attachment.gif> Oracle is committed to developing practices and products that help protect the environment > > -- > <oracle_sig_logo.gif> > Peter Korn | Accessibility Principal > Phone: +1 650 5069522 > 500 Oracle Parkway | Redwood City, CA 94065 > <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment
Received on Friday, 14 September 2012 14:14:44 UTC