Steps to make keyboard navigation usable

[omarreiss]

Opening a new issue for this since I think my issue is more general than it is technical. The premise is very simple. We can dramatically improve keyboard navigation for Gutenberg if we just fix a couple of basic things. Accessibility is a part of this, but right now it's just really hard and tiresome to navigate using the keyboard. This is primarily a usability issue.

Main keyboard navigation usecases that we need to support better:

• Navigating across blocks
• Navigating from a block to its settings and vice versa
• Discovering how these things are navigated using keyboard only

What do we need:

1. a way to navigate the blocks without going into them. Apart from just giving a far better UX, this would allow screen reader users to get an overview of the structure of their post and go in to edit the block they want to edit when they want to edit it.

• Relevant issue: Simplify keyboard navigation through blocks #5694. The whole thing is already almost fully conceptualized. We should just do it.
• Relevant try PR: Accessibility: Try adding the keyboard navigation/edit mode #5709. Turns out the things was even already almost entirely built. Let's just finish this and get it over with.

2. a way to navigate from the block to the block settings and vice versa. I would add skiplinks to each block to do this and have a shortcut to toggle between the block and its settings.
3. a way to discover how keyboard navigation works. I think having a skiplink at the beginning of the navigation which reads "Keyboard navigation manual" would do the trick. It could simply trigger the keyboard shortcuts modal extended with a section about how blocks can be navigated using keyboard. Will create a separate issue for that. This manual would not only be useful for screenreader users but also for regular users. Was explored briefly in User guide and keyboard shortcuts documentation #5420

Some thoughts on navigation and a11y

Navigation and screen reader accessibility go hand in hand. The way to discover what's on a page with a screen reader is simply to navigate through it's basic structure. To make a complex application accessible, we need a layered approach, where the top level structure is as simple as possible and deeper nested capabilities (like editing in a block) can be a layer underneath that. The main function of any top layer is always to provide a framework for orientation, thus navigation is a top level concern. Editing is not, even though it's the primary concern of the editor. In order to edit, it needs to be easy to navigate into editing. From a visual perspective this kind of conceptual hierarchy is actually also how a web page is processed by users. However, instead of explicit it is implicit, so there is less necessity to conceptualize it. I'm sure I'm reiterating here what others might have already expressed far more eloquently.

[anevins12]

a way to discover how keyboard navigation works. I think having a skiplink at the beginning of the navigation which reads "Keyboard navigation manual" would do the trick. It could simply trigger the keyboard shortcuts modal extended with a section about how blocks can be navigated using keyboard.

I would advise against using modal windows and instead providing those instructions in the most convenient manner, as plain text. It will still be difficult to remember these instructions even if you've read them, but it is a good start to the problem.

[tofumatt]

Thanks for the feedback; just addressing some points:

Navigating across blocks

There is a way to navigate across blocks since #10545. A good follow-up might be to show part of the content of the block in the visual navigation and to let screenreader access a bit of the content of the block from the hierarchy navigation menu.

#5709. Turns out the things was even already almost entirely built. Let's just finish this and get it over with.

There were issues with the approach there for screenreaders that I didn't see resolved, but it's a big issue and maybe I missed it. But I don't think it's a case of just needing to write a few tests and shipping it.

Navigating from a block to its settings and vice versa

Skiplinks would further muddy the interface and add even more tab stops though. If we address keyboard shortcut education (and improve block navigation shortcuts where needed), this isn't as needed.

Discovering how these things are navigated using keyboard only

Yeah, this should be better surfaced. I like the idea of a skip link to keyboard shortcuts, but keep in mind that's a modal right now. The idea of surfacing keyboard shortcuts using the NUX guides was floated around too: bonus is that then regular users get lessons on keyboard shortcuts too 😄

[jasmussen]

Worth noting again the thoughts outlined in this comment: #5709 (comment), and specifically adapted mockups in #5694 (comment).

[bemdesign-er]

We do need a better way for users to navigate and orient themselves. As you note, "In order to edit, it needs to be easy to navigate into editing." Skip links and exposing navigation guides are good steps in addressing this.

[omarreiss]

There is a way to navigate across blocks since #10545.

Ah yes, that is definitely an improvement, and I see how it is sort of reachable from within one block through the shortcut. Wouldn't say this solution is nearly as integrated and useful as #10545. But it's certainly better than nothing. I think the layered approach is needed to make it intuitively usable and make the block editor more natively discoverable using a keyboard.

There were issues with the approach there for screenreaders that I didn't see resolved, but it's a big issue and maybe I missed it.

Not saying it's that easy. But the main blocker I got is that it was proposed to make the block overlay / outline semantically a button and this was understood by some as a need to put an actual button in there. Deferring to @afercia for more context.

[timwright12]

...a way to navigate from the block to the block settings and vice versa. I would add skiplinks to each block to do this and have a shortcut to toggle between the block and its settings.

@tofumatt I get what you're saying about mudding up the UI with another tab stop, but currently getting from block to settings and vice versa is near impossible without a mouse. If adding some form of a bypass block helps keyboard users, that could be a big win for universal design. Adding it as an item inside the #10545 menu could be an option (alongside each block item in the menu - so you could jump straight to the settings), but also inline to each block.

(cc @omarreiss)

[tofumatt]

⌥ F10 navigates to the nearest block toolbar, but yeah it doesn't work because that toolbar is only visible on hover. I guess we really need a block toolbar always visible to fix that, though for Unified Toolbar mode it works well. 🤷‍♂️

^` navigates to the next section, which in a few presses will take you to the sidebar where extra block settings live.

A dedicated "Block Settings" shortcut would save on keypress for the second option, but with Unified Toolbar it's a bit better:

https://www.dropbox.com/s/tqtatf3fhyn1dih/Screen%20Recording%202018-11-07%20at%2016.31.08.mov?dl=0

But yeah, it's still a non-obvious setting users need to enable to get there. And getting back to text from the toolbar is meh 😢

[mtias]

For better ⌥ F10 support there's two in progress PRs if people want to help review:

• Fix: Blocks: Alt+F10 should navigate to block toolbar regardless of visibility #11607
• Editor: Add KeybindScope complement to NavigableToolbar #10699

[afercia]

Just to note this issue actually supersedes #5694 and as such it should be milestoned as #5694 was milestoned.

[afercia]

There is a way to navigate across blocks since #10545.

As agreed during the last accessibility meeting, the accessibility team considers the "Blocks navigation menu" implemented in #10545 a nice-to-have but it doesn’t fully address the issue. See #5694 (comment). We haven't reopened #5694 because there's now this issue with a clear, actionable, proposal. Worth mentioning also #11711 and #11713.

Skiplinks would further muddy the interface and add even more tab stops though

I'm not sure I fully understand. Skip links would actually reduce the amount of tab key presses required for navigating content. That said, we can certainly explore other options but there's the need of a mechanism to jump from a block directly to the sidebar. Ideally, this mechanism should be easily discoverable with standard interaction (i.e. no keyboard shortcuts).

Worth noting again the thoughts outlined in this comment: #5709 (comment), and specifically adapted mockups in #5694 (comment).

Again, as pointed out in the following comments, that approach doesn't work with screen readers. It has already been tried. It doesn't work. See #5694 (comment)

This approach was already tried in #5709 and doesn't work when a screen reader is running.

[...]

As mentioned in #5709, there's the need of a button element to switch from a block "navigation mode" to "edit mode".

Lastly:

^` navigates to the next section, which in a few presses will take you to the sidebar where extra block settings live.

We'd make a better service to our users trying to think more holistically. It's not just about navigating to the sidebar. Once I'm on the sidebar, I haven't done anything yet. It's about accomplishing a task and actually being able to use the extra block settings. As demonstrated with a specific example in the accessibility team report, changing the font size required 34 separate keyboard stops.

[timwright12]

It doesn't feel like adding more (or relying on) keyboard shortcuts is the answer here. Adding one extra item to either the toolbar or the "more" menu would be generally simple to implement and high impact for keyboard users. Attaching some ideas I had, would love to hear thoughts/comments.

[tofumatt]

For a sighted user that menu item strikes me as quite confusing. What would it do when clicked? If it opens the sidebar and focuses it, even calling it “Open Block Settings” or just “Block Settings” might be better?

[timwright12]

"Block Settings" makes sense "Move" sounds like you're physically moving something.

What I was thinking was
If settings are closed: Click menu item -> open block settings -> focus first item
If settings are open: Click menu item -> focus item item

Having "Block Settings" and "Hide|Show Block Settings" together could be confusing as well. What do think about the first image with just the gear icon exposed in the toolbar (next to the "more" menu), which the "block settings" tooltip on it. Too much in the toolbar?

If we can work out the action item for this in the next couple days, I should be able to pick it up Monday/Tuesday.

[tofumatt]

Because this issue is still in discussion without a PR yet I'm moving it out of the WP 5.0 milestone, but we can still tackle it in a follow-up 5.0.x release.

[afercia]

If settings are closed: Click menu item -> open block settings -> focus first item
If settings are open: Click menu item -> focus item item

This option was discussed at some point in previous issues / PRs but then agreed to not implement it because it's based on the assumption that when users open the settings sidebar they also want to move focus there. This might be true for some workflows but not for all workflows. For example, users might want to open the sidebar just to check what's in there and still keep focus on the block.

[timwright12]

@afercia That make sense, but we're more so talking about having 2 options in the menu:

1. open/close as it currently does
2. move to/set focus (and open, if needed)

The wording of the two menu items is tricky, since the functionality is so close. It would be great if they were the same, but you're right, not everyone wants to move focus. In my opinion, if they were the same option, it would be much better to present a user with the minor inconvenience of having to jump back to the block vs. the difficult experience we're currently presenting keyboard users who need to access block settings.

I"m on a short week with the holiday, but I might be able to prototype something.

[afercia]

Quoting from the WPCampus/Tenon accessibility report (issue filed at #15322):

Shortcut keys for moving around a document should be considered extra UX features for power users, rather than essential for basic navigation. Focus should follow a predictable order, generally following visible items, and should not be able to reach invisible areas.

Relevant standards

• 1.4.10 Reflow (Level AA)
• 2.4.3 Focus Order (Level A)
• 2.4.7 Focus Visible (Level AA)

[karmatosed]

I am removing the 'User Experience (UX)' label as part of a label cleanup. It's not being used anymore consistently so let's try and keep to 'needs design' and 'needs design feedback'. If we find a need for another label we can consider it but having those 2 should cover this.

[sarahmonster]

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

We determined this issue doesn't strictly need design feedback, and that we should probably treat it as a tracking issue so as to focus work on actionable solutions. It comprises three different issues, all of which have been discussed in other issues. I did a wee bit of digging to pull those up. If there are more representative issues than these, please feel free to edit this comment to reflect that so we have an up-to-date reference.

1. Navigation across blocks: Simplify keyboard navigation through blocks #5694 (Closed, but it seems the solution here isn't sufficient to resolve the problem. Do we need a new issue to discuss solutions here?)
2. Navigating between the block and its advanced settings: Improve keyboard navigation between the block inspector and the block content #13663 (also currently the focus of some cross-team collaboration between design and accessibility)
3. Discoverability of keyboard shortcuts: Surface keyboard shortcuts when modifier keys are held #13688 (revealing keyboard shortcuts in the UI) and Manual for users of assistive technology #10373 (creating a manual for users of assistive technology).

In the interests of pushing things forward and improving keyboard accessibility for all users, let's try to make some progress on these issues, and then we can loop back here to investigate the broader impact of the changes.

[afercia]

While #16500 is potentially a huge improvement (still needs a complete accessibility feedback), it doesn't address all the points raised on this issue and previously on #5694.

The work done on #16500 is greatly appreciated but I'd like to propose to keep this issue open. As mentioned in the accessibility team report on October 2018 and on the WPCampus accessibility report (see for example #15322 and #15314), some of the accessibility issues in Gutenberg are related to the overall design and should be solved at a design level.

[youknowriad]

• I think this was kept open to track the navigation between blcoks which is sovled by Support Navigation and Edit Mode #16500
• The other issues I'm aware of are about the sidebar which is tracked here Improve keyboard navigation between the block inspector and the block content #13663 (I think that's the main thing you're referring to if I understand properly)
• Discoverability of keyboard shortcuts is tracked here Surface keyboard shortcuts when modifier keys are held #13688 and Manual for users of assistive technology #10373

If there are other a11y aspects that needs to be discussed/tracked, please open separate issues. We can't just have a "accessibility is broken" issue.

[afercia]

This issue explicitly mentions (as second point) navigation to the block settings 🙂

Technically, #13663 is a duplicate of a part of this issue.

I'm sorry but I think categorizing this issue as an "accessibility is broken" issue sounds unfair towards the ones who researched, explored, and reported their findings here. Seems to me everything here is well detailed.

Also, #16500 still needs a full accessibility feedback and testing, as I asked yesterday. Not sure an issue can be considered "solved" without extensive testing with assistive technologies and feedback from specialists in the field.

[youknowriad]

#16500 I got a11y review from a bunch of people including @enriquesanchez and I'm happy to follow-up with feedback from anyone.

I'm sorry but I think categorizing this issue as an "accessibility is broken" issue sounds unfair towards the ones who researched, explored, and reported their findings here. Seems to me everything here is well detailed.

Sorry about that, yeah, words badly chosen. I was replying to your comment where you said, we keep this open because of design consideration (it was pretty vague).

Technically, #13663 is a duplicate of a part of this issue.

I don't mind if we close the other one, but let's just focus on one problem in one issue.

[youknowriad]

After reading the issues, I think #13663 goes into more details about the problem and the proposed solutions. I'm proposing that we consolidate there. If there's anything missing from this issue that should be reflected there please add it.

Thanks.

[afercia]

Fair enough. I'm fine with keeping this closed for now with the note that:

• Support Navigation and Edit Mode #16500 still needs extensive testing and complete feedback
• 2 of the 3 issues reported here aren't solved yet