Re: Interaction Context

Gregg,

If what an IC is isn't clearly defined - but is a very fluid thing that 
can in fact change dynamically - then we will have a major compliance 
problem.  Therefore I think we need a clear, concrete, objective 
definition - that doesn't change with author intent.


Peter

On 6/18/2012 11:15 PM, Gregg Vanderheiden wrote:
>
>
>  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
>>>>     <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?).
>
> 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
>>     <http://www.w3.org/TR/WCAG/#processdef>. (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
>>     <http://www.w3.org/TR/WCAG/#processdef>. (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> <http://www.oracle.com/>
>> Peter Korn | Accessibility Principal
>> Phone: +1 650 5069522 <tel:+1%20650%205069522>
>> 500 Oracle Parkway | Redwood City, CA 94065
>> <green-for-email-sig_0.gif> <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