Fix dropdown menu behavior on es-navbar component

[ghislaineguerin]

Expected Behavior

• Dropdown menu should be displayed when hovering over the menu items

Actual Behavior

• Dropdown menu is only displayed when clicking on the menu items

Steps to Reproduce

(to be added)

[MelSumner]

For reference, the navbar component should behave like this: http://w3c.github.io/aria-practices/examples/menubar/menubar-1/menubar-1.html

[alexeykostevich]

@MelSumner , @pichfl , I could have a look at this issue.

@pichfl , please, could you let me know whether showing a submenu on hover is expected in the latest design?

• If yes, we could implement the menubar design pattern (which @MelSumner mentioned above): http://w3c.github.io/aria-practices/examples/menubar/menubar-1/menubar-1.html
• If no, we could implement the disclosure design pattern: https://w3c.github.io/aria-practices/examples/disclosure/disclosure-navigation.html

[pichfl]

¯\_(ツ)_/¯ the original mockup didn't provide any information on this, but personally I'd go with the menubar pattern for larger screens.

[alexeykostevich]

One of the big challenges of implementing the menubar pattern for <EsHeader /> is significant differences in its behaviour for large and small screen.

• The desktop version uses a horizontal layout, while the mobile version uses a vertical one. As a result, the component should use different strategies of keyboard navigation (especially, arrow keys) for different modes.
• The desktop version should use a hover effect to show submenus, while the mobile version should use a click. I’m not sure how much it impacts the overall complexity, but it definitely will.

Taking into account these differences, would it make sense to create 2 internal components (e.g. <EsHeader:EsNavList /> and <EsHeader:EsNavStack />) to encapsulate the differences to reduce the complexity and make them more testable? Then, <EsHeader /> could automatically switch between them based on a media query.

@MelSumner , please, let me know what you think: you have much more experience in accessibility than I do.

Thank you!

[MelSumner]

@alexeykostevich we shouldn't need two components- CSS should be able to handle the layout differences- let me know if I can help with that.

[alexeykostevich]

Thank you for your response, @MelSumner ! Sorry for confusing you with my message: I meant differences in accessibility features not layout.

The example of a menubar, which you mentioned above, implements quite sophisticated (this is state-of-the-art accessibility!) keyboard support.

Here is just a subset of what it implements (please, look Navigation Menubar Example for more details):

Do we expect our navbar to implement this level of accessibility?

If yes, we should take into account that keyboard navigation (especially, Up/Down/Left/Right Arrow keys) should behave differently for the full and minimized versions of the navbar (due to differences in their layout).