- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Thu, 26 Feb 2004 11:54:43 -0500
- 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