Buttons have more than an enabled and disabled state. They also have a loading state. The loading state isn’t usually shown to users because most actions happen within seconds. But for operations that take longer than usual to occur, not showing the loading state leads to action errors.
Action Errors
If the action takes longer than expected to finish, users need to know that the system is processing their request. If they see nothing happening, they’ll think they didn’t press the button correctly. This belief will cause them to press the button again.
When users press a button more than once, it not only increases the system’s processing load, but it duplicates the operation. Depending on the context, this can lead to significant errors that not only frustrate users but you as well.
For example, users could accidentally send repetitive messages, submit forms multiple times, or order the same product twice. These action errors create extra data that you have to manage and clean up. And sometimes cleaning up that data can cost you time and money.
Progress Buttons
To prevent these errors, you need to use progress buttons on operations that take longer than two seconds. A research study found that users expect pages to load in two seconds or less, and become impatient when it takes longer.
A progress button gives users a visual cue that indicates a loading state. When users see a process taking place, they’re less likely to press the button again. It’s crucial to ensure no action errors occur by disabling the button when it’s in progress.
You can display the button’s loading state outside of the button, but this isn’t ideal. Users already have their eyes on the button when they press it. By placing it on the button, it’s in line with their visual field. A progress indicator in another area means users have to look for it and might miss it.
Progress buttons should be simple to implement and have a consistent style. This way, users can better recognize the loading state, and the buttons won’t conflict other screen elements. The progress indicator shouldn’t increase the button size or dimensions. Nor should it require the button to have a unique background color. Instead, use a transparent background to signify a disabled state and a high contrast color for the indicator.
The progress indicator shouldn’t hide the button label, so users always know what’s in progress. Accomplishing this is difficult when you don’t have enough space to fit both the indicator and label together. What you can do is use a linear progress indicator instead of a circular one. This approach displays the progress inside the button while keeping the button label visible. You can also show the progress on the top edge of your button if it has sharp corners.
To better inform users what’s in progress, you can also change the button label to describe what the system is doing. For example, changing the original label from “submit” to “submitting…” tells users what’s happening as they’re waiting. Keep in mind this approach may not work if your button isn’t wide enough to hold a longer label.
Follow the Two-Second Rule
The loading state isn’t what most designers consider when they design buttons. But when your actions take longer than two seconds to complete, it’s essential to show users the loading state. Progress buttons are the control for doing this. Make use of them so users won’t commit action errors that cause you trouble.
Book
Affiliate
I love this UI pattern, but where I work handicap accessibility has become a huge focus and now underpins everything we design online. Do you have any information on how well this type of loading-state button conforms to WCAG accessibility guidelines (or how we can ensure that it does)?
I’ve worked in a big eGov project and things like this wouldn’t impact accessibility, be careful by following blindly the WCAG rules, they sometimes do not work or are outdated and some stakeholders don’t distinguish guidelines from rules, and these are definitely guidelines.
As an example, we had a key stakeholder that was blind and in some cases we weren’t meeting the standards but the interesting part was that he could actually “see” everything we created, just takes proper web dev. and careful testing and applying some common sense.
Hope it helps
My answer to this comes a bit late but perhaps will still be useful for someone.
For this pattern I would interpret the accessibility guidelines in the following way:
– since according to WCAG inactive elements of user interface have no contrast requirement the button bit in disabled state can have lower contrast than 4.5:1 (AA), I would however make sure that the label is still visible, I usually aim at 2-3:1 contrast for inactive elements;
– spinner/ loading animation in this pattern would be the active element and main focus, so it’s important to make sure that there is enough contrast between the colour of the button and the loading animation placed on it.
Other than that I don’t see any accessibility issues related to that as long as the button has the standard setup (clear focus state, correct touch target etc.).
WCAG guidelines can be very helpful in understanding how people with various needs and limitations use internet and I wouldn’t say myself they are outdated. It’s just important to not get discouraged by the amount of legal text the guidelines contain and to look for additional information when needed, internet is full of accessibility forums busy with the interpretations of the guidelines. Commons sense can definitely help a lot when designing for high accessibility but when hard numbers are involved things get pretty straight-forward. Interface that containing elements that don’t meet contrast requirements or touch target requirements can’t be called ‘accessible’.
How do you propose, in your “UX” magnificence as clearly you’d have considered this… this works with JavaScript disabled?
Unless you’re doing server-side rendering, you’d likely not need this if JS is disabled, as it’d be rare for an action to take longer than 2 seconds
I love all of your articles, thanks for sharing the advice! To level up your UX writing, I would recommend learning more about accessibility – just the topics of Color Contrast and Color Independence would be good to start with. Then when you write about specific UI elements you can ensure you’re giving design advice that’s optimal for accessibility. After all, accessibility is “usability for all”. An accessible interface is a usable one, and vice versa.
As designers, it’s our responsibility to design accessible interfaces. No one else will do it for us. We have to. Like usability best practices, we have to bake in accessibility best practices as we go, not try and shoehorn it at the end.
In order to make this suggestion more actionable and helpful, I will give some examples.
In general, here are 2 examples of how accessibility considerations can be added to design advice:
– Regarding Color Contrast: Disabled buttons are quite debated right now and for good reason, they do not have adequate color contrast to be seen by everyone, only by people with eagle eyes. Meaning, they discriminate against people who do not have great vision. The advice is to avoid using them. For that reason, do not gray out the loading state of the button. The icon itself is a completely adequate signifier. Adding the semi-transparent disabled look is not needed. It just means the button’s loading state has now acquired all the discriminating problems a disabled button has.
– Regarding Color Independence: The guideline is that color should not be used as the only visual means of conveying meaning. For example, don’t rely on red to communicate a button is going to do something nuclear. Instead, use an icon (plus red). So the signifier that is carrying the weight of visually communicating “this button is destructive” is the icon. And then, the red is just an added secondary visual cue (that benefits people who do not have color deficiencies or impairment in their vision). A great way to quickly test if something you designed is color-dependent (opposite of color independent) is to turn the mockup grayscale and see if any meaning is lost.
I hope this is helpful, thanks so much for writing these articles, I appreciate them very much!
To your success,
Liz
Hi,
Please update your screenshots. The disabled button text does not have sufficient and may give designers the wrong idea!
Thanks!