W3C WBS Home

Results of Questionnaire UAWG Survey for 23 July

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: w3c-archive@w3.org, jeanne@w3.org

This questionnaire was open from 2009-07-22 to 2009-09-25.

7 answers have been received.

Jump to results for question:

  1. Proposal 4.X Rationale
  2. Proposal 4.X.1 Directly activate elements
  3. Proposal 4.X.2 Modify show/hide indicator
  4. Proposal 4.X.3 Control appearance of click indicators
  5. Proposal 4.X.4 Filter indicators
  6. Proposal 4.X.5 Toggle dynamic updates

1. Proposal 4.X Rationale

From a proposal from Kim Patch.

Current: none

Proposed

As Web pages have gotten more complicated, there are many situations where users who find it difficult or impossible to use the mouse need more than sequential navigation. Direct navigation allows such users, including speech users, to quickly navigate Web elements.

Summary

ChoiceAll responders
Results
Accept the proposal 2
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 5
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder Proposal 4.X RationaleComments
Jan Richards The proposal needs more discussion (see comments field) I'm not sure the idea isn't part of guideline 4.1 Ensure full keyboard access. (btw: I think the idea is interesting)
Greg Lowney The proposal needs more discussion (see comments field) I agree with Jan that all of the proposed 4.x could go under 4.1 (Ensure full keyboard access). As for the rationale, just suggest a minor tweak: the need is spurred not because Web pages are more complicated, but that they often have more clickable elements than can be comfortably traversed using simple next and previous commands. Also, I'd say "including users of assistive technology", which is more inclusive than just "speech users".
Henny Swan The proposal needs more discussion (see comments field) I agree that this is good to add. Would this also cover something like Spatial Navigation as used in Opera as well as something like numbered links as suggested in "4.X.1 Directly activate elements" or is Spatial Navigation covered elsewhere?
Jim Allan Accept the proposal
Markku Hakkinen The proposal needs more discussion (see comments field) I am wondering if 4.7 shouldn't be mod'd to be structured navigation as a top level requirement, with sequential and direct navigation being the sub-categories.

Jeanne F Spellman The proposal needs more discussion (see comments field) I like the proposal. We need to figure out how to integrate it with the existing work.
Kelly Ford Accept the proposal

2. Proposal 4.X.1 Directly activate elements

From a proposal from Kim Patch.

Current: none

Proposed

4.X.1 Directly activate elements. : The user can directly select any actionable element, including link, image, tabbed view, check box, radio button, field etc. using a short series of keystrokes, e.g. numpad number keys, and activate that element using another keystroke, e.g. "Enter" to do the equivalent of a mouse click, "h" to do the equivalent of a mouse hover, or "r" to do the equivalent of a right-click. A keyboard shortcut is provided to hide/show element indicators, e.g. numbers (Level A)

Summary

ChoiceAll responders
Results
Accept the proposal
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 6
Disagree with the proposal
Neutral - will accept the consensus of the group 1

Details

Responder Proposal 4.X.1 Directly activate elementsComments
Jan Richards The proposal needs more discussion (see comments field) I think we should break this into two parts: 1) a requirement to provide keyboard commands for all active elements and 2) a requirement that mouse actions have keyboard equivalents.
Greg Lowney The proposal needs more discussion (see comments field) 1. I'm still concerned that we need to introduce a whole new concept such as "element indicators" when we already have direct navigation shortcuts and the requirement to display them. I still lean towards replacing this proposed section with the recommendation that the UA provide an option to assign direct keyboard commands to all enabled elements that lack them. The display of those direct keyboard command would already be covered by 4.1.5 (Discovery of Keyboard Commands).
2. No need to give so many examples directly in the SC; it's a balancing act between making it easier to understand vs. harder to read, and often it's better to move the examples out of the main sentence.
3. "short" series of keystrokes is undefined and thus subjective.
4. How about "to select or activate", so as to shorten it by a clause.
5. Needs to be limited to "recognized" actionable elements "in content", unless one or both are implied by the definitions of "actionable element".
6. "Actionable element" is currently undefined. The document uses the terms "enabled elements" and "interactive elements" for the same purpose, although even after reading the glossary I'm still unsure of the differences between them.
7. A shortened version, omitting the inline examples, might be: "The user can directly select or activate any recognized actionable element in content using a short series of keystrokes that are displayed with the element."
8. I think this is more appropriate as Level AA for now, perhaps scheduled for upgrade to A when we have more compliance.
Henny Swan The proposal needs more discussion (see comments field)
Jim Allan The proposal needs more discussion (see comments field) 'select' generally means highlight (just before copying)
seems this should say the user can 'focus' an actionable element, and then performs other behaviors/functions (activate, hover, etc).
the example (text beginning with "e.g. 'Enter' to ...) should be in Techniques. Sound prescriptive
Markku Hakkinen The proposal needs more discussion (see comments field) "Select" is not appropriate. The user can directly active any actionable element using a sequence of keystrokes. The applicable keystrokes may be displayed by an option setting in the UA.
Jeanne F Spellman The proposal needs more discussion (see comments field) minor: the examples need a little wordsmithing to make them more distinct from the requirement.
Kelly Ford Neutral - will accept the consensus of the group

3. Proposal 4.X.2 Modify show/hide indicator

From a proposal from Kim Patch.

Current: none

Proposed

4.X.2 Modify show/hide indicator : Clickable element indicators' hide/show shortcut key(s) can be modified by the user (Level AA)

Summary

ChoiceAll responders
Results
Accept the proposal 1
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 4
Disagree with the proposal 1
Neutral - will accept the consensus of the group 1

Details

Responder Proposal 4.X.2 Modify show/hide indicator Comments
Jan Richards The proposal needs more discussion (see comments field) This can be rolled into 4.1.5 Discovery of Keyboard Commands
Greg Lowney The proposal needs more discussion (see comments field) There are a lot of keyboard commands that could be and should be customizable, and I'm not convinced that this one is more important or accessed more frequently than others, and thus needs to be called out and prioritized above customizing them. Examples include those that toggle the display of images or formatting from style sheets, toggling navigation by typing, etc.
Henny Swan The proposal needs more discussion (see comments field)
Jim Allan Neutral - will accept the consensus of the group
Markku Hakkinen Disagree with the proposal Already covered in 4.1.5 and 4.1.8-10
Jeanne F Spellman Accept the proposal
Kelly Ford The proposal needs more discussion (see comments field) don't follow this one.

4. Proposal 4.X.3 Control appearance of click indicators

From a proposal from Kim Patch.

Current: none

Proposed

4.X.3 Control appearance of click indicators : The user can control what the clickable element indicators look like, including size, color, style, transparency and location (Level AA)

Summary

ChoiceAll responders
Results
Accept the proposal 1
Recommend changes (see comments field) 1
The proposal needs more discussion (see comments field) 5
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder Proposal 4.X.3 Control appearance of click indicatorsComments
Jan Richards The proposal needs more discussion (see comments field) This should be covered by: Guideline 1.1 Ensure that non-Web-based functionality is accessible.
Greg Lowney The proposal needs more discussion (see comments field) As above, is the ability to customize these more important than, for example, the ability to customize the appearance of many other things? For example, the display of other direct keyboard commands as required by 4.1.5 (Discovery of Keyboard Commands), and 3.3.1 (Access Relationships) which requires the UA "Provide access to explicitly-defined relationships based on the user's position in content (e.g., show form control's label, show label's form control, show a cell's table headers, etc.)" but doesn't explicitly say that the user has to independently control the presentation of that information. Isn't there a general requirement that would cover this? If not, should there be, rather than to have many specific requirements?
Henny Swan The proposal needs more discussion (see comments field) How easily is this done without affecting the page layout?
Jim Allan The proposal needs more discussion (see comments field) this is controllable now from a user CSS (outline selector)
are we saying there should be a User Interface element/menu/mechanism to avoid user CSS creation? If so, I agree
Markku Hakkinen The proposal needs more discussion (see comments field) If the UA is adhering to UAAG, then wouldn't most of this be a given?
Jeanne F Spellman Recommend changes (see comments field) "the user can control the appearace of the clickable element indicators, including....
Kelly Ford Accept the proposal

5. Proposal 4.X.4 Filter indicators

From a proposal from Kim Patch.

Current: none

Proposed

4.X.4 Filter indicators : The user can control what types of clickable element indicators show by group, e.g. links, images, tabbed views, check boxes, radio buttons, tabs, fields etc.(Level AA)

Summary

ChoiceAll responders
Results
Accept the proposal 2
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 5
Disagree with the proposal
Neutral - will accept the consensus of the group

Details

Responder Proposal 4.X.4 Filter indicatorsComments
Jan Richards The proposal needs more discussion (see comments field) Might be a technique of 4.1.5 Discovery of Keyboard Commands
Greg Lowney The proposal needs more discussion (see comments field) I'm becoming more and more convinced that these would be better as best practices than as separate success criteria, mainly because they are just adding so much length for something that is really just one feature. If we take my suggestion above, we could make this an adjunct to 4.1.5 (Discovery of keyboard commands). However, allowing the user to show direct keyboard commands only for certain types of elements would certainly be lower priority than showing them for all such elements.

Also:
1. Should be consistent on terminology, such as using either "enabled element" or "interactive element" rather than "clickable element".
2. Can delete "by group" as it is implied by "what types", unless I misunderstand what you're trying to say.
3. Perhaps: "The user can control which types of enabled elements have direct keyboard shortcuts displayed."
Henny Swan The proposal needs more discussion (see comments field)
Jim Allan The proposal needs more discussion (see comments field) Show only links on a page, no text, no forms, etc. when a page is downloaded? or Page fully downloads, then user does a command for only images and everything else vanishes?
or are we looking for something like a 'links list' or 'form controls list' that a user can have appear on command then move within the list and be transported to that location on a page?
Markku Hakkinen The proposal needs more discussion (see comments field) I think the idea of filter may be useful in structured navigation... should be addressed in 4.7
Jeanne F Spellman Accept the proposal
Kelly Ford Accept the proposal

6. Proposal 4.X.5 Toggle dynamic updates

From a proposal from Kim Patch.

Current: none

Proposed

4.X.5 Toggle dynamic updates : A control is provided to turn on/off dynamic updates of clickable element indicators. (Level AA)

Summary

ChoiceAll responders
Results
Accept the proposal 1
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 5
Disagree with the proposal
Neutral - will accept the consensus of the group 1

Details

Responder Proposal 4.X.5 Toggle dynamic updatesComments
Jan Richards The proposal needs more discussion (see comments field)
Greg Lowney The proposal needs more discussion (see comments field) 1. "A control is provided" suggests it is a visual control rather than an option in the more general sense. Perhaps "The user has the option to enable or disableā€¦" or other more standard
Henny Swan The proposal needs more discussion (see comments field)
Jim Allan The proposal needs more discussion (see comments field) need to specify what type of dynamic updates. ARIA has 3 levels of update announcements. Perhaps having a ui element to configure UA response and/or override author specified level - e.g. make everything 'interrupt'
Markku Hakkinen The proposal needs more discussion (see comments field) Don't really understand. Are you disabling all dynamic updates? If not, content changes and invalid indicators remain visible?
Jeanne F Spellman Accept the proposal
Kelly Ford Neutral - will accept the consensus of the group

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Judy Brewer <jbrewer@w3.org>
  2. Eric Hansen <ehansen@ets.org>
  3. Peter Parente <pparent@us.ibm.com>
  4. Simon Pieters <simonp@opera.com>
  5. Takeshi Kurosawa <kurosawa-takeshi@mitsue.co.jp>
  6. Alan Cantor <alan@cantoraccess.com>
  7. Simon Harper <simon.harper@manchester.ac.uk>
  8. Kimberly Patch <Kim@redstartsystems.com>
  9. he wen <rockywen@tencent.com>
  10. Henny Swan <hswan@paciellogroup.com>
  11. Shaohang Yang <shaohang.ysh@alibaba-inc.com>

Send an email to all the non-responders.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire


Maintained by Laurent Carcone, from a development by Dominique Hazaël-Massieux (dom@w3.org) on an original design by Michael Sperberg-McQueen $Id: showv.php3,v 1.129 2015/07/01 16:13:23 kahan Exp $. Please send bug reports and request for enhancements to lcarcone@w3.org with w3t-sys@w3.org copied (if your mail client supports it, send mail directly to the right persons)