Breakout block navigator into its own sidebar

[jwold]

Over the past week I've been playing with the block navigation tool a lot, and have found it very useful.

It's made the job of working with nested blocks a lot easier, especially with solving the problem of where to click on a nested block to select the parent or child.

One of the things that I keep coming back to though, is wanting to make the modal popup persistent.

Could we offer an option/toggle to make it pop out into its own left sidebar? Thinking something like:

[brandonpeat]

Love it! I posted something similar for the Inserter module in #11632. Having the option to make some of these small windows a persistent large sidebar would be so helpful to a lot of folks' workflows.

[afercia]

Considering there are proposal to change and extend the features of the Blocks navigation menu, see

• Deleting list items inside the Block Navigation Deleting list items inside the Block Navigation #10984
• Drag & drop reordering of blocks inside block navigation Reordering of blocks inside block navigation #11408
• Blocks Navigation menu: use links not buttons Blocks Navigation menu: use links not buttons #11711

I'd tend to agree with @jwold the UI probably needs some rethinking. There's a need for more space for additional UI controls. If it's going to be a sort of "Blocks overview" to navigate and manage blocks, then the current UI based on a "menu" isn't probably the best one.

However, I'm not sure a sidebar is the best option.

Worth considering to incorporate a good level of accessibility in any design proposal from the beginning. For many users (keyboard users, screen reader users, etc.) content navigation is a linearized experience. Designing a good information architecture since the beginning is key. I'd appreciate to see this applied also to the proposal in #11632.

Specifically about sidebars: The existing Settings sidebar already creates accessibility barriers because it hasn't been designed with accessibility in mind. Currently, jumping from the content area to the sidebar is very hard for users who don't use a pointing device. This is one of the main issues outlined in the accessibility team report. Gutenberg has implemented some tools to mitigate this problem but moving between the content area and the Settings sidebar is still very difficult. There is a proposed plan to improve keyboard navigation in #11581 but I'd recommend to explore other options instead of a new sidebar.

Trying to imagine a linearized content navigation experience:

• where this sidebar is placed in the DOM order?
• does its placement make sense in the overall document structure?
• does the visual order matches the DOM order?
• how it is possible to jump from other areas to this sidebar and vice-versa?
• what is the specific keyboard interaction workflow?
• is focus management necessary? If so, what the specifics are?
• lastly: what about the responsive view?

A couple references:

Content meaningful sequence
https://www.w3.org/TR/WCAG21/#meaningful-sequence

Focus order (visual order must match DOM order)
https://www.w3.org/TR/WCAG21/#focus-order

[jwold]

@afercia thanks for the great feedback. I'm thinking about possibilities. My takeaway right now:

• Explore ideas other than just having a sidebar. Maybe there’s another ways we could integrate a block navigator.
• A big problem with a sidebar is that navigating via keyboard from it to the content and back is problematic. What else could we do? Maybe the navigator inline…?
• Perhaps combine the work with Design Suggestion: Block Sidebar #11632

[brandonpeat]

Yeah, this is all good stuff! While I work with basic accessibility stuff for front-end users, I'm certainly not an expert when it comes to back-end CMS accessibility, so this is all educational for me.

To clarify, is the problem with sidebars that they are sidebars, period? Or just that they are toggle-able on/off via buttons in the Gutenberg header menu (thus breaking DOM order)? The classic editor, as well as other areas of Wordpress such as the Widgets page and the Menus page, incorporate sidebar layouts, so I'm pretty sure the problem is the former vs. the latter, but want to be sure I'm understanding the basis of the problem.

I'd be fine merging #11632 with this one, I think this is a good global conversation about how to improve the structure, functionality, and accessibility of the Gutenberg interface.

[afercia]

The Widgets page and the Menus page, together with Media and the Customizer, are among the most not accessible areas in WordPress 🙂

I'd recommend to read the accessibility report: https://make.wordpress.org/accessibility/2018/10/29/report-on-the-accessibility-status-of-gutenberg/. The root problem is in the sidebars themselves, if they contain actions that are contextual to the current workflow. It's pointless to put the blocks navigation menu in a sidebar if then users need to press Tab dozens of times to get to it and get back.

[brandonpeat]

@afercia Ha, oh no! Well, there's something to be said for consistency, I guess? :) I'll take a deeper dive on the accessibility report this week and see if any new thoughts come to mind. Thanks!

[jwold]

@afercia thank you for that! That gives some context on the bigger problem.

Are you aware of a website/app that does this relatively well, providing contextual actions for the workflow appropriately? Would love to study ways to make this work better.

[afercia]

Are you aware of a website/app that does this relatively well, providing contextual actions for the workflow appropriately?

TinyMCE? The Classic Editor? 🙂where sidebars (meta boxes) contain actions and settings related to the document, not related to the content being edited. Instead, Gutenberg places in the sidebar actions and settings related to the content.

Other app I've seen (Squarespace & Co.), although they're not directly comparable to Gutenberg for many aspects, they put anything related to content in the toolbar above the content.

[jwold]

So having contextual controls above a content area is actually ok from an accessibility perspective because it's quicker to navigation between them (without a mouse), having those contextual controls in the sidebar introduces too much distance between them.

That's the heart of the issue, right?

[karmatosed]

Experience wise there is a large hit having this 3rd sidebar element. Cognitive load is increased and I do wonder if the potential benefits don't outweigh the problems caused. I am incredibly cautious also of having a toggle for this, that brings in yet another option.

I think this for me is one of those things right now I'd decide against and want the entire flow tested and considered, before a solution is put forward. For example, what is the feedback specific to this we need to consider for the flow?

In this, I am not saying it's perfect right now. This does need looking at, @afercia has raised some really good a11y insights and reasons why it needs to be reviewed. However, as far as the sidebar solution lets close this right now and consider from iterations.