Re: Interaction Context

Hi Allen,

That's not quite what I'm saying...  Use of AT could be part of 
satisfying a variety of things in 508, but I don't believe they can ever 
be part of satisfying a WCAG SC.  And therefore, we need to be able to 
support "multiple ways" (if we in fact bring that over to non-web ICT) 
directly, without one of the multiple being that an AT is doing it for 
the ICT (or in conjunction with the ICT).

And I have asked Gregg to describe at least two ways in which a software 
application, without using external AT, might allow a user to navigate 
to a dialog box among a collection of windows.  ALT-TAB is one way.  
What is the other?


Peter


On 6/19/2012 9:19 AM, Hoffman, Allen wrote:
>
> I follow Peter's description in this thread but not Gregg's.
>
> If I read Peter's correctly:
>
> Use of AT to get at something could serve as a sufficient technique 
> for the multiple ways SC, but currently WCAG does not offer this as a 
> solution.
>
> Gregg wrote:
>
> Complying, however,  isn't any more difficult than ensuring that all 
> these combinations work or that an API can work.   For example, how do 
> you ensure you can jump over the ribbons when there are so many 
> different ICs that would include the ribbon.
>
> You just make ribbons be implemented in a standard way that allows you 
> to treat is as an object you can jump over or past.    Then there can 
> be any number of different ribbons with different content and they 
> will all comply -- not because you checked each one - one-by-one  -but 
> because that is they was they are all implemented.
>
> Huh?
>
> I'm not following along here.
>
> Regarding interaction context, the phrase "active focus" or "active 
> interface element" comes to mind when I think outside a Web 
> environment.I don't extend such context to things a user isn't working 
> with, but may work with.For example, while there are ribbons which I 
> can navigate in various sequences, they don't imply interdependent to 
> me, but maybe if they are viewed from a touchscreen perspective they 
> do?I really want to stress my hope that we can provide readers some 
> clearer sense of why a WCAG guideline applies outside Web, where 
> differences are when doing so, and when possible, what kinds of things 
> are known to have high degree of success in meeting the guideline.I 
> know, some of this is beyond the intended scoping, but is what is 
> needed never the less.
>
> Also, just a thought, maybe we should just toss out voice interactive 
> systems as covered under this expanded scoping as they present so many 
> conceptual challenges for applicability.I think clear guidelines for 
> something like interactive natural language human interfaces is 
> needed, rather than attempting to imply graphical Web interface 
> guidelines to such a radically divergent interface.I question validity 
> of such applicability, and I'm one who loves such interfaces.
>
> e
>
> *From:*Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
> *Sent:* Tuesday, June 19, 2012 11:52 AM
> *To:* Peter Korn
> *Cc:* Hoffman, Allen; public-wcag2ict-tf@w3.org
> *Subject:* Re: Interaction Context
>
> I understand what you mean.
>
> But that is the nature of software.  That is the way it is designed.
>
> Don't see as we have any choice.
>
>  Complying, however,  isn't any more difficult than ensuring that all 
> these combinations work or that an API can work.   For example, how do 
> you ensure you can jump over the ribbons when there are so many 
> different ICs that would include the ribbon.
>
> You just make ribbons be implemented in a standard way that allows you 
> to treat is as an object you can jump over or past.    Then there can 
> be any number of different ribbons with different content and they 
> will all comply -- not because you checked each one - one-by-one  -but 
> because that is they was they are all implemented.
>
> etc.
>
> Same way APIs can work - even though you can't test them with every 
> possible part of every program in every possible state and data etc.
>
> /Gregg/
>
> --------------------------------------------------------
> Gregg Vanderheiden Ph.D.
> Director Trace R&D Center
> Professor Industrial & Systems Engineering
> and Biomedical Engineering
> University of Wisconsin-Madison
>
>
> Co-Director, Raising the Floor - International
> and the Global Public Inclusive Infrastructure Project
> http://Raisingthefloor.org   --- http://GPII.net
>
>
>
> On Jun 19, 2012, at 5:22 PM, Peter Korn wrote:
>
>
>
> Allen,
>
> My point is that WCAG doesn't say "you may meet SC x through the use 
> of AT", whereas 508 does (and M376 may).  Therefore if we have a 
> requirement that something can be done "in multiple ways", and the 
> only way to get a 2nd (or 3rd) way (to reach "multiple") is by using 
> AT, then in wouldn't actually be possible for the ICT to meet the 
> provision (on its own).
>
> Make sense?
>
> Peter
>
> On 6/19/2012 5:27 AM, Hoffman, Allen wrote:
>
> Peter you wrote:
>
> ...
>
> 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.
> ...
>
> Can you elaborate for me?
>
>
>
> *From:*Peter Korn [mailto:peter.korn@oracle.com]
> *Sent:* Monday, June 18, 2012 8:30 PM
> *To:* Gregg Vanderheiden
> *Cc:* public-wcag2ict-tf@w3.org <mailto:public-wcag2ict-tf@w3.org>
> *Subject:* Re: Interaction Context
>
> 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
>
> -- 
> <Mail Attachment.gif> <http://www.oracle.com/>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 <tel:+1%20650%205069522>
> 500 Oracle Parkway | Redwood City, CA 94065
> <Mail Attachment.gif> <http://www.oracle.com/commitment>Oracle is 
> committed to developing practices and products that help protect the 
> environment
>
> -- 
> <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 506 9522 <tel:+1%20650%20506%209522>
Oracle Corporate Architecture Group
500 Oracle Parkway | Redwood City, CA 94065
------------------------------------------------------------------------
Note: @sun.com e-mail addresses will shortly no longer function; be sure 
to use: peter.korn@oracle.com to reach me
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment