No Accidental Activation

[kwahlbin]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• Up-Event definition | Up-Event definition for editing
• Single Pointer Activation definition for viewing | Single Pointer Activation for editing
• SC in full draft guideline

Definition of Single Pointer Activation not in FPWD - filed bug #168

SC Shortname

No Accidental Activation

SC Text

For single pointer activation, at least one of the following is true:

• Activation is on the up-event, either explicitly or implicitly as a platform's generic activation/click event;
• A mechanism is available that allows the user to choose the up-event as an option;
• Confirmation is provided, which can dismiss activation;
• Activation is reversible;
• Down-event activation is essential and waiting for the up-event would invalidate the activity.

Suggestion for Priority Level (A/AA/AAA)

Level A

Related Glossary additions or changes

Up-Event: The activation of a component when the trigger stimulus is released. On different platforms the "up-event" may be called different things, such as "touchend" or "mouseup".
Example: For touchscreen interaction, the event is triggered when a finger is lifted from the touchscreen at the end of a tap.

Single Pointer Activation: One point of contact with the screen (vs. multi-touch). A pointer can be any point of contact on the screen made by a mouse cursor, pen, touch (including multi-touch), or other pointing input device. This model makes it easier to write sites and applications that work well no matter what hardware the user has. For scenarios when device-specific handling is desired, this specification also defines properties for inspecting. Pointer Events (REC) Pointer Events Level 2 (ED)]

What Principle and Guideline the SC falls within.

New Proposed Guideline "Pointer Accessible"

Make it easier for users to operate pointer functionality.

Editorial Note for WCAG group: Pointer includes "Touch" in its definition

Description

People with various disabilities can inadvertently initiate touch or mouse events with unwanted results. Up-Event activation refers to the activation of a component when the trigger stimulus is released. For example, for touchscreen interaction the event would be triggered when a finger is lifted from the touchscreen at the end of a tap.There is a distinction between when someone touches a screen and when they remove their finger. On a mouse there is a difference between mouse down (initiating a click) and mouse up (releasing the finger). Authors can reduce the problem of users inadvertently triggering an action, by making activation on the up-event. This gives users the opportunity to move their finger or other pointer (e.g. mouse) away from the wrong target once they hit it. If touch down activation is necessary, there are several options:

• A confirmation alert allows the user to change their mind
• An undo button or other mechanism allows the user to reverse the action.
• A setting in preferences allows the user to choose whether activation happens on the down or up event.

Generic platform activation/click events generally trigger on up and when they do, they are also allowed. For example, in the case of mouse interactions, the "click" event in JavaScript triggers on release of the primary mouse button, and is an example of an implicit up-event.

Examples of where timing of the activation is essential would be:

• An activity that would be invalid if activation waited for the up-event such as a piano program.
• A program for shooting skeets where waiting for the "up" event would invalidate the activation.

Long press activation and 3D touch can be used as long as one of the above listed alternatives is present, and there is another conforming way to provide the action performed by the control.

Examples

• For interface elements that have a single tap or long press as input, the corresponding event is triggered when the finger is lifted inside that element.
• A phone dialling application has number keys that are activated on touch down. A user can undo an unwanted number by hitting the backspace button to delete a mistaken digit.

Benefits

• Makes it easier for all users to recover from hitting the wrong target.
• Helps people with visual disabilities, cognitive limitations, and motor impairments by reducing the chance that a control will be accidentally activated or action will occur unexpectedly.
• Individuals who are unable to detect changes of context are less likely to become disoriented while navigating a site

Evidence

• Discussion forum showing up event is default
• touch is activated on removing finger on Android by default
• touch guidelines by trace
• Jon A. was in touch with a research project which tested 30 users with physical dexterity disabilities. Results outstanding.

NOTE: There is feedback from the WCAG working group on this work. Captured in minutes here and in the Survey remarks. This feedback has been incorporated into this SC.

Testability

The majority of the testing of this will be terminated after the first test.

Activation is on the up-event, either explicitly or implicitly as a platform's generic activation/click event;
Test: Examine code for the Up-Event. This could be done with automated checking. OR activate the event with a pointer to ensure it activates on release rather than on contact.
If that is not true, proceed to the next test.

A mechanism is available that allows the user to choose the up-event as an option;
Test: Examine code for a mechanism that switches activation to the Up-Event. This test could be automated. Or functionally test it by examining for a mechanism that changes event activation to the up-Event.

Confirmation is provided, which can dismiss activation;
Test: Examine code for a confirmation mechanism that allows the user not to proceed with the action. Or functionally test it by activating the control and looking for a confirmation dialogue that allows the user not to proceed with the action or to proceed with the action.

Activation is reversible;
Test: Examine code Can be tested both functionally and by looking at the code for a control that reverses the activation.

Timing of activation is essential and waiting for the up-event would invalidate the activity.[edit]
Test: Can be tested by considering whether activating as the user leaves the surface would invalidate the activity (up-event). AN example would be a piano program that needs the keys to lay as the user touches the key rather than when they leave the key. WCAG 2.2.1

Techniques

• Activating a control using the up-Event in HTML, iOS and Android
• M029(wiki) Touch events are only triggered when touch is removed from a control
• FM001 Failure of SC 2.5.3 due to activating a button on initial touch location rather than the final touch location
• Failure: Actions are only available through long press or 3D touch

Boneyard

Removed Note: This success criteria applies when platform assistive technology (e.g. screen reader) that remaps touch gestures is not turned on - see proposed SC Touch with Assistive Technology.

• Platform assistive technology that remaps touch gestures definition for viewing | Platform assistive technology that remaps touch gestures definition for editing

Platform assistive technology that remaps touch gestures: Software that is integrated into the operating system, ships with the product, and/or is updated or installed via system updates. This software changes the characteristics of the touch interface when turned on. (e.g., a system screen reader may remap a right swipe gesture to move focus from item to item instead of it's default behaviour when the assistive technology is not on).

[alastc]

Looks good to me.

[jnurthen]

"Activation is on the up-event, either explicitly or implicitly as a platform's generic activation/click event;" sounds like a technique not a Success Criteria.

[alastc]

Perhaps, but there isn't an SC for it to go under at the moment?

Do you mean the SC text should be generalised? E.g. Selecting controls with a pointer should allow for incidental activation, under which the methods are provided as techniques. (Not that I'm happy with that text, just trying to understand your point.)

[jnurthen]

@alastc yes that is my point. Essentially what the up-event thing is trying to say (IMO) is that there needs to be a way for someone to start an activation and be able to do something to not complete that activation.
Using the up-event is a technique for this but who knows what else someone might come up with.

This was Q3 on @DavidMacDonald 's Acceptance Criteria
"Does it describe the specific condition required to meet the criteria, not the method to address the criteria. (Yes/No Radio)"

[DavidMacDonald]

We tried a number of ways to word this, and this seemed to be the clearest. It is a generic term "up-event" rather than technology specific. Otherwise we risk getting into what the user can and can't do, which can be difficult to assert given the vast array of abilities various users may or may not have...
However, I think we might be able to address @jnurthen concern by amending the third bullet to something like this:

• Confirmation is provided or another way to dismiss activation is provided once it has begun

[mbgower]

Just for my edification, are you differentiating between selection and activation, and does it need to be explained?
An example from VoiceOver where the Touch Typing interaction is activated:

Touch a key on the keyboard to select it, then lift your finger to enter the character. If you touch the wrong key, slide your finger to the key you want.
VoiceOver speaks the character for each key when you touch it. VoiceOver enters a character when you lift your finger.

I'm assuming that in the context of this SC, entering the character is an example of an 'up event', but the selection of the key on the 'down event' is equally important, and obviously important that it NOT happen on the 'up event'. I realize that the various features and choices in VoiceOver provide ways to workaround this modality. I just wanted to demonstrate a scenario where selection without an up event is essential to an interaction. I'm sure there are many other scenarios (both using and not using AT) where selection needs to occur on the down event.

Are you expecting such interactions to be ignored with the last of the four exception scenarios? Some language defining what is meant by "activation" will help clarify this.

And what about where a target no longer has finger contact (in the case of touch), but there was no 'up event', just a roll away from it? With a mouse, it is possible to click down and then move away from an element without releasing the button, thus not having an up event triggered.

[detlevhfischer]

@mbgower Regarding your Touchtyping with VoiceOver Example:
The SC Text states in its note that the

success criteria applies when platform assistive technology (e.g. screen reader) that remaps touch gestures is not turned on - see proposed SC Touch with Assistive Technology.

We are concerned here with activation. If we need a definition, how about

"Activation means that some user interaction via a pointer (e.g., a mouse click, a tap on the touch screen, or the contact of a stylus) triggers an action, which is usually the defined behaviour of a control. For example, the activation of a link means that the page referenced is called up, while the activation of a checkbox or switch means that its state will change from unchecked (off) to checked (on) or vice versa.

@alastc : In your more generic SC name proposal "Selecting controls with a pointer should allow for incidental activation" above, I am not sure that you used incidental purposefully or whether you meant "should avoid accidental activation". incidental can mean that something happens as a side effect, but may also refer to a particular fitting occasion. It does not seem to express clearly that we are dealing with ways of preventing undesired interactions.

@jnurthen I quite like your idea to keep this more general and leave it to techniques to spell out how accidental activation can be prevented. The current bullet point list in the SC text is not easy to parse and contains somewhat obscure options like "Confirmation is provided, which can dismiss activation" which I so far have not seen used on controls that are triggered on the "down event" (any examples, anyone?)

@DavidMacDonald Regarding the option of a more generic formulation, you expressed concern that

we risk getting into what the user can and can't do, which can be difficult to assert given the vast array of abilities various users may or may not have...

We actually already got into that in our handful of options of what the user might be able to do to avoid accidental activation. As to the vast array of user abilities, the SC focusses on the much narrower subgroup of pointer users without AT. As we will likely see more input mechanisms arrive at our doorstep, keeping this SC more generic would somewhat future-proof it (think virtual touches where the up event may be mapped to a distinct movement away from the touch target along the z-axis, while a lateral movement might prevent activation).

[patrickhlauke]

@mbgower with regards to the voiceover touch typing example, the fact that users can actively change the way they interact with the keyboard ("Standard Typing", "Touch Typing", "Direct Touch Typing") should be sufficient to cover this scenario? Or would it be even better to have an explicit additional bullet point in the SC description along the lines of

• Users can select alternative activation interactions

Incidentally, this could actually replace the second bullet - allowing the user to choose the up-event as an option would be covered by being able to select an alternative activation interaction.

[patrickhlauke]

are you differentiating between selection and activation

I believe the short answer to that would be yes. Selection is also reversible (in most cases?) so even if a reader misunderstood this distinction, it would be exhonerated by the fourth bullet point "Activation is reversible"

[mbgower]

@patrickhlauke, I completely agree that the VoiceOver example I used was already exempted in the language. I was trying to provide a concrete example of selection versus activation. That has been clarified, and overall, I like @detlevhfischer's suggested language:

"Activation means that some user interaction via a pointer (e.g., a mouse click, a tap on the touch screen, or the contact of a stylus) triggers an action, which is usually the defined behaviour of a control. For example, the activation of a link means that the page referenced is called up, while the activation of a checkbox or switch means that its state will change from unchecked (off) to checked (on) or vice versa.

However, I'm not sure why a pointer is specified, as this SC could apply to keyboard as well. Is the assumption that an equivalent will be provided through 2.1.1, so it's redundant? If not, it could be "...via a key event or pointer..." or strip that out entirely and make it "...some interaction triggers..."

Maybe I just need to better understand the rationale for this to "focus on the much narrower subgroup of pointer users". I understand the future-proof desire, but worry that a slew of SCs that focus on more narrowly defined inputs makes for more author effort (reading, understanding, etc.) to reach the same objective and also risks becoming problematic in the future.

"Confirmation is provided, which can dismiss activation" which I so far have not seen used on controls that are triggered on the "down event" (any examples, anyone?)

@detlevhfischer, how about on a touch screen where I press and hold on something like a phone number or physical address which has been underlined by the OS, and that triggers a menu of possible choices I can trigger?

[patrickhlauke]

Accidental activation is more of a problem for pointer-type inputs because these often serve the dual purpose of both activating things and navigating/scrolling. For instance, specifically in the case of touchscreens, a user may place the finger down on the screen over a control, but they intend to then move the finger to scroll. So having something that triggers/activated immediately on touch down would make scrolling excessively difficult for users, particularly if they have limited mobility.

Same for stylus interfaces. For mouse, it's perhaps less problematic (as moving the mouse and activating something is mostly distinct), but one scenario that can cause issues would be controls that are close to each other (which may fail other proposed SC for activation size that we're proposing) - if a user presses the mouse button, but in doing so accidentally moves the mouse as well which results in the mouse pointer going to another control, this may also result in incorrect activation. So waiting explicitly for the "up" event here gives the user a chance to realise this accidental move of the mouse pointer has happened and to "bail out" by moving away from the erroneous control before releasing the mouse button.

For keyboard/keyboard-like interfaces, it's less of a problem (or not a problem at all) in the same sense, since moving/setting focus and activating are (usually?) distinct interactions/keystrokes.

[lseeman]

From the coga perspective we need the undo option (the others are less helpful)

Strong overlap with
\See issue #38 undo and #53 return

[patrickhlauke]

Agree there's conceptual overlap, but I wouldn't want to see pure reliance just on undo/return (i.e. "yes, users with tremors for instance are likely to accidentally activate the wrong things, but it's cool, they can always undo...")

I'd say this SC works well in combination with the COGA ones, as a complementary/failsafe set of requirements.

[DavidMacDonald]

From the coga perspective we need the undo option (the others are less helpful)

Activation is reversible;

Is the same as undo... agree with Patrick that the others are important.

[DavidMacDonald]

I'll add a paragraph to the understanding as per Detlev's recommendation.

Activation means that some user interaction via a pointer (e.g., a mouse click, a tap on the touch screen, or the contact of a stylus) triggers an action, which is usually the defined behaviour of a control. For example, the activation of a link means that the page referenced is called up, while the activation of a checkbox or switch means that its state will change from unchecked (off) to checked (on) or vice versa.

[DavidMacDonald]

There has been some concern over the use of the term "up-event", but I'm not sure how to make a more understandable, more generic term. Instead of

• Activation is on the up-event, either explicitly or implicitly as a platform's generic activation/click event;
  WE COULD SAY
• Activation happens as the user removes pressure from the activation surface rather than when they touch it.
  OR
• Activation happens as the user releases the interactive control rather than when they select it.

[kwahlbin]

For up event is defined in the glossary. No matter what term is used, we will need to have a definition and up event seems to be a good enough term for now.
Up-Event: The activation of a component when the trigger stimulus is released. On different platforms the "up-event" may be called different things, such as "touchend" or "mouseup".
Example: For touchscreen interaction, the event is triggered when a finger is lifted from the touchscreen at the end of a tap.

[awkawk]

Merged into editor's draft, so closing issue.

[DavidMacDonald]

We'll need to scope out
press and hold
activation.
i.e.,
Click on scroll bar moves down on screen, hold activates continual scroll
So in that case the activation should not be on up event, but rather on the hold event.

Perhaps the understanding is the place for this distinction, or in the definition of up event.

[patrickhlauke]

See also #330