Inserter: consider to place tabs at the top

[afercia]

Splitting this out from #1325

Ideally, as mentioned in #1325, tabs should be implemented as an ARIA tabbed interface. Reference: https://www.w3.org/TR/wai-aria-practices/#tabpanel
(Please read the very detailed part related to the expected keyboard interaction)

The practical advantage is not just in the way tabs would be reported to assistive technologies but also in the expected, standard, keyboard interaction.

Why keyboard interaction matters

• say there are 5 tabs with their 5 related content panels
• say that, pressing the Tab key, we move focus to the second tab
• now, to actually navigate to the content panel using the keyboard, we still have to tab through the 3rd, 4th, and 5th tab
• not so ideal

The keyboard interaction model recommended in the ARIA Authoring Practices offers a solution:

• pressing the Tab key, focus moves to the currently selected tab
• to move through tabs, it uses just the left and right arrows (optionally Home and End)
• this way, once focus is on the second tab, we can Tab directly into its content panel

This is a great way to save tab stops and make keyboard navigation efficient.

Worth noting that Tabbed Interfaces like the one described here are everywhere. Even in our operating systems. In fact, many ARIA widgets are based on and inspired by interfaces already present in the operating systems and users are already used to them.

You can actually test this. Open, for example, the "System Preferences > Keyboard" dialog on macOS.

Or, on Windows, the well-known Task Manager:

Notice that tabbing in the dialog, focuses the "tabs" just once. Pressing Tab again, you will navigate away from the "tabs". Instead, once the "tabs" have focus, you can use arrows to navigate through the tabs.

Any "state of the art" tabbed interface should work this way, as the advantages are clear and also because it's a standard interface implemented consistently across platforms.

Currently, the only implementation in WordPress is in the WP embed sharing dialog, implemented by @swissspidy.

Placing the tabs at the bottom would break this interaction model. For this to work, tabs should be at the top. Tabbed interfaces can also be horizontal, with the tabs on the left (right for RTL languages). In any case, the tabs should be before the content.

Reusable UI components gives us a great opportunity to build "state of the arts" interfaces. I'd recommend to strive to stick to the standards and not reinvent the wheel. Also, once a reusable UI component gets done right, it's done right forever.

[jasmussen]

Reusable UI components gives us a great opportunity to build "state of the arts" interfaces. I'd recommend to strive to stick to the standards and not reinvent the wheel. Also, once a reusable UI component gets done right, it's done right forever.

💞

The inserter was just updated to look like this:

Here's a quick bit of web inspector surgery moving them up top:

I'm presuming here we want search to be first, as that get's focus, right? One could also imagine that as soon as you start searching, the tabs disappear entirely — because you search all of them. Is this kosher?

Finally, with tabs on top, we might want to redesign them slightly, perhaps add a little space above them. @paulwilde also had some ideas around letting the tab be more physically connected to the content below, like in your task manager screenshot.

[jasmussen]

The current inspector was largely inspired by the emoji inserter.

For inspiration with regards to search first, then tabs, the phone dialer on Android does this:

[karmatosed]

I would if we can avoid it -1 to moving the tabs to the top. Visually that means its a really hard path for users. From an a11y perspective of usability not just keyboard/screen readers - this means a lot will have issues using.

Can we avoid doing that as I really think its making the experience a lot worse.

[afercia]

@karmatosed open to experimentations. However, how do we solve the keyboard interaction issue? I'd appreciate any proposal to make it better. As you know, keyboard navigation is a linearized process. Forcing users to tab backwards after they select a tab is far from ideal.

I really think its making experience a lot worse

It depends on what kind of users we take into consideration 🙂 We should strive to make the experience as good as possible for all users, not just some users. And it's not just about people with special needs. Many just prefer to use the keyboard.

[afercia]

For completeness: on the other hand, the spec doesn't explicitly prohibits tabs to be placed at the bottom:

The list of tab elements is arranged along one edge of the currently displayed panel, most commonly the top edge.

The expected keyboard interaction should meet the one described in the spec though. For now, I'd agree with @jasmussen as at this stage the best thing is probably wait a bit and let that interface sit in the plugin for a while to be properly tested, see #1497 (comment)

[nylen]

These are not really tabs in the strict sense of presenting multiple, distinct pages of content. A block can appear in both "Recent" and another tab. So it may help to think of this control as a set of filters on a list, and Search is the same type of thing: just another filter.

[afercia]

Not really sure that makes a difference, from a keyboard interaction perspective 🙂

[StaggerLeee]

Dont know it it is for new issue, or.

When scrolling in Insert popup, and comes to the bottom-end or top-end, prevent scrolling of whole page and content editor area. There is no need for it, it is not desired goal of User, to scroll content editor area.

Can make, and it will, editing very unpleasant.

[afercia]

@StaggerLeee thanks, I guess that's something to consider. Not strictly related to this issue though. Would you mind opening a separate issue?

[jasmussen]

@StaggerLeee The term I use for what you describe is "scroll bleed". That is, you scroll the page when you hit the end of another field. We are tracking this in #656

[jasmussen]

@melchoyce had a design for tabs on the side. Can you recall the ticket you posted that in, Mel, and Andrea would that solve issues here?

[melchoyce]

Yup, that was on #1516 (comment)

[afercia]

Tabs on the side would help 🙂 This way, they would be before the tab panels in the source order, which makes much more sense in a linearized navigation as the one keyboard and screen reader users experience.

[karmatosed]

Adding design feedback and needs design because it's been a while since comments on this issue and with Gutenberg as it's stands now, interested what everyone feels.

[mtias]

Done in #3080