Menu structure of items is not a11y compliant.
I can change the nav items container to a UL/OL but need to wrap each individual item as a li for compliance.
I feel the nav items container at least should be set to a list as default (probably a ul) and we can wrap/custom tag individual sub items individually thereafter
As the user has 100% freedom what elements to add inside the âNav itemsâ element there isnât really any built-in & bullet-proof solution to enforce/ensure a rigid ul > li structure. Especially once you take the 100% customisable dropdowns into account as well.
From my tests I could not spot any critical a11y advantages that the ul > li structure inside the nav tag provides. Please correct me if Iâm wrong, and âsignificantâ is of course always subjective.
If you prefer using the ul > li structure inside the nav Iâd recommend setting the HTML tag of the âNav itemsâ element to ul and wrapping your individual menu items into Divs with an li tag set.
Simply pre-populating the âNav nestableâ with those top-level li Divs is not a viable solution, as this easily breaks the HTML markup completely once the user adds a new top level element via a Div element from the elements panel without manually changing the HTML tag to li afterwards.
To be a11y compliant all menus should use a list for the structure as it allows screen readers to announce how many items are in that list.
Totally understand, I was a bit apprehensive to post this one as it was always going to be tricky to solve due to so many different use cases and how it can be built. More of a conversation post really to ascertain wether we are looking to make the menu builder fully compliant out the box or having the user build and adapt to make it compliant
Similarly - the dropdown content should also be a list so it can be announced how many items are in the dropdown. Could having the dropdown items pre-wrapped in a div & li be workable, or again would that be up to the user?
A great website to check structure and compliance is https://www.scope.org.uk
Interesting spot Dan, Iâm of the same thought that for full a11y it should be a ul > li setup.
Nice to know thereâs a way around it with Thomasâ suggestion, but a little cumbersome to say the leastâŠ
Yes the workaround is very cumbersome, every link you need to wrap and then change the tag for. I guess once you have done the first you can just copy from there.
Depends on Bricks is targeting the builder for - if itâs for the ânot bothered about a11yâ users then we will have to live with the long workaround, if for the compliance and to say our menu is complaint out the box then I guess the masses would then complain that they need to undo everything that is there pre populated so they can do what they want with it.
But deleting what is already there is vastly quicker so⊠¯_(ă)_/ÂŻ
Would also like to add that have added some feature requests here - 1.8 Menu Builder - Dropdowns Requests - that are not âbugsâ per se but are related
I would also like to see the lists be used properly out of the box for the nav menu.
IMO it is a critical advantage to have how many items are in the current level of the menu for someone who relies on screen readers.
Edit: I am in favor of 100% freedom as well in terms of what elements are used in the nav I just think by default it should start out as a list.
I see it like Thomas, I prefer to have total freedom and can do what I want instead of being dictated to me by the PageBuilder.
So I have access to the <li> and the <a>. If it was generated automatically, I wouldnât have that and would have to customize it via CustomCSS.
In addition, the dropdown can also be used anywhere else and is also used in the MegaMenu.
In the MegaMenu I have full freedom and can insert images, texts and whatever. But that shouldnât be a list.
You also have complete freedom in how you style your links. You can add icons or maybe an image, none of that would work if Bricks did it. Then it wouldnât be much better than what we have now.
So please stick to this principle, itâs fine the way it is!
// Edit:
I would be fine if the structure looks like this when inserting the element. You probably mean that too.
@thomas
All my previous themes - Astra, GeneratePress, and Beaver Builder use the ânav > ul > liâ structure. These a11y websites (W3.org, WCAG.com) use that same ânav > ul > liâ structure. That structure should be the default.
This is a case of subjective interpretation. The SC for compliance does not indicate you have to put a menu in a list. The W3 examples are not standards.
The nav element can contain links and itâs displayed as nav should be displayed, in the same way we style lists to look in order to make them look more like a menu. Lists have the added benefit of announcing how many items are in the menu. But itâs still a choice that has considerations.
Except it does - have a read through the guidelines.
Well technically none of of WCAG are standards, they are guidelines as is the name. The W3C create the WCAG guidelines so I would take a guess that they would be doing everything âcorrectlyâ for menu structure and semantics.
The W3C/WCAG pages are littered with examples of <nav> all over the place for different criteria and techniques and every single one of them which has a <nav> has a list of items inside be it <ul> or <ol>. It is literally there in their menu tutorial (which follows and adheres to the WCAG guidelines) - Menu Structure | Web Accessibility Initiative (WAI) | W3C
This is a similar structure I can imagine being the default. The default elements that are inserted should be a11y compliant. I get that you want full control and so do I, but it is far easier to delete these components and build how you wish than it is to go through the default menu and make it a11y compliant.
If someone does not know/appreciate a11y and they insert a default menu that is complaint then the site is compliant and it is a win all round. Should we not be striving to make everything a11y complaint out the box so it is easier for everyone from the get go�
As I say, at the end of the day, it depends on which segment of users and what standards Bricks wishes to cater and hold themselves to:
If Bricks just wishes to have a âpowerfulâ menu builder that can be used to build a11y compliant menus with extra work etc then I guess they have succeeded with this implementation.
But perhaps a rethink on voicing all the a11y features front and centre as it is slightly misleading as there is more work to do.
If on the other hand Bricks is aiming to be a11y compliant out the box then the current implementation of the menu builder and default elements is not in compliance and a rethink is needed on how the structure of the list items in the dropdownâs (amongst some other things) is handled from the offset.
Can you really say you are a11y complaint if your default menu does not pass the basic tests?
Just wanted to raise a friendly discussion on this before it goes full release and its too late to change
Thatâs my point though; you are telling them they need to put these items in a list in order to be compliant, but thatâs not the case. The link you reference is just examples on how you can make your site meet WCAG SC, not points you must meet in order to do so.
If we want to be real technical, âa11y compliantâ isnât a thing. (ADA Web Site Compliance Still Not a Thing â Adrian Roselli)
*We cannot be compliant for something that is not a law/standard imposed on us.
Edit: No one should promote something as accessible out of the box. Bricks has shown a commitment to making things more accessible, but accessibility is a scale that we work on moving forward. The nav element allows for a lot more than just a ul and li elements so I think the setup as they have it allows for a lot more flexibility.
Except Adrian also states to build navigation with lists
https://adrianroselli.com/2019/06/link-disclosure-widget-navigation.html#Container
and he also submitted a pull request for a menu build that is now shown on the W3C site as an example of a properly built accessible menu.
What I am suggesting does not take away any of the âpowerâ or âcontrolâ or âfreedomâ to build a menu how you wish - just that the initial menu when the element is added should be built correctly, semantically and to best practices.
This will help everyone in the longer run as users who do not care for a11y or do not know about it can build a proper âbasicâ menu with links and a dropdown perhaps from the get go.
If you do not want to use the standard menu then you can simply delete the elements and build from scratch how you would anyway.
+1 for making this a ul > li structure by default.
Edit: If its going to stay like this, it would be nice to at least have a doc or tutorial for the workaround. Iâm looking at the various elements and I donât see the option to change their HTML tag to ul or li.
you need to make the content <div> under the dropdown into a <ul>/<ol> by using the custom tag
then you need to wrap each link with a <div> and make that div an <li> using the same process
Oh gotcha, I didnât even see the custom tag before. Tedious, but doable. Would not want to do on a very large menu.
Edit: Thanks very much @dan
Thank you for sharing this! I was surprised to learn that this wasnât structured with UL and LI because of the accessibility-focused wording of the release.
Iâm with Dan. This is the main reason.
Is it breaking the rules not to use lists? Not really, thereâs nothing about the ânavâ tag in HTML that demands a list to be used - those using screen readers will know theyâre browsing inside of a navigation, but itâs generally an expectation to know how big that menu is before doing so. For that reason, iâd always use a list.
TBH Iâm surprised nobody has picked up on the much bigger issue, (not that it will be difficult to solve) but which makes this conversation moot in way - none of the mega menu items are currently readable by screen readers anyway, list or no list, due to the aria-hidden=true on the nav element.
none of the mega menu items are currently readable by screen readers anyway, list or no list, due to the aria-hidden=true on the nav element.
@wplit can you expand on this? I do see the aria-hidden=true on the nav element in my source code, but VoiceOver is still reading out all the links.
This explains it wellâŠ
âYou must never use aria-hidden="true" on any focusable element, or on any element that itself contains focusable children.â
If you check some of the screen reader browser extensions, even though the links are focusable, the screen reader wonât read out the link text while that attribute is there on the parent.
( Note that I think this was likely just added in for the mobile menu use, and will likely just be removed for the final version, Iâm just flagging it.) Update - can confirm the attribute is changed for the mobile menu when opened, looks like itâs just been left on the desktop menu
