Re: Interaction Context

 Getting there....

You are thinking of a IC as being a fixed thing like a package.     A SET of ICs is such a thing -- but ICs are  whatever the Author intended the "total user experience',  if you will. 

The parts of an  iCs do NOT have to all come from one author -- (in fact they almost never do -- except in the case of something like the EasyONe communicator that erases all trace of the OS's UI when it launches.  The UI is intended by the app author but the app author incorporates the OS UI for example into the IC that their app presents or is used in. 

Perhaps the term "user experience" needs to be brought in here - not sure.   have to think about it.

More comments below with this as an intro

G


On Jun 19, 2012, at 2:29 AM, Peter Korn wrote:

> 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. (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. (Level AA)"
> 
> So a "modal dialog box" is an IC - perhaps all of the time (or nearly all of the time?). 

Yes if it truly locks out all other interface when it is open.    To be absolutely modal it should block all view of the app and be immovable  - but this is rarely true.  Usually it allows all the info in the background to still be visible to the person who can see.    Can screen readers still access this information? 

> And sometimes a single application with multiple windows is multiple ICs,

Not because of the multiple windows per se.    The IC changes as that app changes what is available to the user to view, navigate and operate.   Those are the multiple ICs whether they involve windows or not. 

> and other times a single application with multiple windows is a single IC. 

Yes - see above.  If the person can move between windows without activating anything then  they are all part of the IC.   As a programmer, in Windows you know that what an ordinary person would refer to as a window was in fact often made up of may windows that were just visually glued together.  And sometimes a singe window is is pieces or can be torn to pieces (pallets) by a user and still operate largely the same. 

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

No.  In fact this is almost never true.   ICs themselves are rarely from a single author -- though a single author...org  may / usually does/ define them or essentially most of the experience (the lower layers may change some).   (the app running on an OS)

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

No.    do you see now how they are not? 

> 
> 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):

yes - this looks ike you are changing the SC which may confuse people.   
> "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. (Level AA)"

I would do it like this

So subsituting a specific example into the SC we get 
> "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. (Level AA)"

But of course that is now what the IC means

first of all --when you have a truly modal dialog box active you cannot choose between it and anything.  it is the whole world at that point and none of the rest of the app is visible.   But for non-modal dialogs (or partially) they should be able to be identified in the pallet of UI components on the page.   I like your note about the title no needing to be visible by the way.  good point. 

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

See above. 


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

???

it certainly is.    Why would you think it was not?    

The WCAG was purposely written to only say WHAT the effect should be not HOW it should be done.   Many of the SC are expected to be done by User agents including AT today. 


>   So these multiple ways must be directly provided by the software, or the software fails the SC.

?????  Don't know where this comes from. 

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

OK.

I have a word processing app.   I present many different ICs to the user at different times when they are using my program.  sometimes the IC I present is all locked up in a modal dialog box where I dim out the background and force them to live in a little box til they are done.   Most of the time though the IC I give them has a menubar and ribbon bar (multiple  usually) and sometime floating pallets. 

These ICs represent a set of ICs that a person encounters when using my program.

NOW = I must (in my app, or relying on features in the OS, or using AT if my software is supported by AT (works with AT) ) :

 - make sure that users can skip over those menus and ribbons and floating pallets and does not need to tab through all of the controls of each of them before I get to to the content they are writing each time the IC changes. 

- 



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

don't follow 

>   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 they say the work together
if the app says it is compatible with windows OS then one can assume that the app is intended to work with the OS UI elements that are used with the APP  (for example print dialog boxes) 

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

No.  you are an individual but you are also part of your family.   You don't stop being one when you are also part of another.

the apps are ICs.   But if they are INTENDED (see the box or documentation or advertising for intent) to work together as one cohesive IC then they are also (when this is done) part of that IC. 

>   And your final two sentences above are also not at all testable. 

review them again now that you have more information / context

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

Grin.  No not like that.  more like you being a person and a member of your family.   ICs nest. 

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

When software is sold separately - the authors are ONLY responsible for what they sell.  If they sell a package that is sold as working together -- they are responsible for them working together as one UI then they are responsible for the ICs of that UI.

IF they say it works on Windows then they are responsible for the UI that is the combination of their package and the parts of the windows UI that they incorporate into their app 

they are NOT responsible for the user pairing their app with another and using them together.  (unless the RFP specifically said that must be true -- in which case the "author" (the system integrator) is warranting that these all work together as one UI. 

I think it is as clear as any other part of 508 where software is integrated. 





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

YEs that was a great insight by you .  Thank you for noticing that.   I added that specifically to a revised version of a Trace submission. 


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

No we don't.  but if they are relying on the UI of the player - then we do.

and we do also kind of in another way -- via the accessibility support bit.    If you create content that has captions, but not in a way that any player can display,  (or if there IS no player that displays captions for the technology you choose)  then you fail.   The goal is not to have captions - but to have captions the user can view. 

so yes - the author is responsible for a) ensuring their content works with players for access features and b) that players are available that support the access in their content (accessibility support) 

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

they are both equally responsible

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

yep.  and that is the way it should be  (and is if we didn’t/ don't make a mistake somewhere) 
> 
> 
>>> 
>>> <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".



OK thanks 




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

Mapping is matching one thing to another.  Like one set of rules to another set of rules.   

I know the term keeps getting used and I always comment that it doesn’t make sense to use it here.     Map wcag to 508 - yes. or map 508 to m376 yes.  
but we are not mapping


Our charge is to say what the WCAG SC would mean when applied to ICT.  it is not to say that they should or shouldn’t.    that is out of scope. 
we also cannot add exceptions.  we can only point out what they would mean or how the words can be understood in a broader context.

if by mapping you mean connecting -- I sort of see that.   But it can't mean disconnecting or mapping to a bit bucket.   That isn't in our scope.    

So far I haven't see an problem.  But we haven't gotten to the end -- and I am learning as we explore this along with everyone else. 

have to run

g



> 
> Make sense now?
> 
> 
> Regards,
> 
> Peter
> 
> -- 
> <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