Changes to fix touchscreen issues when tapping on top-level nav items.

[tanu08]

The behaviour of mouse-clicks versus touch/tap, is now made consistent.

1. onClick / onTouch of top-level items will toggle the menu under the nav-item
2. on hover showing of menus for top level menu items is removed now.

A detailed analysis of touchscreen and mouse click/hover behaviour across browser/OS environments is captured in a long comment here:
#32

[tanu08]

@majornista Sending this PR on top of gh-pages branch. The testing of the touchscreen related fixes can be done by navigating to
https://adobe-accessibility.github.io/Accessible-Mega-Menu/
on Chrome browser.

1. Open developer tools and at the top left of the developer toolbar, there's an option to switch to a mobile-emulator window. In that mode, with the code changes done in this PR, the touch(tap) on top nav items of the menu work consistently similar to how they work on Desktop browsers with mouse interaction.

[care4kittens]

Hi @tanu08 - looks good on many counts. Unfortunately there's a regression in desktop versions. Here's a bug report (not exhaustive):

testing accessible mega menu updates 2018-03-09
issue: mouseclick behavior inconsistent across browsers and platforms

unexpected behavior across most desktop browsers:
description: single mouse click on parent menu items does not open subpanel; subsequent clicks highlight a parent menu item but have no further effect.
- mouse clicks open subpanels, but almost always requires 2 clicks on the desired menu
- First click highlights menu item but does not typically open it (tho intermittently works as expected)
- Second click opens subpanel
- Third click closes subpanel
- Fourth click opens subpanel
- Clicking outside the menu region then clicking a menu item opens the item as expected
- If a sibling menu is open, first click consistently closes
test browser/os:
edge 41.16299 on Windows 10 (latest version)
internet explorer 11.15.16299 (latest version) on Windows 10 (latest version)
firefox 58.0.2 (latest version) on Windows 10 (latest version) & Mac High Sierra (latest version) & Ubuntu 16.04 (latest LTS version)
chrome 65.0.3325 (latest version) & chrome 64.0.3282 (penultimate version) on mac High Sierra (latest version)
chromium 64.0.3282 (latest version) on Ubuntu 16.04 (latest LTS version)

safari desktop:
description: single mouse click on parent menu items does not open subpanels; subsequent clicks have no further effect.
browser/os: safari 11.0.3 (latest version) on Mac High Sierra (latest version) & Sierra (penultimate version)

[majornista]

@tanu08 The rationale for supporting a dual behavior for links as top level menu items, where the menu displays on hover and the clicking the menu item with the menu expanded navigates through to the specified href, was to use the principal of progressive enhancement to add behavior to the menu.

With touch browsers, the behavior of differs mainly to ensure that a screen reader user on a touch device can toggle the menu using a click action on the menu item. Clicking an area outside of the menu isn't a viable option for a screen reader user on a touch device.

If maintaining support for navigation to the top-level menu items is a requirement on touch devices, one simple solution would be to add the link within an <h*> tag at the top of the menu panel on touch devices.

[care4kittens]

@majornista You describe the notion of navigating by clicking a menu item with the menu expanded. Do you have any insights on how well the notion has stood the test of time? I don't believe I've come across it for a while. (@tanu08 comments that adobe.com also went a different direction).

That question aside, can you weigh in on the notion of a patch to this library that supports the behavior @tanu08 proposes (i.e. to have this library work the way it does on adobe.com, with no hyperlinks in top-level nav)? There seem to be several related issues in the queue, and several patches that don't fix the issue with android devices. I wonder if this simplification is a reasonable solution, or at least a stop-gap.

[majornista]

@care4kittens It is probably better practice to toggle submenus with a click, as we do on touch devices, rather than rely on hover. In which case, I'd recommend a separate link within the sub-menu to navigate to any url specified in the top-level header link's href.

[tanu08]

@majornista @care4kittens Thanks for weighing in with your thoughts. I also agree that, navigation of top-level menu links by click(in expanded state) and opening their menus on hover, though works fine on mouse-based interaction, it goes counterproductive on touch-based gestures.
Also, I looked at a few other sites apart from adobe.com, and they all exhibit the behaviour I feel is more intuitive:
to have consistent experience across browser and touchscreen devices - on click of top nav items open their menus, and hover is not doing menu toggle.

@majornista If the above design principle seems fair, then you can take a look at this PR for merging it into main trunk. Let me know your feedback on the patch and if any suggestions to the fix, are also welcome.

[tanu08]

@care4kittens I have fixed the issues you mentioned above re: inconsistency in click behaviour across browsers and the issue with Safari Menu panels not opening.
@majornista I'll try to update this PR itself with the new set of changes, or send in a new one with all the changes done. Let me know if that will work with you.

[tanu08]

@majornista @care4kittens I have pushed another commit to gh-pages branch of my fork, so this PR reflects the updated changes (2 commits till now). With this commit, we have all browsers on desktop and Mobile devices working consistently. A click on desktop browsers opens the menu panel, a touch/tap does that on touchscreen devices.

[majornista]

@tanu08 I just committed a few fixes that seek to address the concerns you have been trying to solve with this PR. Thank you for your contributions.