W3C WBS Home

Results of Questionnaire UAWG Survey for 29 April

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 2010-04-27 to 2010-05-07.

6 answers have been received.

Jump to results for question:

  1. Proposal for 5.3.5 Context Sensitive Help
  2. Proposal for 5.3.6 Appropriate Language

1. Proposal for 5.3.5 Context Sensitive Help

See 5.3.5 Context Sensitive Help

Summary

ChoiceAll 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

Details

Responder Proposal for 5.3.5 Context Sensitive HelpComments 5.1.1
Patrick Lauke The proposal needs more discussion (see comments field) it would be helpful to define exactly what we mean, ideally with an example.
Greg Lowney The proposal needs more discussion (see comments field) 1. Major: Context-sensitive help only makes sense for accessibility features that have a clear context in the user interface (e.g. what are the accessibility features relating to the currently selected content, the control with the focus, the currently displayed dialog box, etc.; even command-line options can be identified from the command line using a help switch.

However, some accessibility features don't have an UI in which to provide context-sensitive help. For example, there would be no appropriate place to put context-sensitive help for caret browsing if the only way to turn it on and off is by pressing the F7 key.

We could fix this by rewriting the SC along the lines of "If the user agent provides context-sensitive help, such help is provided for all user agents features that benefit accessibility." or "There is context-sensitive help on all user interface elements that benefit accessibility

2. Medium: At what granularity is context-sensitivity mandated? For example, is it intended that this requires a "Ignore colors" check box to have its own help topic that is available when the focus is on that control, or is it enough to have a single help topic for the entire dialog box in which that control appears?

3. Medium: This indirectly but effectively requires context sensitive help to for AAA compliance. If that's the goal we should make it explicit. And if that's the case, should it require context-sensitive help more generally, rather than only on accessibility features?

4. Minor: context-sensitive help seems to be more often spelled with a hyphen than without.
Markku Hakkinen Recommend changes (see comments field) As stated, this is problematic. I can see accessibility features that don't have any explicit UI that don't provide a context for context sensitive help to be implemented. Such must be documented elsewhere, in supporting materials.

Perhaps this change is a starting point:

5.3.5 Context Sensitive Help: There is context-sensitive help provided for all user agent features that benefit accessibility AND that have exposed user interface dialogs or controls which allow users to enable, operate, or adjust the feature. (Level AAA)
Kelly Ford Accept the proposal
Jim Allan The proposal needs more discussion (see comments field) couldn't find any colored text. assume the text for intent is from http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0094.html
how do we know which features benefit accessibility. could be nearly anything.
Seems very broad. defining a list is too restrictive.
Simon Harper Accept the proposal

2. Proposal for 5.3.6 Appropriate Language

See 5.3.6 Appropriate Language

Summary

ChoiceAll responders
Results
Accept the proposal 1
Recommend changes (see comments field)
The proposal needs more discussion (see comments field) 3
Disagree with the proposal 2
Neutral - will accept the consensus of the group

Details

Responder Proposal for 5.3.6 Appropriate LanguageComments 5.2.1
Patrick Lauke Disagree with the proposal is this required, if we're already mandating adherence to wcag 2 for electronic documentation?
Greg Lowney The proposal needs more discussion (see comments field) 1. Major: Saying this applies to user agents "producing an end user experience such as speech" is problematic because it is far too broad: pretty much everything the user agent does is geared towards "producing an end user experience (including but not limited to speech)". Therefore I think it needs to be more specific.

2. Medium: It's written in a broad fashion to cover more than just speech synthesis, but to what other experiences would it apply? Would an example be using fonts appropriate for the language, such as display the hanja rather than kanji for the same Unicode code point if the language is identified as Korean?
Markku Hakkinen The proposal needs more discussion (see comments field) Whoa. What is the real intent behind "Appropriate Language"? Are we talking about writing style appropriate to the end user or i18n/l10n? I would think i18n/l10n issues are dealt with elsewhere, as inherent to the presentational requirements of the UI with regards to speech/fonts/etc. Since this guideline is lumped together with help/doc guidelines, I am thinking the "Appropriate Language" likely should mean writing style, particularly to provide understandable, non-techy/non-jargony descriptions on how to use a given feature.

Perhaps I'm missing something?
Kelly Ford Accept the proposal
Jim Allan Disagree with the proposal couldn't find any colored text. assume the text for intent is from http://lists.w3.org/Archives/Public/w3c-wai-ua/2010JanMar/0094.html
high: was surprised that this is about speech synthesis. was thinking it was more about the help was written at an 'appropriate' level for users and not 'overly' technical. This really seems more of a technique under programatically determined.
medium:
it is poorly worded.
proposed 5.3.6 Appropriate Language. If characteristics of the user agent involve producing an end user experience such as speech, the user agent must to react appropriately to language changes.
Simon Harper The proposal needs more discussion (see comments field) Not sure what the language means so I think it needs more discussion.

More details on responses

Non-responders

The following persons have not answered the questionnaire:

  1. Judy Brewer <jbrewer@w3.org>
  2. Jan Richards <jrichards@ocadu.ca>
  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. Jeanne F Spellman <jeanne@w3.org>
  10. Kimberly Patch <Kim@redstartsystems.com>
  11. he wen <rockywen@tencent.com>
  12. Henny Swan <hswan@paciellogroup.com>
  13. Shaohang Yang <shaohang.ysh@alibaba-inc.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)