-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Fix labeling of the navigation links in the list view. #59370
Fix labeling of the navigation links in the list view. #59370
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Size Change: -46 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, @andrewserong. |
Thanks @alexstine for your review. To recap the main change in this PR, the logic to determine the list view items accessible name changes from this:
to this:
This is to take into account navigation links because the links text is stored in their |
Noting that the labeling will need further improvements for the 'locked' information, the 'sticky' information and 'anchor' information that are visually added to the items in the list view, see #59409 |
I decided to change approach. As such I decided to remove the aria-label. The accessible name will now be the visible text. This has a few advantages:
|
@afercia Yeah, I've been wanting to do that for a while now but never got around to refactoring all of that out of the aria-label. Thanks, having another pass on this soon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is testing well.
Latest commit improves things a bit by providing the 'Untitled' fallback only for block labels (e.g. navigation links with a link text made of only spaces) and by adding a test. A separate issue is whether the editor should ever allow to render empty links on the front end, which is tracked in a separate issue at #59560 |
Flaky tests detected in b0ff43e. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/8185862794
|
It is also worth noting that right now on trunk it is possible to add a Heading block and leave it empty or with only spaces. The current code on trunk prioritizes a block |
I'm probably missing something, as the failing tests show. I'll go again through my changes to see what I'm doing wrong. |
cf3e968
to
24776bf
Compare
To clarify: I'd appreciate more thoughts on this though Cc @getdave Open to consideer a different fallback if that's more desirable. |
Thanks @Mamaduka I will rebase. It seems #59827 doesn't take into account the case when a heading contains only spaces though so I hink a In this case, also the |
Good point. I can follow up on that! Update: Though historically, the RichText only checked emptiness based on the string length. See: https://github.com/WordPress/gutenberg/blob/trunk/packages/rich-text/src/is-empty.js Do we still want to account for spaces? |
Ideally we'd wrap this bug up in a single PR @Mamaduka as it will be easier to manage from a release perspective. Is that possible? |
@getdave, do you mean to push fixes on this branch? |
// Users can enter and save a label made of only spaces e.g. for | ||
// navigation links. In that case we provide a fallback label. | ||
// We do want to trim leading and trailing spaces anyways. | ||
const trimmedLabel = label.trim(); | ||
return trimmedLabel === '' ? __( 'Untitled' ) : trimmedLabel; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be handled in getBlockLabel
, which should return a fallback (block title) when only spaces are provided.
Then, we don't need to handle this case by case.
I just saw this comment. Changes in this hook will affect every block in the editor. While the argument makes sense for Heading and Navigation links, it might not work for other blocks like Template Part.
Sorry for adding confusion. I'm not personally intending to be pushing fixes to this branch. I meant, if this is targeting 6.5 it'd probably be easier for all fixes to be in a single PR. But if the followups are minor then maybe we should ship this one "as is" and then decide on whether it would be more appropriate to wait on the followups until a post-6.5 patch release? |
@getdave, unfortunately, I've not been following PR closely enough to propose the milestone. But I can see that PR introduces a new string that can't be merged after hard string free — RC1. |
24776bf
to
13b0fe7
Compare
In the latest two commits:
Overall, I think a decision should be made first: whether to allow users to save empty headings or empty links. This should be evaluated for other blocks as well but it's very impportant for headings and links. Update: |
I think this will need a careful evaluation on what it's best for users. It really depends on the kind of content (the block type). It doesn't only impact the admin, it impacts also the front end. For example:
@getdave @Mamaduka thanks for your feednack, when you have a chance I'd appreciate a final review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, @afercia. The changes test well for me ✅
@@ -405,7 +396,7 @@ function ListViewBlock( { | |||
clientIds={ dropdownClientIds } | |||
block={ block } | |||
icon={ moreVertical } | |||
label={ settingsAriaLabel } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had previously inquired about simplifying the "Options for %s" label, but was informed the block name was necessary by @alexstine. Is that no longer the case?
Either way though, this should be renamed "Options", like it's called in the block toolbar (as they're the same).
@afercia @Mamaduka Was there a reason to change "Options" to "Actions"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@richtabor I guess it was a battle I was going to lose eventually. It was really a stopgap to make NVDA behave as sometimes navigating the rows on the right side would not tell you which block you were opening an options menu for.
* Fix labeling of the navigation links in the site editor list view. * Adjust tests. * Simplify labeling by removing aria-label and using text content. * Improve logic and add test. * Adjust test. * Adjust block renaming test. * Adjust list view test. * Revert changes to useBlockDisplayTitle. * Make heading with only spaces be considered empty. Co-authored-by: afercia <[email protected]> Co-authored-by: alexstine <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: youknowriad <[email protected]>
Fixes #59369
What?
In the Site Editor > Design > Navigation > Any navigation menu, the labeling of the list view doesn't provide any informatiom about what the item is. The only information provided is the link type.
Why?
To be able to understand what they are going to edit, users need to know what the link actually is, ie. the link text.
How?
Testing Instructions
Block 3 of 5, Level 1.
.Observe in the editor navigation panel list view the empty link has now a label 'Untitled'.Block 3 of 5, Level 1. This block is locked.
Testing Instructions for Keyboard
Screenshots or screencast