The Paciello Group comment on 2.5.2 Pointer Cancellation

[patrickhlauke]

Difficult to understand. Appears tech agnostic, but only by inventing new terminology.

No Down-Event: The down-event of the pointer is not used to execute any part of the function;

By default, components like <button> fire on the down event when using a mouse; does satisfying this SC require custom scripting now for all of these, actively having to work against browser/user agent default behavior?

Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or undo the function after completion

This seems to suggest that any action (even from a regular mouse click, for instance on a link) needs to be either abortable or undone? This also doesn't cover the previous point of <button> as that doesn't fire by default on the up-event. If the "completion of the function is on the up-event, and" part is here to distinguish it from the previous point about being on the down-event, then perhaps it is not needed (as the list is "at least one of the following is true")? otherwise it seems to mean that abort/undo does not apply if the action is on the down-event (whereas it does seem that if I did do something on the down-event, BUT provided abort/undo, I should be fulfilling the spirit of this SC)?

Example of a control that sends an email. If a <button>, requires scripting to only activate on "up-event" rather than the browser convention of down-event. If implemented as a link/custom control that does fire on "up-event", how would this allow "abort"? A timer, before the email is really sent? Can't "undo", as once an email is sent it's sent. Or, again, having some sort of "staging" area where an email sits for a while before being actually sent?

Overall, this seems strangely unachievable, and does not exempt standard behavior in user agents.

Maybe go back to the original high level intent of "no accidental activation" as part of the normative language (foregoing the invention of new pseudo-tech-agnostic terms like "up-event"/"down-event"), and providing examples (using actual tech-specific examples like "mousedown", "touchstart", etc) in the understanding?

[awkawk]

Thanks you for your comment. The deadline for comments has passed, but the Working Group will make efforts to consider your comment and any suggestions for improvements.

[steverep]

Hi Patrick,

Much of this comment seems to start from a premise that I want to call into question:

By default, components like <button> fire on the down event when using a mouse

Can you provide some documentation for this? Just for my sanity, I used the ARIA accordion example which uses <button> elements as a quick test, and nothing happens until the up-event, allowing me to move the pointer away after the down-event without expanding anything. Let me know what I'm missing.

[awkawk]

Confirming Steve's observation. Try at https://codepen.io/awkawk/pen/MrXJzr

[patrickhlauke]

Oops, it seems that next time, rather than just gathering comments internally, I should really test things out. You're both indeed correct that <button> also fires the click event by default on the "up" (wondering if there was some half-remembered confusion about keydown/keyup/keypress and click ordering).

In light of that, amended comments:

Difficult to understand. Appears tech agnostic, but only by inventing new terminology.

Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or undo the function after completion

This seems to suggest that any action (even from a regular mouse click, for instance on a form submit button) as a result of a pointer activation needs to be either abortable or undone? But that the same action, if triggered on the same control/link/button using a keyboard, doesn't need to have abort or undo?

Example of a control that sends an email...the user clicks it, or taps it...how would this allow "abort"? A timer, before the email is really sent? Can't "undo", as once an email is sent it's sent. Or, again, having some sort of "staging" area where an email sits for a while before being actually sent?

This feels like it's actually being even stricter than https://www.w3.org/TR/WCAG21/#error-prevention-legal-financial-data and https://www.w3.org/TR/WCAG21/#error-prevention-all (which it would also apply to, if the user submitted information using a pointer - but strangely not if the user used a keyboard?)

Maybe go back to the original high level intent of "no accidental activation" as part of the normative language (foregoing the invention of new pseudo-tech-agnostic terms like "up-event"/"down-event"), and providing examples (using actual tech-specific examples like "mousedown", "touchstart", etc) in the understanding?

[patrickhlauke]

This seems to suggest that any action (even from a regular mouse click, for instance on a form submit button) as a result of a pointer activation needs to be either abortable or undone?

Or is this about being abortable/undoable before the up-event is triggered? i.e. i can press mouse down, but unless i release the mouse while on the same button, the click/press is quietly ignored (generally by the UA)? if so, that's unclear from current wording.

[steverep]

This seems to suggest that any action (even from a regular mouse click, for instance on a form submit button) as a result of a pointer activation needs to be either abortable or undone?

No, the SC states that only 1 of the 4 conditions must be true (and typically only one will be true). By far, the easiest way to pass this for a single click or double click operation is via the first possibility of no down-event. The Abort or Undo statement was introduced to cover operations such as drag and drop, where the down-event is a necessity, but accidents should be able to be mitigated.

But that the same action, if triggered on the same control/link/button using a keyboard, doesn't need to have abort or undo?

Personally, I would argue that's a failure of 2.1.1 for having such functionality available only via pointer. In a practical sense, operations that would be expected to pass via Abort or Undo are very pointer-specific.

Example of a control that sends an email...the user clicks it, or taps it...how would this allow "abort"? A timer, before the email is really sent? Can't "undo", as once an email is sent it's sent. Or, again, having some sort of "staging" area where an email sits for a while before being actually sent?

If, for example, that email could be sent after a drag and drop, then a mechanism to abort could simply be a dialog asking "Are you sure you want to send this?". The distinction is that an abort would cancel the function before it executes whereas an undo would reverse it after the fact.

[detlevhfischer]

hi @steverep I believe when you say "by far, the easiest way to pass this for a single click or double click operation is via the first possibility of no down-event." you mean "no up event" (i.e. moving pointer before releasing it)? I am greatly relieved that button indeed acts on the up event as I had assumed - just tested it myself on a native button before reading the comments above. Do you think the SC Pointer cancellation can do without the 'single' in the SC text so we can keep the current definition "single pointer"? I could then reverse my -1 on PR #731

[awkawk]

But that the same action, if triggered on the same control/link/button using a keyboard, doesn't need to have abort or undo?

It does in some cases. If you use the space bar to activate a button you can tab off of it. This doesn't work when you use the enter key, nor does it work for links (which require enter).

Example of a control that sends an email...the user clicks it, or taps it...how would this allow "abort"? A timer, before the email is really sent? Can't "undo", as once an email is sent it's sent. Or, again, having some sort of "staging" area where an email sits for a while before being actually sent?

You aren't aborting the sending of the email, you are aborting the button action. If it is a keyboard-activated link to send the email then you wouldn't be able to reverse it.

If, for example, that email could be sent after a drag and drop, then a mechanism to abort could simply be a dialog asking "Are you sure you want to send this?". The distinction is that an abort would cancel the function before it executes whereas an undo would reverse it after the fact.

With the current pointer cancellation text drag and drop wouldn't come into scope.

[patrickhlauke]

re-reading the 4 bullets, and getting more of a feel of the intent of all of them...if we're still concerned about, essentially, not firing on the down event:

Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or undo the function after completion;

Shouldn't this read "Completion of the function is on the down-event, and ..." ? Otherwise, why is it that we want to have undo for the up event?

Up Reversal: The up-event reverses any outcome of the preceding down-event;

Shouldn't this be expanded, to say "execution is on the down-event, but the up-event reverses any the outcomes..."

[patrickhlauke]

In fact, maybe to make it clearer, even changing the first bullet to be positive (use up-event) rather than negative (don't use the down-event).

So overall:

Up-Event: The function is triggered only on the up-event; Abort or Undo: Completion of the function is on the down-event, and a mechanism is available to abort the function before completion or undo the function after completion; Up Reversal: Execution of the function is on the down-event, but the up-event reverses any of the outcomes (although with the rewording above, would that not simply count as a special case version of an "Abort or Undo?") Essential: Completing the function on the down-event is essential.

[mraccess77]

Personal understanding of the SC; It is trying to say either execution is on the up event or is completed with the up event. The idea being that if the user touches the wrong control and then slides their finger away the control they initially touched won't be activated. But if they touch and release on teh same control it is activated. With the other exceptions in play if this can't be done. We don't want full activation on the down event as there would be no way to move your finger or pointer away to cancel the down event.

[patrickhlauke]

@mraccess77 in which case, would you agree that if the functionality is on the up-event, there's no need for abort/undo (2nd bullet in the current text)?

[mraccess77]

@Patrickhlauke yes that sounds right about the up event.

[awkawk]

in which case, would you agree that if the functionality is on the up-event, there's no need for abort/undo (2nd bullet in the current text)?

@patrickhlauke I disagree because what @mraccess77 says about being able to move the pointer away or hit the esc key to cancel the click is the abort/undo aspect.

[steverep]

With the current pointer cancellation text drag and drop wouldn't come into scope.

That's not correct at all. The current text per the definition of "single pointer" only excludes multipoint, so any drag and drop or single touch gesture is certainly in scope. This was the entire reason for the revamp of the bullets. See #380. What each bullet was meant to cover was explained during the resolution to that issue.

So, critiquing comments above with that in mind...

In fact, maybe to make it clearer, even changing the first bullet to be positive (use up-event) rather than negative (don't use the down-event)

That's fine, but your wording doesn't go far enough. It either needs to say that down-events are not used at any time, or it only uses up-events (I'm not sure those are the same so I'm much more comfortable with the former). This bullet covers single clicks, double clicks, and some long presses. By guaranteeing the function does not use down-events, the user can cancel at any time just by moving away before triggering an up-event.

Shouldn't this read "Completion of the function is on the down-event, and ..." ? Otherwise, why is it that we want to have undo for the up event?

No, it is correct as is. This bullet covers gestures, drag and drops, etc. where the down-event is obviously needed, but the functionality is not completed until the up-event fires. The reason for saying that explicitly is to avoid the unintended consequence of allowing a single click to be fired on the down-event just because there's an undo available. There was a little more to it than that so I'll go back and check a bit more. Also, the SC doesn't say anything about having undo on the up-event so I'm confused by that comment.

Shouldn't this be expanded, to say "execution is on the down-event, but the up-event reverses any the outcomes..."

I'm failing to see how that's an expansion of what is currently written. Seems the same to me, and perhaps even more restrictive unnecessarily.

Bottome line for me is I think it is good as is.

[patrickhlauke]

@awkawk

@patrickhlauke I disagree because what @mraccess77 says about being able to move the pointer away or hit the esc key to cancel the click is the abort/undo aspect.

in that case the wording is very unclear. to paraphrase my new understanding here, the idea is something like:

Undo/abort: execution is on the up-event; if the user already clicked/tapped (executed the down-event), there is a way for the user to avoid the up-event from taking place; or there is a way for the user to undo the action that is executed after the up-event happened and they released their click/tap

?

noting that the fact that the user is able to move away a mouse/finger and as a result the up-event/click doesn't fire is something that the user agent handles, not something an author usually has to actively work towards.

[steverep]

@patrickhlauke I disagree because what @mraccess77 says about being able to move the pointer away or hit the esc key to cancel the click is the abort/undo aspect.

That's not the abort or undo aspect at all. See my previous reply above. Moving away from a target before releasing is solely covered by the No Down-Event bullet.

[patrickhlauke]

so going back to my previous suggestion, would the following make more sense for the bullets (with some wordsmithing possibly still needed):

Up-Event: The function is triggered only on the up-event; Abort or Undo: Completion of the function is on the down-event, and a mechanism is available to abort the function before completion or undo the function after completion; Up Reversal: Execution of the function is on the down-event, but the up-event reverses any of the outcomes (although with the rewording above, would that not simply count as a special case version of an "Abort or Undo?") Essential: Completing the function on the down-event is essential.

[steverep]

@patrickhlauke, please see my response above on why your suggestions are not satisfactory.

[patrickhlauke]

ah, i missed that you responded both to me and andrew in your response.

@steverep

Also, the SC doesn't say anything about having undo on the up-event so I'm confused by that comment.

on https://www.w3.org/TR/WCAG21/#pointer-cancellation the 2nd bullet says:

Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or undo the function after completion;

[steverep]

Ahhh....now I see your point. This is an editorial problem because it talks about completion too much. I'll think about a better way to say it, but here's the idea:

• Abort: I drag and drop something or perform a single pointer gesture, but before the function begins I get asked, "Are you sure?". In other words, the function doesn't actually execute except by listening to the input.
• Undo: I drag and drop something, but I can click an undo button to reverse it or just drag it back.

In other words, the first use of "completion" is just describing the input procedure, whereas the second is describing the actual function.

[patrickhlauke]

In the context of drag'n'drop type interactions (which was not obvious to me were intended in this), as I now understand is your concern @steverep: if at least one of the 4 bullets needs to be true, what would stop a developer from implementing a drag and drop that does trigger on the up-event, WITHOUT providing a mechanism to abort or undo (essentially, disregarding bullet 2), but then saying "well, i'm still ok because i'm satisfying bullet 1 since i'm not executing on the down event"?

or is the initial act of selecting/grabbing understood as being "part of the function" here?

in any case, this is all very dense and hard to parse (at least for me). assuming it's just me being dense, i'd say the understanding document better be considerably beefed up to make this understandable to a humble developer, with extensive examples of common things like links, buttons, as well as complex drag'n'drop etc scenarios.

[patrickhlauke]

a very late additional thought: do we (either here or anywhere else in WCAG) prevent authors from triggering functionality on mouse hover? (this would be like the mouse/pointer equivalent of "on focus")

this may potentially be squeezed in here as an extra bullet point (a la "no triggering functionality on hover")

[detlevhfischer]

This is a good one for 2.2.

On 17 Jan 2018, at 22:10, Patrick H. Lauke notifications@github.com wrote:

a very late additional though: do we (either here or anywhere else in WCAG) prevent authors from triggering functionality on mouse hover? (this would be like the mouse/pointer equivalent of "on focus")

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/700#issuecomment-358446295, or mute the thread https://github.com/notifications/unsubscribe-auth/AJhtP6hAfG2wbNBP9ZoFok4IbN93UaYdks5tLmHAgaJpZM4RcCgm.

[steverep]

is the initial act of selecting/grabbing understood as being "part of the function" here?

Yes, that's the idea.

in any case, this is all very dense and hard to parse (at least for me). assuming it's just me being dense, i'd say the understanding document better be considerably beefed up to make this understandable to a humble developer, with extensive examples of common things like links, buttons, as well as complex drag'n'drop etc scenarios.

I agree it's dense and yes the Understanding document needs an overhaul. I did my best to state things as succinctly as possible but I'm open to editorial suggestions. I'd rather keep as is for CR and perhaps make editorial changes there after working through the Understanding.

a very late additional thought: do we (either here or anywhere else in WCAG) prevent authors from triggering functionality on mouse hover? (this would be like the mouse/pointer equivalent of "on focus")

I would love to change "On Focus" to "On Focus or Hover". I think it would be a much better fit there than trying to squeeze it in here.

[awkawk]

(Official WG Response) Thank you for the comment. The WG used the discussion in this issue to inform the development of this SC. Please review the current version of the SC in the editor's draft.