Testing feedback: Editor: Try a fixed block toolbar

[rianrietveld]

Issue Overview

People are complaining about the block toolbar showing up constantly and disturbing their writing flow, the PR by @youknowriad explores the possibility to use a fixed a block toolbar at the top. And its content change depending on the selected block.

Related Issues and/or PRs

User testing of Editor: Try a fixed block toolbar: #2148

[rianrietveld]

Test done by Gabriela Nino

http://wpaccess.org/gutenberg/
WordPress 4.8.1
Tested on Mac, Safari, keyboard only and VoiceOver.

Keyboard only test:

I could not figure it out how to access the toolbar. After selecting text in the block, I did not find how to move from the block to the toolbar. In the old version, we use tab and tab + shift to move from the block to the toolbar and vice versa. In this version I tried the same, it didn't work. I tried with enter, space bar without success. I'm not aware if there is a keyboard shortcut to acces the toolbar.

VoiceOver

I got the same problem with VoiceOver. I could not access the toolbar with VO command or tab and tab + shift. I'm not sure if accessibility was already implemented in this patch, but the experience with VO is that the block and the toolbar are completely disconnected from one each other. In the old version, I'm able to navigate from the block to the toolbar (although VO does not announce that there is a toolbar and interaction between elements were not perfect).

Overall impression

I see a positive point using a fixed bar, it could make easier to navigate from one block to another, which could be really nice when several blocks are in the page. Not having to tab to the blocks' toolbars will make faster moving between blocks. But I think that the interaction patterns will need to be studied in deep thought if this solution is chosen to keep.

Both, new and old version, are missing the next points for VoiceOver:

• Find a simpler way to move between blocks.
• When selecting text in a block, it needs to be announced that a toolbar is present (open) so the user knows that she can navigate to the toolbar.
• When moving to the toolbar, announcing when moving on or out the toolbar.
• When the focus is on the toolbar options, I find myself trying to move from one option to another using VO commands (control + option left/right arrows) or only left/right arrows. I guess this is a common reflex of VO users, since we move from one element to another in page using those. If
  I'm not mistaken, NVDA users are more used to move from elements in a page using tab and tab + shift.
• If a style is applied on text, it should be announced when the user is "reading it" otherwise the user won't know what text has already a style applied (bold, italic, etc).
• After applying a style, focus should move so the focus don't stay on the selected text.

The points below are not solutions, but they might be used as start points for a reflexion for the next steps of the Gutenberg project.

[youknowriad]

Yes, in the PR, accessibility is not handled yet, I'd love to implement this (though, I may need some guidance on the best way to approach it).

I'd really like if we can compare the two approaches regardless of the accessibility concerns. Does this reduce the distraction of the blocks toolbar showing up constantly? Do we lose some "context" here because the toolbar is not tied to the block? Is is an acceptable tradeoff?

[melchoyce]

This is really amazing feedback, thanks so much for running this test and summarizing, @rianrietveld! Also thanks to Gabriela Nino for testing :)

[afercia]

Worth noting to move from the block to the toolbar there's the shortcut Alt+F10, which is the same shortcut a;ready used in the current editor. Escape moves focus back from the toolbar to the edited block, same as in the current editor.
The ARIA Authoring Practices suggest to use Alt+F10 for the specific use case of an editor with a toolbar, and WordPress users should be already aware of this shortcut. Discoverability is important though and personally I think Alt+F10 is not so intuitive.
We've discussed to add a more intuitive shortcut and keep the old one, but haven't implemented yet. Suggestions very welcome.

[mtias]

Closing as we support both a header-level toolbar and toolbar-next-to-block now.