w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire Understanding Document Language
The results of this questionnaire are available to anybody.
This questionnaire was open from 2017-09-20 to 2017-10-19.
4 answers have been received.
Jump to results for question:
1. Target Size
Please review the understanding document for target size.
Is this ready for the AGWG review?
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ready for review by the AGWG | 2 |
| No, substantial changes are needed. Suggestions are listed in the comments below. | 1 |
| No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | 1 |
Details
| Responder | Target Size | Comments |
|---|---|---|
| Patrick Lauke | Yes, it is ready for review by the AGWG | Tiny amendment suggestions: "The issue can be further complicated on for responsive/mobile" > "The issue can be problematic for responsive/mobile sites" "Users who have low vision may better see the target" > "Users who have low vision and may have trouble seeing the target" (to keep stylistically with the other bullets) In examples 1, 3 and 5 remove "touch", as this is about target sizes in general, not limited to touch. |
| Kathleen Wahlbin | Yes, it is ready for review by the AGWG | |
| Detlev Fischer | No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | I think this is a good start but needs a bit more work. Things like "a larger target will help them greatly in having positive outcomes on the web page" is just too vague - we should be describing more precisely in what sense a large target is helpful. There are also sentences where bits seem to be missing, such as "The issue can be further complicated on for responsive/mobile" I think we should possibly explain the exceptions (which are many) and the rationale behind them (like the trade-off of more vertical width being necessary which cab make use more difficult on things like drop-down menus and moves more stuff 'below the fold'. We may also point out that in many cases, it is not needed to resort to exceptions, e.g., when drop-dowen menus are short, when there are only few links in inline text with no risk of overlapping, etc. In the examples, I am not sure if we should give the designers the idea that it is fine to provide a mechnanism "to allow users to increase the target size of the targets on the page to meet the minimum target dimensions." This looks like promoting style switcher type solutions - yes, it is a way of meeting the SC, but do we really need to show that? |
| John Foliot | No, substantial changes are needed. Suggestions are listed in the comments below. | Intent Section: * Editorial: "The issue can be further complicated --> on for <-- responsive/mobile..." (on for ?) Examples Section: * The first example really doesn't illustrate anything. In fact, what about when you have those 3 buttons side-by-side without sufficient spacing between the buttons? Many of the affected users would still have difficulty selecting individual buttons. * Examples 4, 5, & 6 appear to be exceptions, rather than examples. * It is unclear exactly what is being conveyed with the examples offered - there are situations, but no observational / learning-point coming from the examples. This section could stand with a serious re-thinking. Techniques Section: * Ideally there should be an indication of [Future link(s)] in the Draft Understanding documents for clarity. |
2. Target Size (no exception)
Please review the understanding document for target size.
Is this ready for the AGWG review?
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ready for review by the AGWG | 2 |
| No, substantial changes are needed. Suggestions are listed in the comments below. | 1 |
| No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | 1 |
Details
| Responder | Target Size (no exception) | Comments |
|---|---|---|
| Patrick Lauke | Yes, it is ready for review by the AGWG | Same comments as for "Target Size" (removing "touch" only applies to the one example) |
| Kathleen Wahlbin | Yes, it is ready for review by the AGWG | |
| Detlev Fischer | No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | Similar remarks as for the SC above (identical issues) only that here of course, we would not need to go into explaining the exceptions. |
| John Foliot | No, substantial changes are needed. Suggestions are listed in the comments below. | Intent Section: * Editorial: "The issue can be further complicated --> on for <-- responsive/mobile..." (on for ?) Examples Section: * The first example really doesn't illustrate anything. In fact, what about when you have those 3 buttons side-by-side without sufficient spacing between the buttons? Many of the affected users would still have difficulty selecting individual buttons. * It is unclear exactly what is being conveyed with the single example offered - there is no observational / learning-point coming from the example. This section could stand with a serious re-thinking. Techniques Section: * Ideally there should be an indication of [Future link(s)] in the Draft Understanding documents for clarity. |
3. Accessible Name
Please review the understanding document for accessible name.
Is this ready for the AGWG review?
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ready for review by the AGWG | |
| No, substantial changes are needed. Suggestions are listed in the comments below. | 2 |
| No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | 2 |
Details
| Responder | Accessible Name | Comments |
|---|---|---|
| Patrick Lauke | No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | "One means of input is speaking menu, link and button labels that appear on a webpage." this may need expanding/contextualising a bit, as it's a bit of a "cold open". Start by explaining that there are users with voice/speech recognition, and that in general these users can navigate/interact with web pages by speaking the visible labels of menus, links etc. The two examples given in the "Intent" section could really do with actual HTML code to illustrate why/how the accessible name doesn't match the visible label. Or remove these from "Intent" and just rely on having these as failure techniques? |
| Kathleen Wahlbin | No, substantial changes are needed. Suggestions are listed in the comments below. | The failures seem repetitive. Can we combine into a single failure? |
| Detlev Fischer | No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | We need to state as simply as possible at the start of the intent section what this SC requires, then explain why. Currently the text is quite wordy and I do not find it easy to parse. "Here are some real-life examples: .." should go under Examples The text under "Techniques" still has the instructions in it which makes it hard to use. |
| John Foliot | No, substantial changes are needed. Suggestions are listed in the comments below. | Intent Section: * The sentence with "...visible label they see but it does not match the Accessible Name, which is what is enabled as a command." is factually incorrect and does not make sense. The Accessible name is the 'Label' for the command/function, but does not 'enable' it (that is left to scripting or user-agent behaviors). * Suggested editorial change: "But if a webpage contains many hidden, extra commands, it becomes easy to unexpectedly <strike>click</strike> <ins>activate</ins> a hidden command." (alternative to activate may also be trigger) Benefits Section: * The benefit speaks about visible tab Focus ("...users will have fewer surprising changes of focus...), yet that aspect is not outlined or mentioned in the Intent section. If the Intent section is to outline the problems being addressed, then it would seem that any benefit would be a problem addressed, and so the issue of hidden tab focus should be included as part of the Intent / Problem Statement Techniques Section: * Ideally there should be an indication of [Future link(s)] in the Draft Understanding documents for clarity. |
4. Character Key Shortcuts
Please review the understanding document for character key shortcuts.
Is this ready for the AGWG review?
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ready for review by the AGWG | 1 |
| No, substantial changes are needed. Suggestions are listed in the comments below. | 1 |
| No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | 1 |
Details
| Responder | Character Key Shortcuts | Comments |
|---|---|---|
| Patrick Lauke | No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | "Intent" relies heavily on referencing Gmail (by name), which of course is not appropriate and should be generalised. |
| Kathleen Wahlbin | Yes, it is ready for review by the AGWG | |
| Detlev Fischer | As I said above for "Accessible name", I think section "Intent" should state very briefly what situation the SC is supposed to prevent - then embark on a longer explanation. I find the text too long - maybe it needs sub-headings. "Here some real-life scenarios:" this should go under Examples. | |
| John Foliot | No, substantial changes are needed. Suggestions are listed in the comments below. | Intent Section: * It is not always clear that this SC is in reference to *single* key shortcuts, and that [Modifier]+character-key is out of scope. Some sentences refer to Character-key(s), while others do reference single-key shortcuts. Editorially this needs to be reviewed and tightened, with a consistent reference to Single Key shortcuts (only). Benefits Section: * Editorial: The sentence "Speech users will be able to turn off single key shortcuts so they can avoid accidentally firing batches of them at once." needs to also indicate that re-mapping single key shortcuts to [Modifier]+character-key is also an acceptable option: [Revision] "Speech users will be able to turn off single key shortcuts<ins>, or re-map them to a [Modifier]+character-key, </ins> so they can avoid accidentally firing batches of them at once." Examples Section: * The first example is a restatement of the same scenario from the Benefits section. Recommend to use a different user-story * Examples 3 & 4 appear to indicate that the content author is required to furnish the mechanism. Q: can these techniques be accomplished today, either via author input, or via Assistive Technology? Examples of this in practice would serve as better Examples. Techniques Section: * Ideally there should be an indication of [Future link(s)] in the Draft Understanding documents for clarity. |
5. Device Sensors
Please review the understanding document for device sensors.
Is this ready for the AGWG review?
Summary
| Choice | All responders |
|---|---|
| Results | |
| Yes, it is ready for review by the AGWG | 1 |
| No, substantial changes are needed. Suggestions are listed in the comments below. | 2 |
| No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | 1 |
Details
| Responder | Device Sensors | Comments |
|---|---|---|
| Patrick Lauke | Yes, it is ready for review by the AGWG | Minor amendments: "...may need to turn off senor inputs..." > "...may need to turn off sensor inputs..." |
| Kathleen Wahlbin | No, substantial changes are needed. Suggestions are listed in the comments below. | We need to add a failure technique for this one |
| Detlev Fischer | No, substantial changes are needed. Suggestions are listed in the comments below. | "..and can be disabled to prevent accidental actuation.." this is usually not something the author has any control over? My understanding (but I could be wrong) is that the OS makes events like shake avaiable for authors to tap into when they are not disabled in OS settings. So it is really about providing equivalent input whenever authors choose to listen to, and implement actions on, these events? I would like to discuss whether we would alo want to cover indirect input via 'sensors' like the camera (gestures, movements in field of view, etc). |
| John Foliot | No, editorial changes are needed. Suggestions have been made or are listed in the comments below. | Techniques Section: * Ideally there should be an indication of [Future link(s)] in the Draft Understanding documents for clarity. |
More details on responses
- Detlev Fischer: last responded on 5, October 2017 at 08:56 (UTC)
- John Foliot: last responded on 9, October 2017 at 23:19 (UTC)
Non-responders
The following persons have not answered the questionnaire:
- David MacDonald
- Kimberly Patch
- Alastair Campbell
- Mike Pluke
- Jonathan Avila
- Jatin Vaishnav
- Kevin White
- Victoria Clark
- Rachael Bradley Montgomery
- Melanie Philipp
- Ruoxi Ran
- Charles Adams
- Jamie Herrera
- Audrey Maniez
- Joe Humbert
- Alain Vagner
- Perrin Anto
- Rachele DiTullio
- Jan Jaap de Groot
- Michael Keane
- Devanshu Chandra
- Julia Kim
- Quintin Balsdon
- Carolina Crespo
- Bram Janssens
- Jeroen Hulscher
- Jeanne Erickson Cooley
- Gert-Jan Vercauteren
- Karla Rubiano
- Aashutosh K
- Hidde de Vries
- Julian Kittelson-Aldred
- Mike Pedersen
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
Report issues
on GitHub project