W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2004

safe selection [was: Re: RE 3.2 was 3.4]

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Thu, 26 Feb 2004 11:54:43 -0500
Message-Id: <5.1.0.14.2.20040226110746.0261a110@pop.mail.iamworld.net>
To: w3c-wai-gl@w3.org

At 01:50 AM 2004-02-26, Gregg Vanderheiden wrote:
>    * [L2?] Except for submit buttons, form controls, options within form 
> controls, and menu items that are part of page content can be selected 
> without causing submission of the form.  [this dictates interface design]
[Note 1: This is not about what people usually think of as organization of 
the content.  It is truly an organizational principle about the dialog 
flow: separation of selection from activation.  But it is about texture, 
distinctions that must be observed in the flow of the interaction.  Not how 
to assemble the micro scale into macro scale.  It's about
the required fineness of the micro scale.]

[Note 2: The exception for submit buttons is wrong.  A select-review-fire 
protocol
should be available for these, too.  Yes, click can be a 'fire immediate'
for these, but some way of selecting them first must be available.  This could
be by tabbing to them or onMouseOver happening.  These should not submit
the form.]

This is a guideline about user-safe interaction.  The generic rule is a 
precedence
relation between 'perceivable' 'comprehensible' and 'operable'  The user should
always be able to require a separation between select and activate, to 
allow for
perception and comprehension *before* deciding to operate any control.

It also has to do with the object-oriented texture of web content.  The 
'browser
back' function is global to the current page, and so may be fired without a 
prior
select phase.  Its context is always the whole URI-denoted context.  But for
actions which are scoped to some subset of the presentation, it must be 
possible
to select a matching subset so that there is a perceivable scoping 
indication that
helps the user comprehend what it is that is likely to result from 
activation of
the control.

Since the outcomes of a UI event depend on the [e.g. focus] interaction 
state of
the document-in-browser, that state must be made perceivable without at the 
same
time causing further operations (state changes).

Especially for control actions such as form submittal that are not known not to
generate unsafe operations across the network.

  http://www.w3.org/TR/2003/WD-webarch-20031209/#safe-interaction

It is well laid out in the User Agent Guidelines.

But is applies also to interaction behavior controlled by scripts provided 
by the
author and server.

Al

>Thanks John
>
>
>
>This is great progress
>
>
>
>Some comments
>
>
>
>-  Do we have a better or more generic word for screen?   Page?  Doc?
>
>- level 1 items cannot dictate format of presentation.  Moved two items 
>down to level 2
>
>-  might want to move some things to level 3 that are hard to do for all 
>sites (to keep from preventing L2 conformance)
>
>-  Some additional notes in brackets below.
>
>
>
>
>
>
>
>Begin proposed wording for Guideline 3.4
>
>
>
>
>
>3.4  Organize content consistently from  to screen and make interactive 
>components behave in predictable ways.
>
>
>
>Success criteria for Level 1
>
>    * [L2?] Components that are repeated on multiple screens within a 
> resource or a section of a resource occur in the same sequence each time 
> they are repeated, for at least one presentation format.
>    * Structural markup is used to group related elements.   [what about 
> technologies that don't allow this?]
>    * Any extreme change of context such as an automatic redirect or a 
> link that opens a new browser window is implemented in a manner that can 
> be programmatically identified.
>    * [L2?] Except for submit buttons, form controls, options within form 
> controls, and menu items that are part of page content can be selected 
> without causing submission of the form.  [this dictates interface design]
>
>
>
>
>
>Success criteria for Level 2
>
>    * [L3? pretty specific. Put order at level 2 and  position L3?] 
> Components that appear visually on multiple screens, such as navigation 
> bars, search forms, and sections within the main content, are displayed 
> in the same location relative to other content on every screen where they 
> appear.
>    * Visual layout is used to group related components. [ so that 
> behavior is predictable. ]
>    * The target of each link is clearly identified.   [how do we do 
> this?]  [ Level 3?]
>    * Link text, including alt text for graphical links, includes words or 
> phrases that occur in the title element of the destination screen. [js 
> note: Do we need a criterion about informative page titles here? I know 
> we discussed one somewhere but I don t remember where.]   [L3?]
>    * Graphical components that appear on multiple screens, including 
> graphical links, are associated with the same text equivalents wherever 
> they appear.   [these are ok guidelines but strict adherence is pretty 
> restrictive since you don't know how they might be used.  L3?]
>    * Interactive elements that appear on multiple screens, including 
> graphical elements, are associated with the same functionality wherever 
> they appear.
>    * Explicit notice is given in advance of any extreme change of context 
> such as an automatic redirect or a link that opens a new browser window.
>
>
>
>
>Success Criteria for Level 3
>
>    * When components such as navigation bars and search forms appear on 
> multiple pages, users can choose to have those elements presented in a 
> different visual position or reading-order.
>    * There are no extreme changes of context such as automatic redirects 
> or automatically appearing pop-up windows.
>
>
>
>
>
>Gregg
>
>------------------------
>
>Gregg C Vanderheiden Ph.D.
>Professor - Depts of Ind. Engr. & BioMed Engr.
>Director - Trace R & D Center
>University of Wisconsin-Madison
><<http://trace.wisc.edu/>http://trace.wisc.edu/> FAX 608/262-8848
>For a list of our list discussions http://trace.wisc.edu/lists/
>
><http://trace.wisc.edu:8080/mailman/listinfo/>
>
>
>
>
Received on Thursday, 26 February 2004 11:54:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:17:55 UTC