Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
No Accidental Activation #65
Current versions of SC and Definitions
Definition of Single Pointer Activation not in FPWD - filed bug #168
No Accidental Activation
For single pointer activation, at least one of the following is true:
Suggestion for Priority Level (A/AA/AAA)
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".
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
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:
Examples of where timing of the activation is essential would be:
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.
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;
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;
Timing of activation is essential and waiting for the up-event would invalidate the activity.
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: 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).
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.)
@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.
This was Q3 on @DavidMacDonald 's Acceptance Criteria
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...
Just for my edification, are you differentiating between selection and activation, and does it need to be explained?
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.
@mbgower Regarding your Touchtyping with VoiceOver Example:
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 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).
@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
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.
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"
@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:
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.
@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?
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.
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.
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.
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
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.
This was referenced
Feb 9, 2017
referenced this issue
Mar 22, 2017
referenced this issue
Mar 31, 2017
We'll need to scope out
Perhaps the understanding is the place for this distinction, or in the definition of up event.