Assess JavaScript behaviours for WCAG 2.1 Pointer Cancellation

Problem/Motivation

A new WCAG 2.1 Success Criterion, "2.5.2 Pointer cancellation" recommends tying custom behaviours to the up pointer events, in preference to the down events.

TODO: demo of why this matters. e.g. Users who employ iOS touch assistance feature, which allows users to fine-tune where their finger is before the touch has any effect. (Not sure of exact terminology here).

Text of WCAG 2.1 - SC 2.5.2 Pointer cancellation

(as of the Candidate Recommendation, 30th Jan 2018)

Success Criterion 2.5.2 Pointer Cancellation (Level A)

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 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.

Extra information is available in Understanding Pointer Cancellation, which will form part of the WCAG 2.1 supporting documents.

Proposed resolution

Assess Drupal core JS for how it uses mousedown vs mouseup events. Likewise for touch events.

Prefer "up" event, if it makes no difference.

Possibly some JS behaviours may need the down event (drag?), in which case identify these and justify why they need the "down" event.

Remaining tasks

Look for all instances of javascript evnt listeners which use "down" events: mousedown, pointerdown, touchstart, MozTouchDown.
Note: We're NOT interested in keydown events here.
TODO: are there any other events we should look for, like vendor specific ones?

For each instance, decide if we can change it to use the equivalent "up" event, or an abstract one like "click".
If it depends on the "down" event, justifiy this with an explanation.

TODO: create child issues for any changes needed.

User interface changes

No changes to the UI design. This is about tightening up implementation to address a new WCAG 2.1 success criterion. Should make the UI more robust and usable for some users with motor difficulties.

API changes

None.

Data model changes

None.