W3C home > Mailing lists > Public > public-wcag2ict-tf@w3.org > June 2012

RE: Interaction Context

From: Crowell, Pierce <Pierce.Crowell@ssa.gov>
Date: Mon, 18 Jun 2012 18:59:28 -0400
To: "'public-wcag2ict-tf@w3.org'" <public-wcag2ict-tf@w3.org>
Message-ID: <87CFEBE3A9AAB941B8EECB87EBC4CC0D2DB2161A87@HQ-MB-06.ba.ad.ssa.gov>
Ahhhh, correctness reels its voluminous head...

Peter, would an analog approach help?

I see too many exceptions to list, I know that the correctness gaps far outweigh our desire to present definitive, determinable, and testable guidance, and think it is far more desirable, in this specific instance, to give a good idea of how to apply the term to most instances and then trust the reader to apply it to their instance.


From: Peter Korn [mailto:peter.korn@oracle.com]
Sent: Monday, June 18, 2012 6:39 PM
To: Gregg Vanderheiden
Cc: public-wcag2ict-tf@w3.org
Subject: Re: Interaction Context


Thanks for your thoughts.  In part because of the importance of objective testability, I'm going to push a little bit harder than may wind up being necessary on terms and how well they work.  Rather that then find out in practice there is ambiguity that bites us in implementation...

Also to keep this growing conversation thread readable/managable, I'm going to snip liberally.

Finally, I'd like to stay a little while longer on the WIMP GUI before getting to deeply into your proposed more general proposed language.


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)

I'm troubled by your notion of "author".  What is "author"?  How do we determine whether the author is the same or not?  Running in the same process is much more precise, technical, and measurable - though it may not quite match what the user is seeing (and of course we have some situations in which multiple processes are contributing to visually rendering the contents of a single window - e.g. Java applets within a web browser content region - though on second though, a Java applet is perhaps its own "interaction context"?).

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

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

Cool, we are agreed here.

Though... as I think more about it, we need to perhaps explicit include as NOT an IC floating palette windows (which are covered by your expanded 2nd and 3rd "what is an IC" above).

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

If these aren't their own IC, then whose IC do they belong to?  Because the Windows Explorer Taskbar is clearly running in the Windows Explorer process, that feels like a fairly natural fit to me (to put it into that IC).  But unless I'm mistaken, the Finder application on Macintosh is different from the Dock application.  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.

So, things that are "desktop-wide" like this I think aren't so clearly in one IC or another, or should perhaps be in their own IC.  Frankly, if it wasn't for 2.4.2 and a desire to avoid saying that the Macintosh Dock might fail 2.4.2 in certain formulations, I would more naturally say that something like the Dock is it's own IC.

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

You wrote:

 *   "1.4.2 Audio Control: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism<http://www.w3.org/TR/WCAG/#mechanismdef> 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.

My sense is that the desktop is part of the software UI of the OS, and so 1.4.2 applies to the desktop as a software application, distinct from any non-desktop/folder windows open from other applications on the desktop.  Of course things get tricky with various desktop hooks/plugins (e.g. adding to the context menu when right-clicking on certain file types which might add "7zip this file", or "check in this source file to the SCCS system".  These are specific and somewhat prosaic examples multiple processes/authors (such as I noted with Java applets, Flash content in web pages, etc.).

You wrote:

 *   "2.4.1 Bypass Blocks: A mechanism<http://www.w3.org/TR/WCAG/#mechanismdef> is available to bypass blocks of content that are repeated on multiple Web pages<http://www.w3.org/TR/WCAG/#webpagedef>. (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 may be charmed by the substitution, but I think it misses what is key to the Intent of 2.4.1, which is why I proposed language that goes beyond a strict substitution (which, again, you further polished).

Separately, if we go with your bullet #3 of what is a single IC (or at least my reading of it) -> that the 4 different OpenOffice windows I have open constitute a single IC, then how does "repeated on multiple ICs" have meaning?  If the "multiple ICs" all have to be from the same author (since it seems out of scope if nothing else to require different authors to have to work together to share the same blocks of content for bypassing).

So... I remain uncharmed by any "web page" / "multiple web pages" (or "set of web pages") substitution for this SC.  I continue to believe this is an irregular verb that needs its own treatment.

You wrote:

 *   "2.4.2 Page Titled: Web pages<http://www.w3.org/TR/WCAG/#webpagedef> 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

I disagree.  From Intent:
The intent of this Success Criterion is to help users find content and orient themselves within it by ensuring that each Web page has a descriptive title. Titles identify the current location without requiring users to read or interpret page content. When titles appear in site maps or lists of search results, users can more quickly identify the content they need. User agents make the title of the page easily available to the user for identifying the page. For instance, a user agent may display the page title in the window title bar or as the name of the tab containing the page.
Titles of modal dialogs don't appear in any search results lists (nor a Taskbar or Dock, though you would say those are N/A).  There is no software user agent that might make such text available.  Many modal dialogs have little text, so giving them the first sentence to read to avoid having to read the 1-3 sentences that are in the dialog is of de minimus value.  So we fall back to the first sentence of intent - to help users find content & orient themselves.  When a non-titled IC is clear from being a fixture of the UI and how it is laid out, etc., I think that a title isn't necessary.  And even if you claim the Dock isn't its own IC, you can perhaps imagine something rather like it that might be.


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

You wrote:

 *   "2.4.3 Focus Order: If a Web page<http://www.w3.org/TR/WCAG/#webpagedef> can be navigated sequentially<http://www.w3.org/TR/WCAG/#nav-seqdef> 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.

Sorry, I glossed over the latter part of the sentence, specifically "and the navigation sequences affect meaning or operation".

You've convinced me that we don't need to treat this specially.


You wrote:

 *   "2.4.5 Multiple Ways: More than one way is available to locate a Web page<http://www.w3.org/TR/WCAG/#webpagedef> within a set of Web pages<http://www.w3.org/TR/WCAG/#set-of-web-pagesdef> except where the Web Page is the result of, or a step in, a process<http://www.w3.org/TR/WCAG/#processdef>. (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)

The plural is that the SC is talking about not just a single IC, but multiple ICs (even though they are part of a "singular" set).  OK, let's do the substitution (in bold italics below):
"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)"
How exactly is this accomplished?  ALT-TAB (or in some desktops/circumstances, CTRL-TAB which restricts cycling of non-modal windows to only those of the same application).  And...  that's generally it.  So every WIMP GUI would fail 2.4.5?  Or does Macintosh Exposé / Mission Control constitute a 2nd one (as well as the similar feature in GNOME Shell), so it is only Windows & most Linux desktops that would fail 2.4.5?  And violating my earlier scoping for this conversation, what about tablet and similar UIs (e.g. iOS) - what are the multiple ways (besides swiping through them) to locate all of the screens in an iOS application?

I think Loïc Martínez gets this one right, where he writes in Proposal #2 (my emphasis added) "This success criterion does not apply to software user interfaces, as it would require multiple ways of reaching any interaction context (window, dialog...) and that is not always feasible nor desirable."

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.


Peter Korn | Accessibility Principal
Phone: +1 650 5069522<tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
[cid:image002.gif@01CD4D83.1FFB7480]<http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment

(image/gif attachment: image001.gif)

(image/gif attachment: image002.gif)

Received on Monday, 18 June 2012 23:00:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:43 UTC