I was faced with this problem on IE11 Mobile (Lumia 520 Phone) on an existing navigation menu, where every link inside my submenus were not firing a click, on the first tap.
This fiddle repro is a partial flyout accessible navigation menu, taken from a sample WAI app menu.
If you test it on IE10 or IE11 Mobile or Touch, you will obverse that none of the submenu links work.
They must be clicked twice to fire the click events.
Why is that?
This bug is a result of a feature to "help simulate hover on touch-enabled devices" that was deployed starting in IE10-11 for Touch.
In short, what causes and requires the double tap is having aria-haspopup=true as the submenu parent element level. Because of it, IE Touch wrongly assumes all those links are toggle themselves and treat them as such. I shall also note that for similar reasons, iOS Safari has its own way to treat elements with “:hover[s] that either hides or shows another element using visibility or display”.
As explained on MSDN’s Internet Explorer 10 Samples and Tutorials:
Alternatively, Internet Explorer 10 adds new behavior to the existing aria-haspopup property to simulate hover on page elements with hidden interactive content.
The issue is that while it was supposedly designed to be helpful, that implementation is based on an incomplete and somewhat misguided reading of what aria-haspopup is, and what it is supposed to do.
aria-haspopup is technically a property (and not state). Meaning that IE placed a touch behavior on an element that isn’t supposed to change at runtime. Unless a responsive context would perhaps require such a change; aria-haspopup='true' shall remain true even if the popup element is shown. The state for the switch being aria-expanded instead.
The concept only works for the MSDN example of aria-haspopup as implemented on that tutorial. i.e. If aria-haspopup=true is placed on the toggle button itself, that IE Touch feature will work as intended. However if the aria-haspopup=true attributes is placed at the parent level like my repro, or like a more traditional app menu, as per this W3C/WAI example, it's a problem.
The solutions to go around this bug are to, either not use aria-haspopup=true on parent elements because of IE10-11 Touch (which sucks for accessibility), or remove it from touch enabled IE10/IE11, either on the server side or with Javascript accordingly.