[#45922] - [6.0] Refactor default frontend menu to fix submenu support and improve accessiblity
- Fixed in Code Base
- 16 Aug 2025
- Medium
- Build: 6.0-dev
- # 45922
- Diff
- LadySolveig:6.0/feat/refacto-frontend-menu
User tests: Successful: Unsuccessful:
Pull Request for Issue # .
Summary of Changes
At the moment, the default frontend layout in the menu module is broken an does not show submenu entries at all.
This PR removes opening on hover completely (broken at all) and adds keyboard support as a accessiblity improvement.
Submenu-Items should again be reachable in frontend with the default menu module layout again.
In order to be as accessible as possible, buttons for opening the submenus have been added, and CSS is now included here to minimise the impact on existing pages.
The CSS has been set to specificity 0 with :where(), making it very easy for the user to overwrite.
Keyboard Support
The source as a reference to the keyboard functionality that was implemented here:
https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation-hybrid/#kbd_label
Example Main Navbar
menu.mp4
Example Menu in sidebar
menu2.mp4
Testing Instructions
- Install Blog Sample Data on your test site
- Go to Content --> Site Modules and open the settings for the
Main Menu BlogModule - Go to tab
Advancedchange the settings to---From Module----> `Default
Only testable with patched version - should respekt the End Level setting 4. Change the End Level Setting from Allto25. Change the End Level Setting to1`
6. Test the keyboard support like described above (image, video, link) for the main menu and a sidebar or footer menu.
- Try out different combinations of the Menu Item. Try different menu item type like alias, separator, etc and combinations of icons and image.
Icos and images can be set in the tab `Link Type for the menu item
Actual result BEFORE applying this Pull Request
The submenu items are not reachable and the js for expanding on hover is broken.
Expected result AFTER applying this Pull Request
Submenus can be expanded and operated with keyboard support.
Result for step 4
Result for step 5
Link to documentations
Please select:
-
Documentation link for docs.joomla.org:
-
No documentation changes for docs.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Repository NPM Change JavaScript Language & Strings Modules Front End |
| Labels |
Added:
Language Change
NPM Resource Changed
PR-6.0-dev
|
||
I have tested this item ✅ successfully on d09b8b4
I have tested this successfully. Thanks @LadySolveig
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45922.
Is it intended that the focus style is different when its a button compared to a link
As you can hopefully see the first and last items in this screenshot are links and they have a solid black outline with suitable space between the outline and the text
Whereas the button in the middle has no specific css and is just using the browser default for ::focus-visible which at least in chrome has rounded corners and a border and outline and the text is right against the olutline
This lack of css on the button also gives off center styling for the arrows when they have focus
Before this PR the option to show/hide submenu items was broken and they were always shown
With this PR its also broken but now they are always hidden
the keyboard navigation part seems to work correctly from an a11y perspective
Is this menu shift intended behaviour when you open a submenu
About the layout shift. Ultimately, it was more a question of whether this should really be done via the module's default layout. I think it depends very much on the template, and the layout in terms of CSS should not come directly from the module.
Here you see something I removed again, as I think it is hardly possible to do the right without knowing the template style.
9783f6b
If something like this is put into the user.cssor the template it works without layout shift.
:where(.mod-menu__sub:not(.mod-menu__sub *)) {
background-color: #fff;
display: block;
margin: 0;
min-width: 12rem;
padding: 0;
position: absolute;
top: 100%;
}
works in the header for example and you would not have a layout shift. But as the default layout can used in sidebar and/or footer. We can't do this globally I think.
| Status | Pending | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2025-08-16 17:48:53 |
| Closed_By | ⇒ | softforge |
Thank you @LadySolveig and all the testers, this is an improvement on what was there and a good exploration of what could be done to improve
Before this PR the option to show/hide submenu items was broken and they were always shown
With this PR its also broken but now they are always hidden
Either I'm misunderstanding it or I can't reproduce it.
menu3.mp4
If there is anything I can fix here, please try rephrasing it again. Thank you.
sorry I both phrased it badly and included the wrong screenshot - so not surprised you didnt understand it
I am talking about the vertical menu as shown with the special menu
My expectation was that show/hide really meant expanded/collapsed
So when submenu items are set to show the full expanded menu is displayed
and when submenu items are set to hide then the menu is displayed collapsed with dropdown arrows
But what we have is
when submenu items are set to show the dropdown arrow is displayed
when submenu is set to hide then the entire submenu is not displayed - not even any arrows
Maybe my expectation is wrong
My expectation
Submenu hide
Submenu show
What we have
Submenu hide
Submenu show
Just spotted this
While making these screenshots I just spotted this behaviour with submenu set to hide if you click on the menu item so that menu item is active then the submenu dropdown suddenly appear for that menu
I have tested this item ✅ successfully on d09b8b4
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/45922.