w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire Survey: CR Tests of 9 October 2014
The results of this questionnaire are available to anybody.
This questionnaire was open from 2014-10-08 to 2014-10-31.
1 answer has been received.
Jump to results for question:
1. 2.3.1
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | |
| Disagree with the proposal | 1 |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal |
Details
| Responder | 2.3.1 | 2.3.1 |
|---|---|---|
| Greg Lowney | Disagree with the proposal | Step 2 is not a question with a true/false answer, so "Expected Result 2 is true" is not appropriate. Either the question should be reworded along the lines of "you can move" or "Check that you can move" (the latter being used by WCAG), or the assertion should be reworded. I'd also say the phrase "device focus movement mechanism" should link to a definition. I suggest using the term "document" instead of "page", to be more technology-neutral. Take for example a web browser that supports accesskey but no way to directly navigate to any other enabled elements, and the tester provides their own HTML test document where the "5th enabled element" referred to is a control that has the accesskey attribute. Their browser then passes, despite the fact that it should fail. What this means is that, while the SC says one can move to "any enabled element", they are only required to work with one type of enabled element or even a subset of that type (e.g. those with accesskey set). I find this emotionally unsatisfying. The alternative would be to require the test document to have each type of enabled element supported by the document format, and instruct them to verify they can move the focus to each one. This test implies that we're not providing a test document (which was my understanding), but the test for 2.3.2 implies we are. I'd recommend using the term "form control" rather than "form element", as the latter seems to include static controls such as group boxes. It does not seem useful to quote the SC and then repeat its wording exactly as the Assertion. It does not appear that WCAG does this, and while ATAG includes assertions they are not merely repeating the SC text. I prefer the WCAG model which says "Procedure" instead of "Assertion". I cleaned up the formatting, turning "Expected Results 2 is true" into "Expected Results:" and "* #2 is true". I also removed unnecessary hard line breaks in the content, making it easier to edit in a variety of window sizes. |
2. 2.3.2
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal | 1 |
Details
| Responder | 2.3.2 | 2.3.2 |
|---|---|---|
| Greg Lowney | Suggest the following changes to the proposal | See comments re 2.3.1. |
3. 2.3.3
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | |
| Disagree with the proposal | 1 |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal |
Details
| Responder | 2.3.3 | 2.3.3 |
|---|---|---|
| Greg Lowney | Disagree with the proposal | The test is incorrect as step #2 requires the user agent to support hiding direct navigation shortcuts, and arguably requires that as the default configuration, but the SC does not require either. Instead, Expected Results #3 implies that the shortcut must be "modifier keys + accesskey", when in fact the SC does not require a modifier key, and the shortcut may not be specified using accesskey; in fact, the shortcut may be an unmodified key, a spoken phrase, a gesture, etc. I added a suggested rewrite of steps 2 and 3. We should use the term "user agent" instead of "browser". It looks like something following "in" was omitted in "direct commands in (e.g. accesskeys)". See comments re 2.3.1. |
4. 2.3.4
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal |
Details
| Responder | 2.3.4 | 2.3.4 |
|---|---|---|
| Greg Lowney | I added blank lines between list items and after mock headings, so they don't flow together. It should refer to "direct commands" instead of "keyboard shortcuts", as the latter is only one example of the former. I'm not sure what the steps are trying to say. Step #1 says "observe that keyboard shortcuts are present in menus", but does that mean the tester should consult the documentation to ensure that some (or all?) menu items have direct commands, or does it mean that they should verify that such commands are shown? There are no instructions on what the tester should do if user agent does not provide such commands (unlike Step 2 that says "if pass go to next else fail"). I reworded Step 1 from "observe that keyboard shortcuts are present in menus" to "Check that keyboard shortcuts are shown with all menu items that have such shortcuts" See comments re 2.3.1. |
5. 2.3.5
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal |
Details
| Responder | 2.3.5 | 2.3.5 |
|---|---|---|
| Greg Lowney |
6. 2.4.1
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal |
Details
| Responder | 2.4.1 | 2.4.1 |
|---|---|---|
| Greg Lowney |
7. 2.4.2
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal |
Details
| Responder | 2.4.2 | 2.4.2 |
|---|---|---|
| Greg Lowney |
8. 2.4.3
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal |
Details
| Responder | 2.4.3 | 2.4.3 |
|---|---|---|
| Greg Lowney |
9. 2.4.4
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal |
Details
| Responder | 2.4.4 | 2.4.4 |
|---|---|---|
| Greg Lowney |
10. 2.4.5
Summary
| Choice | All responders |
|---|---|
| Results | |
| Agree with the proposal | |
| Disagree with the proposal | |
| Neutral, will accept consensus of the group | |
| Suggest the following changes to the proposal |
Details
| Responder | 2.4.5 | 2.4.5 |
|---|---|---|
| Greg Lowney |
More details on responses
- Greg Lowney: last responded on 9, October 2014 at 07:54 (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