Dragging Movements needs some attention #1917
Comments
Finetuning the dragging movements understanding text in response to issue #1917 - Replacing dragging motion with dragging movement - Reducing talk about Pointer Gestures - Simplifying examples, adding single pointer option to select a value in a radial control
I think the problem is that the single pointer definition includes single pointer gestures like swiping, and having swiping (instead of activating some control by single tap or click) as an alternative to dragging feels odd (but possibly valid). I agree that 'operable' does not add anything useful here. What would be clearer might be "single point operable" - not sure how to solve this nicely. For now I will take out 'operable' in both understanding (where it only appears once, in thereference to Technique 219) and in that Technique itself. |
@mbgower Mike, I am not clear what you are referring to with "many pointer alternatives". Resolving the press-and-hold challenge is exactly what this SC is about? Show additional controls (arrows), activate once then swipe, or use a select to determine drop target, are all single pointer alternatives. Dragging will be less onerous for many, but for those that find it hard to press-and-hold-and-move-and-drop-at-the-right-spot, alternatives may be beneficial. But maybe I misunderstood, so if you clarify I can work that into my upcoming PR.
I have no pointers myself right now but I guess this goes to all in the WG - I hope we can supply those pointers. |
|
I believe what was meant is an alternative that uses a single pointer - as opposed to the keyboard, etc. |
|
I think I understand what @mbgower is saying in the last paragraph, and I had the same question for this SC; #1954 doesn't seem to clarify it for me. You can accurately "maintain contact" with any of the modalities mentioned without having to physically "press-and-hold". I mean, mice have click-lock. And a drag event is a mouse event, so a mouse emulator by definition will support it, unless that emulator is not working properly. It's no more cumbersome or difficult to drag something using those than it would be to click or tap (or simulate a click) on 2 different places for any reason. The only reason I can think that the author would be responsible is if they did something really strange to interfere with, alter the behavior of, or visually emulate but not actually use, drag events. Is that what this SC means? |
|
I said:
@detlevhfischer responded:
most trackballs have a button that is assigned to a 'press and hold' action.
So, in other words, the effort to do this is comparable to many single-pointer dragging alternatives (orient, choose, reorient, complete). Many operating systems offer equivalents to this AT feature (like Microsoft's ClickLock). Eye Gaze offers Gaze Drag & Drop. So all three of these solutions (hardware pointer alternative, os-level accessibility feature, eye tracking system) minimize/resolve a key challenge trying to be addressed by this SC. So when the Understanding document says the following, I feel you must provide some research to back that up:
As @norarose states:
I'm not questioning the value of a well-designed single-pointer interaction; I just want the level of challenge and opportunity properly captured. (I also find the 'speech-controlled' mouse emulator comment a bit odd, in that it is easier and more typical for speech interaction to emulate a keyboard (or the hybrid 'click' and 'move to' commands) than to emulate a mouse for many interactions (i.e., having to resort to MouseGrid). |
|
@mbgower @norarose I have no pointers to extant research into the range of pointer use cases where dragging may prove difficult. I hope others can point to relevant research. I think you have a point in saying that of those people who rely on sip-and-puff mice, eye gaze input and such, many will know and use dedicated modes on their input systems to emulate dragging. We are going to investigate this mode of use of severely motor-impaired users in a partner organisation over the next 18 months, and initial interviews and requests have supported the assumption that these users can indeed often cope with dragging scenarios (but this was just a very small sample). Maybe the group most likely to benefit from 2.5.7 Dragging Movements might be long term mouse users experiencing increasing difficulties with the onset of age or illness (strain, pain, tremors etc.) - people who may often have no knowledge of the availability of 'press and hold' options. What I wasn't sure about is whether your demand ("you must provide some research") means, by implication, that in the absence of such pointers the Success Criterion 2.5.7 should just be scrapped. Maybe we can have a group discussion about that, best based on some additional pointers to extant research.
Some users we have worked with experience frequent issues with voice-controlling keyboard input in their preferred browser and use Dragon MouseGrid all the time, and with unbelievable speed and accuracy. But as always, knowing just a few cases means you never know whether this is the 'odd one out' or an indication of a general picture... |
|
Some initial sources, none of them very relevant I fear:
|
|
For those who don't want to read the whole issue, what I previously said was
My concerns are two-fold:
The focus of the current issue was to improve the guidance we publish. When this gets adopted, I'm going to be enforcing the requirement across a lot of teams. I know of a number of interaction that will need to be redesigned. When people challenge why they have to redesign a UI when comparable interactions exist in the underlying OS, it would be great if our supporting material makes a clear case. |
|
I agree with addressing statements in Understanding which are debatable. I do not agree that not being able to cite research automatically means that an assertion is Understanding is debatable. Plenty of 2.0 SC come from lived experience, not research. MATF requesting this SC warrants its inclusion, and I agree with @mbgower that the focus of this current issue is improving our guidance. Am I correct that the only debatable sentence in Understanding is this one:
How about striking "outright impossible"? It could also be softened to "practically impossible". Web content that conforms to 2.0 Level AA already meets 2.1.1 Keyboard so it does seem to me that "outright impossible" must not be literally true.
I think it might be helpful for Understanding to provide an example of a UI where the default interaction is for drag-and-drop and where the OS provides some poor-but-good-as-can-be-expected work-around. The example should be paired with a (at least visually) lightweight change where the author provided for good alternative functionality. This example pair would also need some tally of the difference in the user experience for someone who can point but not drag. Drag-and-drop being a barrier is very common, so I think we can craft out a clarifying example or two. Perhaps what has not been describe well is that needing anything more than a single click makes the UI so much more complicated? Single click is enough most of the time. On a web page, maybe 95% of the time? So never needing to differentiate between click and click-and-hold is huge! Not needing more than one mouse button is equally important, but that didn't use to be an issue with web content. Also "navigate to the desired destination while-the-mouse-button-is-held-down" is not identical to just "navigate". |
|
"Lived experiences" are research. Evidence =/= statistics and formal studies. Anecdotal evidence is a perfectly valid research method in social sciences, and even in some contexts in "hard" sciences - eg medical case studies. Per @detlevhfischer:
My takeaway from these statements is that the supposedly impacted disability groups have been asked for their lived experiences, and those lived experiences are actually being dismissed because they weren't a big enough sample size. In the meantime, most of the comments in this thread so far have really been able to explain the impact of this without the use of words like "maybe", "possibly", "perhaps". Which are assumptions about how disabled people use technology, which accessibility advocates should take care not to insert on another group's behalf. Even in an absence of contradictory evidence, you should be able to provide strong evidence that meeting this SC provides more benefits in a broadly applicable sense than not. Because the way this SC may change authoring practices and design has powerful implications. The fact that this SC exists at all suggests that a single pointer method is automatically more accessible, and why would authors provide both when you only have to provide one? What if the single pointer method requires far more effort than the drag-and-drop? What about disabled people who have adaptive strategies for using drag-and-drop they'd prefer to use and will have to re-adapt when it gets replaced by a more "accessible" method, or find the method they find easiest is being used less and less? What about broken functionality/accessibility support when these changes are implemented, which may be the author's responsibility but will effect users nonetheless? I would think you'd need a stronger justification to take those kinds of risks. |
@norarose I do not see how you come to that conclusion. No one's experiences are being dismissed. Some users who have previously stated that they can manage drag-and-drop scenarios (with some effort) nevertheless support putting forward Dragging Movements as a new SC - as documented in this mail. But the sample is still very small and we did not get input from other organizations contacted. I would urge people with good contacts into the relevant disability groups to reach out and try to get more evidence than we were able to collect. Personally I am not sure whether or not we should go ahead with this. I am glad it will be a group decision with more minds involved. |
I would rephrase that to be 'evidence of lived experience can be valid research' especially if we're talking about user need. I haven't seen anyone disputing that some users are challenged by drag and drop. The question is the degree of the problem, in the context of the web, and how much the author of web content should be required to do about it. If I may offer a parallel discussion, when we were attempting to tackle vestibular disorders in WCAG 2.1, we had to abandon attempts at a AA requirement because we lacked research on specifics around how much movement on what percentage of the screen is statistically more likely to trigger a reaction. A few people's anecdotes on what affects them personally is not sufficient research on which to build specific requirements for an international standard. We had to resort to a general AAA requirement, even though we knew some users were significantly affected by designs involving motion. For Dragging Movement, we lack solid research on the extent of the challenge, and the extent a web-author-only solution fills the need. We can infer that in most situations, a user does not operate exclusively in a web browser; they have to start their operating system (mobile, desktop, etc), launch the browser, etc. So I believe it is a valid question to ask 'what features of the underlying system allow users challenged by dragging movements to work, and do those features work on the web?' and to gather information about availability of built-in or common ATs and devices that alleviate this challenge, and to what degree. |
I think that is the contentious one for me, @bruce-usab. The other things I flagged have been tweaked. I find even your modifications overstated. To date, the information gathered suggests that with a 'press and hold' function, which is common to most (all?) ATs in this space, there is little difference between dragging an item and simply repositioning a pointer (which is required for many of the sufficient techniques). The only difference is choosing whether to initiate a click or a press-and-hold (which are typically designed to be very similar in effort to invoke). Until we have shown differently, I'd be much happier with rewording that reflects our findings to date, such as:
|
|
I would add another use case - on mobile with platform level zoom (not browser zoom) for users with low vision. When you use the 2 or 3 finger zoom feature on (Android and iOS) you are panning the screen. You only see a small part of the screen at a time. If you need to then drag your single finger you cannot drag your single finger left or right to move the panned area as that requires 2 or 3 fingers (depending on platform). Thus, dragging with platform zoom is problematic on mobile. This is not an issue on desktop as the pointer moves the viewport. |
Wow @mraccess77 , sounds like a bug! Is there no issue open against that? Is that only for web stuff, or does that also cause problems for iOS-level drag needs, such as moving an app between home page screens? (realizing that Apple is probably still opaque in regard to surfacing open issues, and it may be hard to answer) I have no idea how WCAG2ICT (or for that matter, EU interpretation) is going to deal with Pointer Gestures and Dragging Movements in regard to interpreting/failing all the AT functionality that relies on dragging and directional movement, not to mention all the basic OS operation that relies on it. |
|
Hi @mbgower it does work on the iOS home screen. But with web content I have run into drag and drop that doesn't work and some that does - so that leads me to believe how it's web drag and drop is implemented makes a difference. I've also found mobile apps where it doesn't work - but with the home screen and other apps it does - so again - seems to be implementation. |
|
@mbgower — I think this is fine:
The line mentions (1) some of the technologies, and that dragging can be (2) cumbersome and error-prone. Those two points are important to retain. I am quite content to use your softened phrasing.
For sophisticated users, with good AT, this is correct. That is not the use case I am thinking of. I submit that the average/typical computer user (who might not even be an office/information worker) knows not what the right mouse button does. This user might not know what is meant by "dragging" the mouse cursor — even though they can use a 'paint' app or play solitaire (and those are physically the same movements). For someone with developmental delays using an electronic head pointer it can be a huge lift to add different modalities to the interface. Point-and-click is simple. Point-and-click-but-sometimes-invoke-menu is not simple. And yes, in this setting, the user might not use anything other than their web browser. So the fact we are only addressing the barrier in web content (and not for desktop apps, nor for the OS) it is still useful and important. I do not agree that AA 2.5.7 dragging is a very comparable situation we had with AAA 2.3.3 animations. With dragging, it is not just end-users asking for something. We have teachers / clinicians / tech support attesting to the barrier. |
|
Thanks @bruce-usab
A simple PR to alter that phrase can close this issue, from my perspective.
In regard to Animations, I was not trying to equate it to Dragging Movements, but trying to explain to a prior commenter that we need the right kind of user information and research to properly scope a requirement -- and that no slight to users' experience is intended by asking questions or seeking for data. |
|
Update from backlog meeting: @mbgower will do a small PR. |
Addresses #1917 and Gundula's comments in https://www.w3.org/2002/09/wbs/35422/wcag22-misc3/results#xq16
Both the Understanding and technique for Dragging Movement could use some work.
The understanding document is a bit repetitive, and spends too much time talking about Pointer Gestures, IMO. It could use some examples, and I question why 'single pointer operable alternative" isn't just "single pointer alternative".
The G219 technique is oddly generic. At the least, it should illustrate the ‘solutions’, especially if this is basically a design solution, not dev solution.
I also find the Understanding document makes various unsubstantiated claims for atypical input modalities and their relative unease using dragging. In a common single-pointer replacement for a dragging movement, the user is still going to need to orient to the final target for an object with a pointer. Given this, the act of maintaining a press-and-hold becomes a key challenge. However, many pointer alternatives have a drag-and-drop feature that resolves this press-and-hold challenge. Given that, is dragging generally a more onerous activity than simply navigating? It would be good to point to some research that shows the benefits of alternatives to dragging, and documents alternative pointing device challenges with dragging.
The text was updated successfully, but these errors were encountered: