whilst true - every single example of a compliant menu structure on any official page uses a list.
All the descriptive text accompanying these examples and tutorials always state a list of links. So yes although technically it is not a “demand” I would take it as it is implied that a list is used.
Good catch - missed that as was too focussed on the list.
On this note, we could also do away with, or at least not make it default included, the <aria-label="menu"> too as the menu is already descriptive so this is redundant. You could change the aria-label on the hamburger to <aria-label="open menu"> to compensate.
He doesn’t say that’s the only way to build an accessible menu, and the pull request has zero to do with using a list or not and everything to do with newbie coders using the wrong pattern for navigation menus and adding the wrong roles. By wrong pattern, he specifies the APPLICATION menu pattern that is being used by developers as a navigation menu instead.
Examples are not guidelines or SC. The SC does not indicate that a navigation has to be in a list. It doesn’t even indicate that you have to notify the users how many items are in the navigation.
Even the APG states “This is an illustrative example of one way of using ARIA that conforms with the ARIA specification.” Not THE ONLY way. They also state they are “different from the accessibility requirements specified by WCAG and ARIA…The APG does not specify normative requirements and thus does not have a conformance model”
WCAG outlines the SC for navigation and nowhere does it state you must put your navigation items in a list in order for it to be accessible. You are using examples to say this is what is needed to be accessible, but that’s not listed in the SC for navigable blocks.
They way it is now is more like the nav element is presented in the HTML spec; it allows for the builder to add what they want, how they want. If you think you need your items in a ul, do it. The beauty of Brick’s Builder is you can create your own templates and reuse as you please.
You can go grab snippets and examples of menus built this way or that way by this person or that person but I believe it is universally accepted by accessibility practitioners, (those that I have come across), that the correct way to build a navigation menu is for it to contain a list of items of which which a screen reader can announce.
This is proved with many many examples and tutorials in both courses and all over the internet. Yes they may be an “example” but 99% of the time if you are shown an example, the example is the correct way and you should be following that method.
We are talking about accessibility, so if you can build it one way that makes it inclusive then it should be built that way. If you build it another way that causes people not to be able to navigate properly then you are not building the menu accessible - standards, rule, guidelines, articles, beliefs or not.
As I have stated, I believe, and others have agreed, that the best, most universally accepted way forward - in both terms of functionality and also to improve the default state of accessibility of Bricks websites in the open world, would be to have a proper structure of nav > list > list item. This will allow proper accessibility and those who want to build an accessible menu can build from there. Those who are not comfortable with a11y or do not know enough about it to make an informed choice also do not need to worry as the menu is accessible out the box.
You have mentioned about being able to build what you want so those who do not want a list, you can very easily delete and build out whatever menu structure you want. No drama’s there.
It is much quicker and easier to delete one bricks element than it is to go into several settings for each element and change the structure, then change the styling to remove the default list styling and add anything else.
We ARE talking about accessibility which is open to subjective interpretation when things like “how to build a proper meu” are not specified. Just because a widely accepted pattern is more universal than another does not make it THE standard.
There are also actual blind users who don’t want the added verbosity the lists bring; they can absolutely update their settings to help, but they don’t always do that. There are agencies that use listless navs. Just because those guys haven’t chimed in here, doesn’t mean they don’t exist. You can find old threads on CSS Tricks alone that show there are developers who use listless navs, and there are reports of actual screen reader users who prefer it without.
Talking accessibility does not mean there is ONLY one way. Not having the links in a list does NOT make the menu inaccessible which is the wrong assumption you are basing your statement on. It’s not “proper” or “improper” accessibility; you are basing your conclusions on examples, not the WCAG SC.
You are asking the builders to add more opinionated presets that we have to undo; it’s just as quick and easy to edit the tags to the ul and li you desire too so that’s just splitting hairs.
When it boils down to it, your claim that the menu is not “a11y compliant” is wrong. And the only support you keep adding for it is other people’s examples of how they would build a menu, and how the majority PREFERS to use lists, not the actual WCAG SC. As Thomas noted, there is more freedom when you can add whatever you want instead of having to start out deleting stuff.
“Those who are not comfortable with a11y or do not know enough about it to make an informed choice also do not need to worry as the menu is accessible out the box.” What specifically makes this menu inaccessible out of the box? We know it’s not the fact that it’s not wrapped in a list because that’s not a requirement under the current standards, and it hasn’t even been added to 2.2 so what does the noob have to worry about of the box?
Accessibility is not all or nothing; it’s a scale.
The “Menu item” is just a “Div” element with the HTML tag set to li. The “Nav items” uses the ul tag. “Dropdown” uses li, and the dropdown “Content” an ul tag, etc.
Thanks for looking at this and changing direction of the implementation. I do feel this will help in the long run and bigger picture of a11y compliance.
We’ve added the ul > li structure and removed the aria-hidden mentioned by David in Bricks 1.8 beta 2, now available as a manual download in your account.
Please let us know if you are still experiencing issues.
As with any beta release, please do not use it on any production/live website. It is only meant for testing in a local/staging environment.
looking forward to testing the beta2