Gutenberg: Block toolbars position counterintuitive for keyboard users

[afercia]

I know this is going to be controversial and a balance would be hard to find, but I have to report it as part of the a11y user testing done during WCUS contributors day 🙂 Big thanks to Jackie D’Elia (@jdelia) and Katherine White (@katwhite). Full report: https://gist.github.com/kwhite/22cf005d0a23f3c66dd8df62a6bde574

This applies to all keyboard users, including screen reader users:

when you do get the controls for a block on tab in, it feels a little counterintuitive to shift + tab to go "back" to a link that didn't exist before. Technically I am not sure there's a good fix for it, though.

This kind of experience is pretty common for keyboard users, since navigation is mostly a linearized experience:

• you tab forwards and the toolbar is hidden
• you land in a block which is now focused
• as a screen reader user, you won't have a clue there's something hidden _before_ your current position that's now revealed
• all keyboard users now have to tab backwards to operate on the toolbar (assuming they've realized there's a toolbar displayed now)

Ideally, from an accessibility perspective, the toolbars should be placed in the source order _after_ the blocks.

Just noting that _some_ web apps out there place the toolbars after the content, for example Gmail when composing a new message.

Would it be possible to consider an user option? One of the things react makes easy is providing alternative views. Taking advantage of this to give users the ability to choose the toolbars position would be great. I know, decisions not options. But I feel this would be one of the few cases where an option would be really beneficial.

[karmatosed]

Is this still an issue with changes in flows @afercia? I know more keyboard testing has happened. We have user options for placing of toolbars for example. Does that not solve this?

[afercia]

Still applies. Users still have to tab backwards to get to the toolbar.
The current option for the toolbars placement is just betwen

• fixed to the top bar
• before each blocks

The proposal here is to add a 3rd option, that would be excellent for keyboard users:

• after each blocks

Would it be possible to consider an user option? One of the things react makes easy is providing alternative views. Taking advantage of this to give users the ability to choose the toolbars position would be great. I know, decisions not options. But I feel this would be one of the few cases where an option would be really beneficial.

[rianrietveld]

This still happens, especially with the table block.

Excerpt from keyboard test reports:

Ben McElroy (bemdesign) on keyboard only
Tables were difficult to manipulate - it was hard to trigger the edit options - they often disappeared and couldn't be triggered again until you had navigated to a different block first and then tabbed back again to the table block. Very frustrating.

@rianrietveld on keyboard only
Video at 24:11 minutes on https://youtu.be/--5iBphEMGA?t=24m11s

Eric Wright on Dragon 14
Video at 44:29 minutes on https://www.dropbox.com/s/o5tz79v9qdf0t15/Gutenburg%202.3%20extended%20a11y%20test.mp4?dl=0

[afercia]

Playing with this (quickly edited code to place the formatting toolbar below the block):

and keyboard interaction is sooo much more intuitive. For example:

• select some text: the toolbar appears
• press Tab and you're in the toolbar
• apply some formatting
• press Escape or arrows and you're back in the block

I'd +1million this for keyboard users.

[rianrietveld]

Pinging @aadrian

[karmatosed]

I don't think that placing the toolbars below works visually. My only thought there is what would the balance be? How can we still get the benefits without literally placing at the bottom? Are there any examples out there which solve this? This problem conflicts with issues like putting controls at the bottom. We'd have this weird double line.

[afercia]

Well the main issue here is not about visuals, which I'd say it's highly subjective. It's about interaction. While for mouse and touch users the placement of the toolbar would mostly be a matter of personal preference, for keyboard users (including assistive technologies users) having the UI controls in a logical order is paramount.

Currently, keyboard users have to tab through the whole toolbar before getting to the block editable area. Once they're within the editable area, they have to tab backwards (or use the Alt+F10 shortcut) to get to the toolbar. This happens for every single block inserted in the post, which makes the overall keyboard experience very uncomfortable, to say the least.

The "decisions not options" principle make sense in most of the cases, but I feel this is an issue where we really need to take into consideration users have different needs. Offering a third option for users who prefer the toolbar at the bottom is the only way I can think of to accommodate for different needs.

How can we still get the benefits without literally placing at the bottom?

I'm not sure we can, as one of the main a11y principles is that visual order should match tab order (i.e. DOM order).

Are there any examples out there which solve this?

The only example of "big" web application that aims to be accessible I can think of is Gmail, and in the New Message editor they place the formatting toolbar at the bottom.

This problem conflicts with issues like putting controls at the bottom. We'd have this weird double line.

Yeah, I know #6224 is going to place the "block tools" at the bottom. I understand two toolbars at the bottom would be a bit weird but I'd still recommend to try this third option after #6224 gets in.

[ZebulanStanphill]

This problem conflicts with issues like putting controls at the bottom. We'd have this weird double line.

Yeah, I know #6224 is going to place the "block tools" at the bottom. I understand two toolbars at the bottom would be a bit weird but I'd still recommend to try this third option after #6224 gets in.

To help with the double line issue, perhaps on wider screens all the controls could be shown on the same line, with the formatting controls on the left, the arrow movers and ellipsis on the right, and a drag space in-between. On shorter screens (or just blocks nested in columns) the arrow movers and ellipsis would move below the formatting controls. That is what happens on mobile right now anyway.

[afercia]

Thanks @SuperGeniusZeb I've forgot what happens on mobile. Yep it would be great to have the third option for the formatting toolbar position doing exactly that, with one important caveat: currently, the position at the bottom is only "visual". The DOM order is unchanged and the formatting toolbar is still at the top in the rendered markup. This should be changed, and the toolbar should be placed at the bottom in a correct DOM order (also, the visual order should always match the DOM order).

[karmatosed]

We have to be a little cautious directly translating mobile UI to desktop. I'd be ok with it as an exploration but this is a major change to the interface that would need extensive usability testing. It's also worth noting I don't think adding yet another option to the toolbar settings is the way forward here. Ideally we end up with only one there and remove both options anyway.

[afercia]

Saying "no" is not a solution though. The current order of the UI controls around the block is far from ideal (to be fair) for keyboard interaction. The main reason for this is because the interface has not been designed with accessibility in mind.
Any alternative solution is very welcome. Personally, I can't think of any solution other than having the controls after the block, for users who need a more logical and intuitive tab order.

[jorgefilipecosta]

Does making the block toolbar follow the ARIA good practices for toolbars https://www.w3.org/TR/wai-aria-practices/examples/toolbar/toolbar.html, making the toolbar tabbable but not having each button tabbable minimizes the problem?
To change the focused button once toolbar is focused we would use arrows as recommended.
If the toolbar is just one tab we may be able to minimize its impact on keyboard users.

[ZebulanStanphill]

Just copy-pasting some mockups I made in #6224:

Wide blocks

Thin blocks

Really thin blocks

I think I am really starting to like this design. For wider blocks, I am not sure if the arrow mover controls should go to the left of the formatting controls or to the right, though.

[karmatosed]

Saying "no" is not a solution though. The current order of the UI controls around the block is far from ideal (to be fair) for keyboard interaction. The main reason for this is because the interface has not been designed with accessibility in mind.

To be clear I am not saying we shouldn't make an accessible solution. I am saying we have to iterate and get to that point. The thing I am not sure works and in seeing visuals feel that a little stronger to be honest, is the direct translation of mobile UI to desktop. I have great belief we as a project can come up with a good working solution here for everyone and what @jorgefilipecosta asks I would like explored as a first option, at least to check if that even is an agreeable option.

@SuperGeniusZeb whilst I appreciate your mocks they do show a problem for me and that is combining all intents in one place. Block controls and editing are not the same and grouping them forces a false similarity. They also cause a problem if you think about style variants and placing along with long tall blocks and blocks at the bottom of the page.

[ZebulanStanphill]

Copy-pasting my response in #6224:

How about separating the controls via color?

[afercia]

Worth noting this issue is strictly related to https://github.com/WordPress/gutenberg/issues/1934

[bemdesign-er]

I like @afercia 's idea of having a user option to determine where the toolbar displays (fixed top, above block, or below block). But if this is not possible, then having the toolbar below the block makes the most sense from an accessibility/responsive POV. I like @SuperGeniusZeb 's concepts here as well.

[karmatosed]

Removing needs dev here as a solution hasn't been found yet agreed to go forward with. Once it is then that can happen.

[Henk57]

Has anyone thought about a dockable 'text toolbox'. In that way the user can decide where to place this on the screen.
The auto-hide is confusing in my opinion. Perhaps this behavior could be a setting, combined with the way the toolbar or toolbox is displayed, in, under, left, right or floating on top.

[boemedia]

I know Gutenberg wants to give a clear editing experience, but now it seems to compromise usability. What would be the disadvantage of having the toolbar in sight by default and let people disable it as an option?

[karmatosed]

We are exploring options with focus mode and fullscreen #9334 has notes about this. That in mind I would suggest we get this in and review after.

[tofumatt]

In general, I agree with the sentiment that it's strange the block toolbar needs to be accessed with a reverse-tab. I think it should come after the content of the block, so it can be accessed with a regular tab press.

If that can be done such that the toolbar appears in the same place it does now but is after the block contents in DOM, would that be okay? If so I think we could accomplish this just with a re-arranging of the HTML and CSS.

If not I think we need to add a third option that puts the toolbar beneath the block for accessibility/keyboard users. It doesn't matter if it "looks weird", it's way more usable (and is largely for non-sighted users anyway).

I'll say that as a frequent keyboard user I find the reverse-tab to bring up the toolbar odd behaviour. I always want to forward-tab.

[tofumatt]

I'm removing "needs design feedback" because this can either be accomplished without changing the visual design, or needs to be added as a third option. This is a legitimate concern and important enough to warrant its own option if needed (like the fixed-to-top-toolbar). It doesn't need design feedback because it's not about the visual design at that point.

[tofumatt]

Oh, I see this issue here now; the block toolbar is contextually rendered based on hover state or reverse-tab, meaning simply moving the toolbar below the block contents in HTML and absolutely positioning the CSS (which I did in about ten minutes in a try/ branch) won't work.

I think this would require its own "always visible block toolbar" setting for non-sighted users, similar to the "Fixed to top" toolbar setting.

---

In general I envision a sort of "Accessibility mode" users can enable. This sort of idea is not unheard of (MacOS, Windows, iOS, and Android all have a wealth of accessibility options that aren't enabled by default but provide features for users who need them), and this is the sort of setting I'd see being available under "Gutenberg Accessibility Options". An always-visible block toolbar might be a bit noisy for most sighted users, but it's incredibly useful in the non-sighted, keyboard user's case.

---

At any rate an always-rendered, forward-tab accessible block toolbar should be available, but as an accessibility option. I'm sadly not sure we can address that before 5.0 ships, but it's totally worth doing.

I don't think this needs design feedback because this would be a user-enabled feature that would sacrifice the visual design of the writing flow for accessibility.

That said, I wonder why we conditionally render the toolbar rather than conditionally hide/show it with CSS. Doing the latter might allow us to just change the HTML order and avoid the accessibility option. 🤷‍♂️

[boemedia]

I'm removing "needs design feedback" because this can either be accomplished without changing the _visual design_, or needs to be added as a third option. It doesn't need design feedback because it's not about the visual design at that point.

I was truly hoping that, within WordPress, we were beyond the point that design is solely seen as 'visual'.

[bemdesign-er]

I think this particular issue highlights that we need to do a better job of being "accessibility-minded" when we design and develop for WordPress. We can't really bolt-on accessibility after the fact for this issue since it really stems from earlier design decisions. Issues like this are why the a11y team (although I do not speak for them) currently feels that we should recommend AT (accessibility technology) users use the classic editor plugin until these issues are addressed.

[tofumatt]

Unfortunately this won't be ready for WP 5.0; I have a try branch at #10462 but I don't think I'll get to it for Monday. If that changes I'll update the milestone.

[timwright12]

Switching the toolbar to the bottom would also deal with this issue: https://github.com/WordPress/gutenberg/issues/11345

[afercia]

Yep. Although I'm still not sure why the Add Block button must be there, before the block UI and add a block _before_ ¯_(ツ)_/¯