Skip to content
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

Keyboard navigation from blocks to the sidebar and back to blocks #1182

Closed
afercia opened this issue Jun 15, 2017 · 17 comments
Closed

Keyboard navigation from blocks to the sidebar and back to blocks #1182

afercia opened this issue Jun 15, 2017 · 17 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).

Comments

@afercia
Copy link
Contributor

afercia commented Jun 15, 2017

During WCEU 2017 contributors day, at the accessibility table we've discussed how to improve keyboard navigation from the post blocks to the sidebar and back to the content, and tried to lay down some ideas.

The Gutenberg sidebar content changes depending on the content block that's currently focused. Initially, the sidebar displays some general Post Settings (they're basically the current meta boxes):

screen shot 2017-06-15 at 11 38 45

Then, for example when an image block is focused, the content sidebar changes and displays some contextual information or controls. In the image block case, it displays the field to enter the image alt attribute:

screen shot 2017-06-15 at 11 38 53

When using a keyboard, navigating from the content (the image block) to the sidebar can be challenging, especially when there are a lots of blocks. Ideally, there should be some mechanism to jump from the image block to the sidebar and back to the content. One option could be using "skip links". Skip links are a well established pattern and users are used to them.
When using the keyboard and focusing a block toolbar:

  • focusing the toolbar could reveal an additional "skip link" in the toolbar that points to the sidebar
  • users would be able to use the skip link and jump to the sidebar
  • when they're done in the sidebar, there should be a skip link to go back to the edited block
  • this would require to use some sort of reference to the edited block to build a proper in-page link #some-block-being-edited

As an example, Press This does something similar: in the responsive view the ul/ol buttons are not displayed by default:

screen shot 2017-06-15 at 11 59 28

when focusing the buttons, they show up:

screen shot 2017-06-15 at 11 58 35

@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Jun 15, 2017
@jasmussen
Copy link
Contributor

I chatted about this with Adrian in person, and noted that in an older mock-up, we had a button, "advanced" on the blocks quick toolbar which would open, and/or set focus on the sidebar inspector. He suggested this could help alleviate this issue, especially if combined with a "close advanced block properties" button that lived in the sidebar. I will dig up the mock-up, but I'm in transit. Would this help, you think?

@afercia
Copy link
Contributor Author

afercia commented Jun 26, 2017

Thinking a bit about this, one way to implement a forth-and-back navigation between blocks and the sidebar settings could be:

Blocks have now a "cog" icon to open the sidebar, if it's closed. I wouldn't change this because users might want to open the sidebar just to check its content and not actually move focus to it:

screen shot 2017-06-26 at 15 18 49

After the cog icon, I'd propose to add a hidden control that gets revealed just on focus, and so it's available to keyboard users. This control should work as a sort of "skip link" to move focus to the sidebar. The control should have some visible text. e;g; "Jump to the sidebar". Sorry I'm not able to mockup this, hope the idea is clear enough.

screen shot 2017-06-26 at 15 20 18

Once users are done in the sidebar, one more "Skip link" or button, that gets revealed just on focus, could be used to allow users to jump back to the edited block:

screen shot 2017-06-26 at 15 20 33

@afercia
Copy link
Contributor Author

afercia commented Jun 26, 2017

Side note: the aria-label on the cog icon label={ __( 'Show inspector' ) } could be simplified and clarified a bit, as users are not required to know what the "inspector" is.

@joedolson
Copy link
Contributor

While I was experimenting with Gutenberg, I couldn't figure out what 'Show Inspector' did. I think that's because in the current plug-in version it doesn't seem to do anything, but the title certainly didn't give me an idea of what it might mean.

@jasmussen
Copy link
Contributor

While I was experimenting with Gutenberg, I couldn't figure out what 'Show Inspector' did. I think that's because in the current plug-in version it doesn't seem to do anything, but the title certainly didn't give me an idea of what it might mean.

We are thinking about evolving the inspector these days, to make some of these aspects more clear. This ticket by Andrea is part of that.

But at the very least, clicking the "Show Inspector" button if the sidebar is already open, it should set focus on an element inside it.

@afercia
Copy link
Contributor Author

afercia commented Jun 28, 2017

Maybe a more meaningful label could help 🙁 As a user, Show Inspector doesn't help me so much because I really don't know what the "inspector" is. I know there's a sidebar with settings though.

@jasmussen
Copy link
Contributor

One of the ideas that I've been thinking about in the past few days is resurrecting the ticket that @GaryJones opened, #1356, and simply calling the sidebar "Settings". There would then be a tabbed interface inside the sidebar. One tab with "Post Settings", and one tab with "Block Settings". You could then choose whether you wanted to see one or the other. The cog label in such a world would be called "Block Settings", and switch to the appropriate tab when clicked.

@afercia
Copy link
Contributor Author

afercia commented Jun 28, 2017

and simply calling the sidebar "Settings"

I tend to agree 🙂 then I'd suggest to change also the "Post settings" button to just "Settings" and any other occurrences, if any.

  • the button will take less space, helping a bit on mobile
  • no need to distinguish post, pages, and CPTs

@jasmussen
Copy link
Contributor

no need to distinguish post, pages, and CPTs

In this idea we'd still have this challenge for the button label on the sidebar tab itself, though, even if not in the editor bar.

@jasmussen
Copy link
Contributor

@afercia can we close this ticket in favor of #2304? Or should we close #2304 in favor of this?

@afercia
Copy link
Contributor Author

afercia commented Aug 19, 2017

@jasmussen not sure moving focus programmatically is the best option, as it usually assumes just one specific workflow. Personally, I'd rather close #2304, see also some of the considerations posted there.

@jasmussen
Copy link
Contributor

Thanks for the info, sounds good to me.

Question: if the sidebar is closed, can clicking the cog _both open the sidebar on the block tab, and act as a skip link at the same time? If yes, then the end result would be the same, no? I'm only trying to clarify what needs to technically happen in order to address this in the best possible way.

@afercia
Copy link
Contributor Author

afercia commented Nov 6, 2017

The introduction of ARIA landmarks and the Ctrl+backtick shortcut mitigated a bit this issue, making easier to jump from a block (in navigation mode) to the sidebar.

Still to evaluate a better way to move back from the sidebar to the edited block.

See also: User testing - Block settings hard to find #3340

@afercia
Copy link
Contributor Author

afercia commented Apr 12, 2018

See #6144 and #5856 that offer users more tools to "jump" from blocks to the sidebar and vice-versa. To evaluate: do we need more "skip links"?

@afercia
Copy link
Contributor Author

afercia commented Apr 16, 2018

#6144 and #5856 are merged so what is left to do for this issue is:

@afercia afercia removed their assignment Jul 2, 2018
@afercia
Copy link
Contributor Author

afercia commented Jul 2, 2018

#3218 is going to be addressed using the F6 key, so I'm going to close this.

@afercia afercia closed this as completed Jul 2, 2018
@afercia
Copy link
Contributor Author

afercia commented Oct 26, 2018

For reference, #3218 is still open and not addressed yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes).
Projects
None yet
Development

No branches or pull requests

3 participants