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

Improve keyboard navigation between the block inspector and the block content #13663

Open
jasmussen opened this Issue Feb 5, 2019 · 20 comments

Comments

Projects
10 participants
@jasmussen
Copy link
Contributor

jasmussen commented Feb 5, 2019

A key point of accessibility feedback centers around difficulty of navigating from the block to the inspector sidebar and back again.

Let's discuss how we can improve that.

Bring the cog to the toolbar

A small first step could be to bring the "settings cog" to the block toolbar. Right now you have to click the ellipsis button and show "Hide Block Settings", which doesn't really do anything other than untoggle the sidebar if visible.

x4ru3mtbqt

If we brought the cog to the block toolbar, this would surface it more visibly as a block option. This button would move focus to the block sidebar, with a visible focus outline, like when you switch regions.

Make it modal, but pinnable

With a cog button in the block toolbar to set focus in the sidebar, the next step to explore might be to make the sidebar behave like a modal. It could work like this:

  • The sidebar is off by default.
  • When you press the cog button, the sidebar opens in a modal behavior. The means it has a drop shadow, and when you click outside or press Escape, it closes and sets focus back on the block you invoked it from.
  • You'd still be able to see the main content in context, despite the behavior being modal.

This would be the default behavior. Google Calendar does something like this:

fyqkas1ffc

We could then add the little "Pin sidebar" button to the main Settings sidebar as well — plugins have these. This would effectively change the behavior back to what we have today. Microsoft Edge does this:

mcdcfat7gj

In this default configuration, you would not have to know keyboard shortcuts other than tab and space to navigate from the block to the inspector sidebar and back again.

Please share your thoughts.

@mapk

This comment has been minimized.

Copy link
Contributor

mapk commented Feb 5, 2019

@LukePettway It would be great to get your thoughts around this!

@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

ZebulanStanphill commented Feb 5, 2019

I really like both of these ideas.

The pinnable modal idea reminds a bit of Divi Builder:
divi-builder-module-settings-modal-demo

Beaver Builder also has functionality similar to this.

@melchoyce

This comment has been minimized.

Copy link
Contributor

melchoyce commented Feb 5, 2019

How's the keyboard navigation in Divi and Beaver Builder? Anything we can learn?

@LukePettway

This comment has been minimized.

Copy link
Contributor

LukePettway commented Feb 5, 2019

Bring the cog to the toolbar

I think this was initially one of the methods that was discussed by a few accessibility team members. I'm not sure if hiding was exactly what he had discussed but I do like the idea of having a way to send the focus over the the inspector sidebar.

It does feel like this could be a little confusing for those using assistive technology because the option is being hidden away in the menu. Is there a way we could have the control that sends the users focus to the inspector visible at all times?

I'd be interested to see user testing data which concludes how often users switch between blocks and the inspector, but at least from my personal experience I found myself doing it quite a bit. This is especially the case when using blocks like Archive and Categories where you might want to change the type of output.

Make it modal, but pinnable

This method seems to work pretty well. Since you are setting the focus to the inspector, it makes it really easy to go from editing a block, to change the settings, and then (hopefully) would jump you back either by pressing escape, or clicking a close button of some kind. I also like the idea of that being an extra control in the block control bar as opposed to hidden in another menu.

One thing I would be mindful of is that at least in the Calendar example, it is a bit jarring on larger displays to have the modal appear so far away from the control that was interacted with. Obviously that would impact users who are able to see more so than those using assistive technology. I'm assuming in this case though the inspect is still in the sidebar position, but acts more like a model which I think mitigates that as a problem.

I agree with @melchoyce , I would love to see how those editors handle user focus. Especially on something that can be dragged arrow. Do the arrow keys allow someone to move the modal as well?

@ZebulanStanphill

This comment has been minimized.

Copy link
Contributor

ZebulanStanphill commented Feb 5, 2019

@melchoyce

How's the keyboard navigation in Divi and Beaver Builder? Anything we can learn?

Sadly, Divi Builder has almost negative accessibility. As far as I can tell, it is impossible to navigate through the UI with a keyboard, and even within the modals there is little to no focus styling.

It does have a nice HUD (accessed with Ctrl+Shift+Space) to jump somewhere or perform actions quickly, though. I think it would be cool if Gutenberg had something like that.
image

EDIT: Upon further inspection, I'd like to revise my statement about Divi Builder being impossible to use without a mouse. The "go to" feature of the HUD can be used to jump to the settings of any section, row, or module, so technically you can navigate the builder with a keyboard. It's still far from ideal, though.
image

Beaver Builder is also unfortunately impossible to use without a mouse.

Also, just so everyone knows, both Divi and Beaver Builder have live demos you can use to see how they work.

Additionally, Elementor and Brizy have free versions available in the WordPress plugin repository if anyone wants to try them out.

@LukePettway

It does feel like this could be a little confusing for those using assistive technology because the option is being hidden away in the menu. Is there a way we could have the control that sends the users focus to the inspector visible at all times?

I assumed that @jasmussen was suggesting that the jump-to-inspector link would be in the toolbar, not hidden in the ellipsis menu. Is that not the case? I would certainly prefer if the link was in the top level of the toolbar.

I'd be interested to see user testing data which concludes how often users switch between blocks and the inspector, but at least from my personal experience I found myself doing it quite a bit. This is especially the case when using blocks like Archive and Categories where you might want to change the type of output.

If settings in the Archives and Categories blocks are being used very frequently, then that may be a sign that they do not belong in the inspector, but rather inline in the edit/selected form of the block or the toolbar. The inspector is for secondary controls.

I'm assuming in this case though the inspect is still in the sidebar position, but acts more like a model which I think mitigates that as a problem.

That was my assumption as well. (The ability to move the modal around like in Divi or Beaver Builder would be a nice bonus, though.)

@melchoyce

This comment has been minimized.

Copy link
Contributor

melchoyce commented Feb 6, 2019

It does have a nice HUD (accessed with Ctrl+Shift+Space) to jump somewhere or perform actions quickly, though. I think it would be cool if Gutenberg had something like that.

Nice — I saw Facebook has something like that, too:

screen shot 2019-02-05 at 7 23 48 pm

screen shot 2019-02-05 at 7 23 57 pm

screen shot 2019-02-05 at 7 24 05 pm

It appears when you use alt + /.

@jasmussen

This comment has been minimized.

Copy link
Contributor Author

jasmussen commented Feb 6, 2019

I think this was initially one of the methods that was discussed by a few accessibility team members. I'm not sure if hiding was exactly what he had discussed but I do like the idea of having a way to send the focus over the the inspector sidebar.

Just in case there was any misunderstanding, I was suggesting we change it to this:

screenshot 2019-02-06 at 11 34 06

This button would open the sidebar and set focus there. Escape would return you, and in step 2, close the sidebar unless pinned. We could use this effect, potentially, to indicate where focus was — though I believe going straight to the modal implementation might be the best approach, not sure it can be split in two.

@LukePettway

This comment has been minimized.

Copy link
Contributor

LukePettway commented Feb 6, 2019

@jasmussen yes that clears it up! I also like the extra emphasis when the focus shifts as well.

@ZebulanStanphill That's a good point. My example is a bit anecdotal since I was working on some functionality for those two blocks. Though I'd still love to know what usage in the wild is like for blocks. Testing assumptions of how frequently users switch back and forth could help improve future blocks as they are developed.

@alexislloyd

This comment has been minimized.

Copy link
Contributor

alexislloyd commented Feb 6, 2019

I love bringing the settings icon to the toolbar, I think that will greatly improve usability. I'm a little unclear on the modal behavior. How would changing settings to a modal improve a11y? My concern about the modal is that I've seen a number of users who like to leave the sidebar shown and if it's modal, that would add another step for them to open it, then pin it. But I'm not sure if I'm understanding the suggestion clearly :)

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Feb 6, 2019

What if the cog would remain in the more menu since you can always find it also in the header next to pinned plugins when using mouse. Instead we could add this cog but show it only for those who navigate with tab (similar concept to skip links).

@jasmussen

This comment has been minimized.

Copy link
Contributor Author

jasmussen commented Feb 7, 2019

I'm a little unclear on the modal behavior. How would changing settings to a modal improve a11y? My concern about the modal is that I've seen a number of users who like to leave the sidebar shown and if it's modal, that would add another step for them to open it, then pin it. But I'm not sure if I'm understanding the suggestion clearly :)

It sounds like you got it right. For a feel for it, try the Google Photos web-app, and open the sidebar on the left. You can close it by clicking outside, or press Escape. Here's a GIF:

modal sidebar

This behavior, combined with the ability to pin the sidebar — agree that's additional complexity — may not be the perfect solution for us, but it seemed worth bringing up as an option.

The use case is to allow someone with no knowledge of Gutenberg-specific keyboard shortcuts to:

  • write a paragraph
  • navigate to block settings to add a dropcap
  • navigate back to the paragraph block to continue writing

using only the keyboard, ideally in as simple a manner as possible.

We have a region hopping shortcut (Ctrl+[the button below escape] similar to Slack), but it is not very discoverable. Skip-links, modal-ish behavior, surfacing keyboard shortcuts visibly as suggested in #13688 might be other options to explore to improve this.

In a modal behavior, someone would:

  • press shift tab to enter the block toolbar
  • tab to the cog, press space
  • the sidebar would open as a modal with a shadow
  • press tab to move focus to the drop cap, press space to activate
  • press Escape to exit the modal, and focus would be back in the block

Is there a half-way point we could explore, where the sidebar would behave in a "modal-ish" way — like the above, but without necessarily being dismissed when the user presses Escape?

@samikeijonen

This comment has been minimized.

Copy link
Contributor

samikeijonen commented Feb 7, 2019

Good discussion!

In the modal-ish sidebar we could have the markup right after the button that triggers it?

@jasmussen

This comment has been minimized.

Copy link
Contributor Author

jasmussen commented Feb 8, 2019

@samikeijonen Not sure we can answer that yet, though probably something to figure out as we get closer to some consensus on this. Question, though — could the sidebar change role to become a dialog, instead of a region? In discussing modal behavior, it seems prudent to at least consider that. What would be the pros/cons/gotchas of such a change?

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Feb 8, 2019

Just noting that this sidebar on small screens looks almost like modal:

screen shot 2019-02-08 at 12 32 59

However, you can't use esc to close it and so on.

@cburton4

This comment has been minimized.

Copy link
Contributor

cburton4 commented Feb 8, 2019

I also love bringing the settings icon to the toolbar!

I believe the pattern that @jasmussen referenced from Google Photos is what they would call a navigation drawer. The main differences being:

  • A navigation drawer with elevation like the example @jasmussen shared usually has a scrim (a dark transparent background that helps focus the user’s attention) that blocks interaction with the rest of the screen’s content.
  • And a standard navigation drawer is usually coplanar (has no elevation) but allows interaction with both screen content and the drawer at the same time.

A standard coplanar navigation drawer would allow for open and close functionality by clicking on the cog in the toolbar, not by clicking outside of the drawer, eliminating the need for an extra pinning action from the user.

nav-drawer-scrim

mio-design_assets_1f9ipky_-qjzpvcklsgmtk11efxzwnxro_standard-usage

@LukePettway

This comment has been minimized.

Copy link
Contributor

LukePettway commented Feb 8, 2019

I like where this is going and I didn't know it was called a scrim! I think this will make it more apparent to users what is going on when they interact with the cog button. Plus I believe it will also make focus trapping into that area a bit easier and more obvious.

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Feb 9, 2019

Noting that there's already #11581 to discuss this issue. Important considerations were made there. Not sure about the best way to coordinate between the two open issues.

This button would move focus to the block sidebar

As mentioned in #11581 (comment) this would be unexpected. Managing focus should only be done to "repair" a focus loss, not to anticipate how users want to use applications: that would be an assumption on a specific user flow.

It might work if the sidebar had a modal bheavior (which doesn't necessarily mean ths sidebar should have a modal look). However, would this mean the sidebar is closed by default unless pinned? I'd share the concern expressed by @alexislloyd as many users like to leave the sidebar shown.

What is good in the modal behavior is that the rest of the interface becomes "inert": tabbing is constrained within the modal and the rest of the interface is not perceived by assistive technologies (the whole #wpwrap gets an aria-hidden="true"). I'm not 100% sure this interaction model is ideal for this case, but it's definitely something worth exploring. As @LukePettway mentioned, user testing data could help. Also, feedback and testing from users with accessibility needs.

In this default configuration, you would not have to know keyboard shortcuts other than tab and space to navigate from the block to the inspector sidebar

Worth reminding that, when tabbing from a selected block to the following block, the following one becomes selected: at this point the inspector content changes and even if users are able to tab to the inspector, what they will find there is the group of settings for the last block in the post.

Worth also reminding the exploration made in #5709 (navigation/edit mode).

@melchoyce

This comment has been minimized.

Copy link
Contributor

melchoyce commented Feb 13, 2019

Nifty keyboard shortcut example from Slack:

https://twitter.com/amber1ey/status/1095715310806683648

(h/t @ryelle)

@afercia

This comment has been minimized.

Copy link
Contributor

afercia commented Feb 13, 2019

There's already a keyboard shortcut to jump through the main regions. The whole point is keyboard shortcuts are not sufficient 🙂A good interface shouldn't rely only on keyboard shortcuts for keyboard users. Keyboard shortcuts have their own problems as mentioned in the accessibility team report.

I'd also quote a previous comment on the Widgets page issue:

There are no tricks, no special keyboard shortcuts or other tools that can replace a good document structure and information architecture.

Still waiting for a decision on this issue, as it's basically a duplicate of #11581 and the discussion should happen there. /Cc @jasmussen

@mapk

This comment has been minimized.

Copy link
Contributor

mapk commented Feb 13, 2019

While I understand this issue does duplicate a part of #11581 – in fact, the previous issue does seem to taper off into this exact topic – I don't want to lose the research that's been added here. Does this sound fair?

Right now, I really like the cog icon in the block toolbar, but I completely get that a user may not want to change focus to the Inspector when clicking it. @timwright12 was going to prototype an idea on the other issue, so pinging them to see if there's been any progress with that.

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