w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody.
This questionnaire was open from 2021-11-12 to 2022-06-07.
18 answers have been received.
Jump to results for question:
Melanie opened issue 2248 about an example in the technique for dragging, 219.
PR 2356 removes one example from the technique.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 12 |
Agree with adjustment | |
Something else |
(6 responses didn't contain an answer to this question)
Responder | DONE: Does a Technique G219 example fail Pointer Gestures? #2248 | Comments |
---|---|---|
Rain Breaw Michaels | ||
Oliver Keim | ||
Charles Adams | ||
Marc Johlic | ||
David MacDonald | ||
Patrick Lauke | ||
Stefan Schnabel | Agree with the update | |
Jaunita George | Agree with the update | |
Todd Libby | Agree with the update | |
Gundula Niemann | Agree with the update | |
Rachael Bradley Montgomery | Agree with the update | |
Laura Carlson | Agree with the update | |
Wilco Fiers | Agree with the update | |
Mike Pluke | Agree with the update | |
Bruce Bailey | Agree with the update | |
Michael Gower | Agree with the update | |
Detlev Fischer | Agree with the update | |
Alastair Campbell | Agree with the update |
In issue 1917 Michael Gower asked whether there was sufficient evidence of dragging solving a real problem.
Detlev did some research and responded, and later asked organisations for further information, and got a response.
The question is whether we, as a group, agree there is sufficient evidence for this SC solving a problem.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with including dragging | 7 |
Do not agree with including dragging | |
Something else | 2 |
(9 responses didn't contain an answer to this question)
Responder | DONE: Dragging Movements needs some attention #1917 | Comments |
---|---|---|
Rain Breaw Michaels | ||
Oliver Keim | ||
Charles Adams | ||
Marc Johlic | ||
David MacDonald | ||
Patrick Lauke | ||
Stefan Schnabel | ||
Jaunita George | Agree with including dragging | |
Todd Libby | Something else | Michael Gower had some reservations in his comment he ended the discussion with that I agree with that I agree with: "I think there are a couple of statements in the Understanding doc that are debatable, and no one has been able to provide research supporting those statements. So I think they should be rewritten. I feel like many of my other comments could be addressed too." "...yet we don't have much to show what we are solving with the SC." I think it would benefit everyone if the statements in question were clarified. |
Gundula Niemann | Agree with including dragging | |
Rachael Bradley Montgomery | Agree with including dragging | |
Laura Carlson | ||
Wilco Fiers | Something else | The understanding document has this question in it: > Is there an assistive technology that helps for people with mobility impairments? The group would like feedback on the frontier between AT & author responsibility. I think we need to have an answer to this before we go to CR, either that of mark this as at risk. I don't think Detlev's research answered this. My guess is the answer's no for mobile touch screen devices, but we need to be sure of that. We should provide information about assistive tech and how to decide on accessibility support in the understanding document. |
Mike Pluke | ||
Bruce Bailey | Agree with including dragging | In this survey MG, suggests we might remove this sentence: > Others use a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulator, which makes dragging cumbersome, error-prone, or outright impossible. Detlev (and others, myself included -- but years ago) have sufficient real-world clinical experience to attest to the above being an objectively true statement. HT to Detlev for reaching out! That said, if we delete "outright impossible" the sentence is then not the least bit controversial. I think is it helpful and important to mention the assistive technologies which benefit from this SC being met. |
Michael Gower | Agree with including dragging | I believe my final comment in issue 1917 clarifies that my desire was to see improved quality of the written material in the existing SC, not to question the relative gain from the SC (which I had raised previously). I think this Understanding document and technique need to be improved. If there is an inability to cite research, just modify the sentence: > Others use a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulator, which makes dragging cumbersome, error-prone, or outright impossible. to read: > Others use a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulator, which may make dragging cumbersome and error-prone. |
Detlev Fischer | Agree with including dragging | I volunteer to work on the Understanding doc - I have just suspended work on it until we are clear that the SC will be part of 2.2 |
Alastair Campbell | Agree with including dragging | We need someone to take the task of updating the understanding doc. Also, regarding public feedback, this SC has sailed through 2 wide reviews with little comment from people I'd typically expect to raise implementation issues (i.e. people creating libraries like Adobe, Salesforce etc.) |
Status: The PR has been merged, but there are significant concerns remaining that are outlined in the issue.
Michael Gower raised issue 1917 requesting updates to the understanding doc.
Detlev made updates in PR 1954.
Note the exampes for the map, kanban and sortable list have not changed. The changes to the examples are the colour wheel and linear slider.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the updates | 7 |
Agree with the updates with adjustment | 2 |
Something else | 2 |
(7 responses didn't contain an answer to this question)
Responder | DEFUNCT: Dragging Movements needs some attention #1917 | Comments |
---|---|---|
Rain Breaw Michaels | Agree with the updates | |
Oliver Keim | Agree with the updates | |
Charles Adams | ||
Marc Johlic | ||
David MacDonald | Agree with the updates with adjustment | <li>In a radial control widget, the visual indicator of the current value of the control can be dragged to a different position. Users can also click or tap on another position of the radial control to change the value.</li> I'm not sure we want to give an example like that... its hard to click on an exact point. for many people. How about: ====== ... Users can also click or tap on another position of the radial control to change the value and +/- buttons for minor adjustments to where the use clicked. ======== I'm not saying the example provided would not pass, I'm just saying our examples should probably be best practices, not things that are hard to do. Editorial: Seems this is not a complete sentence, add [are]: Path-based gestures [are] covered in Success Criterion 2.5.1 Pointer Gestures. For more details, refer to <a href="https://www.w3.org/WAI/WCAG21/Understanding/pointer-gestures.html">Understanding Success Criterion 2.5.1 Pointer Gestures</a> |
Patrick Lauke | Something else | Not sure #1954 fully addresses all of Michael's concerns about claims of ease |
Stefan Schnabel | ||
Jaunita George | ||
Todd Libby | ||
Gundula Niemann | Agree with the updates with adjustment | In the linear slider I do not agree that tapping or clicking a specific location is an adequate equivalent. If the linear slider has many values or continuous values, it might be hard to target a specific value. It only holds if the values are discrete and the pointer target requirement is fulfilled. Still I feel there is some trial and error in it. So I prefer to request a numeric input as non-dragging option. |
Rachael Bradley Montgomery | Agree with the updates | |
Laura Carlson | Agree with the updates | |
Wilco Fiers | Agree with the updates | |
Mike Pluke | ||
Bruce Bailey | Agree with the updates | |
Michael Gower | Something else | I went through and did some basic edits to the technique revisions and created a new PR which I think improves it, https://github.com/w3c/wcag/pull/1975 , but to me the underlying issues remain. I still feel like there are challenges with this Understanding doc. First, as mentioned, it blurs concepts. For instance: > There may be cases where a dragging movement is essential, for example, drawing a freeform figure, or playing a game where the aim is to follow a particular track as accurately as possible. A game that requires someone to "follow a particular track" is describing a path-based gesture, not dragging. Dragging, by definition, does not prescribe direction, only end points. The fact that our Understanding document is adding to this confusion is a red flag to me on its overall maturity. Another example, an acceptable alternative single pointer solution given in the existing and the updated technique is to allow someone to do a "directional swipe" (in the new technique to "allow moving it to an ajacent postion by a swipe gesture"). But that swipe is path-based and so a failure of Pointer Gesture. Again, red flag. Added to those maturity indicators is the failure to address my repeated concerns with a lack of published references to the challenges. My key point: if someone has gross or fine motor skills which prevent them from performing dragging actions, they are likely to have an AT or user setting in place. We have an underlying operational assumption in the WG that the author's responsibilities only extend so far. At some point ATs and User Agents have responsibilities. If a Press and hold mechanism is a common AT or OS feature, where does the author responsibility end? The fact we have no supporting information on this question continues to trouble me. I also continue to wonder if the test technique is too generic: <p>For interface elements that support dragging:</p> <ol> <li>Check the interface for the presence of functions triggered by <a>dragging movement</a>s.</li> <li>Check that there is a <a>single pointer</a> activation alternative to operate the same function</li> </ol> |
Detlev Fischer | Agree with the updates | Happy to fine-tune this further to remove extant ambiguities and to improve the maturity of the Understanding text. Or is the upshot of Michael's comment that we should simply scrap this SC? I wasn't clear about that. |
Alastair Campbell |
Andrew raises in issue 1886 about whether a slider may need to offer text input, and that a radial slider example would help make it clearer.
Detlev created that in PR 1961 (updated since last time).
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 7 |
Agree with the update with adjustment | 5 |
Something else | 1 |
(5 responses didn't contain an answer to this question)
Responder | DONE: Adobe Comment on 2.5.7 Dragging Movements | Comments |
---|---|---|
Rain Breaw Michaels | Agree with the update | |
Oliver Keim | Agree with the update with adjustment | would remove this sentence: "this option counts as a <a>conforming alternate version</a> on the same page". The original component can enclose a text input, or another keyboard-input (e.g. type ahead) and reflect the input in the mouse-centric part. In this case the component is accessible and there is no need for an alternative. Example: A cross-hair-based color picker may also accept arrow key use, or direct keyboard input, like a typed value "#fff", and reflect the value on a text output control. |
Charles Adams | Agree with the update | |
Marc Johlic | Agree with the update | |
David MacDonald | Agree with the update with adjustment | For the last example <li> A linear slider control widget, where the value can be set by dragging the visual indicator (thumb) showing the current value, allows tapping or clicking on any point of the slider groove to change the value and set the thumb to that position. </li> I'm not sure we want to give an example like that... its hard to click along a line to fine an exact point. for many people. How about: ====== ... allows tapping or clicking on any point of the slider groove to change the value and set the thumb to that position and +/- buttons for minor adjustments to where the use clicked. ======== I'm not saying the example provided would not pass, I'm just saying our examples should probably be best practices, not things that are hard to do. |
Patrick Lauke | Agree with the update with adjustment | Left two small comments on the PR - in particular, one sentence that seems back-to-front (to me at least). Can live without this change though. |
Stefan Schnabel | ||
Jaunita George | ||
Todd Libby | ||
Gundula Niemann | Agree with the update with adjustment | It says "Where functionality can be executed via dragging movements and an equivalent option exists that does not rely on dragging and meets all other WCAG Success Criteria, this option counts as a <a>conforming alternate version</a> on the same page. An example is a color wheel where a color can be changed by dragging an indicator. In addition, text fields for the numerical input of color values allow the definition of a color without requiring dragging movements." This is confusing. First, a conforming alternate version is a different version of the software, where it might be given by changing a user setting. This is not the same as providing a second option on doing something on the same page. Next, the color wheel is mentioned here as well as further down. Here it is used as an example for alternate version, further down it is used as an example for compliance. This is confusing. I think it is an example for compliance. |
Rachael Bradley Montgomery | Agree with the update | |
Laura Carlson | Agree with the update | |
Wilco Fiers | Something else | I'm not keen on this "conforming alternative version" argument here. WCAG's definition of CAVs doesn't really allow for the inaccessible and accessible version to exist on the same page. I know many of us (including myself) have been allowing that, but a careful reading of CAV doesn't support this. Alternative controls are permitted under this SC without invoking CAV as an argument anyway, as long as the alternative control is single-pointer operated. If we are okay with a keyboard-only alternative we should explicitly permit that in the SC text. |
Mike Pluke | ||
Bruce Bailey | Agree with the update | |
Michael Gower | Agree with the update with adjustment | I agree with the changes. The one thing I question is whether the text input has to be "on the same page". I think it would be better worded as "from the same page". I can provide a clear example of an interaction where text inputs are offered via a "More" button on the same page. |
Detlev Fischer | Agree with the update | I agree with any fine-tuning that may be necessary to describing the alternate ways of operating the function, whether on page or linked to another page. |
Alastair Campbell |
In issue 1978, JonA asked whether an onscreen keyboard is an acceptable method instead of dragging.
Whilst not ruling out that tapping an input and using an onscreen keyboard may be acceptable in some cases, Detlev updated the example in the understanding document to talk about tapping rather than typing, as a better example. The change is in PR 2009.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 4 |
Agree with the update with adjustment | 3 |
Something else |
(11 responses didn't contain an answer to this question)
Responder | DONE: Is keyboard functionality acceptable if an on-screen keyboard can be used. #1978 | Comments |
---|---|---|
Rain Breaw Michaels | ||
Oliver Keim | ||
Charles Adams | ||
Marc Johlic | ||
David MacDonald | Agree with the update with adjustment | Not sure: I'm not crazy about tapping/clicking an exact location to get a value. Its not the same as sliding where the user sees the incremental value increase or decrease until they see the value they want. If there is something like this I think there should be +/- buttons for fine adjustments to the value. The click will get them to the general value and the +/- buttons can make the fine adjustments. |
Patrick Lauke | Agree with the update | |
Stefan Schnabel | ||
Jaunita George | ||
Todd Libby | ||
Gundula Niemann | ||
Rachael Bradley Montgomery | Agree with the update with adjustment | I recommend removing the word simply as it may not be considered simple by some. I also suggest that single tapping elsewhere in the color wheel would not provide the level of fine tuned movement through color options. To be comparable, a single tap option to move a small amount between colors would need to be available. Proposed resulting text for both of te would be: A radial control widget (color wheel) where the value can be set by dragging the marker for the currently selected color to another position, also provides directional buttons that move the selection around the radial control. |
Laura Carlson | Agree with the update with adjustment | I agree with Rachael to remove the word "simply". |
Wilco Fiers | Agree with the update | |
Mike Pluke | ||
Bruce Bailey | Agree with the update | |
Michael Gower | ||
Detlev Fischer | Agree with the update | As to David's point that single point tapping can be difficult: In terms of fine motor control, I don't think there is a world of difference between repeatedly adjustung a thumb to approximate a desired value and repeatedly tapping a groove (which easily can have a active area wider than the slim groove itself). Offering pointer-operable increment/decrement controls is certainly good in many cases but I would shy away from mandating it. There can be other mechanisms (like a thumb 'snapping to' a a limited set of values on the groove) that might be equally or more effective - it really depends of the operational context. The normative minimum is to 'offer any alternative way of single pointer input that is not a dragging movement' (and if it ia a poiter gesture, the requirements of that SC apply), and leave it to UI designers to work out what the best option is. We cannot, I think, mandate a particular solution. |
Alastair Campbell |
In issue 1977 Jon Avila asks whether the user-agent exception covers browser-based (default) video controls.
There is a draft response, basically saying that it doesn't seem to be an issue, and no one could find an example that would be an issue.
Do you:
Choice | All responders |
---|---|
Results | |
Have an example of an issue (please comment) | 1 |
Agree with the response | 6 |
Agree with adjustment | |
Something else | 1 |
(10 responses didn't contain an answer to this question)
Responder | DONE: Exception for web content used by the author but generated by the user agent? #1977 | Comments |
---|---|---|
Rain Breaw Michaels | ||
Oliver Keim | ||
Charles Adams | ||
Marc Johlic | ||
David MacDonald | Agree with the response | |
Patrick Lauke | Agree with the response | |
Stefan Schnabel | ||
Jaunita George | ||
Todd Libby | ||
Gundula Niemann | ||
Rachael Bradley Montgomery | Agree with the response | |
Laura Carlson | Agree with the response | |
Wilco Fiers | Something else | I'm not keen on saying something's a "grey area" in our response. If we think all user agent controls are exempt, then that needs to be explicit in the SC. If not, lets be clear there is no such exception in the SC, both in this response and in the understanding document. |
Mike Pluke | ||
Bruce Bailey | Have an example of an issue (please comment) | |
Michael Gower | Agree with the response | I had previously responded to this (or a similar issue). I've had a chance to get my head back around it again during the break, following the discussion. So, first point, no one was able to find an example where a user agent default of an html component failed dragging. So it's a hypothetical (or, getting back to the first point, we lack research to know it exists). Second point, if we force authors to override user agent behaviour for native html functionality, we are creating a situation where it is arguably going to make the landscape less accessible. This is the choice an author then faces: 1) test every single browser on every OS to ensure the native user agent behaviour passes 2) create their own version Either of these scenarios is a very big lift. For the second, imagine if every author is responsible for the coming up with their own implementation of interaction for text input types (date, number, color, etc) and video players. I'm already seeing horrible author creations for the equivalent of relatively straightforward elements like select. We have to have language clarifying that user agent defaults are excepted, or we are making the situation worse, not better. |
Detlev Fischer | Agree with the response | We should watch out for examples to substantiate this concern. For the time being, the response seems fine. |
Alastair Campbell |
SuzanneTaylor raised issue 1560 about whether "The definition of "Dragging Movements" appears to exclude when a user defines a path of their own (not content-defined) by dragging, rather than moving an object by dragging. Is this intentional or an oversight?"
The thread moved on, and Detlev created PR 2066 to try and clarify.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 2 |
Agree with adjustment | 4 |
Something else |
(12 responses didn't contain an answer to this question)
Responder | DONE: Does the Definition of "Dragging Movements" Intentionally Limit the Scope to Moving Objects/Items? #1560 | Comments |
---|---|---|
Rain Breaw Michaels | ||
Oliver Keim | ||
Charles Adams | ||
Marc Johlic | ||
David MacDonald | ||
Patrick Lauke | ||
Stefan Schnabel | ||
Jaunita George | ||
Todd Libby | ||
Gundula Niemann | ||
Rachael Bradley Montgomery | Agree with adjustment | Slight rewording for grammar only: Dragging movements that invoke animations keyed to the pointer position are a special case. For example, selection rectangles that set the first x/y rectangle coordinate at the pointer position via a pointer down-event, and the second x/y coordinate, after a dragging movement, at the next up-event. A similar example is a connecting line drawn between two different items on the screen, as in an allocation test where users are required to draw a line between questions and corresponding answers. In these cases, the dragging movement requires an alternative way to accomplish the same action that does not rely on the dragging movement. For example, two separate single tap or click actions may define the rectangle coordinates or the start and end points of a connecting line. |
Laura Carlson | Agree with adjustment | |
Wilco Fiers | Agree with adjustment | I think this is pretty difficult to understand. Any chance we can add an animation that shows this? |
Mike Pluke | ||
Bruce Bailey | Agree with the update | |
Michael Gower | Agree with adjustment | I think your second example is better without the first one. The section needs some slight rewording. I can tackle as part of my review. I think this could really use an illustration! |
Detlev Fischer | Agree with the update | Happy to apply any text adjustments to clarify. |
Alastair Campbell |
Jon Avila raised issue 1979 about the example in the understanding document of the essential exception.
Detlev created PR 2003 to adjust the example.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the change | 4 |
Agree with adjustment | 1 |
Something else | 1 |
(12 responses didn't contain an answer to this question)
Responder | DONE: Exceptions seems like free form paths rather than dragging #1979 | Comments |
---|---|---|
Rain Breaw Michaels | ||
Oliver Keim | ||
Charles Adams | ||
Marc Johlic | ||
David MacDonald | ||
Patrick Lauke | Agree with adjustment | noted in the PR `dragging target` > `drop target` to be in line with d'n'd concepts/nomenclature. |
Stefan Schnabel | ||
Jaunita George | ||
Todd Libby | ||
Gundula Niemann | ||
Rachael Bradley Montgomery | Agree with the change | |
Laura Carlson | Agree with the change | |
Wilco Fiers | Agree with the change | |
Mike Pluke | ||
Bruce Bailey | Agree with the change | |
Michael Gower | Something else | It would be great to find an actual example. |
Detlev Fischer | I believe I have already implemented Patrick's wording change suggestions into my PR. | |
Alastair Campbell |
The following persons have not answered the questionnaire:
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
w3c/wbs-design
or
by mail to sysreq
.