✅ ♿ 🐞 Bug Report: Mega Menu Accessibility is not intuitive #23875
Comments
Daveden2
added
the
status/awaiting_triage
|
I'll second this. It's not expected that a navigation menu on a website will use menubar. The Menubar role is intended for desktop applications, not websites. It's good to have arrow key support in the navigation, but it should also work with tabs too. Keyboard only users (who are not using screen readers and will not get notified that this navigation uses the menubar role) will not know how to interact with this nav. Here's an example of a good nav menu on the WordPress Accessibility Day website. You can also watch this recording of a meetup on accessible navigation. |
|
Also, the aria-label on the nav itself is junky. It needs to label the menu to distinguish it from other nav elements on the page. Currently, the nav looks like this: The aria-label needs to name the nav link this: |
|
@nicholaszein This is my feedback: @Daveden2 We will discuss this internally. Thank you so much for your thorough analysis. @amberhinds Also, I am not sure where the 'aria-label' content has been prescribed to be like that. |
|
@hein-obox, thank you for your response. I'm pleased to know that the team will be looking into it further. In response to your enquiries:
For more information, you may want to explore this PDF slide that I found from Deque: Deque Accessible Mega Menus. Additionally, based on the examples I've come across, a navigation menu using In conclusion, I believe that the preferred approach should be the use of the disclosure (flyout) pattern for navigation menus, which is relatively straightforward to implement and doesn't require an extensive amount of ARIA information. |
|
Hi @Daveden2, Thank you for your feedback, I agree with most of your points. My main concern was with @amberhinds emphasis on what we 'have to do', while I believe there is the freedom to make our own choices and still stick to the W3C Aria guidelines. |
nicholaszein
changed the title
nicholaszein
added
bug
|
Hi Elementor folks, I second the issues and proposed fixes in @Daveden2’s post, and would like to add another, regarding the current implementation of Currently, “Menu” and”Wordpress Menu” Elementor widgets use a If multiple Menu widgets appear on the same page (for instance a primary menu in the site header, with a set of secondary links in the site footer), a user navigating the web page via screen reader will thus be presented with multiple navigation landmarks with no accessible way to differentiate them. (This cannot currently be fixed via the Attributes feature, as adding an aria-label here passes it to the menu widget’s parent div element, and not to the nav element itself — the actual nav element still keeps the "hard-coded" aria-label with the keyboard instructions.) I would propose that a control be exposed in the UI, as soon as possible, allowing the user to override the aria-label on the nav element itself. |
|
Sorry for the delayed response. @hein-obox, something to keep in mind is that accessibility is not just for people who are using screen readers. A lot of people are sighted and have no need for a screen reader, but cannot use a mouse and are keyboard only users. While your nav menu might provide some auditory explanation for screen reader users about how to interact with it, a sighted user will not have that information. The vast majority of websites allow users to tab through menu items and this is the expected behavior. Can you choose not to support the Tab key and require arrow navigation? Yes. But when that is not the expected way to navigate a website, many users will get stuck. In fact, I was hung up on it the first time I encountered it and thought that it was completely broken. I spent ~10 minutes inspecting the code trying to figure out why the tab key didn't work. A typical user, with no dev skills would probably just abandon a site. |
|
Great to see this reported. Here is the reported issue from axe DevTools Pro:
|
|
I hope Elementor team will the accessibility issue a priority. Users should be able to navigate the mega menu using just the keyboard. Thanks in advance! |
|
@Daveden2 @doronwolf @amberhinds We are working on an update of the Mega Menu Accessibility. I have tried to follow your suggestions:
I have followed the markup of the fly-out menus, and used the following websites as a reference: Could please review our work using this demo URL: https://deliverycompany-clone.elementor.cloud/. We haven't added a control to edit the Menu and Menu Toggle aria label yet, but we have an additional task to implement that. See a screenshot for reference: |
|
Hi @hein-obox I conducted a quick test of the Elementor test site plus the eBay menu and the W3C menu. Here are my observations: The Positives
Issues Noticed
|
|
Thank you so much for your feedback @Daveden2 This reminds me to test with the NVDA tool. I will get a Windows laptop to do so. Are you happy with the (absence of) aria-labels and with the overall HTML structure of the menu? I have tried to stick to the given examples as much as possible. The menu has an option for the submenus to be opened on 'hover' or on 'click'. I have changed the settings to 'click'. Does that change the screenreader behavior? |
|
@hein-obox, it seems to be doing the job well on my desktop computer. Mobile Screen Reader TestI noticed that using VoiceOver or TalkBack on mobile, the dropdown content is sort of disconnected from the menu items. When I trigger the hamburger menu, I have to swipe to the end of the list of top-level links before I can access the dropdown content. HTML Content PlacementOn a side note, like Maxime mentioned a few times, in the html the dropdown content should ideally directly follow the trigger button within the same So, something link Aria LabelsI feel that the aria-label on the buttons should be changed to something like "item_name submenu". The reason is that right now, whether the menu item is opened or closed, it'll still first read "Expand: item_name" If possible, we could switch to using a visually hidden text rather than aria-labels. Maybe @amberhinds could help me out on this one. ConclusionThese are just my opinions and observations. I wish a native screen reader user or certified accessibility auditor would chime in. |
|
@rami-elementor For your reference. |
|
@askwpgirl, the current plugin version of the mega menu is still not tab navigable. My recent comments were in response to testing the links provided by @hein-obox This is weird. When I test the page on my Windows PC using Chrome, I can navigate to the links using the tab key just fine. Upon retesting, I've identified another bug: while the links are visible within the top menu items, they can't be activated. When clicking the "Kids" menu item, the dropdown menu activates instead of directing me to the associated link. Interestingly, the https://elementor.com link appears on hover, suggesting the link itself is present but is being blocked. |
|
Yes, I see why I was confused. The top level items except the two Kids items do not have Can you add links to those items? Ideally, how normally accessible menus work is as follows:
What Elementor developers got mixed up was that they used arrow navigation for main level and tab navigation for drop down items when it should be the opposite. What they got right was the drop down icon being a separate element that is activated on return key and functions like a button. You are getting very close in your mockup! Amber would be great to consult with on any other tweaks that needs. |
|
@askwpgirl and @Daveden2 Thank you so much for your feedback. |
|
About the sub menu title: I think text would be preferred over an aria-label. But I agree with the general gist of Amber's feedback. About your mobile experience: I haven't been able to test screen readers on a mobile device. I tried it on my Android, but it didn't work very well in general. I have tested this website on a Samsung emulator using browserstack.com and there it works fine. It would have helped me if browserstack.com had given me a 'broken' experience, then I could have tried to debug it. Now I am not sure. About the html markup, the preferred markup would be to have containers inside wrapped inside the menu item container, but that is creating are limitations for us. Therefore we have decided to leave the html structure as is, and to use JavaScript to focus the container items, which works well in all desktop browsers and with NVDA on Windows. Currently I am clueless about your mobile experience. Do you know if Talkback works well on other websites? E.g. when you go to ebay.com, are you able to open the menu when clicking on the hamburger icon? On my phone that wasn't possible either. |
|
@hein-obox, after a quick test, I think I now understand the problem. First, the ebay mobile menu uses multilevel menu structure for their mobile menu which is different from Elementor's demo. But I've gone ahead to test the demo menu using my samsung with TalkBack active. First, I used the native tap and swipe functions; then I connected it to my pc using samsung dex + keybaord. The menu works well with the keyboard interaction but not the swipe interaction. When using talkback or voiceover natively on mobile, we use swipe left and swipe right to navigate. So, I'm guessing that's where the problem lies. I'm assuming the elementor js only catches tabbing and other keyboard keys. As @amberhinds mentioned, the escape key should work to close the mobile menu toggle. Some people have their windows resized or zoomed in on desktop or use keyboards on their mobile devices. So, we should take that into consideration. On a side note, funny enough, when testing ebay, their mobile menu toggle closed using the escape key but their desktop menu didn't! |
|
@Daveden2 Swipe left/right: that is great feedback. I am going to study that. |
|
@hein-obox I no longer have my pc turned on. But I think I noticed the escape key closes submenus not the entire hamburger menu. |
|
@Daveden2 Do you know if can simulate the swipe left/right on a desktop as well or do I need to use a mobile device for that? |
|
@hein-obox unfortunately I have no idea. |
|
@hein-obox FireFox in recent versions has implemented swipe gestures and you can use them in the responsive developer mode. Just want to say thank you all as well. This is fantastic work and gives me confidence in a current accessibility-focused project with Elementor. |
Hi! Thank you so much for fixing the mega menu for accessibility! Do you know if we can download this beta version or do you know when it will be released? I don't see the accessibility option "Additional Settings," so I assume that it has not been released yet. Thanks |
|
@blackvx, I had a very brief look at 3.20-beta1 and also didn't see the option to add an aria-label to the nav menu. I guess it wasn't included or maybe I missed it. I recommend adding it as an "accessible name" feature. On a separate note, @hein-obox, apologies for not responding earlier 🙏. Did you receive any feedback on mobile screen reader testing for the current setup? I'll do a proper test on the menu as soon as I can. |
|
@blackvx @Daveden2 About the Talkback Gesture testing: I will reach out to the specialists to find out more information about it, but at this stage it doesn't have priority for us. |
|
Why did the team decide not to add the aria-label setting?
…On Tue, Feb 20, 2024, 6:01 AM Hein van Vlastuin ***@***.***> wrote:
@blackvx <https://github.com/blackvx> @Daveden2
<https://github.com/Daveden2>
We have decided at this stage not to implement the Aria Label control in
the editor. This is an internal decision made by our product team. I hope
that we will reconsider this option in the future.
About the Talkback Gesture testing: I will reach out to the specialists to
find out more information about it, but at this stage it doesn't have
priority for us.
—
Reply to this email directly, view it on GitHub
<#23875 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADELJMGV2AKUA67VWBR7OX3YUSGABAVCNFSM6AAAAAA5BMMXE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJUGA3DONJTHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@amberhinds We haven't added it anywhere in the editor. This is for consistency reasons. When we add it, we would like to add it in more places, and we want to make sure that we do it in a consistent way and not haphazardly. |
|
We need to look for other options. Does anyone know if there is an addon to Elementor with an accessible menu widget (essential-addons, happyaddons etc)? thanks! |
|
Does the mega menu support adding the aria-label in custom attributes and allow it to override your hard coded aria-label? That might be a decent solution that doesn't introduce another field right away. If you don't allow users to name, it I would at least change your default from aria-label="Menu" to aria-label="Main" or aria-label="Primary". That would at least provide more information about what kind of menu it is. (Though it's still problematic if two are added to the page because they'll no longer have unique labels.) |
|
@doron Wolf Morrison ***@***.***> Can you please check this
ongoing conversation?
…On Wed, 21 Feb 2024, 00:09 Amber Hinds, ***@***.***> wrote:
Does the mega menu support adding the aria-label in custom attributes and
allow it to override your hard coded aria-label? That might be a decent
solution that doesn't introduce another field right away.
If you don't allow users to name, it I would at least change your default
from aria-label="Menu" to aria-label="Main" or aria-label="Primary". That
would at least provide more information about what kind of menu it is.
(Though it's still problematic if two are added to the page because they'll
no longer have unique labels.)
—
Reply to this email directly, view it on GitHub
<#23875 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AWP3HQWI343DLEN6QN6YCA3YUUNIXAVCNFSM6AAAAAA5BMMXE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJVGIYDEMBVHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@doron Wolf Morrison ***@***.***> @rami Yushuvaev
***@***.***> I love the suggestion of using custom attributes.
…On Thu, 22 Feb 2024, 12:26 Hein van Vlastuin, ***@***.***> wrote:
@doron Wolf Morrison ***@***.***> Can you please check this
ongoing conversation?
On Wed, 21 Feb 2024, 00:09 Amber Hinds, ***@***.***> wrote:
> Does the mega menu support adding the aria-label in custom attributes and
> allow it to override your hard coded aria-label? That might be a decent
> solution that doesn't introduce another field right away.
>
> If you don't allow users to name, it I would at least change your default
> from aria-label="Menu" to aria-label="Main" or aria-label="Primary". That
> would at least provide more information about what kind of menu it is.
> (Though it's still problematic if two are added to the page because they'll
> no longer have unique labels.)
>
> —
> Reply to this email directly, view it on GitHub
> <#23875 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AWP3HQWI343DLEN6QN6YCA3YUUNIXAVCNFSM6AAAAAA5BMMXE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJVGIYDEMBVHA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
@amberhinds We are still pushing to add the functionality to update the Aria Label in the near future. |
+1 custom atts seems like a simpler solution than adding more fields to UI. I tried just now with current stable releases and it did not change. Is there some work to do to allow it as an att/value? Will be launching an accessibility-forward site (with Elementor Pro) to a national audience quite soon and would love to give the client confidence we are not alienating portions of their audience! |
nicholaszein
added
the
status/merged
nicholaszein
changed the title
nicholaszein
added
the
solved
|
Hey everyone! As you might already know... 📢 We're happy to announce that the issue you raised was resolved in Elementor Pro v3.20.0! 🥳Than you everybody so much for your contribution and feedback! 🙏 Special thanks to @Daveden2 and @amberhinds for providing crucial feedback to make this a reality! 💪 We know that the option to edit/customize For now, we are closing this issue as solved!
Cheers 🥂 |
|
This is fabulous news! Thank you to everyone involved. |
|
@nicholaszein Thank you for your update! Thank you @amberhinds and @Daveden2 to help us find the right direction. |
|
Go team. Hearts to @amberhinds and @Daveden2 |
|
Hi @Daveden2, I have created a POC of the Mega Menu with an updated markup: https://deliverycompany-clone.elementor.cloud/. I have been able to insert the content of the menu item inside the item itself. In this way, I expect a better support by screen readers, because we are following the order of the dom which elements, which doesn't require JS to update the current focus. Could you please test this for us on screen readers? |
|
Greetings @hein-obox , I'm not as knowledgable as David and I'm looking forward to his report, but I did a quick test with TalkBack, and I'd like to share it with you: https://vento.so/view/f809ed36-bfb9-4327-8054-33eb0308ee8f?utm_medium=share I hope this is helpful. The only issue I found was that the title itself was triggering the open/close action, and this might not be ideal. Other than that it seemed to work quite well. Cheers and thanks for your dedication on this! |
Prerequisites
Description
After seeking feedback from various accessibility groups, it has become evident that the current implementation of the mega menu utilising the role="menubar" attribute lacks intuitiveness and raises several accessibility concerns.
Issues
This bug report outlines three issues:
Proposed Solution
<ul><li><a>Dropdown Subitems</a></li></ul>, andSteps to reproduce
Isolating the problem
System Info
Click to reveal
The text was updated successfully, but these errors were encountered: