RE: A 10,000 foot view of this question

The last definition for set of documents I recall was from Pierce I think, and basically paraphrasing now included that the set was published together, and included identification of set members.  Initially I advocated we require that the set is defined by actual links from a master document, or from document to document, but folks pushed back that this was more restrictive than needed.  While I'd prefer that constraint I can live without it-it just raises the bar for testing greatly in my opinion.  I think published together sounds great, but is very vague in reality.  Published can mean lots of things to lots of people, does it mean copyright, public access, team access, or what?  Even together starts to become complicated if you ask me.  What if you "post" a set of documents on Monday morning, update one on Monday afternoon, delete one Tuesday, and add a new one on Wednesday?  Seems this is similar to Web pages so I don't have so much concern as folks who work these issues will just have to set their bars of testing and move on.

As far as software, how would we look at something like google's applications wich are linked on a page, but are sort of standalone, e.g. gmail, youtube, google plus?  If we understand how we would treat that we should be able to translate that to nonWeb "collection" of software.  Suites of software should not be required to find information within multiple applications, no matter if the stuff was installed form a central installation system, came in the box, or whatever.  The concept that we require multi-application search seems like pie in the sky to me.  It sounds great, but should be a nice-to-have kind of thing rather than a have to have kind of thing.




From: Bailey, Bruce [mailto:Bailey@Access-Board.gov]
Sent: Friday, September 14, 2012 7:49 AM
To: public-wcag2ict-tf@w3.org
Subject: 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<mailto: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