3.6.2

#38. (Re 3.6.2)
Give user option whether to preserve font size restrictions: Give the user control over whether font size distinctions are reserved when rendered. Most users will benefit from the ability to scale up all text while maintaining size distinctions between different types of elements, but there are cases where it is equally important to some users that they be able to choose to hide such distinctions and instead use a single font size or a very restricted range of such sizes. An example would be a user with low visual acuity who chooses to have all text rendered at an extremely large size (e.g. the text nearly as large as the window); such a user would be hampered if the UA is forced to render titles in a size larger than the height of the window. Thus I recommend changing the wording from "When rendered text is rescaled..." to "The user has the option whether, when rendered text is rescaled...".

Summary

Details

3.9.New

#53. (Re 3.9.New)
Allow users supplied style sheets: 3.9 requires the user be allowed to diasble or switch between user-supplied style sheets, but nowhere does this draft document require or recommend that the user be allowed to supply any. I think this is pretty basic and should be a Level A success criterion (or, at worse, Level AA).

Please put any proposals for this text in your comments AND send them to the group mailing list w3c-wai-ua@w3.org.

Summary

Details

4.1.10

#55. (Re 4.1.10 **)
Clarify difference between 4.1.10 vs. 4.1.11: 4.1.10 and 4.1.11 seem to overlap and the difference between them is unclear. Were the two supposed to be combined? First, 4.1.9 applies to UI only, whereas 4.1.10 applies to both UI and rendered content (e.g. accesskey=). Second, 4.1.9 requires the user be able to assign new shortcut keys, whereas 4.1.10 does not. (At least not explicitly; see my other comment on the need to define "override" in these contexts.) (Priority: 1 High)

Please put any proposals for this text in your comments AND send them to the group mailing list w3c-wai-ua@w3.org.

Summary

Details

4.1.5

#63. (Re 4.1.5)
Clarify "Display of Keyboard Commands" or reduce to Level AA: While I'm all in favor of encouraging the display of keyboard commands with the associated items, I don't think it is reasonable to make it a Level A requirement at this time as (a) I don't know of any user agent that complies, and (b) the wording it too vague. Keep in mind that the current wording would apply to both rendered content and to the user agent's user interface. For example, does any browser provide an option that would display "CTRL+L" or "CTRL+D" printed next to its address bar? Is CTRL+B or CMD+B ever displayed next to selected text? The vagueness stems to the ambiguity of the term "direct keyboard commands", which are not defined (see my comment below that addresses this more specifically). (Priority: 1 High)

Please put any proposals for this text in your comments AND send them to the group mailing list w3c-wai-ua@w3.org.

Summary

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)

Please put any proposals for this text in your comments AND send them to the group mailing list w3c-wai-ua@w3.org.

Summary

Details

4.1.8

#69. (Re 4.1.8)
Require single keystroke OR key combination, etc.: Change the text from "are available in a single keystroke" to "are available using a single keystroke, key combination, or sequence of unmodified keystrokes". The dictionaries I found online all define keystroke as a single depression of a single key, and there are clearly not enough available single keystrokes to assign to all of the important commands. (The reason I also include "or sequence of unmodified keys" is because of the StickyKeys feature which allows the user to emulate a key combination using sequential unmodified keystrokes.) Since this is only Level AA it's not high priority, but without a change such as this it would not be accomplishing its goal AND it would make Level AA compliance extremely difficult. (THAT CAN BE MEMORIZED AND ENTERED WITHOUT CHECKING INTERMEDIATE RESULTS, e.g. F10,F,O is OK for File->Open, but F10,Down,Down,Enter is not?) (Priority: 2 Medium)

Please put any proposals for this text in your comments AND send them to the group mailing list w3c-wai-ua@w3.org.

Summary

Details