Formatting toolbar controls missing when using a keyboard

[afercia]

When using the mouse and clicking, for example, on a paragraph, the formatting toolbar appears with all its controls displayed:

Instead, when using the keyboard to navigate with the Tab key and the toolbar is focused, only a few controls are displayed. In the screenshots below, the focused element is highlighted with a red outline.

Tabbing into the toolbar: only 4 controls are initially displayed:

Press tab again to move to the last of these 4 controls:

Now press tab again: the missing controls appear but they're "skipped", as focus has already landed on the block content:

The expected behavior would be that all the toolbar controls are displayed when the toolbar receives focus.

Not sure what's happening, I can reproduce consistently on current master with different browsers. No JS errors.

[afercia]

Uploading an animated GIF to clarify, still happens on 3.0. Please notice in a first moment the toolbar has just a few buttons. Then, when tabbing through the toolbar, bold, italic, strikethrough, and link appear:

[afercia]

With regards to the related conversation on Slack, worth noting in the current Classic Editor there's no need to make a selection to have the bold, italic, strikethrough, and link buttons work. In fact, it is possible to just put the caret within a word, press (for example) bold and the whole word becomes bold.

Regardless, the caret must be within the editable area but I'm not sure not showing the buttons if the caret is not within the editable area is the best user experience. Seems to me it's just a bit confusing.

[IreneStr]

@jorgefilipecosta, @enejb and I have discussed this on WCEU. It might be a good idea to pass a boolean as a prop to each block that determines whether the first editable should be automatically focussed when the block gains focus, for example when tabbing to it. That way, when a user tabs to a paragraph (or any other block for that matter), the rich text formatting buttons will always show up. If there are reasons to not focus the first editable, this can also be managed with this prop.

[afercia]

Yep focusing the editable area could help. It's an option to evaluate but we should also take in consideration the proposed switch between navigation / edit mode, see #5709. If we find a way to make it work well with Windows screen readers too, then switching to edit mode would automatically move focus to the editable area.

[joedolson]

Tested 10/16/2018 with NVDA/Firefox and this appears to work as expected now.

[designsimply]

Closing based on the latest reply. Thank you for testing @joedolson!