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

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

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Thu, 26 Feb 2004 17:01:23 -0500
Message-Id: <5.1.0.14.2.20040226165035.00ab6db0@pop.mail.iamworld.net>
To: <w3c-wai-gl@w3.org>

At 11:59 AM 2004-02-26, John M Slatin wrote:

>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?

Focus and selection would seem to be pretty consistent across
mouse+keyboard+screen GUIs.

The User Agent Guidelines treats them as generics.

My suggestion for WCAG would be to use the definitions in UAAG 1.0 until
such time as PF can give you something better.

http://www.w3.org/TR/UAAG10/glossary.html

We are actively working toward something better, but it's not worth calling
'better' yet.  We are trying to get a more precise model supported across
HTML, CSS, SVG, etc. and accessibility APIs.  Wish us luck.

But until that time, it makes sense to distinguish them, and it's
usually sufficient to treat them as defined by their entries in the glossary
in UAAG 1.0.

Al


>"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 17:11:31 UTC

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