Re: Interaction Context

Hi peter

good idea

and NICE POST

If we go with the definition I just posted  (and added to the end of this post) then the answers to your questions are easy (I think).  
And the concerns you have below are resolved as well.  

Give it a read and see what you think

first - here is what I proposed: 

=================
FROM THE OTHER EMAIL  (with front end filled in and wording cleaned up) and using "same author, group or organization"


PROPOSAL

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above) if the term Web Page is replaced by the term  "interaction context"  or by the definition  "the current set of input and output elements available to the user to see, hear, feel or act on, --  where the set is limited to those elements a) intended by the author (person, group or organization) to be available to the user at the same time, and b) that are present without the user acting other than simply navigatiing among the elements".


Set of Web page
s currently defined in WCAG as 

Set of Web Pages
collection of Web pages that share a common purpose and that are created by the same author, group or organization
Note:  Different language versions would be considered different sets of Web pages. 

and so "set of web pages" becomes "set of interaction contexts" quite logically  where it is defined (by substituting "interaction context" where you see "web page")

Set of Interaction Contexts
collection of  interaction contexts that share a common purpose and that are created by the same author, group or organization
Note: Different language versions would be considered different sets of interaction contexts.





Now here are your questions. 

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)
All windows  (with or without a title) from a single author,  that a person can move about in without acting on anything ,along with anything else outside of that window 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) - most commonly the top-most or "current" window - along with anything else outside of that window that belongs to the same application and a user can directly interact (e.g. the menu bar on the top of the screen of a Macintosh) 

What ISN'T an IC

(these are all part of a context of interaction
A menu bar, a menu
A toolbar
A pane of a window (e.g. in a split view or a side-by-side compare of two documents)
A list box
A single pane in a tab panel
The entire collection of tabs in a tab panel
Also NOT and IC

(although parts of them may be part of other contexts if the authors designed their products to work with them.  An argument could be made that all of the standard parts of the taskbar/dock would be part of the context because the author intended the app to work with the standard doc features (in fact it probably is part of the testing.)
The Windows Explorer Taskbar.  Is this like the menu bar of the Macintosh UI - outside of the (Folder / drive) Windows but part of the Windows Explorer process and therefore a constant adjunct to the Explorer windows?  Or are those OS-level toolbars their own "interaction contexts" - since they aren't really tied to the Windows and in fact are nearly always active nearly all the time?  
The Macintosh Dock.  Same comment as Windows Taskbar above...


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.

You wrote:
> "1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)"
> 
> Since we care about audio accessibility issues all the time, we need to make sure that everything within the WIMP GUI is contained within an "interaction context".  So we therefore must include "the desktop" as an additional case (not all UIs place the desktop formally in its own "window").  This concern likewise appears for 2.1.2 No Keyboard Trap (we don't want a focus keyboard trap to be OK on the desktop), 2.2.2 Pause, Stop Hide, etc. etc.
The desktop is only part of the interaction context if the author intended it to be.   This is usually true.  But for Easy One communicator for example a modal state is created where none of the desktop or even the task bard is visible or accessible.  So they would NOT be part of the interaction context. 

Also, for this SC, the need could be met by the app or the OS as long as the OS is maintained as part of the interaction Context. 



You wrote:
> "2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)"
> 
> Here is the first place where we encounter the plural.  We also encounter a situation where what is stated in the Intent for the SC isn't well met by a simple substitution.  So here is a provision where I think we greatly benefit by moving away from a strict language substitution, and treat it differently (as I have tried to do with Proposal #3 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/241-bypass-blocks and which Gregg has further polished and shortened).
This actually should be a SET OF WEB PAGES.  

I think we can get the WCAG to agree to that.  Then it falls back into the "same author, group or organization".  Then I think the substitution works charmingly.   There are many contexts created by all the combinations of components and features -- but if the same block keeps appearing there should be a way to skip over it.  and there is for almost all software that is software program like.   Software that is document like though.... it may not be automatic - though it should too if the page is well structured in a standard way. 





You wrote:
> "2.4.2 Page Titled: Web pages have titles that describe topic or purpose. (Level A)"
> 
> Do we feel that in fact a title is truly needed for everything that is an "interaction context"?
Yes definitely


>   Does the main Windows Explorer Taskbar - the one that contains the "Start menu", need a title? 
I don't think it is an context by itself


> What about modal dialogs that don't have a title bar - would they all be non-compliant? 
See comment about "first text".   That can act as the descriptive title I believe.  serves the same purpose thought not as short. 


> Or is Proposal #2 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/242-page-titled enough of an "out" - that the "first words they contain" be the title. 
That is the idea - that since it serves the same purpose....  In fact the reason the dialogs DON'T have a title is because they the sentence functions as on.   How many dialogs do you find that have no title and no first text that explains what they are????

> And if we go with that proposal, then does the word "Start" in the Windows Explorer Taskbar satisfy this? 
the explorer task bar is not an interaction context by itself


> Does the Macintosh Dock fail to meet 2.4.2 because there is no text in the Dock? 
Ditto

> If so, do we feel that failing the Dock is in keeping with the Intent of 2.4.2? 
N/A
> The Dock, after all, isn't filled with content and the context of the Dock makes it's meaning clear...  Also, there is position information in the GUI that is very different from the web - where each web page appears in the same place in the GUI - within the content region of your browser window... 
N/A  it is not an interaction context.  it is only part of one.   Actually part of many but the whole desktop would be one context.  And it is named I believe it is announced whenever you torn focus to it.   
> 
> 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. 



You wrote:
> "2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)"
> 
> Again I think we can't go the substitution route here, as much of the desktop GUI is reachable outside of a simple focus order (e.g. the menu bar is outside of the focus order; you only read it by going directly to it - from anywhere else - and not by TABbing around the UI until you reach it in a specific place in the order). 
I don't see how you feel it doesn’t fit.  First, mostly it is irrelevant because there is nothing linear about accessing all of this.  The context can be navigated in many different ways and they all have meaning.  So a linear presentation is not needed.   You DO have to have some means of linearly going through all of the items on the desktop so you don't miss any.  But there are many ways to linearly go through them and any would meet the SC.   ONLY when the meaning or function must be in a linear fashion - is it required that any  linear means of navigating is required. 
> Alternately... do we take the out that the WIMP GUI isn't something "designed to be navigated sequentially"
that isn't an out.  That is a fact.   now some PARTS may need to be navigated linearly to make sense  (e.g. a help dialog with steps in it) and that would have to be navigable linearly. 
> ?  [I must say, the Mathematician in me recoils at that notion, given a deep proof in number theory and topology that any finite field can be ordered sequentially - as well as a number of infinite ones]. 
as it should.   And this SC makes no such requirement. 
> Of course, some AT (e.g. outSPOKEN for Macintosh, VoiceOver for iOS) impose their own sequential navigation whether one was designed or not, which shows the intellectual limitations of that "out" [and also provide a demonstration of the mathematical proof within the GUI]
All that the SC requires is that SOME linear order be provided (that is meaningful) - and that is only required if the meaning or function requires it.    This SC is functioning exactly as it is intended.   It is only when more is read into it than is there - that I see any problem.  If we return to its intent and its wording -- the path looks clear.    




You wrote:
> "2.4.5 Multiple Ways: More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. (Level AA)"
> 
> This is the second place where we get the plural, with I think a similar problem (as with 2.4.1).  What is the boundaries of a "set of interaction contexts" - when are they in the same set and when not?  Since the Intent spells out 
I don't see any plural.  "Set of web pages" is singular and is the defined term.   The set of interaction contexts is clearly defined in the definition of "set of web pages"  (see previous note)

I would again return to both
a) the previous email (which I will paste below for convenience) and
b) the wording of the success criterion 


Now I may have missed something -- but this all seems to fall into place rather nicely.    Better than with out other definitions.   I think.

take another look and let me know what you see. 


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 18, 2012, at 10:37 PM, Peter Korn wrote:

> Hi Gregg, Andi, all,
> 
> Early in our work (and in Oracle's response to the ANPRM), I've said that that I don't think we can find a single concept/term that can substitute for "web page" (and "web pages") everywhere.  In one of our first meetings I suggested that we revisit the term question after we've walked through all of the provisions, as we will then see what might make sense.  
> 
> BUT... at the pace we are going, if we don't try to find ways of accelerating  our work we may not finish our first draft on time (already in doubt even with significant acceleration).  And... perhaps even if we can't find a single term that works everywhere, perhaps it works in enough places as to be useful, and we simply have exceptions (like irregular verbs) where we have a longer or otherwise different "applying" text for the SC.
> 
> 
> While it is important to develop language that isn't tied to the GUI, I think it is very instructive to look closely at the WIMP GUI (WIMP = WIndows Mouse Pointer).  Because if we can't get something that works there, I doubt we can get something that works more generally.
> 
> We've had various proposals for language - "interaction context", "context of interaction", and the more GUI-specific "active window" / "active viewport".  I propose that we see if we can agree on an a list of those things in the GUI what would be (and what would NOT be) an "interaction context".  THEN to see whether that list of things can reasonably stand in for "web page" (and "set of web pages") in (enough of) the various provisions that use that term.  If that works, we might then see if we can generalize this beyond the WIMP GUI.
> 
> The sense that I get of what the "core" of this idea is of these various term/definition proposals, is that it is that portion of the UI that a user can interact with at this time - with perhaps an artificial exclusion of other programs that can also be interacted with directly (e.g. a modal dialog box is an interaction context, though the user can directly and immediately interact with a different application not connected with that modal dialog - or with aspects of the OS - without thereby pulling in the entire OS into the notion of "interaction context").
> 
> OK, so here's a brainstorm proposed enumeration of what IS an interaction context within the WIMP GUI:
> A window, or dialog box (with or without a title) - most commonly the top-most or "current" window - along with anything else outside of that window that belongs to the same application and a user can directly interact (e.g. the menu bar on the top of the screen of a Macintosh)
> And things that are NOT an interaction context within the WIMP GUI:
> A menu bar, a menu
> A toolbar
> A pane of a window (e.g. in a split view or a side-by-side compare of two documents)
> A list box
> A single pane in a tab panel
> The entire collection of tabs in a tab panel
> And here are things that I'm really not sure about:
> The Windows Explorer Taskbar.  Is this like the menu bar of the Macintosh UI - outside of the (Folder / drive) Windows but part of the Windows Explorer process and therefore a constant adjunct to the Explorer windows?  Or are those OS-level toolbars their own "interaction contexts" - since they aren't really tied to the Windows and in fact are nearly always active nearly all the time?  
> The Macintosh Dock.  Same comment as Windows Taskbar above...
> [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?]
> 
> OK, so how would this division of what is/is not an "interaction context" work as a "web page" and "set of web pages" substitution for various SC?
> "1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)"
> 
> Since we care about audio accessibility issues all the time, we need to make sure that everything within the WIMP GUI is contained within an "interaction context".  So we therefore must include "the desktop" as an additional case (not all UIs place the desktop formally in its own "window").  This concern likewise appears for 2.1.2 No Keyboard Trap (we don't want a focus keyboard trap to be OK on the desktop), 2.2.2 Pause, Stop Hide, etc. etc.
> 
> "2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)"
> 
> Here is the first place where we encounter the plural.  We also encounter a situation where what is stated in the Intent for the SC isn't well met by a simple substitution.  So here is a provision where I think we greatly benefit by moving away from a strict language substitution, and treat it differently (as I have tried to do with Proposal #3 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/241-bypass-blocks and which Gregg has further polished and shortened).
> 
> "2.4.2 Page Titled: Web pages have titles that describe topic or purpose. (Level A)"
> 
> Do we feel that in fact a title is truly needed for everything that is an "interaction context"?  Does the main Windows Explorer Taskbar - the one that contains the "Start menu", need a title?  What about modal dialogs that don't have a title bar - would they all be non-compliant?  Or is Proposal #2 at https://sites.google.com/site/wcag2ict/home/2-operable/24-provide-ways-to-help-users-navigate-find-content-and-determine-where-they-are/242-page-titled enough of an "out" - that the "first words they contain" be the title.  And if we go with that proposal, then does the word "Start" in the Windows Explorer Taskbar satisfy this?  Does the Macintosh Dock fail to meet 2.4.2 because there is no text in the Dock?  If so, do we feel that failing the Dock is in keeping with the Intent of 2.4.2?  The Dock, after all, isn't filled with content and the context of the Dock makes it's meaning clear...  Also, there is position information in the GUI that is very different from the web - where each web page appears in the same place in the GUI - within the content region of your browser window... 
> 
> 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.
> 
> "2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)"
> 
> Again I think we can't go the substitution route here, as much of the desktop GUI is reachable outside of a simple focus order (e.g. the menu bar is outside of the focus order; you only read it by going directly to it - from anywhere else - and not by TABbing around the UI until you reach it in a specific place in the order).  Alternately... do we take the out that the WIMP GUI isn't something "designed to be navigated sequentially"?  [I must say, the Mathematician in me recoils at that notion, given a deep proof in number theory and topology that any finite field can be ordered sequentially - as well as a number of infinite ones].  Of course, some AT (e.g. outSPOKEN for Macintosh, VoiceOver for iOS) impose their own sequential navigation whether one was designed or not, which shows the intellectual limitations of that "out" [and also provide a demonstration of the mathematical proof within the GUI]
> 
> "2.4.5 Multiple Ways: More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. (Level AA)"
> 
> This is the second place where we get the plural, with I think a similar problem (as with 2.4.1).  What is the boundaries of a "set of interaction contexts" - when are they in the same set and when not?  Since the Intent spells out 
> I'm going to stop here; I don't want this e-mail to become an SC-by-SC review - we already have that process.
> But at least for me, going this far in the process shows that:  (a) it is possible to have a term that has a consistent and useful meaning within the WIMP GUI, and I suspect within software UIs generally; (b) such a term can work as an effective stand-in for "web page" in enough provisions as to be useful; (c) we have a bunch of "irregular verbs" that we will simply have to deal with on their own and not try to force a "web page" language       substitution on them; and finally (d) anything with the plural "web pages" is a strong candidate for being an irregular verb.
> 
> Peter
> 
> On 6/18/2012 12:27 PM, Gregg Vanderheiden wrote:
>> 
>> How about the following as something to consider - work from
>> 
>> Two words or a LOT of words.   But someone said (Bruce I think) that substituted many words for a few to get transparency.  This is many more but... 
>> 
>> give it a look
>> give it a think
>> 
>> comments welcome
>> 
>> 
>> 
>> PROPOSAL
>> 
>> 
>> blah blah ......replacing the term Web Page by the term  "interaction context"  or by the definition  "the current set of input and output elements, intended by an author to be available at one time to the user, for the user to see, hear, feel or act on, where the set is limited to those elements that are present if the user does not act other than simple navigation among the elements".
>> 
>> 
>> Set of Web pages currently defined in WCAG as 
>> 
>> Set of Web Pages
>> collection of Web pages that share a common purpose and that are created by the same author, group or organization
>> Note:  Different language versions would be considered different sets of Web pages. 
>> 
>> and it becomes quite logically 
>> 
>> Set of Interaction Contexts
>> collection of interaction contexts that share a common purpose and that are created by the same author, group or organization
>> Note:  Different language versions would be considered different sets of interaction contexts.
>> 
>> 
>> The one problem I did see was that you can navigate among a set of open windows from many different applications.  
>> So that is why the "author intent" clause is there above -- since authors have no control over what all windows you have open.  and we need to  keep the user from navigating among contexts and have the grand sum of all open windows constitute the context.
>> 
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> <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