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

Thanks, Al. I wasn't sure I should include the exception for Submit
buttons, and I agree that it hsould be possible to tab to a select
button or other control without submitting it.  Is it meaningful to
distinguish here between receiving focus and selecting? Or is that
meaningful only in the MS Windows context?




"Good design is accessible design." 
Please note our new name and URL!
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Al Gilman
Sent: Thursday, February 26, 2004 10:55 am
To: w3c-wai-gl@w3.org
Subject: safe selection [was: Re: RE 3.2 was 3.4]



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 12:00:22 UTC