You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.
The current Accidental Activation SC text and understanding is clear for single tap or click and even touch and hold, but when a pointer action occurs as a result of a series of events, the criterion seems to gray. Clarification is needed around pointer actions that occur in series, such as:
Drag and drop: If drag and drop are taken as two separate activations, then the drag would presumably pass as essential, and the drop would pass as the up event. If a drag and drop is taken as one activation, then it could be interpreted either as passing via exception or because the drop occurs on the up-event. The issue comes in because this doesn't actually satisfy any user problem. Accidental drops would benefit greatly by being able to be reversed or confirmed.
single pointer gestures: As with drag and drop, I could interpret this as being exempt because the down-event activates the start of the gesture, or I could consider the whole series as the activation and the criterion passes if the up-event is the final straw. However, this has not satisfied any user need regarding accidental gestures, where again reversal or confirmation is desired.
Double click, triple click, etc.: Does each tap or click need to be on the up-event, or just the final one? This matters because the action could be aborted at any stage.
As suggested in #330, talking about "release" instead of "up-event" would begin to help here, but I think wording around what constitutes an "activation" is needed.
The text was updated successfully, but these errors were encountered:
@awkawk, here's what I came up with to rectify this issue and others discussed on the call yesterday:
For functionality which 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;
Essential Completing the function on the down-event is essential.
Then we link to functionality and mechanism, and change the proposed definition of "single pointer activation" to simply "single pointer", i.e. it talks about one point of contact with a screen or a single mouse cursor. This would just result in a purely editorial change to Pointer Gestures to delete "activation". Some rationale:
The first bullet is the desired choice for single clicks, double clicks, etc. By simply saying the down event is not used (as opposed to using the up event), it guarantees there is a place to abort by moving away before the up-event.
The second bullet is the choice for drag and drop, single point gestures, and long press.
The essential bullet is for stuff already identified (e.g. games).
Delete wording around "explicitly or implicitly as a platform's generic activation event". This is encompassed by using "mechanism", which says authors can either provide their own or rely on the user agent.
Added "completion is on the up-event" to the abort/undo condition because this is only meant to be an out for non-click events, right? A big question though: Aren't most actions reversible? For example, is the browser's back button a mechanism for reversal? Adding this phrase fixes that loophole.
The current Accidental Activation SC text and understanding is clear for single tap or click and even touch and hold, but when a pointer action occurs as a result of a series of events, the criterion seems to gray. Clarification is needed around pointer actions that occur in series, such as:
As suggested in #330, talking about "release" instead of "up-event" would begin to help here, but I think wording around what constitutes an "activation" is needed.
The text was updated successfully, but these errors were encountered: