Understanding Success Criterion 2.5.2 Pointer Cancellation - Codoid
Select Page
Accessibility Testing

Understanding Success Criterion 2.5.2 Pointer Cancellation

Understanding Success Criterion 2.5.2 Pointer Cancellation can be hard without the right examples. Read our blog to understand it clearly.

Understanding Success Criterion 2.5.2 Pointer Cancellation - Blog
Listen to this blog

Wrong clicks and incorrect touches can be annoying to any user. But what could be just annoying to regular users can have serious impacts when used by people with disabilities as such issues could render the product unusable. That is why WCAG introduced the Success Criterion 2.5.2 for Pointer Cancellation in WCAG 2.1. Understanding Success Criterion 2.5.2 Pointer Cancellation is very important as it has to be fulfilled to achieve Level A compliance. So in this blog, we will be exploring the different conditions that have to be satisfied and get to know the exceptions by using examples. But before that, let’s take a deeper look at why Pointer Cancellation is very important for people with disabilities.

UNDERSTANDING SUCCESS CRITERION 2.5.2 POINTER CANCELLATION

The 2.5.2 Pointer Cancellation success criterion belongs to the 2.5 guidelines of WCAG 2.1 that deals with input modalities for making it easier for people with disabilities to use more input methods other than the keyboard. Visually challenged people might use a braille keyboard and be unable to use a mouse or touch input devices. But people with other disabilities such as hearing loss or even color blindness will be able to use a mouse or provide touch inputs as well. But the primary focus of the 2.5.2 Pointer Cancellation success criterion is to help people with motor-based impairments and cognitive disabilities as they are prone to making more mistakes.

Pointer Cancellation can be compared to the undo button that is present in most applications. For example, if we accidentally delete all the selected text in Microsoft Word or Google Docs, we would just hit the undo button and fix the issue. But it is not that simple when it comes to using the web as people might be taking an important online test or making a purchase and so on. So WCAG has given 3 options for us to choose from as the 2.5.2 Pointer Cancellation success criteria will be satisfied even if one of the 3 conditions is met.

The 3 Conditions in 2.5.2 Pointer Cancellation

Before we move forward in our effort to understand the 2.5.2 Pointer Cancellation success criterion, we’ll have to know what Up and Down events are. If we were to take the mouse as an example, the down event is the process of pressing the button down, and the up event is the process of releasing the pressed button. The same applies to touch-enabled devices as well where touching a part of the screen is the down-event and releasing your hand is the up-event.

For example, let’s say there is a button to mute the audio output. You can observe in the illustration that the audio will not be muted when the button is pressed down (Down-Event) and that the functionality will be carried out when the button is released (Up-Event).

Comparing Down Event and Up Event - 2.5.2 Pointer Cancellation

No-Down-event

One of the best ways to achieve pointer cancellation is by ensuring that the function is not carried out with the down-event completion alone. So if you are holding the mouse button down, the action should be completed only when you let it go (When the up-event happens). By doing so, there will be an option to abort or even reverse the click when the up-event happens.

The Exception

But there are a few exceptions when it comes to the 2.5.2 Pointer Cancellation success criterion as not all functionalities can be developed in a way that prevents a no-down-event. Let’s take an example of a piano application where a key press or touch input will mimic the action of the keys of a piano getting pressed. Such a scenario can be an exception as there might be a need for two or more keys to be pressed simultaneously to produce a particular sound. In addition to that, the duration of the key press will also determine how long the sound will be actively produced.

 

Up-event abort or Undo

So if ensuring that the down press does not affect functionality until the key is released, the next step would be to define a target area around the click. By doing so, we can enable users to move out of the target area if they have clicked incorrectly and then perform the up-event to either abort the operation or undo it.

Example

The drag and drop feature is a very great example as there will be a target area from where the file is being dragged to where it is being dropped and if at all the user has dragged the wrong file, then they can just undo their action by dropping the item outside the target area. Even if it is not a drag-and-drop feature, the users must be able to just move away from the target area before performing the up-event to abort the down-event.

 

Up Reversal

This is also similar to the up-event abort or undo function we have seen thus far in terms of the 2.5.2 Pointer Cancellation success criterion. But it serves a different purpose instead of aborting or undoing an action. It can be used for functions that use press and hold actions. So it will only hold the effect of a down-event until the up-event is performed.

Example:

Activating or viewing a pop-up is a great example of a press-and-hold action. If a user clicks on a pop-up or a pop-up video the down-event will ensure that the pop-up stays open or active until the up-event is performed. It will revert back to the state it was in before the down-event.

A Quick Tip

Even if we follow such conditions, users are prone to make mistakes by performing both the down and up events quickly unaware that they have made a mistake. So if you are working on pages that don’t support the back button such as payment gateways, online examination submissions, and so on, it is always better to use a confirmation pop-up.

Example:

If we take an online examination itself as an example, the submit button shouldn’t work on a single click as an incorrect click might end the exam for the participants abruptly. So a pop-up that confirms if the user is ready to submit their answers and end the examination should be mandatory to ensure incorrect outcomes.

Conclusion

We hope you have clearly understood Success Criterion 2.5.2 Pointer Cancellation by now and will be able to implement your gained knowledge while testing a product. As one of the leading accessibility testing services providers in the industry, we are experts when it comes to testing in accordance with WCAG’s success criteria. We will continue to share more informative content and recommend you subscribe to our newsletter to keep yourself updated on software testing.

Comments(0)

Submit a Comment

Your email address will not be published.