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

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 
>> <mailto: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
>
> -- 
> Oracle <http://www.oracle.com>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 <tel:+1%20650%205069522>
> 500 Oracle Parkway | Redwood City, CA 94065
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
> developing practices and products that help protect the environment

-- 
Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 5069522 <tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment