Unexpected reverse-tab behaviour

[moorscode]

Issue Overview

When entering some text in a block and moving to the next block, I want to be able to quickly return to the previous block to change my typo or revise my content.

Steps to Reproduce (for bugs)

1. Create a fresh post
2. Enter some stuff in the title block
3. Tab to the next block (text)
4. Notice your typo
5. Shift-tab back to the title block, in 14 steps.

Expected Behavior

I expect to more easily return to the block I came from.

Possible Solution

It would be acceptable to have either a short-key to jump to the previous block or have a navigational choice about going to the 'toolbar', 'block-controls' or 'previous block'.

[karmatosed]

I think this is due to the nature of tabbing but I agree it doesn't make sense to a user. @afercia is there any way this could be negotiated and still be accessible?

[afercia]

It's a bit more complex. At the moment, the Gutenberg blocks have different behaviors. Some blocks have two focusable containers, while other blocks have just one.

Also, I see a different behavior between Chrome and Firefox, where on Firefox sometimes blocks don't get focused. Not sure trying to manage focus in this way is a good idea in the first place.

Let's compare, for example, a text block with an image block.

Tabbing forwards in Chrome:

• text block (2 focusable containers):
  • focus goes natively on the outer container and then Gutenberg immediately moves it into the inner container (the content)
  • the toolbar appears but is already "behind" the tab order
  • at the following Tab key press, focus goes to the next block
• image block (1 focusable container):
  • focus goes natively on the outer container and stays there
  • at the following Tab key press, focus follows the native tab order and goes to the "move" buttons, then the cog/delete buttons, and then the toolbar
  • the image itself is not focusable (that's ok) so focus goes to the image caption
  • the focus behavior on the image caption is similar to the one of the text block (the toolbar is skipped)

Tabbing forwards in Firefox:

• text block (2 focusable containers):
  • focus goes nowhere, there's no focused element at all: I guess Gutenberg fails in moving the focus to the inner container
  • the toolbar appears but still there's no focused element
  • at the following Tab key press, focus goes to the next block
• image block (1 focusable container):
  • same as Chrome

Tabbing backwards in Chrome:

• text block (2 focusable containers):
  • focus goes natively on the outer container and then Gutenberg immediately moves it into the inner container (the content)
  • the toolbar appears
  • at the following Shift+Tab key press, the toolbar is the previous element in the native tab order so it gets focus, followed by the delete/cog buttons, and the move buttons
  • lastly, focus goes on the outer container
• image block (1 focusable container):
  • focus goes natively on the outer container and then Gutenberg immediately moves it to the image caption
  • at the following Shift+Tab key press, focus follows the native tab order and goes to the caption toolbar
  • then it goes to the image toolbar, delete/cog buttons, and move buttons for a total of 16 steps
  • lastly, focus goes on the outer container

Tabbing backwards in Firefox:

• text block (2 focusable containers):
  • focus goes natively on the outer container, the toolbar appears but Gutenberg seems to fail to move focus to the inner container
  • at the following Shift+Tab key press, everything is skipped and focus goes to the previous block
• image block (1 focusable container):
  • same as above

Sorry if it's a bit TL;DR 🙂 and I may have missed something. Worth noting these behaviors change if you change tabbing direction while you're on a block. I've noticed also some inconsistencies, difficult to describe. And I haven't tested in depth other blocks or other browsers (I wonder what might happen on IE 11 😱 )

The whole point, in my opinion, is that focus management as it is now is highly confusing and inefficient. However, before attempting any coding, making a decision about how focus should behave would be highly recommended.

Easy, quick, and consistent navigation with the keyboard in both direction is key.

I've seen some initial feedback from users who reported there are way too many tab stops. I'd tend to agree. Reducing the amount of tab stops is the first thing I'd consider. In this regard, making the toolbars real ARIA toolbar, with the expected keyboard interaction, could be an option. See #632 and https://www.w3.org/TR/wai-aria-practices/#toolbar
Example:
https://www.w3.org/TR/wai-aria-practices/examples/toolbar/toolbar.html
where using only one tab stop on the toolbar and then arrows to navigate its content greatly help a quick navigation. This was also discussed in the last a11y meeting on Slack, see https://wordpress.slack.com/archives/C02RP4X03/p1500313173411327
where it was also pointed out that yes, it would be a good approach, but there's also some learning curve for users.

One more thing I'd recommend is to review the hide/show mechanism of the toolbars. #552 (Pressing cmd/ctrl as a way to navigate into block toolbars) could help.

One more very important consideration: focusing the outer container is really important because it's the only element that uses an aria-label to announce the block type. I'm not sure that trying to automatically move focus to the inner container is the best way to go.

[mattyrob]

The current editor allows easy navigation through your content using the cursor keys alone, I believe that any move away from this using other keys is a regression from the current 'distraction free writing' ethos and we really need to think about hopping to the next block up (if one exists) using the up cursor button if you are already at the top of the current block. vice versa using the down cursor key to hop to the next block (provided you are not at the bottom of the last block).

[afercia]

@mattyrob I think what you are describing is arrow keys navigation, which is already implemented (#520) even if currently it's a bit buggy, and no one here is proposing to remove that.

This issue is about navigation with the Tab key, which is a different matter.:

• inconsistent across blocks
• inconsistent when tabbing forwards / backwards

[jeffpaul]

This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs.

[afercia]

Just tested again on current master (41cde56).

Seems to me something has changed regarding keyboard navigation through blocks, but the original issue still stands: when tabbing backwards, users are forced to tab through too many UI controls before they actually get the previous block.

Fix toolbar to the top "on":

• tabbing forwards requires 2 tab presses: first tab focuses the block, second tab puts the caret inside the block (not sure why, seems to me this is new, unrelated to the original issue though)
• tabbing backwards: you're forced to tab through the ellipsis toggle and block mover controls; note: the quote block seems to be buggy

Fix toolbar to the top "off":

• tabbing forwards requires 2 tab presses (see above); note: the quote block seems to be buggy
• tabbing backwards: you're forced to tab through all the toolbar controls, the ellipsis toggle, and block mover controls

Overall, I think keyboard navigation has been a bit overlooked in the last releases and probably needs a bit more focus and, hopefully, some improvements.

[afercia]

I think this could be addressed by the proposed third position for the formatting toolbars (see #3976) together with the proposed "navigation mode and edit mode", see #5694. @moorscode do you think those 2 proposals would address your concerns?

[afercia]

See #3976 that should be in the a11y merge proposal as the approach proposed there would solve this issue.

[moorscode]

To reduce complexity in the text below, I like to clarify some words I will be using and what they represent.

• button: a control-item in a list of control, like the styling bar
• element: a content field, navigation holder, styling bar, etc.

How I think this should work:
When reverse-tabbing in an element or on the first button of a list of buttons, the result should be the "previous" element. If this element has several buttons, the first item should be selected.
If the user wants to use a specific button, it can be focussed using forward-tabbing.

When the focus is on a button which is not the first one in a list of buttons, the "previous" button should be focussed, instead of leaving the list to focus the "previous" element.

Example:

1. The focus is on a content-field in a paragraph block
2. Reverse-tab is being pressed
3. The left-most (first) button on the styling bar is focussed
4. Reverse-tab is being pressed
5. The first button in the /\ \/ navigation bar is focussed
6. Reverse-tab is being pressed
7. The title field is focussed

Motivation for this specification:

1. An experience which is easy to predict.
2. The functionality can be used that is required to be used.
3. The main control to use is the regular tab button, reducing the need for the more complex 2-button control of shift+tab.
4. Simple specifications should be implementable in a general way

[hedgefield]

To clarify I've drawn a quick diagram.

Basically, when you're reverse-tabbing through your content and reach the left edge so to speak, from that point on the reverse tabbing direction only goes up.

[afercia]

It is interesting to note that, when it comes to the toolbars (or styling bar of formatting toolbar whatever we want to call them) part of the issue @moorscode and @hedgefield highlighted above could be addressed just following the ARIA keyboard interaction pattern for toolbars.

Reference:
https://www.w3.org/TR/wai-aria-practices/#toolbar

Putting it simply, ARIA toolbars have just one tabbable element at a time. So when tabbing through the UI, a toolbar is just one tab stop. Pressing again Tab or Shift+Tab, navigates to the following or previous focusable element.

Once the toolbar gets focus, its buttons can be navigates with arrows only. Also, the role="toolbar" makes screen readers switch to "forms mode" which allows key presses to work on a toolbar.

You can try it ourself on the W3C example: https://www.w3.org/TR/wai-aria-practices/examples/toolbar/toolbar.html

The great advantage of this pattern is that it greatly decreases the number of tab stops in the UI. Keyboard users are not forced to always navigate through all the buttons in a toolbar. Maybe they just need to get to the block mover buttons, or to the More options button: why we should force them to navigate through the whole toolbar each time?

Instead, when they need to operate on the toolbar buttons, they can just Tab to the toolbar and then user the arrow keys.

From the ARIA authoring practices linked above:

• When the toolbar receives focus, focus is set on the first control that is not disabled.

In other words, it has just one focusable button at a time. Initial focus goes on the first focusable control.

• Optionally, if the toolbar has previously contained focus, focus is set on the control that last had focus.

This is the "roving tabindex" behavior which is used on the W3C example and also on the TinyMCE toolbars (press Alt+F10 to move to the toolbar and focus will be placed on the button that previously had focus). Worth noting the roving tabindex as previously discussed also on #578 and #3281

As far as I see, the first part would be relatively simple to implement: just switch all the toolbar focusable controls to tabindex="-1" except the control that gets initial focus which must have tabindex="0". Arrow navigation is already implemented, it would just need to get the focusables and not the tabbables.

[samikeijonen]

Andreas previous comment makes sense to me.

As a side note, arrow up/down keys seems the best way to navigate from block to block at the moment, when the focus is in the block content.

[grahamarmfield]

+1 for the idea from @afercia to use the W3C toolbar pattern. I think this would make life easier for keyboard and screen reader users.

Not sure how the idea of having jump links to the panels on the right hand side would fit in, but I suppose that could be the first element in the toolbar?

@samikeijonen Not sure if I've understood your comment on up/down arrow keys. If I'm updating a paragraph (behaves like a textbox) then I'd expect the up/down arrow keys to take me up or down a line within the currently active text.

[samikeijonen]

@grahamarmfield

Not sure if I've understood your comment on up/down arrow keys. If I'm updating a paragraph (behaves like a textbox) then I'd expect the up/down arrow keys to take me up or down a line within the currently active text.

I ment at the moment (still in v 3.1) that's how it works. But I'm not sure should should up/down arrow keys stay inside a current block.

[grahamarmfield]

@samikeijonen Yes, it's my view that up and down arrow keys should stay within the same block.

[mtias]

As a side note, arrow up/down keys seems the best way to navigate from block to block at the moment, when the focus is in the block content.

This is precisely how it works. Am I missing anything?

[tofumatt]

I just tested this in Windows 10 Edge and indeed, the arrow keys move between blocks without focusing the block toolbar.

Perhaps we could add such tests to https://github.com/WordPress/gutenberg/blob/master/test/e2e/specs/writing-flow.test.js, but this is working in the editor.

Of course, the reverse-Tab behaviour still focuses the toolbar, but that's intentional. We offer the "skip" key via the Up arrow.