Keyboard operation is confusing and inconsistent

[karlgroves]

Keyboard operation is confusing and inconsistent

• Severity: Medium
• Affected Populations:
  • Blind
  • Low-Vision
  • Motor Impaired
  • Cognitively Impaired
• Platform(s):
  • All / Universal
• Components affected:
  • Block Editing

Issue description

Keyboard navigation between Blocks, Block controls, and the Block panel,
is inconsistent and difficult to use.

In the default setup (no Unified Toolbar), getting controls to appear
generally requires moving keyboard focus with the Tab key. Moving
between Blocks is meant to be done by moving the cursor with arrow keys.
However:

• Some Blocks seem to trap the cursor, specifically the Cover type,
  however some Paragraph Blocks from the Gutenberg demo do as well
  (for unknown reasons; creating Paragraph type duplicates of these
  Blocks does not reproduce the trapping, so it's not clear why this
  occurs). In order to escape these Blocks, users must use the Tab
  key, which then adds the additional Tab stops of the toolbars which
  appear.
• When attempting to copy text within a Block using Shift and Arrow
  keys, the last line (or first line if starting from the bottom and
  going back) can't be selected without also beginning to select
  multiple Blocks. This might be deliberate (to encourage users who
  are attempting to select all of a Block's content to instead use
  the dedicated duplicate function) but users should expect to be able
  to select any text they wish. Additionally, it's common in a
  multi-line Block to accidentally move the cursor to a previous Block
  when merely trying to get the cursor moved to the first line (and
  accidentally move to a later Block while moving the cursor to the
  last line), especially if a screen reader is running.
• Users who are not using zoom must Shift+Tab backwards from the text
  to reach the toolbar, which matches the visual order when the
  toolbar is above the text. However users who are zoomed-in see the
  toolbar under the text, yet still have to Shift+Tab backwards to
  reach it
• While interacting with the Block's toolbar, focus sometimes ends up
  at the top of the document. This seems to be intermittent and
  unintended, but every time it happens it is frustrating.
• After a link is created, moving focus to it again offers an editing
  popup, however this is not keyboard accessible. It appears to be the
  only place where users can set whether the link opens in a new
  tab/window, and therefore this functionality is not available to
  keyboard users.
• If a Table is being created and the "Edit Table" popup is opened,
  users may attempt to use their Arrow keys to navigate it, however
  this unexpectedly moves the user focus to the top or bottom of the
  whole editable area. The only interaction users can safely do is to
  immediately press Esc to close the dropdown. This happens when the
  dropdown opens and all of the options are disabled.

In the Unified Toolbar setup, only the "New Block" and move controls
are in the Tab order, and moving between Blocks is still done by moving
the cursor with Arrow keys. Users can use the keyboard shortcut
Alt+F10 to jump focus to the Unified Toolbar (and can then Tab past
the Editor Top Bar buttons to the Block toolbar), however there is no
way to jump back from the panel to the Block in question.

In both settings, there is no non-exhaustive way of going from a Block
to the Block Settings panel, and if somehow the chosen Block is
forgotten (i.e. not seen as selected by the editor), then the Block
panel goes blank, and therefore the button that bring users back to the
Block in question is also lost.

Remediation Guidance

Add some kind of Bypass Block mechanism for keyboard user to move from a
selected block to the Block Panel, since this appears to be the only
place where font settings, drop cap and colors can be set.

Add a similar Bypass Block mechanism for users who've jumped to the
Unified Toolbar, to get back to the selected block without needing to go
through the Block panel's skip link.

If opening a popup cannot allow JavaScript to move focus to the first
item in the popup automatically (for example, because the popup has no
focusable items inside), then the Arrow keys should either move the
cursor up or down from the toolbar button (thereby closing the popup),
or keep focus there until users close the popup with the Esc key.

In any case, do not allow Arrow keys to move the cursor to the beginning
or end of the document; this is the last thing users would expect.
Ideally, if there are no available options in a dropdown, perhaps the
activating button should have the dropdown replace the options with a
message such as "No options currently available."

Wait for all content inside a block to receive selection before offering
multiple-block selection.

Allow cursor movement to always be able to move between blocks
regardless of type (unless there was a good reason for this; if so,
explaining the reason to users would then be helpful).

Ensure popups opened from within blocks can be reached by keyboard.

Relevant standards

• 2.1.1 Keyboard
  (Level A)
• 2.4.1 Bypass Blocks
  (Level A)
• 2.4.3 Focus Order
  (Level A)

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-95 in Tenon's report

[afercia]

Totally agree and this issue alone is one of the main accessibility barriers in Gutenberg, as also outlined in the Accessibility team report published on October 2018.

Previously: #5694, #5709, #11581.

Granted, this is a broader, structural, issue related to initial design choices made with no accessibility in mind. It relates to the general layout of the main editor sections and the fact the layout contributes to a far from ideal architecture information that makes no much sense when linearized.

[melchoyce]

Screenshots from the report:

[afercia]

See also #3697, #3003, and #2031.

[afercia]

Related broader issues: #11581 and #13663.

[sarahmonster]

The design team discussed this during a triage session in Slack today (Note: You may need a Slack account to log in.)

This has been a long-standing and much-discussed problem. The overall consensus was that this is a sticky problem that warrants a holistic solution, taking into account all of the comments, ideas, and discussions from the existing issues.

This would be a good opportunity for a designer and a developer to pair up and prototype a solution.

[mapk]

Allow cursor movement to always be able to move between blocks
regardless of type (unless there was a good reason for this; if so,
explaining the reason to users would then be helpful).

I believe this part has been resolved with the keyboard Navigation mode.

[enriquesanchez]

Revisiting this issue now that a few keyboard navigation improvements have been introduced in recent PRs:

✅ Some Blocks seem to trap the cursor, specifically the Cover type

This is no longer the case after the introduction of Navigation and Edit modes. When nested inside the Cover block, you can enter Navigation mode and tab out of the Cover block.

---

✅ When attempting to copy text within a Block using Shift and Arrow
keys, the last line can't be selected without also beginning to select
multiple Blocks.

This has been fixed now (#19094 and #19121):

---

✅ Users who are zoomed-in see the toolbar under the text, yet still have to Shift+Tab backwards to reach it

I wasn't able to find the PR that fixed this, but I just tested and this no longer seems to be a problem:

Zoomed in at 150%:

Zoomed in at 200%:

---

✅ While interacting with the Block's toolbar, focus sometimes ends up
at the top of the document.

Fixed in #18779

---

❌ After a link is created, moving focus to it again offers an editing
popup, however this is not keyboard accessible

While this is possible with cmd/ctrl + K, I think it's not obvious and the interaction could be improved. Currently being discussed in #20136.

---

✅ If a Table is being created and the "Edit Table" popup is opened,
users may attempt to use their Arrow keys to navigate it, however
this unexpectedly moves the user focus to the top or bottom of the
whole editable area.

This is no longer an issue according to my tests. I am able to access the contents of the 'Edit Table' popup with my arrow keys:

[afercia]

Thanks so much for re-testing all these issues and for the GIFs.

Zoomed in at 200%:

I'd like to add that in the "responsive view", the tab order between the "header toolbar", the "header settings", and the block toolbar is now completely non-sense and the visual order doesn't match the DOM order.

Worth reminding about 40% of screen reader users use an external keyboard with their mobile device from "sometimes" to "always":
https://webaim.org/projects/screenreadersurvey7/#mobilekeyboard

Mobile devices are often considered to be touch-only interfaces, yet many screen reader users use a keyboard when using their mobile devices.

(data from October 2017)

This should probably be discussed in a next accessibility team meeting.

[enriquesanchez]

Updating my last comment:

While this is possible with cmd/ctrl + K, I think it's not obvious and the interaction could be improved. Currently being discussed in #20136.

This is actually the expected and recommended behavior. Thank you @MarcoZehe for your feedback:

[...] it is good UX that the cursor stays in the link text even though the link UI opens. There is nothing more frustrating than the cursor jumping away from the text you're trying to review when some other UI part gets displayed [...] using the same keystroke to edit an existing link when the cursor is on it is common keyboard UX

So:

✅ After a link is created, moving focus to it again offers an editing popup, however this is not keyboard accessible

This is possible with cmd/ctrl + K.

[enriquesanchez]

Thanks for raising that problem @afercia. I've created #20996 to follow up on it.