Site Editor: Confusing back button behaviour when using command palette

[noisysocks]

In an effort to address #50676 I opened #52456 which makes the back button in the Site Editor go back when possible instead of up.

There's still some confusing flows, however.

• Open the site editor
• Navigate a bit between pages, templates, ...
• Land on a random template in edit mode
• Open the command center and navigate to a random page "Sample page" for instance
• Click the "view mode" and click "back".

Instead of going to the "pages" sidebar, you go to the previous template that was opened. That feels wrong to me, If I wanted that I would have clicked the "previous" button of the browser why duplicate this one in the UI.

Originally posted by @youknowriad in #52456 (comment)

[noisysocks]

@jameskoster @SaxonF: What should happen here? Should navigating using the command palette reset the history?

It feels to me like we'll constantly be playing whack-a-mole with similarly confusing flows that arise from having a back button that does something different depending on context. I wonder if we can come up with a design that eliminates the need for a back button altogether. Not sure. We'll likely need to get this airtight in the context of https://make.wordpress.org/core/2023/07/12/admin-design/.

[jameskoster]

Should navigating using the command palette reset the history?

That seems reasonable to me.

But I feel the whack-a-mole situation. I don't know how this might have come about, but upon logging into my local this morning after the weekend I found myself stuck in a loop:

drilldown.mp4

I agree that we should spend some more time on the design to get this right. Adjusting the behavior of the button is only one way to eliminate the confusion, but there are others to explore such as:

• Marking cross-section shortcuts more significantly in the experience so that folks understand they've shifted context
• Different design patterns:
  • Breadcrumbs
  • A situational 'back to source' link like the one in iOS:

[youknowriad]

Should navigating using the command palette reset the history?

For me, we're treating the symptom rather than treating the root cause. Every time a shortcut will be added to the UI (command palette is just one of them), this problem is going to surface.

The real problem is that the "back" button in the sidebar is equivalent to "navigate to parent" instead of "navigate to previous" and as long as the code says "goBack", we're going to have edge cases. The only valid solution is "goToParent" and since a page can't have two parents, we need to deambiguate between these two pages: in other words consider "page1" that was opened from "pages" different than "page1" than was opened from "templates" (have different parents for these, different urls...)

[afercia]

The only valid solution is "goToParent"

I'd agree this would probably be the most expected behavior. But then, the navigator screens must not contain items that belong to other parents. for example, the Pages screen contains 'pseudo-pages' that actually are templates. Going back from them will bring users to Templates instead of where they were (Pages) which is totally disorienting.

[youknowriad]

#52761 this issue is another symptom of the "goBack" behavior. I think we should restore "goToParent" for 6.3. We can solve the landing on wrong parent by "deduplicating these children" or something else but it feels bad to allow users to end up in "empty state" like #52761

[jameskoster]

I'm conflicted on this one. I agree that the edge cases that are cropping up on trunk are annoying. But so are the original issues.

I suppose it's too late now, but if we do restore the previous behavior, would it be feasible to include a label on the button:

This would give users some prior understanding about where clicking the back button will take them.

It would also solve a minor issue we have with the current format, where the panel heading and the chevron can easily be mistaken for a single element. For example < Home could be interpreted as a link to "Home" rather than the parent of home.

cc @SaxonF @richtabor as we were talking about this a bit earlier.

[afercia]

@jameskoster from an a11y perspective, I'd totally support visible text for the Back button. I'd even expand the label, instead of just:

< Templates

I'd suggest:

< Back to Templates

I do realize that designers would love to keep the UI as light as possible and reduce visual clutter. But when an UI is confusing (and this one proved to be), I think that the best option is visible text that fully explains what the control action is.

It would also solve a minor issue we have with the current format, where the panel heading and the chevron can easily be mistaken for a single element.

That's another very good point 👍

[richtabor]

#52761 this issue is another symptom of the "goBack" behavior. I think we should restore "goToParent" for 6.3.

I think so too. I've been stuck in loops trying to figure out how to get back to the top-level navigation whenever I use the command center to navigate.

The back control should consistently go up the tree, not back to a previous state.

This would give users some prior understanding about where clicking the back button will take them.

I like the idea of using the previous title as a label, but I don't think that should be a blocker for this fix (but if we can squeeze it in, awesome).

The expectation is that you go back up the tree. The difficult part is when you can get to a view from different entry points (as pointed out initially) — like viewing a page from Navigation, vs. viewing a page from Pages.

I do realize that designers would love to keep the UI as light as possible and reduce visual clutter. But when an UI is confusing (and this one proved to be),

I think a chevron icon pointing the direction you came from, along with the title of the previous view, is enough of a hint to help you understand where you're going. It's pretty much standard practice.

[afercia]

I think a chevron icon pointing the direction you came from, along with the title of the previous view, is enough of a hint to help you understand where you're going. It's pretty much standard practice.

From an a11y perspective no it isn't ideal:

• icons do do not have universal meaning. As such they can only be used as an aid but we should not rely on them.
• The accessible name of an UI control must clearly communicate what it does. The action here is 'Go back' to somewhere else so the 'go back' part shoul dbe part of the accessible name. The < Templates pattern uses visible text only for the destination while it hides the actual action, which is the most important part.
• we could provide an aria-label to expand the control name but that would only help screen reader users. Ideally, the visible text should match the accessible name.

Aside: there's some inconsistency across the editor regarding the left chevron icon and 'back' text, where:

• sometimes there is only the chevron icon
• sometimes there is the chevron icon plus a 'Back' text
• sometimes there is the chevron icon plus a 'Go back' text

I think I provided some example screenshots of these inconsistencies in another issue but I can't find it any longer.

[richtabor]

Aside: there's some inconsistency across the editor regarding the left chevron icon and 'back' text, where:

I think the title should be used consistently; that way you know where you're navigating to.

From an a11y perspective no it isn't ideal

Prepending "Back to" is superfluous — more UI doesn't mean less confusion; usually the opposite. It would be instantly less scannable/understandable, especially for languages where the character count is much higher per word. Sure, we could add it to the aria-label and tooltip (there's already a tooltip indicating the title).

Do you presume that every link/control/action on a page/site should have "Go to" or "Back to" prepended visually? Trying to understand from your view. 🖤

Resources:
https://developer.apple.com/design/human-interface-guidelines/navigation-bars
https://m3.material.io/components/top-app-bar/overview

[afercia]

Do you presume that every link/control/action on a page/site should have "Go to" or "Back to" prepended visually? Trying to understand from your view. 🖤

It really depends on the labeling of the control and the assistive technology in use. Often, expanding the accessible name of a control by the means of visually hidden text or aria-label etc. does help screen reader users but impacts other users e.g. speech recognition software users.

Ideally, the visible text should match the accessible name. There are exceptions of course byt in general the best option is always visible text and nothing else.

For example:

The pattern with only the chevron icon <;

• Visible text: <
• Let's say we implement the actual labeling with an aria-label Go back.
• As a blind screen reader users that would be ok: the screen reader announces Go back so that I'm able to understand what that button does.
• As a speech recognition software user, I don't know what the accessible name of the button is. I see only a chevron icon. I would be forced to try to guess what the actual name is to be able to issue the right voice command. I'm a lucky guy so I succeed at the first attempt by issuing the voice command Click back. From that moment on, I would expect all chevron icon button to use the same name Back. Instead, given the large inconsistency of these buttons labeling e.g.:
  • Back
  • Go back
  • Go to the Dashboard
  • Navigate to the previous view (this is the left chevron icon button in the Styles sidebar)
• basically I woudl never know for sure what the chevron icon button name is so that using the proper voice command would be very challenging. Of course, if we always used visible text, this would not be a problem.
• As a user with vision impairments, I may not be able to see the chevron icon. Instead, visible text is better and I can use the browser or operating built-in tools to enlarge the text, magnify the screen, increase the contrast, etc.
• Icons don't have an universal meaning. In some cultures the left chevron icon may have a completely different meaning.
• Cognitive impairments: decrypting the meaning of an icon may be challenging for some users. visible text is always better.

Some of these considerations also apply to other patterns e,g, the one with the chevron icon and text < Templates;

• Visible text: < Templates
• If we try to clarify what the button does with an aria-label, for example Back to Templates, then there would be a mismatch between the visible text and the actual accessible name.
• While blind screen reader users would hear a meaningful name Back to Templates, speech recognition software users would be totally tricked by the mismatch.
• Worth mentioning not all screen reader users are 100% blind. Some have vision impairments and use a screen reader as an aid. The mismatch would be confusing for these users as well.

The pattern < Back to Templates

• By using fully visible text for the button action and context, ther would be no need for further clarification.
• There would be no mismatch between visible text and accessible name.
• The icon would still provide some visual affordance.
• The visible text would be clear and simple, accessible to everyone.

@richtabor thank you for the links you provided. Interesting reading.

The Apple docs:
Seem to me those recommendations mostly apply to mobile, operating systems, and 'app or games'. In fact, there is a specific page dedicated to 'Web Views' where HTML content is mentioned. Mobile, OSes, app/games, are a totally different matter. I do realize designers mostly think visually. Accessibility specialists mostly think in terms of content structure and semantics. We need to put together the best of the two worlds :)
It is clear the documentation you linked mostly applies to mobile and app/games by the terminology they use. For example when they mention by using a familiar gesture, like tapping or swiping down. That is not our case.
Anyways, the most interesting thing I read on that page is actually about the Back button:

If you implement a custom back button, make sure it still looks like a back button, behaves as people expect, matches the rest of your interface, and is consistently implemented throughout your app or game

I'd be happy to see such a consistent Back button in use in the editor but, alas, we're not there yet.

One more interesting thing I read there is the strong recommendation to always use a clear, visible title for any screen. In the editor, we had to go through a lengthy discussion to introduce a main H1 heading in the post/site editor. The current implementation has still lot of room for improvements, to be fair. Many screens don't have a clear, visible title yet. When pointing to some authoritative documentation, I would appreciate to see all the recommended points to be taken into consideration, not only the ones that in a specific moment may backup a specific argumentation. ❤️ I would greatly appreciate to see more design work about the titles of the various editor screens.

The Material documentation:
I'm afraid I'm not going to even read those docs as Material is mainly a series of design patterns for mobile which proved to not be the best source of inspiration for accessible patterns. In the history of the Gutenberg project it already occurred to discuss together some patterns from Material. As accessibility specialists, we always pointed out Material should not be fully trusted in a project that aims to be accessible for everyone. I'd recommend some documentation related to Universal Design instead.

Lastly, I'd like to point out that for all the ones that use macOS, may assistive technologies are built-in and cane be used and tested with little effort. For example, I'd recommend to try Voice Control and use the Editor by issuing voice commands. I'm not saying all designers and developers must be Voice Control super expert but at the very least they should have a basic idea of how it works. I'm pretty sure that trying to use the Editor with Voice Control would be an enlightening experience.

[richtabor]

Thanks for the details.

While blind screen reader users would hear a meaningful name Back to Templates, speech recognition software users would be totally tricked by the mismatch.
Worth mentioning not all screen reader users are 100% blind. Some have vision impairments and use a screen reader as an aid. The mismatch would be confusing for these users as well.

Could you elaborate on the "trick" or "confusion" introduced here?

In fact, there is a specific page dedicated to 'Web Views' where HTML content is mentioned.

Do you have examples of where "< Back to ____" is a common pattern used on web-based applications?

We need to put together the best of the two worlds :)

Agreed, 100%. 🖤

When pointing to some authoritative documentation, I would appreciate to see all the recommended points to be taken into consideration, not only the ones that in a specific moment may backup a specific argumentation.

There's not going to be one document that details exactly how we need to build these experiences. We all pull from multiple sources, and personal experiences, with a goal of building delightful and accessible experiences across WordPress. That's what makes WordPress what it is today.

I'm giving examples with detailed insights on why a specific implementation has been used (extensively). Although Material and iOS are mobile-first, if there's an experience we use every day on our mobile devices, why would we expect the same experience to look and perform differently via the web?

If you implement a custom back button, make sure it still looks like a back button, behaves as people expect, matches the rest of your interface, and is consistently implemented throughout your app or game
I'd be happy to see such a consistent Back button
From that moment on, I would expect all chevron icon button to use the same name Back. Instead, given the large inconsistency of these buttons labeling

100%. We need to keep pushing for consistency.

[afercia]

Could you elaborate on the "trick" or "confusion" introduced here?

The mismatch between visible text of a control and its actual accessible name would be maybe cleaer after trying at least once a speech recognition software. As designers and developers in a project that aims to be accessible, we all need to have at least a basic understanding of all devices and technology users may use.
I can point you to the related WCAG Success Criterion 2.5.3 Label in Name, I'd suggest to skip the technical jargon of the spec and follow the link 'Understanding'.

Do you have examples of where "< Back to ____" is a common pattern used on web-based applications?

I don't :) I'm trying to save both worlds. If it was up to me, I would use only text. If design prefers an icon, why not use both? It's also important to realize that many of the design patterns we see around are not accessible. I'm not sure looking for common patterns in use is always a good thing. Maybe a better approach would be looking at what is in use and adapt to this project specific accessibility needs.

[richtabor]

I'm not sure looking for common patterns in use is always a good thing. Maybe a better approach would be looking at what is in use and adapt to this project specific accessibility needs.

The trouble I have with that notion is that we're assuming there are no accessible cases of a web-based application using a "back" button of any sort. Nine times out of ten, we're not reinventing the wheel—perhaps making it much more better—but not starting with a completely blank slate.

If it was up to me, I would use only text. If design prefers an icon, why not use both?

I want to use both as well. I want this to be usable for everyone.

I do think we're hitting the subjective level of design and accessibility, where a gray area does exist between the two.

Even the Label in Name understanding doc mentions "Where practical, make the control’s text label and name match". "Practical" leaves quite a bit of room for interpretation.

From my point of view, adding "< Back to templates" fully visible is much less practical than "< Templates", as it makes the UI harder to scan/comprehend holistically as you're sifting through what's rendered — especially for languages where "Back to" is any more than six characters. That's my hesitation.

It's not about reducing visuals/minimizing the interface, but rather pushing for an experience that falls within that gray area; meets in the middle of design and accessibility.

I think we're detracting from the overall goal of this issue though; to adapt the back button behavior. The UI tweaks would be a follow-up of this issue. But I do appreciate the conversation. 🙂