Improvements to the styling, grouping, etc. of the Layout Builder UI actions form

When switching away from Local Tasks, the "Revert to Defaults" link should be conditionally displayed.

Hmm, I disagree that the main "Layout" link should be placed somewhere else. I think it's more confusing to not have it near the other page tasks, despite the fact that clicking the link doesn't bring users to a different page.

I think the real UX issue is the supplementary links for saving changes and canceling changes.

For what it's worth, our team had a similar UX discussion for our precursor to Layout Builder; a first iteration had placed the "Layout" button in the admin toolbar, much like how the experimental block_place module approached it.

Ultimately, our UX person led us to agree that the local tasks was the most intuitive placement, despite its divergent behavior from "Edit" or "Revisions":

We shouldn't be abusing the local task links for these actions (save, cancel, and revert to default). The primary and secondary tabs are a navigation landmark region, and these actions don't amount to navigation:

• HTML nav element - "The nav element represents a section of a page that links to other pages or to parts within the page". (Emphasis mine).
• ARIA navigation role - A collection of navigational elements (usually links) for navigating the document or related documents.

The visual arrangement shown in #8 is fine, but semantically it isn't navigation. Instead, a custom landmark region like <div role="region" aria-label="Layout builder tools"> will suffice. The ARIA region role is for "a perceivable section containing content that is relevant to a specific, author-specified purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page" (emphasis mine, again).

Expanding on #11...

To be clear, I think we MUST correct the semantic misuse of the navigation landmark role (by moving the actions out of the secondary tabs) for accessibility. The fact that the tabs are identified as a navigation landmark region creates an expectation for what kind of content will be found there. A screen reader user may well overlook navigation landmark regions when they are trying to find the "save" button (i.e. they can be "easily missed" as the issue title says).

Based on the accessibility review above, I think this probably qualifies as a major bug.

I want to expand on why I'm proposing a custom region called "layout builder tools" in #11. It's because this can go beyond "where to the save and cancel buttons live?" to include some other tools like these:

• Toggle the visual preview of block content on/off. Discussed in #2959493: Allow Layout Builder live previews to be toggled to allow easier drag-and-drop.
• Toggle the inline display of block administrative labels. Also mentioned in #2959493: Allow Layout Builder live previews to be toggled to allow easier drag-and-drop.
• Toggle the visual display of section + region names. See #3007978-15: Accessibility Plan for Layout Builder.
• Others, e.g. from future contrib modules.

Collectively the save/cancel buttons, together with toggles like these, amount to an application toolbar for the layout builder. A custom landmark role="region" is appropriate for this.

I made some pen-and-paper mockups of the custom landmark region I described in #11. (Sorry about the messy handwriting.)

The first version has the existing 3 buttons, and also some checkboxes to represent some of the options from #16, to customize the information being displayed.

The second version hides the checkboxes inside a "more options" collapsible region, because we don't know quite how many we are dealing with yet.

This allows more space to arrange the display customization options. Here I've shown radio and checkbox controls to toggle the block content, and admin labels for blocks and regions.

I have some mockups of the rest of the UI to show the effect of these options. I'll add those to the related issues.

Not much to add, but chiming in to say those mockups look great to me and is how I envisioned this would look as well.

To clarify, these actions are currently links. But due to purely architectural issues, they will likely be changing to buttons.
This doesn't seem to conflict with #17, but just wanted to call that out.

Task Bar Option A1-A2

• Task bar sits at top of content box
• Box auto expands when additional tabs (features, plug-ins) are added
• Save and Cancel button placement at right
• Can see all tabs but could get too long if high number of plug-ins, etc

Task Bar Option B1-B2

• Task bar again sits at top of content box
• Tabs and bar are more compressed
• Chevron expands the bar to reveal additional tabs (features, plug-ins)
• Save and Cancel button placement at right like pattern

Task Bar Option C1-C2

• Task bar moved up to sit below the page nav bar
• Tabs and bar are again more compressed
• Save and Cancel start at left
• Basic tab functions after the divide
• Chevron expands the bar to reveal additional tabs

Following on from #19, I wonder if it's worth postponing this for now until #3004536: Move the Layout Builder UI into an entity form for better integration with other content authoring modules and core features is fully implement or at least RTBC, so that we know what form the UI will take going forward, as that linked issue could directly impact this one.

Agreed

These actions have stopped being links and are now buttons

#19: Yes, these would be better as buttons.

#23:

These actions have stopped being links and are now buttons

"Save layout" is now a button, but "discard changes" and "revert changes" are still links. Filed #3037113: Replace layout builder discard-changes + revert-to-default links with buttons to address that.

Fixing tag.
Also, this needs an issue summary update. Is there still a change needed here?

yes, todo:

1. Build the place where the UI toggle options live.
2. The role=region custom landmark is still desirable. The must-fix misuse of the secondary tabs landmark has been addressed (#11-12) but the landmark region is still desirable to find these buttons. Now that the save button is the first submit in a <form>, it would be normally be a candidate for implicit form submission. However, there aren't actually any of the elements that would normally trigger that; the "form" is really just a collection of actions, without any checkboxes, text fields, etc. So assistive tech users may still have trouble finding this region, and making it a landmark role=region would help.

#5

When switching away from Local Tasks, the "Revert to Defaults" link should be conditionally displayed.

This is something we can do now.

Alright, I chatted with @andrewmacpherson about this issue, and there are two remaining parts to solve:

1. #3040645: Add a role=region wrapper to the Layout Builder action form to fix screen reader navigation barriers is the most important part, because this directly affects the navigability of the UI in screen readers.
2. Then, there's remaining improvements we should make to the styling and grouping of the elements (the remaining scope of this issue). I'm retitling/recategorizing as a major task to reflect that, and also I think we should postpone this until we've stabilized the module (so that we can build on top of the completed MVP user experience) and probably also completed at least #3040645: Add a role=region wrapper to the Layout Builder action form to fix screen reader navigation barriers.

We'll still want to update the issue summary here to reflect the current state of things, since the original issue was filed while these were still the highly confusing local tasks.

Thanks!

I'm working with layout builder for the first time on a project and was wondering if there has been any usability findings from "simple editors" which are using Layout builder?

Because my main issue (and I found this issue to be the one touching this) is that there are now 2 tabs: Edit and Layout which basically *both* cover content editing. As a dev or site builder, I understand why this distinction exists, but as somebody who just want to edit content this must be confusing having 2 different screens for basically the same content.

So just wondering if this issue is the best place for that or if this discussion already took place (probably) somewhere else.

edit: found #3121372: Use layout builder for content add/edit form

Tagging for https://www.w3.org/WAI/WCAG21/Understanding/name-role-value

The issues this was originally postponed on have long been resolved