RE: A 10,000 foot view of this question

Peter's "10,000 view" and flowchart below seems fair to me.  One conditional I would add to his flow chart approach is that for the path to drop to the next level, it is first necessary to articulate the characteristics that distinguishes non-web ICT from web content.

I think our current impasse with "set of documents" versus "set of web pages" comes down to a feeling that one is different than the other, but I have not seen that difference articulated well in writing.  It may be the case that "set of web pages" is too vague a construct for the comfort level of members of this taskforce.  If that is really what the root of the problem is, we should just note that and move ahead (since changing WCAG is out of scope).  I have heard a few people deny that this is the case, that "set of web pages" is sufficiently well defined but "set of documents" is not.  I would very much like to see that assertion addressed in writing.


From: Peter Korn [mailto:peter.korn@oracle.com]
Sent: Thursday, September 13, 2012 8:13 PM
To: public-wcag2ict-tf@w3.org
Subject: A 10,000 foot view of this question [was Re: How much room do we have in "describing how to apply" [was Re: examples of sets of documents]]

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

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

Peter