在没有Javascript的情况下激活带有键盘焦点的父链接？答案

【问题标题】：Activating parent link with keyboard focus on tabbable child without Javascript?在没有Javascript的情况下激活带有键盘焦点的父链接？
【发布时间】：2016-11-05 19:37:54
【问题描述】：

考虑像this这样的情况：

<a href="#">
    <div tabindex="0">Tab focus me, then ⏎</div>
</a>

如果我专注于 <div /> 并按 Enter 键，我会在主要桌面浏览器 (OS X Yosemite) 上获得不同的行为：

Chrome 54.0.2840.71：父链接未激活。 <a /> 和子 <div /> 都可以通过选项卡单独选择。
Firefox 48.0.2：<a /> 本身似乎无法选择，但可以通过关注 <div /> 来激活链接。
Opera 39.0：与 Chrome 相同的行为。
Safari 9.1.2：与Firefox一样，<a />本身无法选择，但选择<div />时，链接不是 EM>激活。

既然<a /> 不能嵌套，有没有办法让一个有焦点的子元素在没有Javascript 的情况下跨浏览器激活父链接？ Javascript 选项很明显，但我发现它有点令人难以置信，这么简单的东西就需要它。

【问题讨论】：

我认为您正在尝试解决一个不存在的问题。您是否有示例页面或描述您想要实现的目标？在您的示例中，tabindex 完全没有必要，因为 <a> 将获得焦点，并且没有其他子元素可以发挥作用。因此需要一个真实的例子或场景。
这里的大局是什么 - 为什么要尝试嵌套交互式元素？你能举例说明这个 UI 在现实世界中的样子吗？可能有另一种获得最终结果的方法可以避免这种情况......
很抱歉没有一个非玩具示例，我正在制作一个更具说明性的示例。
在实现this example的过程中，我看到没有这个必要。最初，我打算让整个卡片可以点击“阅读更多”作为鼠标用户的目标——该链接为屏幕阅读器用户提供更多上下文。最后，“阅读更多”的链接就足够了。

标签： html hyperlink accessibility tabindex

【解决方案1】：

任何带有 tabindex 的元素都被视为interactive content

见： http://w3c.github.io/html/single-page.html#kinds-of-content-interactive-content

tabindex 属性还可以使任何元素成为交互式内容。

而且那些交互元素不能属于a[href]标签

a 元素可以围绕整个段落、列表、表格等，甚至整个部分，只要其中没有交互式内容

因此，如果没有 javascript，您将无法实现这一目标，因为这不是您的浏览器应该正常执行的操作。

【讨论】：

有趣！感谢您链接和引用规范。 “这不是你的浏览器应该正常做的事情”——我知道浏览器通过重组层次结构 (jsfiddle) 来防止 <a /> 嵌套和违反此规则。在旧版浏览器中a > [tabindex] 结构有多不安全，因为最新版本不会重组？

【解决方案2】：

我认为没有 JS 就没有办法解决这个问题。问题是你如何测试重点是什么？试试这个：

setInterval(function(){
  console.log(document.activeElement);
},1000);

我已经在 FF 和 Chrome 上进行了测试，您可以专注于锚点和 div ...但链接只会从锚点触发，这似乎很明显。

顺便说一句：为什么你甚至需要这个 tabindex ？

【讨论】：

【解决方案3】：

在没有示例或用例的情况下，鉴于上面 Adam 的回答，我还想指出，仅通过关注链接的任何部分来激活链接（无论是直接还是间接）都违反了 WCAG 2.0 Success标准 3.2.1。这是 A 级项目（意味着您无法通过任何未通过的 A 级测试的 AA 级合规性）。

3.2.1: On Focus: Level A

当任何组件获得焦点时，它不会启动上下文更改。

“更改上下文”将涵盖加载新页面/URL。

简而言之，不仅 HTML 规范告诉您不要嵌套交互式内容，WCAG 还明确禁止仅通过聚焦元素来更改页面。

简而言之，不要这样做。即使您可以使用 JavaScript（我什至不会尝试），那么您的项目也将不符合基本的可访问性准则（并且违反某些国家/地区的法律）。这也意味着您正在让您的雇主/客户面临诉讼（假设仅仅制造糟糕的、无法访问的用户体验是不够的）。

【讨论】：

如果我将上下文更改绑定到某个“onfocus”事件，我可以将其理解为违反本规范。按下回车键或单击任意焦点元素时启动上下文更改不是很明显吗？
例如，在按钮或链接上单击（或点击或按下 Enter）通常会更改上下文并且是预期的（例外是它们更改现有页面，尽管这也可能是上下文的更改）。但是，将焦点放在按钮/链接上不会改变上下文，也不应该改变。在这种情况下，当您单击该元素时，它是否获得焦点与此无关。考虑同时使用鼠标和键盘的用户，他们可能会在页面中切换，然后单击其他位置的元素。
“但是，将焦点放在按钮/链接上不会改变上下文，也不应该改变。”我完全同意。在这种情况下，关注链接的子项（参见我的问题中的 JSFiddle）不会改变上下文，我也不希望它改变——只有单击、点击或按下回车键，就像您的标准链接/按钮一样。
那么在父元素已经可以接收焦点的情况下，让子元素成为焦点的目的是什么？我不明白您要达到什么目的，您的问题听起来像是您希望父母在孩子获得焦点时激活。
@Alohci，我不确定这与我的回答有何关系。但是将一个可聚焦的元素放在另一个交互元素中是一个问题。无法访问图像的上下文菜单也是一个问题。你必须整理出一个同时解决这两个问题的接口。