Re: Proposed deletion of checkpoint on spawning windows

Strange that we should turn up on opposite sides of the same argument, as
compared with the parse tree in HTML.

The basic requirement is that the user must be able to maintain control of
the composite process.  Process complexity in the context of an ephemeral,
narrowband display interface like audio is a serious risk factor, and
mechanisms to manage it must be included in the global principles of
operation.

For audio access, the collection of active windows must be something that
the user can recall.  In GUI mode the user only has to be able to recognize
them.  This is the difference.  It is a canard of human factors that the
GUI gives the user access to far more commands because the user doesn't
have to recall them, only recognize them.  People's recognition memory far
exceeds their recall memory.

This means that the typical process structure in a GUI session is fat and
sloppy as compared to anything that can be trusted to be usable in
audio-only mode.  Confirm and prune are necessary capabilities.

Consider simple conflicts like the screen reader synthetic voice
conflicting with audio in an 'embed' tag.  Only the user knows that the
screen reader is talking; the web browser doesn't.  Same for the SMIL
player.  The SMIL player may expose an HTML object through a web player,
but the SMIL player won't know that when that web player hits the operating
system, it meets a screen reader, and the screen reader starts talking at
the user.  The user needs the capability to retain effective control of the
process set, because in AT scenarios there will be processes going on that
the mass market products and media authors didn't anticipate or understand.
And modes of interference between cognitive processes that you and I don't
understand.

Consider the example of the auto-submit-on-enter for some forms.  This is a
sufficiently severe hazard that the user should be able to require
protection from it
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999JulSep/0143.html>.

Moving the user around in the interaction world is a transaction of
severity comparable to submitting a form.

Opening a new window moves where the user is in the interaction world.  It
is not enough to ensure that the user does this knowingly, it is necessary
to ensure that the user does this willingly.  Before accepting a new base
of operation in their cognitive space, the user may require a review of
what all is still there and how the new interaction locus relates to the
rest of what is there.  As I have said ad_nauseam on this thread, because
the complexity tolerance in some PWD interaction environments is lower than
the run of the mill, systematic means for user supervision of process
sprawl to manage complexity must be incorporated throughout as built-in
principles of operation.

Al

At 01:09 PM 8/25/99 -0400, Charles McCathieNevile wrote:
>I think this is not as bad as unacceptable. What we want to achieve is the
>continued orientationof the user. One of the suggestions Hakon Lie made for
>dealing with multiple windows is to open new windows which then inheirt the
>history of their parent. Opera behaves more like a traditional window-based

>application, which keeps track of how many windows it has opened and what
>they are, than explorer or netscape, which abandon responsibility for this in
>favour of the Operating System.
>
>It seems to me that Hakon's approach would satisfy the requirements, so long
>as it was clear that the user knew they were being transferred to a new
>window. After all, this is how prompting and alerts often happen, and that
>does not, of itself, cause a problem (there are good an bad
>implementations...)
>
>Charles McCN
>
>On Wed, 25 Aug 1999, Al Gilman wrote:
>
>  The proposed change is unacceptable.
>  
>  It is not enough, in general to only inform the user.  The way the
>  currently active set of processes grows in a GUI environment is not
>  suitable for an eyes-free enviroment where the memory of the user, and not
>  the imagery of the screen, retains the overview of "what is there."
>  Therefore stricter user supervision of the proliferation of concurrent
>  entries in "what is there" is required in the eyes-free environment than in
>  a GUI environment.
>  
>  Simply turning off the opening of new windows is too severe, too, as you
>  have noted.  But any action that does not come with a guarantee that use of
>  the browser "back" command will accomplish an "undo" of that action is an
>  action of a hightened severity class and the user should be able to set "on
>  confirm only" or "disallow" as policy rules for that class. 
>  
>  The whole issue of concurrent process management is a can of worms that we
>  have not gotten to the bottom of.  Last I knew there was not a consistent
>  philosophy between DHTML and SMIL.  But a laissez-faire "fire and forget"
>  policy where a document can cite a URI in a link, and when the user
>  activates the link the author's recovered content of the new document
>  orders the initiation of a new user-interaction process without its being
>  reversible by the standard navigation error recovery mechanism of the
>  browser back button means that the browser has ceded too much control to
>  the author in a way which fails to faithfully serve the interest (and in
>  the case of PWDs acute need) of the user.  [Sentence too long; you can edit
>  it.]
>  
>  This is related to generic control of link-related actions under discussion
>  between WAI-PF and X-Link working groups.
>  
>  Al
>  
>  At 11:39 AM 8/25/99 -0400, Ian Jacobs wrote:
>  >Hello,
>  >
>  >In [1], checkpoint 5.11 reads:
>  >
>  >    Allow the user to turn on and off support for spawned 
>  >    windows. [Priority 1] 
>  >
>  >In SYMM Working Group teleconference, we discussed
>  >the meaning of this checkpoint. There are many instances
>  >where opening a window is vital to the functioning of the
>  >page (e.g., when, from a SMIL presentation, one opens
>  >an HTML media object in a new window. Note that SMIL
>  >players do not currently render HTML themselves.). 
>  >
>  >I believe the intent of the checkpoint is to prevent
>  >disorienting changes to view, selection, or focus,
>  >a goal covered by checkpoint 10.1:
>  >
>  >   Provide information about document and view changes 
>  >   (to the user and through programming interfaces).

>  >
>  >Note: I propose adding the words "focus" and "selection" 
>  >explicitly to 10.1.
>  >
>  >While turning off spawning of windows may be one solution
>  >to avoiding disorienting changes in views, I don't think
>  >it's an effective solution since so much functionality
>  >may be lost. Instead, in the techniques, we should tell
>  >user agents how to inform users of changes to the view.
>  >For instance, by emitting an audio cue, by speaking
>  >"title" text of the linked resource along with some
>  >warning, etc. 
>  >
>  >I propose deleting checkpoint 5.11 and ensuring that the
>  >goal of not disorienting users is clearly stated in 10.1.
>  >
>  > - Ian
>  >
>  >[1] http://www.w3.org/WAI/UA/WAI-USERAGENT-19990809 
>  >-- 
>  >Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>  >Tel/Fax:                     +1 212 684-1814
>  > 
>  
>
>--Charles McCathieNevile            mailto:charles@w3.org
>phone: +1 617 258 0992   http://www.w3.org/People/Charles
>W3C Web Accessibility Initiative    http://www.w3.org/WAI
>MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
>

Received on Wednesday, 25 August 1999 14:54:11 UTC