Re: Proposed deletion of checkpoint on spawning windows

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
>

Received on Wednesday, 25 August 1999 12:49:14 UTC