W3C home > Mailing lists > Public > public-wcag2ict-tf@w3.org > June 2012

Re: Interaction Context

From: Peter Korn <peter.korn@oracle.com>
Date: Mon, 18 Jun 2012 17:29:41 -0700
Message-ID: <4FDFC7F5.5060708@oracle.com>
To: Gregg Vanderheiden <gv@trace.wisc.edu>
CC: public-wcag2ict-tf@w3.org
Gregg,

I'm going to cut-and-paste a bit out of order, to hopefully help focus 
the conversation on a few key issues.

You wrote:

> *What is an IC*
>
>   *  a modal dialog box  (with or without a title) all by itself
>   * a nonmodal dialog  (with or without a title) along with anything
>     else outside of that dialog that belongs to the same application
>     (or it could be a suit)  (same 'author)  that a user can directly
>     interact with (e.g. ONLY those parts of the menu bar on the top of
>     the screen of a Macintosh that the author intends to work with
>     their program.  Other things added by the user are not part of the
>     context for the application (though they are for the user)
>     ...
>

and later you wrote in response to me:

>>
>> I'm also troubled by your 3rd bullet.  As I read it, if I have 4 
>> windows open - two Writer documents, a Calc spreadsheet, and an 
>> Impress slide presentation - they would all be the same IC because 
>> they are all part of the OpenOffice suite and therefore the same 
>> "author".  That doesn't make sense to me.  It also breaks down for me 
>> 2.4.1 below (which I'll discuss in more detail there).
>
> IF they are designed to all work together -- and you can navigate 
> among them  -- and they are intended to work as one -- then yes.   If 
> they are just miscellaneous programs from the same company - then they 
> are not the same context.

and yet later:

> Grin.  I has to do with how they are viewed and work together.   
> Remember that a single application presents MANY DIFFERENT ICs from 
> one moment to the next.   So All the apps can be one IC one moment and 
> yet different ICs at another.
>
> the key word is CONTEXT not application.     You change context within 
> an app.  And your context of operation at any point in time includes 
> the app and the OS.

and finally getting to 2.4.5, in response to me, you wrote:

>
>>     *"2.4.5 Multiple Ways:* More than one way is available to locate
>>     a /*dialog box*/ within a/*set of windows all belonging to the
>>     same application */except where the Web Page is the result of, or
>>     a step in, a process <http://www.w3.org/TR/WCAG/#processdef>.
>>     (Level AA)"
>>
> ?????  dialog boxes are not ICS -- so I wouldn’t expect this to make 
> sense.
>
> I don't understand your substitutions.  Hence I'm not surprised the 
> sentences don't computer.
>
> this reads
>
>     *"2.4.5 Multiple Ways:* More than one way is available to locate a
>     /*IC*/ within a/* set of ICs */except where the IC is the result
>     of, or a step in, a process
>     <http://www.w3.org/TR/WCAG/#processdef>. (Level AA)"
>

So a "modal dialog box" is an IC - perhaps all of the time (or nearly 
all of the time?).  And sometimes a single application with multiple 
windows is multiple ICs, and other times a single application with 
multiple windows is a single IC.  But in any case, a "set of web pages" 
(I mean "set of ICs") must always be from the same author to be within 
the set, so I guess "set of ICs" must always be a set of windows/dialog 
boxes/etc. from the same application or application suite, else they 
aren't in the same set.

So, scratching my head a bit about 2.4.5... I come to the following 
specific recasting (remember, getting specific like this is a way to 
test the definition - if you cannot substitute the definition for the 
term, then the definition fails):

    *"2.4.5 Multiple Ways:* More than one way is available to locate a
    /*modal dialog box*/ within a/*set of windows/dialog boxes/... all
    belonging to the same application or suite of applications, from the
    same author */except where the Web Page is the result of, or a step
    in, a process <http://www.w3.org/TR/WCAG/#processdef>. (Level AA)"

How does that text above NOT flow from your proposed definitions of 
these terms?

And again - and perhaps more importantly - WHAT DOES THIS MEAN in 
practice?  What are the actual, multiple ways for the ICT itself to 
provide these multiple ways.  Note: unlike 508/M376, we cannot "meet the 
SC directly or through the use of supported AT" - that's not a WCAG 
concept.  So these multiple ways must be directly provided by the 
software, or the software fails the SC.

More generally - would /*you */please do as I have done, and give at 
least one concrete WIMP GUI example of a single IC within a set of ICs 
and describe the multiple ways of locating that single IC within that 
set of ICs?  Because I'm just not seeing it...



Now, on to some other parts of our discussion...

<snip>

>>   How do we determine whether the author is the same or not?
>
> IF the product is a microsoft product then Microsoft is the 'author". 
>  Note that is says  author ... organization.

  ...

>>
>> I'm also troubled by your 3rd bullet.  As I read it, if I have 4 
>> windows open - two Writer documents, a Calc spreadsheet, and an 
>> Impress slide presentation - they would all be the same IC because 
>> they are all part of the OpenOffice suite and therefore the same 
>> "author".  That doesn't make sense to me.  It also breaks down for me 
>> 2.4.1 below (which I'll discuss in more detail there).
>
> IF they are designed to all work together -- and you can navigate 
> among them  -- and they are intended to work as one -- then yes.   If 
> they are just miscellaneous programs from the same company - then they 
> are not the same context.

...

> Remember that a single application presents MANY DIFFERENT ICs from 
> one moment to the next.   So All the apps can be one IC one moment and 
> yet different ICs at another. 


I don't think this is tenable without a more clear rule.  It isn't 
objectively testable.  How do we say when a collection of apps designed 
to work well together but also available separately is "miscellaneous 
programs from the same company" or not?  If sold separately they are 
each their own IC, but when available together they loose there separate 
identities and become part of a larger shared IC?  And your final two 
sentences above are also not at all testable.  How can we evaluate 
provisions that speak to multiple ICs (or a "set of ICs") when sometimes 
this collection of things is a single IC and other times it is multiple 
ICs?  How do we when when it is one and when it is the other? (like a 
photon, sometimes a particle, sometimes a wave?  and sometimes oth at 
the same time?  but sometimes a particle among a set of waves...???  - 
quantum electrodynamics isn't my strong suit)



Next topic:

>> And even if I am mistaken, in a variety of UNIX graphical 
>> environments that is the case - there are a number of different apps 
>> that may appear to be "the desktop" - certainly different programming 
>> groups may have authored them.
>
> Right - and if the authors intend them to all work as one IC they are. 
>  Authors intent.

At some point we are going to also have to deal with conformance to WCAG 
in the context of non-web ICT.  A major part of how WCAG conformance is 
playing out in the world is through evaluation not just by the author.  
Also by the user or purchaser (or a third party).  If "author intent" 
plays a role in how to give meaning to the terms we use in the context 
of software, then we have a large potential train wreck ahead of us as 
folks other than authors attempt to assess whether WCAG is met or not by 
software ICT.



Next topic:
>>
>> I also, frankly, question whether 2.4.2 needs to apply to all ICs in 
>> the software world - precisely because much of the Intent is 
>> addressable without needing to have a visible text title (and the 
>> Dock's title isn't visible, just spoken via AT).
>
> You are defining IC as being bits of IC's     so you get a dead 
> end-which you should.

Actually, I was caught up in a different way.  I was caught up in the 
notion that the title should be visible.  If we addressed 2.4.2 with a 
Note making clear that the title doesn't have to be visually rendered on 
the screen by the ICT, then I think we solve the example scenarios I was 
bringing up.  I've added this to DISCUSSION POINTS for 2.4.2:

    Note: the title doesn't have to be made visible on the the screen in
    order to satisfy this Criterion, so long as it is programmatically
    determinable and available to AT.


Next topic:

>
>>
>>>
>>> You wrote:
>>>>
>>>> [Also, we may need to reconcile that a web browser is software, yet 
>>>> by this definition both a portion of the web browser window - the 
>>>> web page - and the entire window, are both an "interaction 
>>>> context".  Is that a problem?]
>>>>
>>>
>>> The web browser is a context by itself -- but the browser is not 
>>> responsible for the content.
>>>
>>>
>>> The content Plus the browser is a context to the page author - at 
>>> least for the browsers the authors intend their page to work with.
>>
>> Hmmm...  So really any sort of "software player" would be presenting 
>> 2 ICs: one for the player "chrome", and a second for the "player 
>> content".  E.g. a Flash application, or Java applet, or... running 
>> within a web page is an IC separate from the hosting application (or 
>> to use W3C terminology, the User Agent).  That certainly is in 
>> keeping with the "author" notion.
>
> I think I follow you here.  But remember that the author of the 
> "content" includes the player in their IC.

Sorry, you've lost me here.  In the web context, we don't hold web page 
authors responsible for the accessibility of the user agent.  If the IC 
of a Java applet includes the Java runtime, and the IC of the Flash app 
includes the Flash player, and the IC of the PDF document includes Adobe 
Reader (or some other PDF viewer)...  then you are making authors 
responsible for something they cannot control.

Why should web authors not be responsible for accessibility of the web 
browser but authors of highly interactive PDF documents (so they aren't 
simple electronic content) be responsible for one of several PDF viewers 
on the market?  If they are the same IC, then it seems to me the 
responsibility issue follows from that (as a WCAG in the software 
context conformance assessment would get made on the entire IC).


>>
>> <snip>
>>
>>>>   * My feeling is that "interaction context" is a poor substitute
>>>>     for web page" in 2.4.2 - as it also is with 2.4.1.  This SC is
>>>>     an "irregular verb" that we just need to deal with separately,
>>>>     relying more on the Intent language.
>>>>
>>> Seems to fit to me.
>>
>> I only see a possible fit here, and only for the first of the 
>> multiple sentences in the Intent, and by doing so in a way that goes 
>> beyond what is strictly necessary in the more varied world of 
>> software UIs generally.
>>
>> I think SC is still better served by treating it a (slightly) 
>> irregular verb.
>
> Sorry -- I don't understand either sentence.  Nor what you mean by a 
> sentence being an irregular verb.  If you mean that the term doesn’t 
> work here -- I still don't see why.


As I'm now comfortable with 2.4.2, now that I realize the title doesn't 
have to be visible on the screen, I think the 'irregular verb' and 
related discussions for 2.4.2 are "overtaken by events".


And finally to a larger concept:

>
>> Anyway... my point in this discussion isn't to try to wrestle a whole 
>> bunch of provisions all at once, but to see if as a group we have 
>> rough consensus that:
>>
>>   * there is a workable notion - precise definition TBD - that works
>>     in a lot of places
>>   * there are some places (my "irregular verbs") where a straight
>>     substitution doesn't work; so we should some up with a term that
>>     does work in the "lots of places" and use it there, but not try
>>     to twist either the term or the fitting in order to insist it be
>>     used everywhere - (in other words, let our world have a few
>>     irregular verbs)
>>
>> It sounds to me Gregg that you want to keep pushing for a world free 
>> of exceptions.  Or maybe it is just that you don't see the exceptions 
>> where I see them.
>
>
> Don't know where you get that...   I don't agree we should have a 
> world free of exceptions.   WCAG is full of them.  ANd I endorse a 
> bunch of global exceptions in 508.    But we have no authority to 
> create any new exceptions in WCAG or 508.     So I'm not sure where 
> the topic comes from.

The 'exception' notion is this: specific SCs for which our mapping of 
"web page" to "IC" doesn't (quite) work are "exceptions" to *our* 
mapping rule of "web page" to "IC".  For those exceptions we have more 
work to do in our mapping of the SC to the non-web ICT world.

Make sense now?


Regards,

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
Received on Tuesday, 19 June 2012 00:30:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 June 2012 00:30:24 GMT