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-05 to 2009-05-15.
8 answers have been received.
Jump to results for question:
#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...".
Choice | All responders |
---|---|
Results | |
Accept the proposal | 4 |
Recommend changes (see comments field) | 2 |
The proposal needs more discussion (see comments field) | 2 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
Responder | #38 Text Configuration | Comments |
---|---|---|
Jan Richards | Recommend changes (see comments field) | So maybe?: 3.6.2 Text Scale Distinctions: when rendered text is rescaled, the user has the option to either preserve or remove distinctions in the relatives scales of rendered text. (Level A) |
Kimberly Patch | Accept the proposal | |
Simon Harper | Accept the proposal | Good point, I agree. |
David Poehlman | Accept the proposal | |
Jeanne F Spellman | Accept the proposal | |
Kelly Ford | Recommend changes (see comments field) | I prefer Jan's wording on this. |
Jim Allan | The proposal needs more discussion (see comments field) | The current 3.6.2 should remain. This could be a new success criteria with AA. |
Markku Hakkinen | The proposal needs more discussion (see comments field) | I can see the point, but if the user requires such a large text size, wouldn't the overall user experience be best if the UA is used in conjunction with a screen magnifier, so that the entire UA and OS UI is available? Alternately, a global UA setting to a plain text mode (like opera's Lynx style) seems more practical, or a user supplied style sheet. |
#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.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 4 |
Recommend changes (see comments field) | 1 |
The proposal needs more discussion (see comments field) | 2 |
Disagree with the proposal | 1 |
Neutral - will accept the consensus of the group |
Responder | #53 Allow users supplied stylesheets | Comments |
---|---|---|
Jan Richards | The proposal needs more discussion (see comments field) | I'm not sure - what if the user agent instead provides a large number/range of display options? |
Kimberly Patch | Accept the proposal | |
Simon Harper | Disagree with the proposal | I think this is implicit in the ability to switch between user supplied sheets - If you can't supply a CSS then you can't switch to it. |
David Poehlman | Accept the proposal | |
Jeanne F Spellman | Accept the proposal | 3.9.2 Create User Style Sheets: The user has the option to create stylesheets overriding author-supplied stylesheets. (Level A) existing 3.9.2 becomes 3.9.3 |
Kelly Ford | Recommend changes (see comments field) | Agree here. We should add the requirement for users to be able to create style sheets. |
Jim Allan | Accept the proposal | Didn't see a need for a new success criteria. I assumed if the user has a style sheet and can select between them, then by implication the user was able to supply them. Current UAs allow user supplied CSS. Though this comment shows that 3.9.2 is unclear. the implication that there was a mechanism to supply user CSS is also in UAAG10 - 14.4.2 Allow the user to choose from and apply at least one user style sheet. we don't want implications and assumptions. Proposal: 3.9x User is able to provide one or more personal style sheets. This should go before 3.9.2 What about mobile or other thin clients? they may not be able to allow user CSS. Conformance rears its ugly head again. |
Markku Hakkinen | The proposal needs more discussion (see comments field) | Can't see this as level A, as some UA's, especially on some platforms, may not allow or have provision for user supplied style sheet. |
#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.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 2 |
Recommend changes (see comments field) | 2 |
The proposal needs more discussion (see comments field) | 2 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group | 1 |
(1 response didn't contain an answer to this question)
Responder | #55 Clarify difference between 4.1.10 and 4.1.11 | Comments |
---|---|---|
Jan Richards | Accept the proposal | I agree that these need clarifying (but there is no proposal yet). |
Kimberly Patch | The proposal needs more discussion (see comments field) | It's important to that the user be able to both assign new shortcut keys and override existing ones. I also think it's important that the user be able to easily see any UI changes -- see 4.1.5 comment. |
Simon Harper | Recommend changes (see comments field) | The user can override any keyboard shortcut or keybinding,including recognized author supplied shortcuts (e.g accesskeys) and user interface controls, except for conventional bindings for the operating environment (e.g., for access to help). The user must have an option to save these overrides so that the rebinding persists beyond the current session. |
David Poehlman | Accept the proposal | |
Jeanne F Spellman | ||
Kelly Ford | Neutral - will accept the consensus of the group | |
Jim Allan | The proposal needs more discussion (see comments field) | Right. This is confusing. Seems to artifact of many edits. 4.1.10 Removed clause revering to UI...that is covered in 4.1.9 4.1.11 change title, made it inclusive of all overrides 4.1.12 NEW. Needed when author or UA extension provides keybinding not available on user's device. 4.1.13. New. Always have to have a reset to default Propose: 4.1.10 User Override of Author Keyboard Commands: The user can override any recognized author supplied keyboard shortcuts (e.g accesskeys). (Level A) 4.1.11: Keyboard Command Override Persistence: The user must have an option to save the override of all keyboard shortcuts so that the rebinding persists beyond the current session. (Level A) [this may be covered in 4.5.1 Save Settings) 4.1.12 Keyboard Command conflict: The user agent should inform the user when a specified keybinding in content or the user interface is missing from the user's keyboard and allow an override. 4.1.13 Keyboard Command Reset: The user has the option to restore all keyboard overrides to their default values. |
Markku Hakkinen | Recommend changes (see comments field) | Agree with Jim's comments posted to the list, |
#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.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 1 |
Recommend changes (see comments field) | 1 |
The proposal needs more discussion (see comments field) | 3 |
Disagree with the proposal | 2 |
Neutral - will accept the consensus of the group |
(1 response didn't contain an answer to this question)
Responder | #63 Clarify "Display of Keyboard Commands" | Comments |
---|---|---|
Jan Richards | The proposal needs more discussion (see comments field) | Greg's right that this requirement goes beyond the current state of things. But that's not necessarily a problem as long as we all agree. Definitely needs discussion. |
Kimberly Patch | The proposal needs more discussion (see comments field) | I think as an option browsers should have the caps Ctrl+D next to the address bar(grey text in the address field would be a more elegant solution). Keyboard shortcuts that act on any text are different because they have no location associated with them. I think there are creative ways to give the user guidance, even with these, however. A drop-down menu could show and concisely define all keyboard shortcut commands, including those that act on any text. Even better if the list were printable and/or configurable. I think it's key that there be somewhere easy to get to to see what keyboard commands are. Also, if the user changes the keyboard shortcut, does the display change? |
Simon Harper | Disagree with the proposal | This looks fine to me, the scenario above is one interpretation of possible behaviour, but there are ways of doing this without such methods as 'printing the commands next to the option they relate to', as described. |
David Poehlman | Accept the proposal | |
Jeanne F Spellman | ||
Kelly Ford | Recommend changes (see comments field) | Thinking about the comments here, I do tend to agree. We need to think about this one further. |
Jim Allan | The proposal needs more discussion (see comments field) | Level AA may be appropriate. this is an option. Similar to Word 2007 when you hit the alt key, the Associated keybindings appear on screen. Many folks would like to use the keyboard to move to designated areas of the screen, but don't know what that part of the screen or an item is called to even look up the keybinding...if it is in the documentation/help |
Markku Hakkinen | Disagree with the proposal | I don't think the original text implies that the commands would be displayed adjacent to the element to which the apply, though that is one option. A UA could display a list of available commands upon request by the user in a dialog, or AT working in conjunction with the UA may display such a list. I think this can be reworded, but no proposal yet. I think also there was discussion of this previously, but can't locate it. |
#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.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 6 |
Recommend changes (see comments field) | 1 |
The proposal needs more discussion (see comments field) | |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
(1 response didn't contain an answer to this question)
Responder | #65 require all platform text area keyboard conventions | Comments |
---|---|---|
Jan Richards | Accept the proposal | I agree (but there is no proposal yet). |
Kimberly Patch | Accept the proposal | |
Simon Harper | Accept the proposal | Reword to include the defined term selection - and 'standard text area conventions' includes by default the actions specified by the comment. 4.1.6 Standard Text Area Conventions: Views that render text support the standard text area conventions for the platform including, but not necessarily limited to: character keys, backspace/delete, insert, selection, "arrow" key navigation (e.g., "caret" browsing), page up/page down, navigate to start/end, navigate by paragraph, etc. (Level A) |
David Poehlman | Accept the proposal | |
Jeanne F Spellman | ||
Kelly Ford | Accept the proposal | |
Jim Allan | Accept the proposal | Proposed: Standard text area keyboard conventions: Views that render text support the standard text area conventions for the platform including, but not necessarily limited to: character keys, backspace/delete, insert, "arrow" key navigation (e.g., "caret" browsing), cut, copy, paste, delete, select all, undo, navigate to start/end, navigate by paragraph, shift-to-select mechanism, etc. (Level A) |
Markku Hakkinen | Recommend changes (see comments field) | Jim's proposal to the list looks like a good resolution |
#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.
Choice | All responders |
---|---|
Results | |
Accept the proposal | 4 |
Recommend changes (see comments field) | 1 |
The proposal needs more discussion (see comments field) | 1 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
(2 responses didn't contain an answer to this question)
Responder | #69 Require single keystroke OR key combination | Comments |
---|---|---|
Jan Richards | The proposal needs more discussion (see comments field) | We need to make sure we have our :keystroke" definition and I think the current wording will work. |
Kimberly Patch | Accept the proposal | |
Simon Harper | Accept the proposal | This is a really nice (and elegant addition) IMO. |
David Poehlman | Accept the proposal | |
Jeanne F Spellman | ||
Kelly Ford | Accept the proposal | |
Jim Allan | Propose: 4.1.8 Important Command Functions: Important command functions (e.g. related to navigation, display, content, information management, etc.) are available using a single keystroke, key combination, or sequence of unmodified keystrokes. (Level AA) | |
Markku Hakkinen | Recommend changes (see comments field) | Again, Jim's proposal to the list is a good resolution. |
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
.