Tl;dr: We should treat the browser like an execution environment and not consider the browser's elements to be a part of our web application. Provide an explicit way to "close" the form and exit that sub-journey. It offers two major benefits over implicitly expecting them to back-navigate:
- The action is predictable and controllable -- we can explicitly set the navigation target and ensure we know where the user will end up.
- We don't require the user to step up out of the web page / web app's context to use the browser's context, which in any case doesn't offer a predictable experience with respect to navigating in forms.
To expand on that...
A few of my clients over the years have been larger organizations with employees ranging from Digital Natives to the Silent Generation, if you'll allow the Western demographics. Across the whole spectrum, something I've seen time and again is that a web browser is many different things to many different people. Having such a broad array of people has lent a few helpful lessons.
Relevant to this question, some folks are unaware of the difference between new tabs opening and in-tab page navigation. When a web application mixes navigation methods, by using in-page modals, in-tab navigation and new tab navigation for various activities, some users will quickly lose their current context and make unpredictable choices when trying to get back to where they previously had been.
Context is key.
If I open a new tab, the user has to remember
- what they were doing in the first tab
- where the first tab is in their tab bar
- what they're doing in the new tab
- that they need to close the new tab to get back to the first
It's a lot to remember and a lot of users simply don't have the same sort of fundamental understanding of what a browser is and how it works. This leads to thinking they can browse back when they need to close tabs, or close tabs when they need to browse back, or refreshing and resetting/changing session context or parameters that might not be stored in cookies, browser data or URL arguments.
When interacting with forms in web apps, clicking the back button in the browser may
- Take the user back an action in the form
- Take the user back a page in the form
- Take them all the way back to the previous context they were in
There isn't a common pattern universal to browser navigation in web application forms, which means we can't predict what the user will assume or attempt to do.
(To note, someone referenced a Nielsen-Norman Group article on cancel buttons and back navigation in the browser. It was excellent guidance in 2000, but it was written at a point in web history where sites and web apps were both significantly simpler and less, well, "application-y".)
Since we can't predict what a user is going to do or expect from the browser, we need to offer a method that we can control. The cancel action allows us to explicitly set a navigation target and guide the user back to where they expect to be.