W3C WBS Home

Results of Questionnaire UAWG Survey for 7 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-05 to 2009-05-15.

8 answers have been received.

Jump to results for question:

  1. #38 Text Configuration
  2. #53 Allow users supplied stylesheets
  3. #55 Clarify difference between 4.1.10 and 4.1.11
  4. #63 Clarify "Display of Keyboard Commands"
  5. #65 require all platform text area keyboard conventions
  6. #69 Require single keystroke OR key combination

1. #38 Text Configuration

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

ChoiceAll 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

Details

Responder #38 Text ConfigurationComments
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.

2. #53 Allow users supplied stylesheets

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

ChoiceAll 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

Details

Responder #53 Allow users supplied stylesheetsComments
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.

3. #55 Clarify difference between 4.1.10 and 4.1.11

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

ChoiceAll 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)

Details

Responder #55 Clarify difference between 4.1.10 and 4.1.11Comments
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,

4. #63 Clarify "Display of Keyboard Commands"

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

ChoiceAll 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)

Details

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.

5. #65 require all platform text area keyboard conventions

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

ChoiceAll 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)

Details

Responder #65 require all platform text area keyboard conventionsComments
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

6. #69 Require single keystroke OR key combination

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

ChoiceAll 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)

Details

Responder #69 Require single keystroke OR key combinationComments
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.

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. Eric Hansen <ehansen@ets.org>
  4. Wayne Dick <wayneedick@gmail.com>
  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. he wen <rockywen@tencent.com>
  10. Henny Swan <hswan@paciellogroup.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.127 2015-02-04 08:52:34 carcone 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)