w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire UAWG Survey for 27 May - 10 June
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-05-25 to 2010-06-11.
5 answers have been received.
Jump to results for question:
- Proposal for 3.10.5 Scrollbars
- Proposal for 3.10.8 Do Not Take Focus
- Proposal for 3.10.9 Stay on Top
- Proposal for 3.10.10 Close Viewport
- Proposal for 3.10.11 Same UI
- Proposal for 3.10.12 Indicate Viewport Position
- Proposal for 4.7x (formerly 3.3.2) 4.7.x Location in Hierarchy
- Proposal for 5.3.6 Appropriate Language
1. Proposal for 3.10.5 Scrollbars
See 3.10.5 Scrollbars Intent, Examples and Related Resources.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Accept the proposal | 2 |
| Recommend changes (see comments field) | 1 |
| The proposal needs more discussion (see comments field) | 2 |
| Disagree with the proposal | |
| Neutral - will accept the consensus of the group |
Details
| Responder | Proposal for 3.10.5 Scrollbars | Comments 3.10.5 |
|---|---|---|
| Kimberly Patch | Accept the proposal | Accept, but I do have something to think about |
| Greg Lowney | The proposal needs more discussion (see comments field) | 1. The SC wording prevents the user from having the option to omit scrollbars, and prohibits controls other than scrollbars even if they provide equivalent benefits, both of which should be allowed. I also think we can omit the clause ("including after user preferences have been applied)" as inherent and making it harder to read; otherwise we'd have to include it in many places where we talk about rendered content.I suggest changing the SC to read "The user has the ability to have all scrollbars or equivalent controls displayed for all graphical viewports where the rendered content extends beyond the viewport dimensions. This ability overrides any values specified by the author. (Level A)". 2. Standard scrollbars provide benefits beyond those mentioned in the Intent. The Intent currently does not indicate that or why the mechanism should provide indication of the direction of the extra content, indicate how much content is outside the viewport, and provide the user with a control for panning/scrolling the viewport. Which of those do we want to require? As worded, the intent would be met by simply changing the color of the bounding box to indicate there was extra content, yet that would only provide a small set of the benefits of a scrollbar. Similarly, do we want a read-only scrollbar, which the user could look at but not drag, to be acceptable? I suggest "…scrollbars provide a visible indication that not all of the rendered content is currently visible within the viewport, and the direction where that content is located." 3. Cross-reference 3.10.12 (Indicate Viewport Position). |
| Kelly Ford | Accept the proposal | |
| Markku Hakkinen | The proposal needs more discussion (see comments field) | I almost said accept, but some points got me thinking: 1. Reading this proposed text, I assume the UA will automatically detect when any content exceeds the viewport size and force scroll bar display, even if the author has elected to hide the scroll bars. What this really seems to boil down to is simple: disallow author hiding of scroll bars. It should no longer be an option for authors. All of the UAs I tested have the desired behavior: scroll bars displayed when the content dimension exceeds the viewport dimensions. Authors who create pop-up windows whose content does not exceed viewport get nice clean window borders. I am thinking the ability to hide scroll bars may be legacy, in that earlier UAs always showed scroll bars irrespective of whether they were active. 2. Scroll bars not only show position, and direction, but also most now size the scroll thumb to be proportional to the amount of content currently displayed. This would have to be available to the AT. |
| Jim Allan | Recommend changes (see comments field) | Additional Example: A Web site presents a recipe that fits within a viewport without scroll bars. The user scales the font such that the the recipe exceeds the vertical and horizontal dimension of the viewport. The user agent detects that the veiwport bounds are exceeded by the newly scaled text. The user agent displays appropriate scroll bars that allow the user to read the text. |
2. Proposal for 3.10.8 Do Not Take Focus
See 3.10.8 Do Not Take Focus Intent, Examples and Related Resources.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Accept the proposal | 1 |
| Recommend changes (see comments field) | |
| The proposal needs more discussion (see comments field) | 2 |
| Disagree with the proposal | |
| Neutral - will accept the consensus of the group | 2 |
Details
| Responder | Proposal for 3.10.8 Do Not Take Focus | Comments 3.10.8 |
|---|---|---|
| Kimberly Patch | The proposal needs more discussion (see comments field) | Two issues: 1. The user needs to be able to specify that focus change or not change with the pop up. It's also problem when a pop-up is present but is difficult to get to. 2. RE: "perhaps with a click on the notification mechanism" -- there has to also be keyboard shortcut. |
| Greg Lowney | The proposal needs more discussion (see comments field) | 1. Does "user's request" mean in response to user input, even if the user may not realize that a new window will open? For example, the user is running a web application and chooses the "Save" command, and although this normally doesn't trigger a pop-up, this time a network error or server limit prevents the document from being saved, and the application wants to put up a warning dialog box telling the user and asking how it should proceed. This dialog would be in response to user input, yet not expected by the user. If the user has chosen to allow pop-ups but not to let them take focus, should the browser give this dialog focus? 2. It says "the user has the option that if *a* 'top-level' viewport opens", but what it means is "if a 'top-level' viewport opens *without explicit user request*", which could be written that way or "when *such a* 'top-level' viewport opens". 3. It's a minor concern, but I'm not sure that 3.10.8 (Option to have new windows not take focus) isn't mostly redundant given 3.10.7 (Option to open new windows only on request). I'd like to see some real usage cases, as the current example is too general, vague, and full of options for me to really get the point. |
| Kelly Ford | Neutral - will accept the consensus of the group | I think I wrote this one. It is kind of verbose but I'll accept the group's opinion. |
| Markku Hakkinen | Neutral - will accept the consensus of the group | |
| Jim Allan | Accept the proposal |
3. Proposal for 3.10.9 Stay on Top
See 3.10.9 Stay on Top Intent, Examples and Related Resources.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Accept the proposal | 2 |
| Recommend changes (see comments field) | |
| The proposal needs more discussion (see comments field) | |
| Disagree with the proposal | |
| Neutral - will accept the consensus of the group | 3 |
Details
| Responder | Proposal for 3.10.9 Stay on Top | Comments 3.10.9 |
|---|---|---|
| Kimberly Patch | Accept the proposal | |
| Greg Lowney | Neutral - will accept the consensus of the group | 1. On first reading I misinterpreted this because it said the window would "remain" on top. Since it may not already be on top, I think it would be clearer as "be displayed and remain 'on top'", or at least make this explicit in the Intent section. 2. Shouldn't this apply only to graphical, "top-level" viewports? Is there a reason we can't use the term "windows" for these, or am I misinterpreting the glossary entry for "top-level" viewport? 3. The Example talks about the window being "top most window in the user agent" but the SC is written so that it must be the topmost window in the entire system. Which are we expecting? 4. I usually use "topmost" rather than "top most", as does the Oxford English Dictionary. 5. The phrase "top-level" viewport should link to its definition. |
| Kelly Ford | Accept the proposal | |
| Markku Hakkinen | Neutral - will accept the consensus of the group | |
| Jim Allan | Neutral - will accept the consensus of the group |
4. Proposal for 3.10.10 Close Viewport
See 3.10.10 Close Viewport Intent, Examples and Related Resources.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Accept the proposal | 3 |
| Recommend changes (see comments field) | |
| The proposal needs more discussion (see comments field) | 2 |
| Disagree with the proposal | |
| Neutral - will accept the consensus of the group |
Details
| Responder | Proposal for 3.10.10 Close Viewport | Comments 3.10.10 |
|---|---|---|
| Kimberly Patch | The proposal needs more discussion (see comments field) | Something to watch in general This language implies mouse control: The user activates a close button. |
| Greg Lowney | The proposal needs more discussion (see comments field) | 1. If "'top-level' viewport" means window, which is how I interpret the glossary entry, then I don't understand the need for this success criterion because pretty much all user agents allow the user to close their windows. If "'top-level' window" should mean tab or document, then the glossary entry is misleading. And in that case, are there any known user agents that don't support this? Can we give a realistic example where it would be a problem? |
| Kelly Ford | Accept the proposal | |
| Markku Hakkinen | Accept the proposal | |
| Jim Allan | Accept the proposal |
5. Proposal for 3.10.11 Same UI
See 3.10.11 Same UI Intent, Examples and Related Resources.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Accept the proposal | 2 |
| Recommend changes (see comments field) | 2 |
| The proposal needs more discussion (see comments field) | 1 |
| Disagree with the proposal | |
| Neutral - will accept the consensus of the group |
Details
| Responder | Proposal for 3.10.11 Same UI | Comments 3.10.11 |
|---|---|---|
| Kimberly Patch | Accept the proposal | |
| Greg Lowney | Recommend changes (see comments field) | 1. The goal seems to be that either that the user sets a configuration to be used for all new browser windows, not including pop-up windows such as dialog boxes and floating toolbars (which would not have all the menu bars, tabs, etc. found on document windows). The current wording fails to address this by (a) it doesn't allow an exemption for dialog boxes, floating toolbars, and the like, and (b) by saying that new windows inherit configuration from the "current or spawning" window, it doesn't address the first browser window opened in a new session. It would be reasonable to say that the user should be able to set the default configuration for new windows, and optionally add that subsequent windows in the same session should inherit the configuration of the window which spawned the new window. |
| Kelly Ford | Accept the proposal | |
| Markku Hakkinen | The proposal needs more discussion (see comments field) | Accept, but a clear defintion of what the UI elements are would helpful. |
| Jim Allan | Recommend changes (see comments field) | in the SC ... the current or spawning viewpor. should be "... the current or spawning viewport". Additional example: the we page opens a new window that the author has coded to display without 'chrome' and contains content from the same website. The user has a setting to override the author 'no-chrome' setting, so the new viewport has a full user interface. |
6. Proposal for 3.10.12 Indicate Viewport Position
See 3.10.12 Indicate Viewport Position Intent, Examples and Related Resources.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Accept the proposal | 4 |
| Recommend changes (see comments field) | |
| The proposal needs more discussion (see comments field) | 1 |
| Disagree with the proposal | |
| Neutral - will accept the consensus of the group |
Details
| Responder | Proposal for 3.10.12 Indicate Viewport Position | Comments 3.10.12 |
|---|---|---|
| Kimberly Patch | Accept the proposal | |
| Greg Lowney | Accept the proposal | 1. Cross-reference the requirement to provide scrollbars. |
| Kelly Ford | Accept the proposal | |
| Markku Hakkinen | The proposal needs more discussion (see comments field) | Intent suggests the thumb sizing relative to what is viewed, though it is not explicit. Rewrite: 3.10.12 Indicate Viewport Position: Indicate the viewport's position relative to rendered content (e.g., the proportion along an audio or video timeline, the proportion of a Web page before the current position ), and what proportion of the content is currently visible in the viewport along either vertical or horizontal dimension. (Level AAA) |
| Jim Allan | Accept the proposal |
7. Proposal for 4.7x (formerly 3.3.2) 4.7.x Location in Hierarchy
See 4.7.x Location in Hierarchy. Proposal from Simon.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Accept the proposal | 1 |
| Recommend changes (see comments field) | |
| The proposal needs more discussion (see comments field) | 2 |
| Disagree with the proposal | |
| Neutral - will accept the consensus of the group | 2 |
Details
| Responder | Proposal for 4.7x (formerly 3.3.2) 4.7.x Location in Hierarchy | Comments 3.10.12 |
|---|---|---|
| Kimberly Patch | The proposal needs more discussion (see comments field) | Wordsmithing -- I think it will be easier to read this way: change ...elements), and only if the user agent keeps an internal model of the hierarchy which it does not expose via the DOM or some other accessibility mechanism. to ...elements). This node view is required only if user agent keeps an internal model of the hierarchy but does not expose it via the DOM or some other accessibility mechanism. |
| Greg Lowney | The proposal needs more discussion (see comments field) | 1. I'm afraid this is still too complicated for me to follow. We really need to simply the wording to make it clearer and more easily understood. Can you try writing it out? Are you saying something like: (a) When the user agent determines that content represents a hierarchy, and (b) that hierarchy is not explicitly represented in markup (e.g. not HTML nested lists and heading), and (c) the user agent keeps an internal model of that hierarchy (as opposed to just rendering the visuals and forgetting it?), and (d) it does not expose that hierarchy programmatically (e.g. doesn't expose it through the DOM or MSAA) (e) THEN the user agent should allow the user to view the path of nodes from the root of that hierarchy to the node that they are currently viewing (e.g. an ordered list of category or document names). 2. The complicated sentence leaves me unclear exactly how the HTML 5 Canvass Element or itemprop microdata fit into your description. 3. The success criterion merely requires the user agent to present a list, whereas the Intent and Examples talk about the user using using the list as a navigation mechanism (e.g. list of links). Which are you trying to require? |
| Kelly Ford | Accept the proposal | |
| Markku Hakkinen | Neutral - will accept the consensus of the group | |
| Jim Allan | Neutral - will accept the consensus of the group | I have trouble parsing this. |
8. Proposal for 5.3.6 Appropriate Language
See 5.3.6 Appropriate Language
Intent, Examples and ResourcesSummary
| Choice | All responders |
|---|---|
| Results | |
| Accept the proposal | 1 |
| Recommend changes (see comments field) | 1 |
| The proposal needs more discussion (see comments field) | 2 |
| Disagree with the proposal | |
| Neutral - will accept the consensus of the group | 1 |
Details
| Responder | Proposal for 5.3.6 Appropriate Language | Comments 3.10.12 |
|---|---|---|
| Kimberly Patch | The proposal needs more discussion (see comments field) | missing the level |
| Greg Lowney | The proposal needs more discussion (see comments field) | From the 4/29 survey: 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? New: 3. Medium: Instead of "react appropriately to language changes", it should probably be "react appropriately to *recognized* language changes". Otherwise we'd seem to be requiring user agents to detect language and language changes in the content, and I don't think that was the intention. |
| Kelly Ford | Accept the proposal | |
| Markku Hakkinen | Neutral - will accept the consensus of the group | |
| Jim Allan | Recommend changes (see comments field) | 5.3.6 Appropriate Language If characteristics of the user agent involve producing an end user experience such as speech, the user agent changes language as appropriate based on the supported technologies. |
More details on responses
- Kimberly Patch: last responded on 25, May 2010 at 21:44 (UTC)
- Greg Lowney: last responded on 27, May 2010 at 07:24 (UTC)
- Kelly Ford: last responded on 27, May 2010 at 12:10 (UTC)
- Markku Hakkinen: last responded on 27, May 2010 at 17:01 (UTC)
- Jim Allan: last responded on 3, June 2010 at 16:13 (UTC)
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
Report issues
on GitHub project