I have no idea. I haven't been part of any conversation on the topic. I'm guessing if there is no one to implement, it probably is.

So now I am confused because I thought that the only problem with the existing menu was that it didnt support that

When used with the menu bar toggled to collapsed

1. menu icons look very small to me (I am not a designer)
2. menu links that have a submenu do not expand - only the direct menu items eg system
3. when you select an item eg users->groups then on page load the menu is collapsed and there is no indicator what is the active menu item

From an accessibility perspective

1. there needs to be greater background colour contrast between the normal and hover states at the top level
2. there needs to be a background color on the submenu hover state and it looks like there is a subtle text color change on the hover which depending on the background might need tweaking
3. the font icon needs to be aria-hidden
4. the parent items have a role of menuitem which iirc is not correct as they are not active links and should have a role=presentation
5. the parent items should have an aria-haspopup = true

Very nice! But i also feel the lack of "New Item"...
Another consideration on the UX: the switch is too similar to the menu items. It should be smaller or less highlighted.

So now I am confused because I thought that the only problem with the existing menu was that it didn't support that

I honestly can't comment on that.. it wasn't from me you heard it. My reasoning for changing this to an accordion is I find the current menu gimmicky at best. Imo accordions work in almost every instance (device, number of items, expected behavior, expandable, industry standard ... ). It is fair to say we have tried everything else.

menu icons look very small to me (I am not a designer)

Personally, I have always found the icons too big in J4. I'll increase the size slightly although I would like to avoid increasing the height of each menu item. A downside to accordions is the need to scroll on larger menus, increased menu item heights would increase this probability.

menu links that have a submenu do not expand - only the direct menu items eg system

I presume you are referring to when an item is opened? The menu should stay open on the 'current' menu item?

I'll update the PR regarding the accessibility issues presuming I get any indication that this is deemed an improvement and might actually get merged.

Regarding the 'new item' option there is no reason why it can't be added to this menu after. There are both a11y and PHP considerations on how best it should be done. Neither of which are areas I am skilled in.

menu icons look very small to me (I am not a designer)

Personally, I have always found the icons too big in J4. I'll increase the size slightly although I would like to avoid increasing the height of each menu item. A downside to accordions is the need to scroll on larger menus, increased menu item heights would increase this probability.

Point taken about the menu item height

menu links that have a submenu do not expand - only the direct menu items eg system

I presume you are referring to when an item is opened? The menu should stay open on the 'current' menu item?

Sorry something got lost as I was editing the report. There are two different issues

1. The menu should stay open on the 'current' menu item?
2. The menu doesn't expand when collapsed to icon only

Do we really need the option to toggle the menu down to just the icons? It complicates this no end and also bordering on being a bit of a gimmick.

Personally it is essential. For me it was the thing that convinced me a vertical menu was a good choice. In all the time I have been working with J4 I have not had it expanded at all. As for it being a gimmick it is a very common design pattern.

My thoughts are with you Ciaran. Probably the 6th time you've revisited this and it's now back to square 1 :D

Much better using an accordion:

• Easier to maintain
• Less code
• Works flawlessly on all device sizes
• Simple
• No dirty work arounds required when too many items are there
• Easier to make accessible

One thing I will say it just ensure that when you have an expanded menu item, ensure you can still scroll through the menu if there are too many items.

current and toggle now working as expected although I would add some styling to <a active similar to the styling on the active parent

.main-nav>li.active>a {
    background-color: rgba(0,0,0,0.4);
}

there are still a lot of a11y errors

@C-Lodder You have said accordions are the way to go from day one... we should have listened ?

@brianteeman

I have amended the styling per your a11y suggestions.

the font icon needs to be aria-hidden

the parent items have a role of menuitem which iirc is not correct as they are not active links and should have a role=presentation

the parent items should have an aria-haspopup = true

The above I am not really sure where/how to change. Could you possibly create issues and hopefully someone with the smarts can fix them. The issues are present regardless of this PR.

thanks for the styling changes they are good.

looking at the a11y stuff now

AFAICT the a11y changes can be made in a separate pr

the only bit that would be better to be done in this pr is

It should be possible to change this to regular css with list-style=circle - otherwise the screenreader announces "white circle" menu name

That was actually how this PR was initially. The issue is was when we start adding a background hover color to the 2nd and 3rd level menu items, using list-style gets difficult. There are workarounds but they come with other side effects (eg. only the text is clickable, not the whole list item).

Is there an alternative a11y solution to using the background to highlight hover?

If not we could just add HTML for the font awesome icon rather than adding it with CSS.

If not we could just add HTML for the font awesome icon rather than adding it with CSS.

You can either change it to an html span for the icon with aria-hidden=true
OR use the background technique described here by @C-Lodder
joomla-projects/custom-elements#99 (comment)

I'll try background technique using data uri

surprised hound didnt pick up on the invalid style - but when that is fixed then it should be all ok for me and as you said we can then fix all the a11y markup issues in another pr

I have tested this item ✅ successfully on b9c3e05

Works as intended and a11y can be addressed in a new pr

I have tested this item ✅ successfully on b9c3e05

Works as intended and a11y can be addressed in a new pr

Menus:
We do not have direct access to Manage Menus, only through Add New Menu and then close.

I guess we should modify joomla.xml and modern.xml with something like

	<menuitem
			title="MOD_MENU_MENUS"
			type="heading"
			class="class:list"
	>
		<menuitem
				title="MOD_MENU_MENU_MANAGER"
				type="component"
				element="com_menus"
				link="index.php?option=com_menus"
				>
			<menuitem
				title="MOD_MENU_MENU_MANAGER_MANAGE"
				type="component"
				element="com_menus"
				link="index.php?option=com_menus&amp;view=menus"
			/>
			<menuitem
				title="MOD_MENU_MENU_MANAGER_NEW_MENU"
				type="component"
				element="com_menus"
				link="index.php?option=com_menus&amp;view=menu&amp;layout=edit"
				scope="edit"
			/>
		</menuitem>
		<menuitem
				type="separator"
		/>

and new string
`MOD_MENU_MENU_MANAGER_MANAGE="Manage Menus"

but we have the same issue when we want to display the specific menu items directly from a menu
One has to go first to Add new menu item and then close, or choose All menu items and filter again there.

Not really user friendly.
Only way I see is to add a supplementary <menuitem> [...] /> as done above.

Good spot. However the problem is that for some reason the "menus" is not using the same "add new" as the rest of joomla. For now I would recommend removing the add new menu links here so that they can be handled exactly the same as add new article - which has not been done yet. This way all the add new will be able to be created and styled exactly the same way

So for now, remove Add New Menu and link Manage to menu manager?

Looking back at the initial talks we had about the sidebar with the UX team (pardon my language), we decided to remove all the "add new" items as we wanted to reduce the number of nested dropdowns within the accordion.

We were going to compromise with alternative quick links which may already exist now.

Not sure what plans are for this but maybe just remember that the nesting was a PITA

Makes good sense. I'll remove the "add new" item from here. Further down the line, someone might be willing and able to add the alternative quick links.

I have removed the 'Add New Menu' so 'Manage' now links to the menu manager. Not sure if the 'Manage' string should be changed.

Don't worry about the strings for now. They all need review/change to satisfy a111y as there should not be multiple links on a page with the same name

Note to self of fixes and a11y things to change if this is accepted (I hope it is)

• Set correct aria roles etc
• ensure unique names for links
• "add new" links
• check conditional menu items

Can you fix conflicts please?

I have tested this item ✅ successfully on 8480c94

@wilsonge it would be good to get this merged so that I can submit the pr to fix the a11y. The old menu must have rewritten lots of markup with js etc (or it was just completely broken for a11y). I suspect it might take a few iterations to get it perfect

Better to wait till @ciar4n cleaned up the pr and fixed the conflict. But in generall I agree as it actually makes joomla usable when working with extensions.

Thx @laoneo. Conflicts and mentioned issues fixed.

Right... think i've successfully screwed this branch up :/

I have tested this item ✅ successfully on c053ed5

The only issue I found was that when clicking on a component subitem, it doesn't expand to it on a page reload. But this can be fixed then in a followup pr.

I have tested this item ✅ successfully on c053ed5

The only issue I found was that when clicking on a component subitem, it doesn't expand to it on a page reload. But this can be fixed then in a followup pr.

Second levels will now open if active

I have tested this item ✅ successfully on d69c02c

I have tested this item ✅ successfully on d69c02c

LGTM lets merge and then I can fix the a11y

small css change required https://github.com/joomla/joomla-cms/pull/22587/files#r225589673

ah - ok - missed that. The issue I wanted to resolve was the circle bullet. You successfully used a background image but the list-style is still there

You can ignore that. Chrome lists default values set by the browser as 'user'. That CSS is not in the template.

ok - maybe it is something else causing the error I am hearing with a11y - I will look into that when I do the a11y pr

Is the screenreader reading something it shouldnt?

yes - it is saying white bullet

I have tested this item ✅ successfully on d69c02c

PR ready to submit to address accessibility once this is merged

PR ready to submit to address accessibility once this is merged

Thanks, makes working with components usable.

@brianteeman @laoneo @C-Lodder Thanks for the help on this