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

"Slash menu": improve instructions and feedback #5592

Closed
afercia opened this issue Mar 13, 2018 · 5 comments · Fixed by #51018
Closed

"Slash menu": improve instructions and feedback #5592

afercia opened this issue Mar 13, 2018 · 5 comments · Fixed by #51018
Assignees
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Dev Ready for, and needs developer efforts [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended

Comments

@afercia
Copy link
Contributor

afercia commented Mar 13, 2018

Follow up to #5591 to address the second part of the feedback we're getting from assistive technologies users. For full details, please refer to #5591.

Screen reader users are able to use the slash menu. However, only 10 block types are displayed by default and there are no instructions that typing actually filters the list and makes new results appear in the menu.

In the test session reported on #5591 the user had a simple task: add a table with 2 columns, 2 rows and add some data in the cells

The feedback was:

When I hit slash, table wasn't included in the menu.

I'm wondering if this applies also to sighted users: they can certainly try to type something and they will see the menu changes, but maybe discoverability is not that great.

Unfortunately, the audible message used for screen reader users is always the same for all the auto-completers in Gutenberg. It's always:
nn results found, use up and down arrow keys to navigate.

screenshot 77

In this specific case, screen reader users need some more context and a meaningful message instructing them to type to refine the search results.

Once they start typing, I think the feedback is good enough. The only issue is the initial message and instructions, clearly not sufficient to understand how this feature works.

screenshot 78

Why the initial message "10 results found, use up and down arrow keys to navigate." is confusing?

I guess because users have typed just a slash /. Actually, they haven't typed any search term but they get a message that says 10 results found. Instead, the message should briefly reflect what actually happens in the UI:

  • 10 initial choices are displayed
  • typing something will display other search redsults

To communicate this, there's the need of a different message.

I'd propose to consider a way to make each autocompleter have its own message. One size doesn't fit all. These auto-completers work in different ways and they need to be communicated with different, meaningful messages.

Optionally, it would be great to have 2 different messages based on the user workflow:

  • a message when the menu opens for the first time
  • a different message for the search results
@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Mar 13, 2018
@bemdesign-er
Copy link

bemdesign-er commented Aug 13, 2018

Maybe something like "Triggering block search - 10 blocks currently listed: . Start typing to search for a specific block..."

And then when user pauses in typing: "n blocks found - n1 [name of block], n2 [name of block], n3 [name of block]..." etc.

@nerrad
Copy link
Contributor

nerrad commented Jun 2, 2019

It's been a while since this was first reported. Needs testing to confirm the issue still exists.

@nerrad nerrad added [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. Needs Testing Needs further testing to be confirmed. labels Jun 2, 2019
@afercia afercia added [Type] Bug An existing feature does not function as intended and removed Needs Testing Needs further testing to be confirmed. [Status] Stale Gives the original author opportunity to update before closing. Can be reopened as needed. labels Jun 4, 2019
@afercia
Copy link
Contributor Author

afercia commented Jun 4, 2019

The problem still exists. Going to add the "bug" label, as the lack of proper instructions hinders the ability to use this feature.

@paaljoachim
Copy link
Contributor

@joedolson Could you take a look and see if this issue is still valid?
Thank you!

@gwwar
Copy link
Contributor

gwwar commented Feb 25, 2021

This one came up in #core-editor bug triage. https://wordpress.slack.com/archives/C02QB2JS7/p1614280418266100

I think we're using the default component messaging and we need some specific instructions for the inserter usage. Is anyone interested in taking this?

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). Needs Dev Ready for, and needs developer efforts [Status] In Progress Tracking issues with work in progress [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants