w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
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:
- Proposal 4.X Rationale
- Proposal 4.X.1 Directly activate elements
- Proposal 4.X.2 Modify show/hide indicator
- Proposal 4.X.3 Control appearance of click indicators
- Proposal 4.X.4 Filter indicators
- 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
| Choice | All 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 Rationale | Comments |
|---|---|---|
| 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
| Choice | All 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 elements | Comments |
|---|---|---|
| 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
| Choice | All 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
| Choice | All 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 indicators | Comments |
|---|---|---|
| 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
| Choice | All 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 indicators | Comments |
|---|---|---|
| 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
| Choice | All 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 updates | Comments |
|---|---|---|
| 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
- Jan Richards: last responded on 22, July 2009 at 14:46 (UTC)
- Greg Lowney: last responded on 23, July 2009 at 09:06 (UTC)
- Henny Swan: last responded on 23, July 2009 at 15:54 (UTC)
- Jim Allan: last responded on 23, July 2009 at 16:40 (UTC)
- Markku Hakkinen: last responded on 23, July 2009 at 16:45 (UTC)
- Jeanne F Spellman: last responded on 23, July 2009 at 16:52 (UTC)
- Kelly Ford: last responded on 23, July 2009 at 16:58 (UTC)
Everybody has responded to this questionnaire.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project