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

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

Details

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

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

Details

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

Details

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

Details

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

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

Details

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

Details

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

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

Details