Browser: Chrome / Firefox (latest) Operating System: Windows / macOS
Summary: While the mobile submenu issue reported in my previous post has been fixed in RC2, there’s still an accessibility issue with keyboard navigation on desktop. Submenus cannot be opened using keyboard navigation (Tab + Enter/Space).
Steps to Reproduce:
Create a page with a “Nav Menu” element containing parent/child items
View the page on desktop
Use Tab key to navigate to a parent menu item that has children
Press Enter or Spacebar while focused on the parent item
Expected Behavior: The submenu should expand to show child items, allowing continued keyboard navigation through the submenu items.
Actual Behavior: The submenu does not open with keyboard navigation. It only opens on mouse hover.
Accessibility Concern: This creates an accessibility barrier for users who rely on keyboard navigation, which is essential for compliance with WCAG guidelines and inclusive web design.
Additional Testing:
Mouse hover works correctly ✓
Mobile touch interaction works correctly (after RC2 fix) ✓
Keyboard navigation fails ✗
Could you please investigate the keyboard accessibility for desktop navigation menus in the next RC release?
Hi Krystian,
When and where exactly did you report the problem? The phrase “still present” confuses me a little, because we can’t solve unknown problems And as far as I can see, there is no report from you on this.
However, I can’t reproduce the problem (it’s a new nav menu element with default settings):
Sorry, meant that the dropdown problem still occurs, although I previously described the problem of not being able to expand the submenu on mobile devices.
Since it works for you - the problem may be related to my CSS. I apologize for misleading you
My custom CSS for the submenu was missing a :focus-within selector, which broke keyboard navigation. After removing my custom show/hide logic and letting Bricks handle it, everything works perfectly. Sorry for the false alarm and thanks for pointing me in the right direction!
