W3C WBS Home

Results of Questionnaire UAWG Survey for 14 May

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-05-13 to 2009-05-29.

7 answers have been received.

Jump to results for question:

  1. #64 Define "direct keyboard command"
  2. #65. (Re 4.1.6) Require all platform text area keyboard conventions, not just navigation
  3. #71. (Re 4.1.9) Is overriding all UI keyboard commands too broad?
  4. #78. (Re 4.2.3 **) ""Activate all input device event handlers""
  5. #78. (Re 4.2.3 **) ""Activate all input device event handlers""
  6. ACTION-149 to write proposal for 'default settings of UA should be accessible'
  7. ACTION-181 Investigate / review interactive and enabled for contradictions.

1. #64 Define "direct keyboard command"

4.1.5

#64. (Re 4.1.5 **)
Define "direct keyboard command": The term "direct keyboard command" is used in 4.1.1, 4.1.3, and 4.1.5, but is never defined. Is it supposed to refer only to (a) "direct keyboard navigation commands" that merely move the focus to an associated item (e.g. CTRL+L or CTRL+D to move the focus to the address bar and select its contents), and/or to (b) keyboard commands that immediately activate or perform an action upon a user interface element (e.g. ALT+F to activate the File menu), and/or (c) keyboard commands that immediately carry out a specific action, usually but not always upon the element that has the selection or focus (e.g. CTRL+A to select the entire contents of the field that currently has or contains the keyboard focus)? If you mean choice (a) then you might want to use the term "direct keyboard navigation commands" rather than "direct keyboard commands". (Compare to ISO 9241-171 terminology--shortcut keys?) (Priority: 1 High) (Type: Clarify)

Summary

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

(1 response didn't contain an answer to this question)

Details

Responder #64 Define "direct keyboard command"Comments
Jan Richards The proposal needs more discussion (see comments field) My proposal on this is at:
http://lists.w3.org/Archives/Public/w3c-wai-ua/2008AprJun/0004.html
David Poehlman Accept the proposal
Simon Harper The proposal needs more discussion (see comments field)
Kimberly Patch The proposal needs more discussion (see comments field) I think direct keyboard command is any key or key combination that affects a program in any way.
Kelly Ford Recommend changes (see comments field) I think we mean all of these options and a glossary definition should spell this out.
Markku Hakkinen
Henny Swan Accept the proposal It might be an idea to review the whole document to see if there are other terms that we have missed in the Glossary.

2. #65. (Re 4.1.6) Require all platform text area keyboard conventions, not just navigation

4.1.6

#65. (Re 4.1.6)
Require all platform text area keyboard conventions, not just navigation: I don't think 4.1.6 should be limited to only requiring UA comply with the platform's standard keyboard commands for "navigation" within text fields, but should instead require support or all platform conventions for keyboard commands in text fields, including, but not limited to, commands for cut, copy, paste, delete, select all, and undo. Therefore I recommend changing the title to "Standard text area keyboard conventions" and the text to include "cut, copy, paste, delete, select all, and undo". Note that the title limits the scope to "navigation" but the wording of the actual success criterion does not: it does not explicitly say "navigation", but on the other hand the list of "including, but not limited to" examples does not include any that commands that lack a navigation component, even if some of them have effects beyond merely navigation (e.g. delete, shift-to-select). (Priority: 2 Medium) (Type: Expand)

Summary

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

(1 response didn't contain an answer to this question)

Details

Responder #65. (Re 4.1.6) Require all platform text area keyboard conventions, not just navigationComments
Jan Richards Accept the proposal
David Poehlman Accept the proposal didn't we already answer this one?
Simon Harper Accept the proposal
Kimberly Patch The proposal needs more discussion (see comments field) I agree. I think there are some more standard keyboard commands that would be appropriate to add to this list: Redo, Zoom In/Out, Bold, Italicize, and Underline actions, and Print, Find, Save As and Options dialog boxes. Not all programs have these functionalities, but if they do they should follow the standard keyboard commands. In some cases there's also the issue of browser versus application shortcuts. The Find dialog box in Google Documents is one example. In terms of resolving browser versus application conflicts one solution may be to reserve the main shortcut for the browser and use the same shortcut plus an additional control key for the application, e.g. Control F Find for the browser and Shift Control F find for the application.
Kelly Ford Accept the proposal Approve this one with the basic title change and text change suggested.
Markku Hakkinen
Henny Swan Accept the proposal

3. #71. (Re 4.1.9) Is overriding all UI keyboard commands too broad?

4.1.9

#71. (Re 4.1.9)
Is overriding all UI keyboard commands too broad?: I'm concerned because I'm not sure that any browsers allow the user to override *all* of the platform's UI keyboard commands" (e.g. ALT to activate the menu bar, CTRL+O for open, CTRL+A for select all, Tab for sequential navigation, etc.). Is it possible that the current wording is unintentionally broad? (Priority: 1 High) (Type: Clarify)

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 #71. (Re 4.1.9) Is overriding all UI keyboard commands too broad?Comments
Jan Richards The proposal needs more discussion (see comments field) I agree with Greg.
David Poehlman Accept the proposal
Simon Harper The proposal needs more discussion (see comments field) I think it is both broad but justified.
Kimberly Patch The proposal needs more discussion (see comments field) I think it's important that people be able to override all and it's equally important that there's an easy way to put defaults back.
Kelly Ford The proposal needs more discussion (see comments field) As written this guideline does have the requirement qualification except for conventional bindings for the operating environment (e.g., for access to help). I would say that ctrl+o for example is a convention of an operating system. Browser vendors are free to go beyond here and other keyboard requirements do encourage this but I think this one is acceptable as written.
Markku Hakkinen The proposal needs more discussion (see comments field) Agree with this concern
Henny Swan Accept the proposal This is something that is possible with Opera if really needed.

4. #78. (Re 4.2.3 **) ""Activate all input device event handlers""

4.2.3

#78. (Re 4.2.3 **)
""Activate all input device event handlers"" is unclear: I'm afraid that I can't understand this success criterion based on its title (""Activate All"") or its text ( ""The user can activate, as a group, all event handlers of the same input device event type, for the same control""), nor is it clear how it is different than 4.2.1. Both require the user be able to activate event handlers, but they differ in: (a) although 4.2.1 applies to ""(content) elements"" that take content focus while 4.2.3 applies to ""(user interface) controls"" (per glossary definitons); (b) 4.2.1 requires that the user can activate them with the keyboard while 4.2.3 doesn't specify the means, presumably making it OK if the user has to click a mouse to activate a mouse-click event handler (which seems to remove the point); (c) 4.2.3 says ""as a group"" while presumably 4.2.1 finds it enough if they can be activated separately; (d) 4.2.1 only applies to the event handlers that are ""explicitly associated"" with the element that has content focus, while presumably 4.2.3 requires it for all UI controls that handle events even if they ""bubble up"" to the control rather than being ""explicitly associated"" with it; (e) 4.2.1 requires the user be able to navigate to and then trigger event handlers for an element, while 4.2.3 would presumably be met by providing an entirely separate facility that merely allowed the user to pick UI controls and their event handlers from a master list; (f) etc., etc. As you can see, I find 4.2.3 (and probably 4.2.1) need significant changes to be made both clear and useful. I recommend that the two SC be combined into a single SC that (a) applies to both content elements that have the content focus AND to UI controls that have the UI focus, (b) lets the user activate, in a single operation, ""all"" of the event handlers for the user's choice of input device event handlers ""explicitly associated"" with that element or control. (Priority: 1 High) (Type: Clarify)"

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 #78. (Re 4.2.3 **) ""Activate all input device event handlers""Comments
Jan Richards The proposal needs more discussion (see comments field)
David Poehlman Accept the proposal
Simon Harper The proposal needs more discussion (see comments field)
Kimberly Patch The proposal needs more discussion (see comments field)
Kelly Ford The proposal needs more discussion (see comments field) We should discuss this one. I do agree clarification is needed.
Markku Hakkinen Neutral - will accept the consensus of the group
Henny Swan The proposal needs more discussion (see comments field)

5. #78. (Re 4.2.3 **) ""Activate all input device event handlers""

4.2.3

#78. (Re 4.2.3 **)
""Activate all input device event handlers"" is unclear: I'm afraid that I can't understand this success criterion based on its title (""Activate All"") or its text ( ""The user can activate, as a group, all event handlers of the same input device event type, for the same control""), nor is it clear how it is different than 4.2.1. Both require the user be able to activate event handlers, but they differ in: (a) although 4.2.1 applies to ""(content) elements"" that take content focus while 4.2.3 applies to ""(user interface) controls"" (per glossary definitons); (b) 4.2.1 requires that the user can activate them with the keyboard while 4.2.3 doesn't specify the means, presumably making it OK if the user has to click a mouse to activate a mouse-click event handler (which seems to remove the point); (c) 4.2.3 says ""as a group"" while presumably 4.2.1 finds it enough if they can be activated separately; (d) 4.2.1 only applies to the event handlers that are ""explicitly associated"" with the element that has content focus, while presumably 4.2.3 requires it for all UI controls that handle events even if they ""bubble up"" to the control rather than being ""explicitly associated"" with it; (e) 4.2.1 requires the user be able to navigate to and then trigger event handlers for an element, while 4.2.3 would presumably be met by providing an entirely separate facility that merely allowed the user to pick UI controls and their event handlers from a master list; (f) etc., etc. As you can see, I find 4.2.3 (and probably 4.2.1) need significant changes to be made both clear and useful. I recommend that the two SC be combined into a single SC that (a) applies to both content elements that have the content focus AND to UI controls that have the UI focus, (b) lets the user activate, in a single operation, ""all"" of the event handlers for the user's choice of input device event handlers ""explicitly associated"" with that element or control. (Priority: 1 High) (Type: Clarify)"

Summary

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

(3 responses didn't contain an answer to this question)

Details

Responder #78. (Re 4.2.3 **) ""Activate all input device event handlers""Comments
Jan Richards Neutral - will accept the consensus of the group Repeat of above.
David Poehlman this is the same as #5?
Simon Harper The proposal needs more discussion (see comments field) Duplicate for #5
Kimberly Patch
Kelly Ford
Markku Hakkinen Neutral - will accept the consensus of the group
Henny Swan The proposal needs more discussion (see comments field)

6. ACTION-149 to write proposal for 'default settings of UA should be accessible'

Proposal from Simon Harper for Action Item 149: Simon's email with comments on the proposal

Proposed

4.5.X Reconfigure Defaults: The user agent will allow its default settings to be reconfigured by the user, via a globally accessible key combination (level A); and further, will automatically prompt the user to reconfigure the default settings at the first application launch after installation (Level AA).'

Summary

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

Details

Responder ACTION-149 to write proposal for 'default settings of UA should be accessible'Comments
Jan Richards The proposal needs more discussion (see comments field) Does the first part mean that Tools>Options needs a keyboard shortcut? Is the second part necessary? Maybe I wasn't there when this was discussed but ( ACTION-149 to write proposal for 'default settings of UA should be accessible') sounds like it was meant to mean that certain accessibility settings were going to be on by default.
David Poehlman Accept the proposal
Simon Harper Accept the proposal
Kimberly Patch The proposal needs more discussion (see comments field) This may be beyond the scope of this item, but it's also important that the user be able to save reconfigured default settings. Even better if there's some way to share these settings.
Kelly Ford Neutral - will accept the consensus of the group
Markku Hakkinen The proposal needs more discussion (see comments field) The globally accessible key combination as to bring up a configuration dialog. Is it necessary to add this point?
Henny Swan Accept the proposal

7. ACTION-181 Investigate / review interactive and enabled for contradictions.

Proposal from Simon Harper for Action Item 181: Simon's email with comments on the proposal

Proposed

I think there is a a very good case to either amalgamate or remove the defn of 'interactive element' as it is included in the defn of 'enabled element, disabled element'.

Summary

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

(1 response didn't contain an answer to this question)

Details

Responder ACTION-181 Investigate / review interactive and enabled for contradictions.Comments
Jan Richards
David Poehlman Neutral - will accept the consensus of the group
Simon Harper Accept the proposal
Kimberly Patch Neutral - will accept the consensus of the group
Kelly Ford Accept the proposal
Markku Hakkinen Accept the proposal
Henny Swan Accept the proposal

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Greg Lowney <w3.org@access-research.org>
  2. Judy Brewer <jbrewer@w3.org>
  3. Jim Allan <jimallan@tsbvi.edu>
  4. Eric Hansen <ehansen@ets.org>
  5. Peter Parente <pparent@us.ibm.com>
  6. Simon Pieters <simonp@opera.com>
  7. Takeshi Kurosawa <kurosawa-takeshi@mitsue.co.jp>
  8. Alan Cantor <alan@cantoraccess.com>
  9. Jeanne F Spellman <jeanne@w3.org>
  10. he wen <rockywen@tencent.com>
  11. Henny Swan <hswan@paciellogroup.com>
  12. 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)