Re: Interaction Context

Gregg,

If I have a window open, but it isn't the front most window, what are 
two ways I can navigate to it in Windows?  I can use ALT-TAB to get to 
it, that's one.  Or I can launch my screen reader and get a list of open 
windows and navigate to it that way.  BUT... that requires that I have a 
specific 3rd party AT installed in order to do it - which I believe 
means that is not a valid way to meet the SC (which is what I meant when 
I said that "AT can't be used to meet an SC").


Peter

On 6/19/2012 1:39 PM, Gregg Vanderheiden wrote:
> Peter
> Something like 2/5th of WCAG is about AT being used to meet the SC.
>
> What do you mean WCAG doesn’t allow AT to be used to meet the SC?  I'm 
> not  sure what you are getting at.
>
>
> RE two ways to navigate to a dialog box ---  do you mean two ways to 
> invoke it?
> One would be via help text I would image.   A menu is another way.   
> Button on tool bars can invoke them.
>
> Got particular menu in mind?   (if it is part of a process it is 
> excepted by the way)
>
>
>
> /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 8:33 PM, Peter Korn wrote:
>
>> 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://Raisingthefloor.org/>   --- 
>>> http://GPII.net <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_sig_logo.gif> <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-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

Received on Tuesday, 19 June 2012 21:31:23 UTC