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 2010-04-20 to 2010-05-07.
8 answers have been received.
Jump to results for question:
Choice | All responders |
---|---|
Results | |
Accept the proposal | 5 |
Recommend changes (see comments field) | 3 |
The proposal needs more discussion (see comments field) | |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
Responder | Proposal for 5.1.1 | Comments 5.1.1 |
---|---|---|
Kimberly Patch | Accept the proposal | |
Greg Lowney | Recommend changes (see comments field) | 1. The Intent does not explain why the user might want control over notifications that do not require a key press or other input to dismiss (e.g. those that time out or are dismissed when the user navigates to a new page). You might add that "Such notifications are also problematic for users who have more and average difficulty resuming a task, including those who have attention disorders and those whose use of assistive technology or large fonts make navigation cumbersome." 2. Saying that it's "important" that these users be able to avoid unnecessary messages begs the question of why it's only Level AA. You might replace "important" with "useful". 3. The sentence structure of this success criterion, with its lists, clauses and modifiers, is complicated and ambiguous. For example, a list followed by a clause leaves it unclear whether the "based on" applies only to the last item in the list ("updating/changing information") or also on the first list item. It's similarly unclear whether it's talking about "text messaging or updating/changing information in the content" that is "non-essential or low priority", or whether it's talking about "non-essential or low priority text messages" and "updating/changing information in the content", etc. |
Simon Harper | Accept the proposal | |
Kelly Ford | Accept the proposal | keypress should be key presses |
Markku Hakkinen | Recommend changes (see comments field) | Some rewording: Intent of Success Criterion 5.1.1: Messages designed to inform the user, and requiring keyboard interaction to read, respond to or remove the message, can be a burden to users for whom keypresses can be time-consuming, tiring, or painful. It's important that these users be able to avoid unnecessary messages. |
Jim Allan | Accept the proposal | |
Patrick Lauke | Accept the proposal | |
Jeanne F Spellman | Recommend changes (see comments field) | the example needs more detail, e.g. The browser does automatic updates. When the update message is first presented, the user has the option to save their preference whether or not they are informed of messages in the future. There is an option in the Preferences area which allows the user to change what messages can be ignored. |
Choice | All responders |
---|---|
Results | |
Accept the proposal | 5 |
Recommend changes (see comments field) | 1 |
The proposal needs more discussion (see comments field) | 1 |
Disagree with the proposal | 1 |
Neutral - will accept the consensus of the group |
Responder | Proposal for 5.2.1 Form Submission | Comments 5.2.1 |
---|---|---|
Kimberly Patch | Accept the proposal | |
Greg Lowney | Disagree with the proposal | 1. "a global option disable" should be "a global option to disable". 2. I find the draft wording of the SC very problematic. For example: a. What if there is no submit control and the other method is the only method (e.g. a hotkey or menu item to send)? What about technologies other than HTML where there is no dedicated Submit control? b. Could giving the user the ability to require confirmation before submitting or canceling forms be an acceptable alternative to disabling the default method? c. The intent paragraph seems to focus almost exclusively on use of the Enter key, but the SC itself is much broader than that; the intent paragraph should address the full scope of the SC in order to justify that breadth. d. Why would this be specific to form submissions? Wouldn't the problem be equally bad for, say, cases where the Escape key dismisses a form and causes the user to lose all the data they'd entered? By analogy wouldn't they want the ability to require a specific control rather than responding to the keyboard input when the focus is on other controls? e. If there is a submit form control, and the author associates that with a keystroke (e.g. using the accesskey= to associate a key combination with the submit control, using Javascript to cause the Esc key to activate it), pressing that keystroke will activate the control and submit the form regardless of where the focus was in the form. In that case, the implementation passes the SC as it's currently worded, despite clearly not meeting its intent. f. If this applies only to forms, I can imagine it leading to debate over whether something is or is not a form as developers, authors, or purchasers/regulators try to force or avoid implementing this feature. We do not define forms or submission controls, and while they're clear in HTML, they may not be clear in other technologies (e.g. Canvas with AJAX). |
Simon Harper | Accept the proposal | Should login be an exception? - No all form submission should be consistent. |
Kelly Ford | Accept the proposal | |
Markku Hakkinen | Accept the proposal | |
Jim Allan | Accept the proposal | |
Patrick Lauke | Recommend changes (see comments field) | "global option disable" > "global option to disable" don't see why login should be an exception...if hitting enter to, as the example says, advance to next field in AT also submits form, this would still cause a problem for those users, whether it's a login form or not. "This allows the user to complete forms from the banking website" do we need to specifically say the "from the banking website" bit? I'd remove it, or qualify it with a "forms on a banking site, for instance," incidentally, don't think any current browsers offer this option, but it should be trivial to implement. |
Jeanne F Spellman | The proposal needs more discussion (see comments field) | How to handle login? I accept the proposal for what is there, but I don't want to see simple forms overlooked. |
Choice | All responders |
---|---|
Results | |
Accept the proposal | 4 |
Recommend changes (see comments field) | 3 |
The proposal needs more discussion (see comments field) | 1 |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
Responder | Proposal for 5.3.1 Accessible Format | Comments 5.3.1 |
---|---|---|
Kimberly Patch | Accept the proposal | |
Greg Lowney | Recommend changes (see comments field) | 1. Minor: "and identified" should be "that is identified". 2. Minor: Is "benchmark" really the best term to use when we mean a standard or set of guidelines? While it is used that sense, that's certainly different than the sense used in Wikipedia's article on "Benchmark (computing)", for example. Thefreedictionary.com and Merriam-webster both define it as "a standard". 3. Minor: I would change "who utilize…accessible formats" to something like "who rely on alternative reading tools or the variety of presentation options made possible by accessible formats". |
Simon Harper | Accept the proposal | |
Kelly Ford | Recommend changes (see comments field) | Should benchmark be standard? |
Markku Hakkinen | Accept the proposal | |
Jim Allan | Accept the proposal | |
Patrick Lauke | The proposal needs more discussion (see comments field) | "it must conform to WCAG 2.0 Level "A" " I'd add an "at least" in there "and if not provided as Web content" > "and, if not provided as Web content" I'm not certain if the wording for the non-Web content bit provides strange loopholes. What if a user agent provides its documentation purely as a braille manual? It's a published, recognised format...but will be of little to no use for deaf users, for instance. |
Jeanne F Spellman | Recommend changes (see comments field) | needs a non-web example. |
See 5.3.2 Document Accessibility Features
Choice | All responders |
---|---|
Results | |
Accept the proposal | 4 |
Recommend changes (see comments field) | 3 |
The proposal needs more discussion (see comments field) | |
Disagree with the proposal | |
Neutral - will accept the consensus of the group |
Responder | Proposal for 5.3.2 Document Accessibility Features | Comments 5.3.2 |
---|---|---|
Kimberly Patch | Accept the proposal | |
Greg Lowney | Recommend changes (see comments field) | 1. The first sentence of the Intent paragraph essentially says that providing a list of features provides the user with a list of features. How about something like "Documentation that describes the product's accessibility features enables users to find and learn how to use the features they need. Features that are not documented may as well not exist for many users, especially if they are effectively hidden within a large set of menus, dialog boxes, and configuration files. This is especially critical for users who rely on accessibility features, as they may need to find and configure those features before they can effectively explore the product's user interface. 2. The example just restates the success criterion. I think it would be more effective to add specific, user-centered examples, such as "Jack uses an alternative keyboard and cannot use a mouse. When he needs to select and copy text from a Web page, he searches the online help for "keyboard selection" and gets a page which tells him how to turn on 'caret browsing' and use arrow and shift keys to select the text he wants." Another would be "Francia relies on a screen reader, and the browser's documentation tells her that she has to start the browser with a specific command-line option to enable its screen reader compatibility features." (That is assuming we don't want to mention Google Chrome by name.) 3. Just a thought: should we require the documentation to address accessibility features that a product lacks? For example, we could require that the documentation for a product claiming Level A conformance must list any Level A criteria for which it claims an exemption (e.g. lack of keyboard access to feature considered too minor to block their conformance claim)? In the Designed for Microsoft Windows standard, for example, we allowed exceptions for minor features (which were defined as features which were not installed by default, and not mentioned in pre-purchase advertising or on the box). The goal would be to prevent a user from tearing their hair out trying to figure out how to make something work when it is designed not to. |
Simon Harper | Accept the proposal | |
Kelly Ford | Recommend changes (see comments field) | In the first sentence compatibility should be assistive technology compatibility to avoid confusion. |
Markku Hakkinen | Accept the proposal | |
Jim Allan | Accept the proposal | |
Patrick Lauke | Recommend changes (see comments field) | "and listing any supported third party assistive technologies that may be supported or required." remove the first "supported" |
Jeanne F Spellman |
Proposals for the remaining sections of Implementing UAAG 2.0 section 5 are needed. Please choose a section to write and note the section number below.
Responder | I will write implementing info for success criteria: |
---|---|
Kimberly Patch | I can do 5.3.4 |
Greg Lowney | |
Simon Harper | |
Kelly Ford | I'll write 5.3.3 on changes between versions and 5.3.5 on context sensitive help. |
Markku Hakkinen | Could take something on after I clear existing action items. |
Jim Allan | |
Patrick Lauke | |
Jeanne F Spellman |
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
.