-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Find a better place for the "Manage All Reusable Blocks" link #13390
Comments
This seems like the best option to me. This could also solve discoverability issues, as noted in #13519. |
This issue is even more important now that the menu has seen some significant improvements in #14843. The whole menu now works as expected: arrows navigation goes through all the menu items, the menu and its items behave as expected... with the exception of the "Manage All Reusable Blocks" link. This is a link and it's now announced as a menu item (the actual announcement varies depending on the browser / screen reader combo): This way, users have no clue activating this menu item will trigger navigation to another page, they have no idea it's actually a link. I'd tend to think that also for users who don't use assistive technologies the navigation to a different page is unexpected. /Cc @gziolo |
diff --git a/packages/components/src/menu-item/index.js b/packages/components/src/menu-item/index.js
index de5429ddf..268cfce75 100644
--- a/packages/components/src/menu-item/index.js
+++ b/packages/components/src/menu-item/index.js
@@ -28,7 +28,7 @@ export function MenuItem( {
icon,
shortcut,
isSelected,
- role = 'menuitem',
+ role,
...props
} ) {
className = classnames( 'components-menu-item__button', className, {
@@ -67,7 +67,7 @@ export function MenuItem( {
{
// Make sure aria-checked matches spec https://www.w3.org/TR/wai-aria-1.1/#aria-checked
'aria-checked': ( role === 'menuitemcheckbox' || role === 'menuitemradio' ) ? isSelected : undefined,
- role,
+ role: role || props.href ? role : 'menuitem',
className,
...props,
},
diff --git a/packages/edit-post/src/plugins/index.js b/packages/edit-post/src/plugins/index.js
index bae6f0811..27eb91b47 100644
--- a/packages/edit-post/src/plugins/index.js
+++ b/packages/edit-post/src/plugins/index.js
@@ -23,7 +23,6 @@ registerPlugin( 'edit-post', {
<>
<ManageBlocksMenuItem onSelect={ onClose } />
<MenuItem
- role="menuitem"
href={ addQueryArgs( 'edit.php', { post_type: 'wp_block' } ) }
>
{ __( 'Manage All Reusable Blocks' ) } Would it solve the issue for More Menu? I see the following: I can use only @mapk - do you have some thoughts on whether we could move this link somewhere else. According to specs |
Well, actually on the ARIA authoring practices there's an example of ARIA menu with I think it could also be solved by changing the text "Manage All Reusable Blocks" to make clear it goes to another page. However, I'd prefer this link to be moved somewhere else. |
There are only two items in that menu that include verbs; "Copy all content" and "Manage all reusable blocks". The Copy option keeps the user on the same page and provides immediate feedback. It does seem confusing that the "Manage all reusable blocks" item navigates the user to another page entirely. I understand the importance of surfacing reusable block editing, but now that we have a Block Manager, I feel that ALL blocks should be listed there, even reusable blocks. Right now they are not. I'm in favor of a solution that:
Example |
I like this proposal. I imagined myself something similar 👍 |
Thanks @mapk, grouping anything related to blocks management in one place makes sense to me. The "Edit blocks" link that looks like a link helps as well. Language related question: I'm not a native English speaker so I definitely may be wrong but shouldn't "Block Manager" be "Blocks Manager" ? |
Agree with moving the link to the Block Manager. Also worth noting is @melchoyce's proposal to introduce a Block > Manage section into WP Admin. |
Let's just add a tab into the Block Inserter next to the Patterns tab. Having a way to preview reusable blocks similar to patterns. |
We're currently looking to add tabs for Blocks and Patterns in the Inserter right now. We may possibly add Template-parts there too, so the Inserter may get too overwhelming with a resuable blocks tab. |
Still, I don't think reusable blocks belong in the same section as regular blocks. In fact, I'd consider them to be closer to patterns or template parts in some ways. They should be shown with a preview rather than an icon, just like patterns. I think the best place for a "Manage Reusable Blocks" link is just somewhere in the WP admin navigation menu, next to wherever full site editing will go. Reusable blocks are just another post type after all. Why do we hide the interface for managing them? |
Is this issue still in valid? |
+1 to this. I am not 100% sure what the ideal location would be, but it should be listed somewhere on the main admin navigation to improve discoverability. |
+1 It's very weird that there's no way to access reusable blocks from main menu, this is the obvious and expected way from an user perspective. |
It'd be great to access these from main admin rather than opening up a post to get the menu link to get to the lost post blocks. Would it be possible to have something like this under the Gutenberg plugin's menu list? along with the ability to see the templates, blocks and patterns for Classic theme users this way too? |
Coming back to this WAY later :D and I'm wondering if we should close this out or update it because, as of WordPress 6.6, there's a dedicated section for synced patterns in Patterns for both classic themes and block themes (classic themes have a "Patterns" section under Appearance and block themes show "Patterns" as a top level item). This "manage all reusable blocks" has now become "Manage patterns". How is this announced now though? Is there more we can do there to keep this issue actionable? |
I'd close this, @annezazu. |
In the top bar "more" menu, "Manage All Reusable Blocks" is a link and triggers navigation to
wp-admin/edit.php?post_type=wp_block
:However, it's placed within an ARIA
menu
and has a role ofmenuitem
. This way, it's announced by assistive technologies as a menu item. There's nothing to inform users it's a link and that activating it will trigger navigation to a new page. In short, the current interaction is completely unexpected.I'd say that also visually there's nothing that communicates to users this is a link. The navigation to a new page may be completely unexpected for non screen reader users too.
Using an
<a>
element is correct, but this link can't be placed within a role=menu. This is a good example where design needs to take semantics and expected interaction into consideration. The whole menu is made of menu items for actions and that's the convention communicated to users. A link feels out of place.Worth noting that in the inserter, this link is actually communicated as a link because the native semantics is preserved:
ARIA roles and attributes communicate semantics and also expected interaction. It would be great to enforce via code that components using role=menu can't contain links.
Regarding the specific case of the "Manage All Reusable Blocks" link, it should be removed from the more menu entirely.
I seem to recall there was some previous conversation about the discoverability of this link. As it's a link that points to a default WordPress admin page that displays a specific post type, one option could be considering to place it in the WordPress admin menu on the left.
The text was updated successfully, but these errors were encountered: