-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tech drag drop cancel #456
Conversation
Hi Detlev, Presumably this is to support 2.5.2? Particularly "Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion;" A few little points:
I suspect someone will say "this isn't a technique, it is a test procedure", but I can't think how to convert it to be a more specific technique at the moment :-/ |
typo: us for is, first line |
After the explicit exclusion of draf-n-drop actions from the scope of SC 2.5.1 Pointer Gestures, it seemed wise to rename this technique from "Ensuring that drag-and-drop gestures can be cancelled" to "Ensuring that drag-and-drop actions can be cancelled" to avoid confusion. It seemed difficult, however, to remove every mention of 'gesture', for example, in the User Agent and Assistive Technology Support Notes: "On touch screen devices, author-supplied path-based and multipoint gestures usually do not work when OS level assistive technologies (AT) like a built-in screenreader is turned on." - Is it confusing to talk about "path-based and multipoint actions" rather than gestures? I am not sure how to best remove the wobbliness of this...
Made ‘item’ consistent as the thing being picked up.
@detlevhfischer I think this is a sufficient technique for pointer cancellation, but I have to admit it took a lot of thought to get there, is that right? |
I didn't review this because it was closed after requesting my review. If this was approved by the WG, it should be reopened and whatever fixes needed made. |
This was approved on the call, not sure why Detlev closed it. I was just checking that I had targeted the correct SC. |
Can't review the whole file at the moment, so I'll just note that a concern I have with this phrase is that some things are draggable which I might not classify as drag and drop. For instance, a slider is draggable. However, I haven't seen anyone implement a cancel function on a slider. To me, that would be pretty intrusive (given the drag is a change of value on a continuum and it is just a matter of repositioning it). |
Was clashing with published 207 for icon contrast.
Just corrected a clashing filename, it can be previwered here now: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The structure of the technique looks ok.
I'm concerned about the links in the Understanding doc to M029 and FM001. Those are not approved techniques, and the first issue is people might follow the links and not know the difference. Further, the naming pattern makes the generator think they are official techniques and try to process them as such, which will create problems since corresponding files (in the suite) don't exist. I recently expanded the ability of the generator to recognize technique filename patterns, but that means these techniques are getting swept into the recognition. We can't have it both ways, liberal recognition and exclusion of things that are deliberately made overly similar.
We need either a decision that no links in Understanding techniques sections are allowed except to approved techniques, or agree on parameters for such links that will avoid accidental inclusion in the generator and confusion with readers. Until that's sorted, I can't approve this merge.
Good point, I had left those in for reference, but I've moved the references into the spreadsheet and removed the links. |
Rawgit view:
http://htmlpreview.github.io/?https://github.com/w3c/wcag/blob/tech-drag-drop-cancel/techniques/general/G208.html