2.5.2 Pointer cancellation - abort or undo clause is confusing

[becka11y]

Regarding the abort or undo clause, " 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;"

The use of "and" confuses me. It seems this implies that the completion is on the up-event AND a mechanism is available to abort the function before completion. And the comma after up-event adds to the confusion (implying the and clause IS a separate action). I think the and should be or because the understanding document implies that using the down-event is acceptable as long as there is an undo. It uses the example of phone dialing.

Thus the abort or undo clause becomes: "Completion of the function is on the up-event or a mechanism is available to abort the function before completion or undo the function after completion;

thanks for the clarification.

[patrickhlauke]

it took me a long time to work this SC out, but my understanding is that that point is specifically about drag'n'drop scenarios. the "and" is intentional. once you "grabbed" something, dropping it is on the up event...but there must be a way to abort this (i.e. that you can grab something, but then there's some way of not being forced to execute - for instance, NOT dropping the item in its intended drop target area). this aspect should definitely be clarified in understanding.

[steverep]

Hi @becka11y, Patrick's explanation is correct and this is a case where we simply need to get the understanding doc in sync with the latest SC. For now, you can check out the conversations in #380 and the latter half of #700 for some more detail. I'm going to be working on this understanding next. Sorry for the confusion.

[detlevhfischer]

I have in the meantime covered that somewhat in the understanding text. I believe the mechanism wording will invite misunderstanding, so we may need to add clarification that this does not necessarily mean on-screen controls. We have been wondering on yesterday’s call wether a drag-and-drop sufficient technique would make sense. The problem seems to occur in cases where there is no area outside the drop target areas to release the target that has been picked up. This could be the case in kanban board implementations, for example, that cover the entire screen area. The gap that opens were the item has been picked up often closes in implementations I have seen, like the react example (see video on implementation wiki page). So it is debatable wether dropping it where it has been picked up (not easy to see because the gap is closed) would meet the success criterion. Thoughts welcome... Detlev Sent from phone

…

Am 23.02.2018 um 02:00 schrieb Patrick H. Lauke ***@***.***>: it took me a long time to work this SC out, but my understanding is that that point is specifically about drag'n'drop scenarios. the "and" is intentional. once you "grabbed" something, dropping it is on the up event...but there must be a way to abort this (i.e. that you can grab something, but then there's some way of not being forced to execute - for instance, NOT dropping the item in its intended drop target area). this aspect should definitely be clarified in understanding. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[becka11y]

Thanks for your responses. I am still confused as to how the number dialing example in the Understanding document meets this SC. iOS enters a phone number on the down event, there is an undo button so it seems to pass but, I don't think the language in the Abort and Undo bullet is clear about that. In the current wording, the "mechanism is available to abort the function before completion or undo the function after completion," seems to apply only to the up event example. But, I think the part "or undo the function after completion" applies to actions that occur on the down event.
Perhaps,
Completion of the function is on the up-event and a mechanism is available to abort the function before completion, or a mechanism is available to undo the function after completion;
or
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, or if the function is on the down event a mechanism is available to undo the function.

But that wording may open up a new debate. But, when I first read this SC I thought iOS would fail but then I read the understanding document and realized it would pass and I don't see the wording in the SC to support that.

[mraccess77]

I brought up this very scenario with the iOS phone dialer several years ago on the mobile accessibility task force. It was my understanding at the time that the undo covered this scenario as well and that undo was NOT just limited to drag and drop. This in my opinion is strengthened by the word choice "functionality". Functionality is about purpose/outcome rather than how it is achieved.

[mbgower]

I acknowledge that this is a meaty SC. Simple message is: use the up event for triggering user actions.

Having said that, I agree with @becka11y's read of the logic, and that the phone interface is a perfect example. It uses the down event to trigger the phone numbers. Say I mistouch a number. The number needs to be removed, but none of the bulleted scenarios allow use of the backspace to pass this SC, since the second bullet is an "and," making the Undo action dependent on an up event to be a valid way of meeting the requirement.

The only way to parse the current dialing interaction as a "pass" is if one considers the function to be to actually calling the number, in which case the green 'place phone call' button beneath the number pad IS on the up event and completes the action, meeting bullet 2. If this is the argument -- that typing is an action that forms part of the function of placing a call and so each number entry is not a separate function -- it needs to be made clearer...and seems like something of a slippery slope. (The same scenario occurs, BTW, with any typing using the native keyboard in iOS. )

So, three possible other responses:

1. The current phone interaction on iOS and Android should fail and be remediated.
2. The phone example is irrelevant, since it is a native UI and so not covered by WCAG. (Possibly as well, that there are accessibility settings in the OS to accommodate improved touch affordances.)
3. The SC needs a slight editorial wording for 'clarity'

I wonder if the solution is to modify the second bullet to read:

A mechanism is available to undo the function after completion or, where completion of the function is on the up-event, to abort the function before completion;

I think this could be argued as editorial. It also seems to jibe with the Understanding document where one of the solutions states:

An undo button or other mechanism allows the user to reverse the action.

[patrickhlauke]

On 01/03/2018 14:52, Mike Gower wrote: [...]

The only way to parse the current dialing interaction as a "pass" is if one considers the /function/ of the dial to be to actually calling the number, in which case the green 'place phone call' button beneath the number pad IS on the up event and completes the action, meeting bullet 2. If this is the argument -- that typing is an action that forms part of the function of placing a call and so each number entry is not a separate function -- it needs to be made clearer...and seems like something of a slippery slope. (The same scenario occurs, BTW, with any typing using the native keyboard in iOS. )

Do the definitions linked from the normative SC text help in any way? functionality: processes and outcomes achievable through user action https://www.w3.org/TR/WCAG21/#dfn-functionality process: series of user actions where each action is required in order to complete an activity https://www.w3.org/TR/WCAG21/#dfn-processes Is the single typing of a digit counted as "functionality"? Or a single user action which is part of a process (dialing the entire number, then hitting the dial button) only? Noting also that the green dial button does not react on down, but on up, and has the same bail-out as regular buttons (if i down over it, then move my finger away, then releasing the finger/doing the up action does NOT trigger dialing).

I wonder if the solution is to modify the second bullet to read: A mechanism is available to undo the function after completion or, where completion of the function is on the up-event, to abort the function before completion;

As this point, that sounds like two separate bullets crammed together into one? Are the two mutually exclusive amongst themselves? If not, as it's already part of an "at least one of these must be true" list of bullets, this sounds more like splitting it into two separate bullets may work best? (which may go a bit beyond pure editorial, not sure)

[mbgower]

Do the definitions linked from the normative SC text help in any way?

I don't think they help a great deal. Sure we can say the typing of phone numbers is a set of 10 discrete actions to create a full US/Canada phone number; however, the function of pressing each number button to populate the phone input seems to still exist as a separate atomic function necessary to complete the whole.

Noting also that the green dial button does not react on down, but on up, and has the same bail-out as regular buttons (if i down over it, then move my finger away, then releasing the finger/doing the up action does NOT trigger dialing).

Yep, the point I was trying to make -- unlike the number buttons, the Call button behaves on up event.

As this point, that sounds like two separate bullets crammed together into one?

Well, after all the label for the bullet is already "Abort or Undo"; all I've done is separated the two actions with an "or" conjunction :). And yes, one of the reasons of doing it this way is it is a lot easier to argue it is just editorial.
Separating into 2 bullets is feasible, especially given the "or" and the "any of these must be true" text. I'll see if I can word it that way without exceeding an 'editorial' change.

[mbgower]

Here are the changes in bold. I think this could be considered editorial...

For functionality that can be operated using a single pointer, at least one of the following is true:

• No Down-Event:
  The down-event of the pointer is not used to execute any part of the function;
• Undo:
  A mechanism is available to undo the function after completion;
• Abort:
  Where completion of the function is on the up-event, a mechanism is available to abort the function before completion;
• Up Reversal;
  The up-event reverses any outcome of the preceding down-event;
• Essential:
  Completing the function on the down-event is essential.

[mraccess77]

* I don't think they help a great deal. Sure we can say the typing of phone numbers is a set of 10 discrete actions to create a full US/Canada phone number; however, the function of pressing each number button to populate the phone input seems to still exist as a separate atomic function necessary to complete the whole. Yes, exactly, entering each number is a function and that number can be erased by tapping the back/delete icon so there is an undo mechanism for that function. So this passes the original intention of the SC because the number may have accidently entered can be erased and backspaced through. That’s my recollection of the discussions from the TF several years ago. So having the undo clause separate is needed.

[mbgower]

@steverep , is this a friendly change?
#773 (comment)
@michael-n-cooper would this be allowable as an editorial change? It is arguably for clarification and does not increase the requirement.

[mbgower]

[Proposed official response]
Thank you for your comment. The working group agrees the wording is unclear and that "or" is intended. To resolve, we are making an editorial change to split Abort and Undo into two separate bullets in the list of possible means of meeting the SC. This not only clarifies the "or" choice, but makes the phone dialing example in the Understanding document clearly match the Undo bullet.
The wording will become (changes in bold):

For functionality that can be operated using a single pointer, at least one of the following is true:

• No Down-Event:
  The down-event of the pointer is not used to execute any part of the function;
• Undo:
  A mechanism is available to undo the function after completion;
• Abort:
  Where completion of the function is on the up-event, a mechanism is available to abort the function before completion;
• Up Reversal;
  The up-event reverses any outcome of the preceding down-event;
• Essential:
  Completing the function on the down-event is essential.

[awkawk]

Questions from the WG:

1. Do Apple-specific UI events (e.g. TouchUpInside/Outside) work with this SC text? (@patrickhlauke)
2. @steverep Can you explain the first bullet? Is down-event being involved with the function a common or uncommon occurence?

[DavidMacDonald]

#773 (comment)

editorial to @mbgower suggestion

Current proposal

Abort:
Where completion of the function is on the up-event, a mechanism is available to abort the function before completion;

Amended proposal

A mechanism is available to abort the function before completion;

[patrickhlauke]

Do Apple-specific UI events (e.g. TouchUpInside/Outside) work with this SC text? (@patrickhlauke)

These are native events, not web content events, so they'd be out of scope for WCAG (but can be clarified in a more general ICT mapping context?)

(but from my understanding, if listening to TouchUpInside for your actual activation you're ensuring that the user has an "out" by moving their finger outside of the element before lifting their finger, or you can explicitly listen for TouchUpOutside as the "cancel"/"abort")

[StommePoes]

Is the single typing of a digit counted as "functionality"? Or a single
user action which is part of a process (dialing the entire number, then
hitting the dial button) only?

While dialing a number is a common thing where, in your own time and with backspace buttons, you can type whatever and nothing really matters until you hit the call button.

BUT

Once you're in a call, if it is automated, typing is often sent immediately (the process becomes the function). "Hit # to complete." "Press 1 for English." etc.

Does that scenario change anything with the keyboard/phone example? Similar could be any webby dashboard/whatever that does similar-- would the keys have to be changed to up events to pass? Should they fail if the same keys are sometimes functions and sometimes process-actions and is it confuzling if sometimes ups trigger and sometimes downs?

[mbgower]

I had a chat with @steverep today, who was the original author of this SC. He is swamped at the moment, so I'm going to paraphrase our discussion and explain why he does not want it changed, and what we can do to address @becka11y 's original issue.

First, Becky is correct that there could be slight revisions to the language to make things clearer. I'll list one editorial change here which I hope does that:

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;

So, I have added in the word "to" in front of "undo", which I hope clarifies that it qualifies function and is not an alternative to completion on the up-event. Becky had already correctly interpreted the SC language (and was thrown off by the incorrect Understanding document), so hopefully this makes it still clearer.

I am now going to elaborate on the reasons why Steve strongly objects to the changes in my proposed response comment (and David's alternative).

Steve's key point here is that if we remove the up-event qualification on undo and abort, then we are essentially negating the first bullet covering "no down-event".

Establishing that "the down-event of the pointer is not used to execute any part of the function" is critical because then the remaining bullets of the SC are essentially exceptions for when down-event is used. (In other words, the idea is you should normally pass on the first bullet, and only need to progress to other bullets where you have a more complex interaction.)

Steve wants to avoid situations where, for example, a link can be triggered on the down-event, because "all" the user has to do is hit the Back button on the browser to "undo" it. The proposed language changes would allow anything to be triggered on the down event so long as there is some way of undoing it afterwards, which is obviously non-optimal.

An important point to make: Steve emphasizes that emulating a keyboard or numeric keypad falls under Essential, because physical keyboards/pads function on down-event. To make an emulator function on up-event would be to significantly affect the response time and the interaction expected by users. He plans to revise the outdated Understanding document to make this clear.

He believes that the phone dialer (and any other keyboard emulator) use case is one of the few where the Essential categorization could be invoked. Because of this, I suggest that including something like this under the SC text might be advisable: Note. Functions that emulate a keyboard or numeric keypad key press are considered essential.

To summarize, Steve is recommending the following be done in response to this issue:

1. Make the slight editorial change to the Abort or Under bullet by adding "to" before "undo"
2. Rewrite the Understanding document, including making it clear the Phone example is an essential exception
3. Considering adding a Note under the SC text.

@awkawk, once Becky has responded to this approach, I think we need to do another WG Review

[awkawk]

@mbgower Can you make a pull request of the proposed changes today?

[mbgower]

@awkawk, done, although I did it in the existing branch and so have accidentally pulled in more than just my changes.
#860

I only saw this now, so haven't addressed changes in the Understanding document (note that this pull request contains a bunch of changes from Detlev which may already cover it).

[awkawk]

[Proposed Response]
Thank you for the comment. To address this concern we are making a simple change to the "undo or abort" bullet and are adding a note to clarify the use of down-event. See https://github.com/w3c/wcag21/pull/860/files?diff=split for the changes to the SC text.

[mraccess77]

Can someone help me understand now when the mechanism to undo would apply or not apply? Are we allowing undo or not? For example, allowing the user to go back a page after following a link on the down event.

[mbgower]

@mraccess77 The mechanism to Undo is an option to comply where the function is completed on the up event.

My understand is that where something is wholly triggered on the down event, you could not comply through Undo. You would have to have some part of your action completion on the up event to meet Undo or Abort. It is intended for complex mouse interactions. A single click event like hitting a link should always take place on the up event.

Note that this does not prevent someone from adding an Undo for any function (it's built into every keyboard UI).

[mraccess77]

Thanks @mbgower that was helpful. I guess we might want to emphasize the "completion" bit to help users parse it easier.

[mbgower]

Agreed. Adding an Understanding label to this so it is picked up in when that doc is updated.

[michael-n-cooper]

Referencing #791 for actioning.

Please note we have specific issues setup iterative updates to the understanding documents, this issue is not lost, but will be tracked on that issue.

[mbgower]

I have created a pull request to address these consideration. #884