w3c/wbs-design
or
by mail to sysreq
.
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:
#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)
Choice | All 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)
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. |
#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)
Choice | All 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)
Responder | #65. (Re 4.1.6) Require all platform text area keyboard conventions, not just navigation | Comments |
---|---|---|
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 |
#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)
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 |
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. |
#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)"
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 |
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) |
#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)"
Choice | All 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)
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) |
Proposal from Simon Harper for Action Item 149: Simon's email with comments on the proposal
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).'
Choice | All 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 |
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 |
Proposal from Simon Harper for Action Item 181: Simon's email with comments on the proposal
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'.
Choice | All 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)
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 |
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
w3c/wbs-design
or
by mail to sysreq
.