New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Formatting toolbar controls missing when using a keyboard #6910

Closed
afercia opened this Issue May 23, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@afercia
Contributor

afercia commented May 23, 2018

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

screen shot 2018-05-23 at 11 49 29

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:

screen shot 2018-05-23 at 11 40 41

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

screen shot 2018-05-23 at 11 40 47

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

screen shot 2018-05-23 at 11 40 52

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

This comment has been minimized.

Contributor

afercia commented Jun 5, 2018

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:

gutenberg_6910

@afercia

This comment has been minimized.

Contributor

afercia commented Jun 12, 2018

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

This comment has been minimized.

Member

IreneStr commented Jun 14, 2018

@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

This comment has been minimized.

Contributor

afercia commented Jun 21, 2018

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

This comment has been minimized.

joedolson commented Oct 16, 2018

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

@designsimply

This comment has been minimized.

Contributor

designsimply commented Oct 16, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment