标签：很复杂™

我之前说过，作为一名刚开始使用 JavaScript 的前端开发人员，你可以学习的一项快速而强大的技巧是 更改类。

const button = document.querySelector(".my-button");
const element = document.querySelector(".content");

button.addEventListener("click", function() {
  element.classList.toggle("sparkles");
});

我们可以用这项技能来构建一些标签，对吧？没错。

我们做到了。

假设我们现在在技能集中拥有更改类的能力，并且需要构建一个选项卡界面。如果我们只添加一些处理点击处理程序的代码，我们就可以构建一些简单的选项卡，就像这样

查看 CodePen 上
XQpqZV by Chris Coyier (@chriscoyier)
在 CodePen 上。

完全可用的选项卡。我可能要在这里稍微夸奖一下自己。看到我如何使用这些锚链接在链接和选项卡部分之间创建跳转链接了吗？这非常语义化，不是吗？选项卡可以通过键盘访问，具有焦点样式，并且可以通过 Return 键激活。

我们赢了吗？尘埃落定？完美的选项卡？

没有什么事是那么容易的，是吗？

这里的一个问题是我们没有对键盘处理做任何特殊处理，而选项卡界面可能需要键盘处理。 Heydon Pickering 谈到了这一点

与同一个页面上的链接不同，选项卡不会将用户移动到相关的内容部分/面板。它只是在视觉上显示内容。这对希望在不同部分之间快速切换而不必每次选择新部分时都返回页面的视力正常的用户（包括视力正常的屏幕阅读器用户）来说是有利的。

但这带来了一个不幸的副作用：如果用户希望通过键盘移动到某个部分并与其内部内容进行交互，他们必须逐步浏览当前选项卡右侧的任何选项卡，这些选项卡处于焦点顺序。

事实证明，选项卡界面可以并且应该执行许多其他行为检查清单。在 Heydon 的解释中，Tab 键实际上是作为一种方式，用于从选项卡本身跳转到与该选项卡相关的内容，实际上移动焦点。 Shift+Tab 将它们带回来。然后使用箭头键更改选项卡。所有这些都需要更多 JavaScript 甚至一些 HTML 来允许焦点状态……加上一些 aria-* 属性，我缺乏专业知识来解释它们为什么重要。

最后，就像这样

查看 CodePen 上
Tab Interface (PE) by Heydon (@heydon)
在 CodePen 上。

所以问题就变成了：我们的更改类技能实际上是 web 的弊端，因为它们没有考虑到这些问题吗？用我们拥有的任何基本工具做事对于 web 可访问性来说是净损失吗？我不知道。对我的小脑袋来说，这个问题太大了。但这是一个值得思考的问题。

部分原因在于肌肉记忆。

如果我们先学习像第一个演示那样编写标签，只要没有人因为这样做而咬我们的手指，我们就倾向于一遍又一遍地使用它。我用大约三分钟编写了那个演示，因为我已经做过很多次了。创建这些选项卡无疑是我肌肉记忆的一部分。

关于 JavaScript 框架是 web 上的祸害有很多说法，因为它们似乎正在 ushering in an era of worst-in-class accessibility. 但是，如果你的构建标签的肌肉记忆是使用预构建的选项卡 UI，它会带来所有正确的功能，并且大部分样式由你决定，会怎么样？

这就是 Reach UI 选项卡 所做的（假设我们在使用 React……）。

我不是要告诉你转而去把你的项目切换到 React，以便获得一些免费的选项卡，但 React 已经非常庞大了。如果像这样的良好模式成为默认选择，那么它可能会对可访问性产生积极影响。对我来说，这似乎是可能的。它可能只会阻止我第 359 次笨拙地手写选项卡界面。