Abort of the Up-Event not possible - Violation of SC 2.5.2

[JAWS-test]

I have an application that contains menu items that are not triggered until the up-event. So "No Down-Event" from SC 2.5.2 is fulfilled. However, it is not possible in the application to abort the Up-Event by dragging the mouse away. I.e. if I drag the mouse away from the menu item, the page is still opened as soon as the mouse button is released. Is this then a violation of SC 2.5.2 (although the wording does not indicate this) or is it a gap in SC 2.5.2?

[patrickhlauke]

Abort or Undo 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;

does it not fail the "and" part?

[patrickhlauke]

actually, looking at this closer...

I think the "at least one of the following is true" clause actually leads to gaps.

taking this example, the first clause is clearly TRUE. the fact that the second clause is FALSE (because it doesn't do the "and" part) is irrelevant, since we already now have "at least one of the following"

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;
• Abort or Undo: 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;
• Up Reversal: The up-event reverses any outcome of the preceding down-event;
• Essential: Completing the function on the down-event is essential.

[patrickhlauke]

seems the relationship between those 4 points is more complex than "at least one of these is true". it's more

( (No Down-Event) AND (Abort or Undo) ) OR ( ( NOT (No Down-Event) ) AND (Up Reversal) ) OR (Essential)

[edit: even that's probably not right...there's definitely some interconnectivity between the first one and the following two]

[mraccess77]

The intent of the wording was that if you did use the up event that it could be canceled or undone. So if you can undo it would seem to pass the intent.

[patrickhlauke]

yes but the SC says ... "at least one of these", as JAWS-test's example passes the first point (as it's not on the down event), that satisfies the "one of these" clause and the SC would pass (when of course it shouldn't)

So if you can undo it would seem to pass the intent.

and to be clearer, in this case JAWS-test is saying that it can't be aborted/undone I think

[JAWS-test]

The intent of the wording was that if you did use the up event that it could be canceled or undone

That was the intention, but it was not formulated in this way. So what do I do with my WCAG test? Do I detect a violation of the intent, or do I say it is not a violation because the wording of the SC is fulfilled? It is probably not the intention that counts, but the formulation of the SC. But that concludes my question as to whether the SC should be revised so that the intention is better achieved?

[alastc]

If it's not using the down event, then I'd say it passes via the 1st bullet.

I.e. if I drag the mouse away from the menu item, the page is still opened as soon as the mouse button is released.

I've not seen such an example, do you mean that:

• You click on the link ('down')
• You move off the link
• You release the click ('up')

And the link still activates? That seems odd.

-Alastair

[JAWS-test]

I've not seen such an example, do you mean that ...

Yes, that's the way it is. It's not a web application, it's a software. However, according to EN 301 549 the SC 2.5.2 also applies to software.

[patrickhlauke]

@alastc do you agree there's a gap, per the above (about the "at least one")?

[JAWS-test]

Also in a web page such a behavior can be implemented with JavaScript, see: https://codepen.io/jaws-test/pen/GRodaom

[alastc]

@JAWS-test - that seems like slight of hand, I'd argue the down event is used to 'execute any part of the function', therefore that is caught by the 1st bullet.

Perhaps the same is happening in the app version you are looking at, but because you can't interrogate the code it is not apparent?

Conceptually, the code must capture that you clicked within a target, it is just delaying the action until you have released.

So on that basis, @patrickhlauke, I'm not convinced it is a gap, but it does seem harder to detect in an app.

[patrickhlauke]

seems more like a "semantic sleight of hand". not sure the fine point of "it's executing on the down-event, just delaying until the up-event" is obvious or clear. if something is delaying, then it's not executing. unless we say the logic that does the delaying is "part of the function".

maybe the understanding could include some specific example then along these lines, so it's documented somehow?

[alastc]

Well, the example is clearly doing something with the down event, if it is on the link. I'd agree the up-event is not covered where you click outside the link.

Happy to add something to the understanding, any suggestions?

[patrickhlauke]

the example is clearly doing something with the down event

problem is with modern tooling, most sites do "something" with almost every event. it's hard to then disentangle specifically if that "something" is "the actually part of "the function" or not.

anyway, i'll mull over something, but it still feels like splitting hairs either way. still feel that

( (No Down-Event) AND (Abort or Undo) ) OR ( ( NOT (No Down-Event) ) AND (Up Reversal) ) OR (Essential)

is perhaps more accurate than saying "one of these needs to be true"

[JAWS-test]

I'd argue the down event is used to 'execute any part of the function', therefore that is caught by the 1st bullet.

I can't tell you what's happening in the software. And even with a website, it can't be the task of a WCAG audit to examine the JS code. Also, I wouldn't say that in my example something happens in the down event according to SC 2.5.2. If it does, then the JS-click event would also be an event that only works because down and up events occur on the same element. The click-event is not a pure up-event, as you can see on https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_onclick

[jake-abma]

agree with Alastair the down-event IS used in this case

[patrickhlauke]

how's about this https://codepen.io/patrickhlauke/pen/BajVKYx - the only event used is the up event, but it still can't be cancelled. however, because the "no down-event" clause is fulfilled, this passes the SC because "at least one of these is true"

(and yes, this is currently an artificial example, but with event delegation this sort of thing will be used as well - or with complex interfaces where they just hang the listener high up and then, in the function that gets executed, work out which element was actually under the mouse pointer at the time)

[patrickhlauke]

here's a radical thought to patch that gap: what would happen if the first bullet (which is the one that is "true" in the above example, and then exonerates my demo from failing) was simply removed?

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

Abort or Undo: 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; Up Reversal: The up-event reverses any outcome of the preceding down-event; Essential: Completing the function on the down-event is essential.

would this, which patches the gap, miss out any particular scenarios?

[JAWS-test]

what would happen if the first bullet (which is the one that is "true" in the above example, and then exonerates my demo from failing) was simply removed?

I think that would work very well. But then the understanding should be adjusted, because "Abort or Undo" currently refers very much to Drag & Drop. The explanation of "No Down-Event" would then have to be moved to "Abort or Undo

[JAWS-test]

agree with Alastair the down-event IS used in this case

The problem is that every normal click event is also a down- and up-event, just like in my example. The only difference is that the click event checks that the target for the down event is identical to the target for the up event. However, SC 2.5.2 does not make this specification, so the example I gave and the one in the software I tested should not count as a down event in the sense of SC 2.5.2

[alastc]

how's about this https://codepen.io/patrickhlauke/pen/BajVKYx - the only event used is the up event, but it still can't be cancelled.

Interestingly I can click on each link, drag off, and cancel that action. Is that intended? Presumably the high specificity (or whatever the correct JS term is) of the link means it over-rides the background event?

The intent of the SC was to prevent immediate actions on the down event, I'm not sure if malicious up-event usage is an equivalent, or was intended to be caught?

[patrickhlauke]

I'm not sure if malicious up-event usage is an equivalent, or was intended to be caught?

while my example is a bit artificial, this is not "malicious". it's a pattern that can happen to be used in the wild when there's event delegation. in any case, the intent of the SC was to make sure users don't accidentally trigger stuff when they didn't intend to. not providing a way to abort/undo going from the down to the up event is exactly what this SC intends to do. just that the way it's currently worded with the "at least one of these" allows situations that do cause the problem this SC tries to prevent to actually be nominally compliant.

[patrickhlauke]

Interestingly I can click on each link, drag off, and cancel that action. Is that intended?

no i still wanted those links to work as they should, so didn't do anything special there. i could have though (e.g. if i really wanted to, could have done a preventDefault on the links).

anyway, the point is: these sorts of event delegation patterns can and do happen https://medium.com/@bretdoucette/part-4-what-is-event-delegation-in-javascript-f5c8c0de2983

it's not outlandish to expect that the SC that intends to avoid situations where a user accidentally does a "down event" has something happen right away, OR inescapably on the up event that follows. and this is purely down to the "at least one of these" and the first clause leading to unintended gaps.

[patrickhlauke]

But then the understanding should be adjusted

well yes of course, but let's concentrate first on seeing if the NORMATIVE part of the SC can be streamlined to still cover the same as before while also plugging this gap.

[patrickhlauke]

an even cleaner/clearer example, this time using just touchend https://codepen.io/patrickhlauke/pen/PoZaJpK - open it on a touch device (or using chrome or whatever with device and touch emulation) ... for best results, use the live view https://codepen.io/patrickhlauke/live/PoZaJpK

again, this is the sort of thing this SC tries to avoid. and yet, the fact that nothing happens on the down-event (since the auto-capturing of the event happens by default in the browser with touch events, so it's absolutely nothing the author is actively doing), this case passes the normative wording of the SC.

if, as proposed above, the first bullet was simply removed, this scenario would fail

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

Abort or Undo: 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; Up Reversal: The up-event reverses any outcome of the preceding down-event; Essential: Completing the function on the down-event is essential.

[JAWS-test]

I have found that HTML sliders also respond to the down event. It's even more complex with the W3C ARIA sliders (see https://github.com/w3c/aria-practices/issues/2446)

• 2 do not react to down event and operation can be cancelled by dragging the mouse away
• 2 do not respond to down event, but operation cannot be canceled by dragging away, since dragging away operates the slider.

Does this make the ARIA and HTML sliders violate 2.5.2?

[jake-abma]

Why would the slider violate 2.5.2? it's the total implementation which causes a violation.

You may use these sliders but something else also needs to be done in combination, and so they will / can pass.

See the Understanding doc text:

For more complex interactions, such as drag and drop, the down- and up-events may initiate and end a series of actions to complete a process. For example, with drag and drop, the item may be:

• selected with a press (down-event),

• moved to a new location, while still being depressed, and

• released (up-event) to conclude the drop action.

In such a complex action, the need for an Abort or Undo function increases. Designers may elect to confirm the move through something like a confirmation dialog or an undo button, giving the user the ability to Undo the process just completed. Alternatively, the ability to Abort the action can be achieved if, before completing step 3, the user returns the selected item to its original location and concludes the process there. If other parts of the screen disallow a move, the user can conclude the drag and drop there, effectively nullifying the operation.

You're right I think if only the sliders are used as seen on the Authoring pages, but isn't that exactly why the SC is created in the first place?!

Use the slider BUT also "confirm the move through something like a confirmation dialog or an undo button" or alike