- From: Al Gilman <asgilman@iamdigex.net>
- Date: Wed, 25 Aug 1999 13:41:33 -0400
- To: Charles McCathieNevile <charles@w3.org>
- Cc: w3c-wai-ua@w3.org, w3c-wai-pf@w3.org
No. This leaves the user with too much garbage-collection liability. Telling is not enough; the system must recognize that it opens new processes under the user's permission and it is at the user's discretion how closely they wish to hold that permission-granting. Living with a littered desktop is easy in a GUI world. I do it in hardcopy all the time. It is not a condition that an eyes-free user can operate in; her environment has to be neater and more tightly controlled. The maximum degree of user control needs to be the base level and shortcuts added over that; not the other way around. 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 13:34:25 UTC