Improve menu parent link selection

Here's a screen shot showing the existing selection plus the proposed change .. as each box is selected, the children are ajax loaded

and a patch off the current git repository.

updating tags
Wonder if there's any chance this can get into D7 too? :)

Drupal 9.4.9 → was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Drupal 9.3.15 → was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Drupal 8 is end-of-life as of November 17, 2021 → . There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule → and the Allowed changes during the Drupal core release cycle → .

Drupal 8.8.7 → was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 → or Drupal 9.0.0 → for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule → and the Allowed changes during the Drupal 8 and 9 release cycles → .

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule → and the Allowed changes during the Drupal 8 and 9 release cycles → .

Drupal 8.5.6 → was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. ( Drupal 8.6.0-rc1 → is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

Drupal 8.4.4 → was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. ( Drupal 8.5.0-alpha1 → is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

Drupal 8.3.6 → was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. ( Drupal 8.4.0-alpha1 → is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

Drupal 8.2.6 → was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. ( Drupal 8.3.0-alpha1 → is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

Drupal 8.1.9 → was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 → is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

Drupal 8.0.6 → was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 → is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule → and the Allowed changes during the Drupal 8 release cycle → .

This still requires an user to know what weight means and essentially guess what weight other items in the menu are in order to fit it in the correct place the first time around.

It would be better to take an approach along the lines of Menu Browser → or Menu Order which get rid of weights entirely and allow users to choose a menu and drag & drop an item either as a child of a page, or above/below a sibling.

Also referencing #1101600: Users need to be able to select from list when adding menu items to a menu → , which is the flipside to this problem from the list links page.

This seems like it would still be useful.

seems to be about what https://www.drupal.org/project/cshs → does.

Next things to work on this is to get some code clean-up and maybe add some tests for this.

Issue summary hasn't been updated in 12 years, so definitely think it should be updated to todays template.

Applying the MR though not seeing any difference when adding a menu link.

Attaching the screenshots demonstrating the new way of selecting the parent list.

smustgrave → credited tim.plunkett → .

Added screenshots from #28 to issue summary.

Moving to NW for threads from tim.plunkett, saving credit for.

Only rebased to see if the pipeline would pass. Had a bunch of errors before but think that was gitlab issue.

Believe this is good, as all threads have least been answered. And confirmed I get the same behavior as the screenshots

I am adding ✨ Make it easier to add a child menu item Fixed as a related issue. It is a complementary solution to the same problem.

The tests that I added in that issue should catch any problems, but it would be reassuring to have someone test manually that the changes here do not affect the default selection we get when using the "add child" link.

I think this issue should also get an accessibility review, just to make sure it works well with keyboard navigation, scree readers, and such. I am adding the tag for that and setting the status back to NR.

Thanks for the attention to the issue summary. That will help in the review process.

Tabbing is fine.

But reading https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Liv... think we may need aria-live for the section that is auto updating.

While testing this issue I still had the changes for 📌 Redesign the menu link add form to be less overwhelming Needs review applied. Turns out both issues are intertwined:

Quickly chatted with @benjifisher in the #accessibility channel where he posted the other issue and we were in agreement that the menu select field should be moved over to the sidebar right above the parent link select field. He recommended to post this comment on both issues and whichever issue is fixed second should adapt for the other.

And two additional observations when the select fields are announced by a screenreader (VoiceOver in my case).

1. The greater and less than announcements are confusing (see less_greater_than.mp4) and since menu and parent link are no single select field anymore < and > are not necessary anymore to visually distinguish menus for sighted users

2. For screenreader users the list is flat and none hierarchical (see flat.mp4). The pause just slightly differs based on the number of dashes.

We should make the same change to the node-edit form. I am not sure whether it makes sense to do that as part of this issue or if it should be a follow-up.

So now the menu select list does not contain the < and > icons as requested in #37.1 📌 Improve menu parent link selection Needs work . Also #37.2 📌 Improve menu parent link selection Needs work can be a follow-up for this issue.

@benjifisher can
#39 📌 Improve menu parent link selection Needs work be done in a follow-up as well?

Posted some feedback on the MR.

From #42:

@benjifisher can #39 be done in a follow-up as well?

Yes. That is what I meant by this: "I am not sure whether it makes sense to do that as part of this issue or if it should be a follow-up."

Not on the accessibility team but still wonder if #36 applies. For the need of an aria-live region.

I've executed MR #47, applied it seamlessly, and rigorously tested it locally. Presently, the interface showcases two distinct dropdowns, each delineating the parent link and menu. I've enclosed a screenshot capturing the changes made after the patch.

Sometime it shows Parent link before Menu, which is not correct. See attached SS.

I have added the weight to the select element.Attaching the screenshot for the same.

Follow-up needs to be created for #37.2 and #39

I have opened a follow-up for #39 in Improve menu parent link selection for node edit form. 📌 Improve menu parent link selection for node edit form. Active

Follow-up created, feedback addressed and changes looks good to me. Marking as RTBC.

Marking as NR for `Needs accessibility review` and `Usability`

Dynamic content which updates without a page reload is generally either a region or a widget. Simple content changes which are not interactive should be marked as live regions. A live region is explicitly denoted using the aria-live attribute.

Using a screen reader (mac's version of one) there is no announcement of the dynamic change to the list.

For the menu link followup I've always used https://www.drupal.org/project/cshs → which has worked well.

Marking as NR for `Needs accessibility review` and `Usability`

The "Usability" tag means that the issue affects usability (and is intended to improve it). There is a separate tag, "Needs usability review", for issues that need review by the Usability team or a topic maintainer. For official descriptions of the issue tags, see Issue tags -- special tags → .

Another reason to set this issue back to NW is that 📌 Redesign the menu link add form to be less overwhelming Needs review was just fixed. We need to update the work here, and we need new "before" and "after" screenshots. I am updating the "Remaining tasks" in the issue summary and adding the tag for an issue summary update.

I have made some changes according to the latest changes in #2519362: Redesign the menu link add form to be less overwhelming. Attaching the screenshots of the initial steps.

Can we get new before and after screenshots in the issue summary now that 📌 Redesign the menu link add form to be less overwhelming Needs review has landed.

Ideally five screenshots:

1. Before: dropdown collapsed
2. Before: dropdown expanded
3. After: both dropdowns collapsed
4. After: menu dropdown expanded
5. After: parent link dropdown expanded

Thanks,
-Aaron

I have added screenshots for both the states for both the forms as requested in #63.Marking it to needs review.

Before and after screenshots are added and the changes looks good to me. But this still needs accessibility review.

I am restoring the "Needs screenshots" issue tag because we still need to update the "Current" (or "before") screenshot now that 📌 Redesign the menu link add form to be less overwhelming Needs review is fixed.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2023-12-15 Needs work . That issue has a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMcHale, @Emma Horrell, @benjifisher, @rkoller, @simohell, and @worldlinemine.

We agreed that this issue is a big improvement. Besides the usability problem of a really long select list, sometimes two parts of the menu tree look similar. For example, the links under "blog" might be similar to the links under "services". In this case, it is easy to move a link to the wrong place. If those similar sections are parts of different menus, then it will be much easier to avoid mistakes with this change.

Another point is that there are two ways to change the parent of a menu link: from the edit page for the link, or from the listing page for the menu. But if you want to move a link to a different menu, it can only be done from the edit page for the link. After this issue, that will be much easier.

There is one change that the Usability group would like to see as part of this issue:

• When the Menu selection changes, move the focus to the Parent link select list.

This should be implemented with a delay, so that it is possible to navigate the Menu select list from the keyboard without constantly moving to the other select list. Or perhaps trigger the change of focus on mouse events but not keyboard events. I expect the Accessibility review will have more specific guidance.

In a separate Slack discussion, we considered whether the Menu and Parent link select lists should be grouped in a <details> element. Opinions were split: some like it the way it is, and others think the two select lists should be grouped for consistency with the other elements in the sidebar. If they are grouped, then the <details> element should be open by default. It looks as though the current MR uses a <div> element to group the two select lists.

Another idea for a follow-up issue: consider changing the Add form to be consistent with the Edit form. Currently, the Add form only shows elements of the selected menu as possible parent links. That was a good idea before this issue, but it is worth reconsidering once this issue is fixed. I think it would simplify the code and make the two forms more consistent if we simply set a default value for the Menu select list.

Another idea came up: out of scope for this issue, but worth considering in a separate one. Just as the node module logs an Info message whenever a node is created, edited, or deleted, we should consider the same sort of logging for menu links. That would make it easier to fix the problem if, despite this issue, an administrator accidentally moves a link to the wrong place.

Yet another idea (also out of scope): add a search function to the "Parent link" select list.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Attached the screenshots of both the form before this patch.

There is one change that the Usability group would like to see as part of this issue:

When the Menu selection changes, move the focus to the Parent link select list.
This should be implemented with a delay, so that it is possible to navigate the Menu select list from the keyboard without constantly moving to the other select list. Or perhaps trigger the change of focus on mouse events but not keyboard events. I expect the Accessibility review will have more specific guidance.

I think this can be done once we get a accessibility review on this.

Another idea for a follow-up issue: consider changing the Add form to be consistent with the Edit form. Currently, the Add form only shows elements of the selected menu as possible parent links. That was a good idea before this issue, but it is worth reconsidering once this issue is fixed. I think it would simplify the code and make the two forms more consistent if we simply set a default value for the Menu select list.

I created a follow-up for this Consider changing the menu-link Add form to be consistent with the Edit form. 📌 Consider changing the menu-link Add form to be consistent with the Edit form. Active

Yet another idea (also out of scope): add a search function to the "Parent link" select list.

I think this would also help us to provide users with a good UX.I created a follow-up for the same in Add search functionality to the "Parent link" select list. ✨ Add search functionality to the "Parent link" select list. Active .

I have created the follow-ups that are or could be a great enhancement in conjunction with this issue and also attached the required SS. Marking it needs review as it still needs reviews of accessibility team so that we have a good understanding of how should be proceed with the remaining tasks.

1. There was a suggestion for "When the Menu selection changes, move the focus to the Parent link select list." - this isn't something I'd approve in my role as accessibility maintainer. The expectation is focus would remain on the control being manipulated. Deviating from this expectation would likely cause more confusion than it would offer any benefits.
2. The now-two select elements should be semantically grouped, you can reference the related elements section of these W3 docs.

The accessibility of the grouping seems to work, but having it in a fieldset is introducing some style problems due to there being fairly opinionated fieldset styles that aren't ideal for this use case (particularly in Claro). Suggestion in MR.

Updated the IS as before screenshots added in #68 📌 Improve menu parent link selection Needs work .

@bnjmnm could you approve that the aria-label in div looks good.

Umm, with umami, when I go to this page after applying the patch: https://drupal.ddev.site/en/admin/structure/menu/link/entity.entity_view... I see that the parent menu is "User account menu" and the parent is the correct "Display mode" from the Administration menu, saving the link doesn't break anything but there is something wrong with the default value for the parent menu.

Ran into the same thing as @nod_ in #81