Top level menu item links do not work with touch-only device

[Philippe-dev]

When touched for the first time, top level items display their respective panel, but when touched for the second time (while panel is open) nothing happens.

The demo page does not work either for top level items links with tablets and smartphones.

I have tried numerous solutions messing up with _clickHandler function, but to no avail so far. Has anybody managed to make it work with tablets ans smartphones?

[blakes7]

Did you ever resolve this @Padawan83 ?
I added a private var, along with about 15 lines lines of code in the _clickHandler to overcome this and another touch issue.

[Philippe-dev]

@blake7 : I would be very glad to see and test these 15 lines, could you please share your solution here ?

[blakes7]

Certainly. Let me add some comments in the code.. and i'll attach here momentarily :-)

[blakes7]

Hi @Padawan83.
This is what i used. Feel free to test (i only confirm it works ok on iPad).
It overcomes 2 issues

1. Clicking the same menu item doesnt collapse the list
2. Click a menu item, then clicking elsewhere on the page, you can no longer open the same menu item.

:-)
jquery-accessibleMegaMenu.js.zip

[Philippe-dev]

Hello

Thank you for your help. I tried your patch but encountered the same behaviour as with my trials: when touched, top level menu item opens its panel but the link is also followed. So the panel opens briefly, and the new page is loaded

However I did not try with the same device as you, I used an android tablet and phone. It could be the issue...

I was trying to get the mega menu to open on touch, and if clicked again to follow the link.

[multimediavt]

I am having the same issue with top level (parent) links being dead on iPad running iOS 9.3.1. I can either have the Accessible MegaMenu things work for keyboard nav on desktop or have the top level links work for mobile, not both. This is a major issue and does not seem to affect all sites implementing this, so I am at a loss. For instance http://www.washington.edu works fine and with expected behavior, but http://www.vt.edu does not work and I am at a loss to determine why.

I am still trying to figure out what is going wrong, but this problem persists.

UPDATE: I still need to do some more QA on this, but I think I found what was blocking the click action on a touch device. I commented out lines 306 and 307 under the _clickHandler function. These lines were:

event.preventDefault();
event.stopPropagation();

These were blocking the parent link. I am still able to pop the dropdown open with the first tap, and collapse it by tapping anywhere off the parent link. Again, I am going to do some more QA on this over the next day or so and will stop back to comment when complete. Right now it looks like lines 306 and 307 could be removed.

UPDATE 2: Ok, so everything checks out across desktop (Win and OS X) and iOS. The Android (v4.4 and up) behavior doesn't change whether those lines are commented or not. On Android the parent links are followed and there is no click event capture to leave the dropdown open, so there is a flash of a dropdown as it goes to the parent link location. Some more work needs to be done on the _clickHandler, but I've made this hack work for iOS devices for now.

[erichomanchuk]

I was having the same issues on Android Chrome browser I would have to double click to open the menu, on iOS devices clicking on the top level would open them menu but would go to the url in the top level link.

I fixed it by using an older version on the script, specifically reverted to the commit 201f1cc and now behaviour is expected.

I did notice another issue on the samsung device internet browser where it works improperly still probably likely due to the fact that a link has a click and a hover event on touch devices for samsung.

[llahnoraa]

+1

It doesn't work on iPad or any of the tablet devices. This needed to be resolved as soon as possible.

This is a great plugin, btw, but needed to be fixed :)

[kimisgold]

+1

Surfaces and touch-enabled Ultrabooks are becoming more popular, and thus this is becoming an even bigger obstacle for our userbase.

[tanu08]

This is going to be a long post, so please bear with me... :)

I have started using this jquery-based keyboard accessible mega-menu plugin recently, and found it interesting. While testing it out on different platforms (Desktop, iOS and Android) I encountered the same issues that are reported here (Issue #32 and issue #31). I am working on a fix for these touchscreen related issues, but the fix goes counter to some of the design recommendations of this plugin (mainly, removing anchor tag from top-level menu items, and have them to show menus only).

Digging deeper into the library's code and its behaviour across various user interface events (click, touch, hover, keyboard) made me analyse the menus on following web-pages:

1. https://www.adobe.com (Adobe's main landing page, which supposedly uses this plugin)
2. https://adobe-accessibility.github.io/Accessible-Mega-Menu/ (the demo page served from the "gh-pages" branch of this repo)

The documentation of the library indicates that the HTML for this menu needs to have following structure:

<nav>
        <ul class="nav-menu">
            <li class="nav-item">
                <a href="?movie">Movies</a>
                <div class="sub-nav">
                    <ul class="sub-nav-group">
                        <li><a href="?movie&genre=0">Action &amp; Adventure</a></li>
                        <li><a href="?movie&genre=2">Children &amp; Family</a></li>
                        <li>&#8230;</li>
                    </ul>
                </div>
            </li>
         </ul>
</nav>

With the above HTML, the mega-menu that gets rendered exhibits following behaviour on the demo page on different platforms:

1. Desktop Chrome: https://adobe-accessibility.github.io/Accessible-Mega-Menu/
   On hover: hovering any top-level menu item shows the menu beneath it.
   On click: Clicking any top-level menu item, navigates to the url of its child tag.

2. Android Chrome: https://adobe-accessibility.github.io/Accessible-Mega-Menu/
   On tap / touch: Touching any top-level menu item shows the menu beneath it. There's no user gesture possible to allow navigating to the top-nav item's link.

The above behaviour made me read up more about touch events and design principles for handling both touch and mouse events, in a uniform manner. This is where I believe the library's approach of providing a "link (anchor) tag" as well as a menu, for top-level nav items, is erroneous.

Reasoning:
To allow two separate actions - 1. navigate to the link of top-level item, 2. open the top-level item's menu, would need two separate user gestures. For a mouse-based user interaction (on Desktop browsers), this was achieved using "hover" for showing menu and "click" for navigation to links.
But, for a touch-based user interaction (touchscreen PCs, mobiles) there's only one type of event (a Touch event) that occurs. So to achieve two actions (1 & 2) from a single user input (Touch/Tap) is just not possible.

Now coming to how https://adobe.com works on Desktop and Mobile platforms. It wasn't surprising to see that the mega-menu on adobe.com doesn't show the menu on "hover" action. Instead, a click is needed to show the menu. How about navigating to top-level links? Well, all the top level links have anchor tags with href="#". Which in essence means, there's no top-level navigation links. And thats the reason why https://adobe.com works uniformly across desktop and mobile browsers.

In nutshell:
I think the mega-menu should not have anchor tags under the top-level nav items. With that change, the user expectation and experience can be made uniform across Desktop and Mobile browsers:
On Desktop: A "click" on top-level nav item would toggle its menu panel.
On touchscreens: A "touch" on top-level nav item would toggle its menu panel.

I'll send PRs for any bugs around the touch-based issues that I can fix, but would be happy to hear what others in the community think about the above observations.

@majornista @Padawan83 @multimediavt @azinck @peterc (tagging folks from issues #31 and #32)

[majornista]

#53 (comment)