Pointer Cancellation: Real-World Examples

 While reading through the Operable Principles, I admit that I was confused about the success criteria around pointer cancellation.

The success criteria states, 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 to 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
Some of my initial questions when reading this are:
  • It mentions functionality using a single pointer, but what are the other options? Is there a double pointer?
  • Do they mean that when they release the down-click the user is prompted to abort the action or undo? 
  • Are they holding down a mouse button reading something that gives them the option to undo what they are in the middle of doing?
  • How often does this apply to all basic buttons for forms and navigation?
  • What situation would reversing an action on release of a button possibly relate to?
Some clear things were:
  • Not allowing an action to be completed UNTIL the user released the mouse click on a button makes sense because, in my mind, the action isn't complete until you've released the button.
  • Being able to undo something easily makes sense especially for situations where it was too easy to complete the task, or too hard to correct it after the fact manually.
To better understand these success criteria, I did some more reading and research to put them into the context of real-world examples of interactions.

No Down Event: Reduce accidental form submissions

I'm on a web page and I'm filling out my billing address to purchase a book. I've filled out all the fields and my credit card information is accurate. As I hit the "submit order" button, I look up at my order and realize I entered a shipping address that I don't currently live at. I haven't released the submit button yet, and because the action is only complete after I release it, I can hold down on the mouse button and move the cursor off the form button before releasing. This allows me to cancel my button press and allows me to change my shipping address.

This way of "canceling" a pressed action also applies to links as well as buttons and is relevant to touch screen interactions as well as mouse-driven ones. This does NOT apply to keyboard navigation functionality when interacting with buttons or links (at least not that I've been able to test).

Abort or Undo: Easily correct a mistake after completion

I've just spent the last hour writing a company-wide email with sensitive information in it and wanted to send it to my manager first for proof-reading. As I go to hit send, I noticed all-too-late that the recipient wasn't my manager Morgan B., but Morgan C. from another department. While the "send" button in the email client included the action on the up-event, I didn't notice until I had released the button. Luckily for me, it also has a toast notification confirming the email was sent, with an "undo" link that's relevant for the next 30 seconds.


Confluence has this same functionality available when a page is moved by dragging and dropping to a new location. Because the drag and drop motions are so tricky and not very accurate at all, you don't know if you're successful until you release the mouse button and get the confirmation. It's then that you have the option to undo the move and try again if necessary.

I think this specific option is incredibly useful/necessary for anything that requires drag and drop functionality for this exact reason.

Up Reversal: Pausing a video before resuming

On Instagram, I'm looking at my feed of stories from people I follow, and one person has included a wall of text on a slide that I won't be able to read in the allotted time before transitioning to the next slide. I can press and hold the screen until I'm done reading. The press is the pause action and the release is the resume.

The specific example given for this success criteria is foreign to me. It states, "press-and-hold actions such as where a transient popup appears (or a video plays) when the user presses on an object (down-event), but the popup (or video) disappears as soon as the user releases the pointer (up-event)."

Personally, I can't think of ever experiencing a transient popup video disappearing after I released a press from it. This may be referencing some kind of preview functionality if there's a static image for video libraries that you can preview a short clip of the video with a hold and press instead of a typical up event.

This particularly relates to touch screen interactions more so than desktop/mouse driven interactions. 

Essential: The down event needs to be the action for it to work properly

The game I'm playing on my smartphone emulates a real piano and the down event of each press is what triggers the sound to play for as long and as hard as the press of my finger is registering.

Or, I'm playing a game in which I need to press a button to shoot a water balloon at a unicorn, and for the game to not lag significantly enough to affect my shooting accuracy, the action is triggered on the down event. 

Summary

For the most part, all clickable actions on standard websites (like form buttons and navigation links) would require the action to only take place on the up event.

For more consequential actions like sending emails, financial/billing related functionality, or anything that would cause a significant issue if sent with errors; the use of a way to undo within the UI is incredibly helpful. This may also help reduce support and bug fix issues within an organization, depending on the type of user and method of fixing mistakes like that exist.

The other options seem much more specific to unique interactions such as interactive media, or robust electronic information. 

Popular posts from this blog

Practice Site: Keyboard Accessible Tooltip Fail

Image
While reading about keyboard input methods and learning about the success criteria requiring custom keyboard instructions for any custom key commands, one method of accomplishing this was using a tool tip to present the instructions. It mentioned that the tooltip would have to be accessible via keyboard navigation and be able to be read by a screen reader. That reminded me that on my practice site, I spent a significant amount of time creating an example of success criteria for 3.1.3 to provide a definition of an unusual word when the user hovers over the text "affordance" displaying in a tooltip. I did not, however, make this accessible to keyboard-only users or screen readers. Turns out it wasn't even focusable until I gave it a tab index. More investigation into ARIA Practices for 3.24 Tooltip Widget call out specifically that the tooltip container requires role="tooltip" (which I did not have), and the element triggering the tooltip references the tooltip ...
Read more

Boiling the Ocean of Accessibility

Image
It can be daunting to look at an entire platform and be told, "Ok, now make it accessible." You don't need revolutionary planning, or exhaustive sprints to start. Including some accessibility work into regular sprint planning can offset any extra LOE, and you can start adding accessibility requirements right into each ticket. In a blog post for MediSked that I wrote in 2021, " Modular Accessibility for All Users ", I outline some easy ways to incorporate real accessibility into the SDLC, and start making progress to a completely accessible product as a whole. Some of the basics include: Using a third-party library of components that have accessibility built in. (Like Kendo UI for VUE or Deque Code Library )You'll still need to adjust and apply them right, but it will get you most of the way there. Include it in every ticket. Link to specific areas that apply to that ticket so engineers and testers know what to focus on. You can link right to the Deque chec...
Read more

Practice Site: Accessible Forms

Image
Today I finally bit the bullet and focused on creating a page on the practice site that would allow me to practice with form components, and live events based on actions. I have the basics down thanks to a friend of mine who walked me through the tools and resources that would be best for this very specific scenario and wrote the skeleton of the page that I could edit to make more accessible. She recommended using JQuery and JavaScript to avoid requiring a database or AJAX. Thanks to w3school.com for their amazing resources. My goal is to make the form fields clear on each submit, and post the data in a styled way on the page. I'd also like to make each submit speak a "success" message to alert the user of the new content, and of course, add labels to everything. Since this took the entire day, it will have to do for now. Luckily there are built-in focus states for the input and button elements by default. This was a productive day, but I may need to take a walk after ...
Read more