1

我在现有导航菜单上的 IE11 Mobile（Lumia 520 电话）上遇到了这个问题，在第一次点击时，我的子菜单中的每个链接都没有触发点击。

这个fiddle repro是一个部分弹出式可访问导航菜单，取自示例WAI 应用程序菜单。

如果您在 IE10 或 IE11 Mobile 或 Touch 上对其进行测试，您会发现所有子菜单链接都不起作用。

它们必须被点击两次才能触发点击事件。

这是为什么？

4

1 回答 1

1

此错误是从 IE10-11 for Touch 开始部署的“帮助模拟触控设备上的悬停”功能的结果。

简而言之，导致和需要双击的原因是aria-haspopup=true子菜单父元素级别。正因为如此，IE Touch 错误地假设所有这些链接都是自己切换的，并将它们视为此类。我还要注意，出于类似的原因，iOS Safari 有自己的方式来处理带有“<em>:hover[s] 的元素，它可以使用可见性或显示隐藏或显示另一个元素”</a>。

正如 MSDN 的Internet Explorer 10 Samples and Tutorials中所述：

或者，Internet Explorer 10 向现有的 aria-haspopup 属性添加了新行为，以模拟悬停在具有隐藏交互式内容的页面元素上。

问题在于，虽然它被认为是有帮助的，但该实现是基于对aria-haspopup是什么以及它应该做什么的不完整且有些误导的阅读。

  1. aria-haspopup在技​​术上是一个属性（而不是状态）。这意味着 IE 在运行时不应更改的元素上放置了触摸行为。除非响应式上下文可能需要进行此类更改；即使显示弹出元素，也aria-haspopup='true'应保留。取而代之true的是开关的状态。aria-expanded

  2. 该概念仅适用于该教程中实现的 aria-haspopup的MSDN 示例。ie如果 aria-haspopup=true放置在切换按钮本身上，则 IE Touch 功能将按预期工作。但是，如果aria-haspopup=true属性被放置在父级别，如我的 repro，或者像更传统的应用程序菜单，根据这个W3C/WAI 示例，这是一个问题。

解决此错误的解决方案是，要么aria-haspopup=true因为 IE10-11 Touch（这对可访问性很糟糕）而不在父元素上使用，要么在服务器端或相应地使用 Javascript 将其从启用触摸的 IE10/IE11 中删除。

于 2016-01-10T07:10:52.673 回答