a11y 和 JS——一段看似非传统的爱情故事

这篇文章的灵感来源于几件事。首先，几个月前，Rian Rietveld宣布辞去WordPress无障碍功能负责人一职。我阅读了她的帖子，发现主要原因似乎与Gutenberg编辑器有关。尽管wpa11y团队发出了种种警告，他们仍然执意发布Gutenberg，而对于需要辅助设备的用户来说，它几乎无法使用。我认为这其中蕴藏着一个绝佳的机会，可以向社区普及相关知识，并帮助其他人学习。

在瑞安的博客文章中，有几点让我印象深刻，认为它们是主要问题（以下内容直接摘自她的网站）：

• “Gutenberg 的代码库对我们所有人来说都很困难，因为 wpa11y 团队中没有人是熟练的 React 开发人员。所以我们自己很难实现更改和编写 PR。”
• “社区里没有一位 React 开发人员具备无障碍设计方面的经验。”

最近（截至撰写本文时是上周），Chris Coyier 发表了一篇题为《鸿沟》（The Great Divide）的文章，阐述了前端开发人员之间存在的巨大鸿沟——一部分人专注于无障碍设计/HTML/CSS，而另一部分人则专注于 JavaScript。这篇文章引起了不小的轰动，尤其是在将无障碍设计与 HTML/CSS 联系起来讨论时。总的来说，我认为这篇文章写得不错，但我认为无障碍设计是一个多方面的问题，并不局限于 HTML/CSS。Dan Abramov 也指出了这一点，我同意他的观点。我并不赞同讨论过程中出现的过度激烈的争论，但这又是另一个话题了。

吹毛求疵一下：我觉得最好避免将“JavaScript”和“无障碍设计”等概念并列提及，仿佛这两种技能是相互矛盾的。pic.twitter.com/ 8OSjWoP2E1

— 丹·阿布拉莫夫 ( @dan_abramov ) 2019 年 1 月 21 日

我从来都不是那种对 JavaScript 避之不及的人。事实上，那样做可能不太好，因为我的日常工作就是写 JavaScript。但似乎存在一种误解，认为 JavaScript 和无障碍设计是水火不容的。我想整理一份清单，说明如何才能恰当地使用原生 JavaScript，从而提升而非损害无障碍设计。

菜单和超级菜单

菜单是思考 JavaScript 代码的绝佳切入点，因为几乎所有网站都有菜单。我通常使用原生 JavaScript 在获得焦点时打开和关闭菜单。我在一篇关于使用原生 JavaScript构建基本键盘辅助导航的博文中详细介绍了这一点。你还可以使用菜单来切换子菜单的打开状态aria-expanded。我会在以后的文章中更详细地介绍 ARIA，但你只需要知道，aria-expanded菜单的打开和关闭状态会告诉屏幕阅读器。

我在之前一篇关于手动辅助功能测试的文章中提到过，可以参考一下 MegaMenus 的设计思路。我建议大家设身处地地想一想，一个电商网站该如何让使用键盘的用户更容易浏览。比如说，如果我要找女装，我肯定不想tab先点击男装区的49 个链接才能找到。

我们可以做些什么呢？或许可以创建一个按钮来关闭菜单，并将焦点放在内容顶部（类似于“跳转至内容”链接）。我们可能还想创建一个按钮，上面写着类似“跳转至‘女性’”的内容。或许我们只想在用户使用键盘导航时显示这些链接，而在用户使用鼠标时则不显示。这些都是我们可以考虑的问题，以便让操作更便捷。

手风琴

我知道市面上有很多手风琴组件库，但我倾向于自己编写代码，或者从 CodePen 上寻找灵感。如果你仔细思考如何与组件交互，需要触发哪些按键，以及如何编写 HTML 代码，那么着手解决问题的过程就会充满乐趣！很多时候，我看到一些手工编写的手风琴组件，其 JavaScript 代码只能通过点击事件触发。不仅如此，很多时候你甚至无法将焦点集中在展开手风琴部分的箭头上。有时，手风琴内部甚至隐藏着一些链接，这些链接会在你看不到的情况下被选中。

我曾经需要创建一个键盘可访问的手风琴式控件，但由于客户要求，我不能修改标记。标记基本上就是一个完整的无序列表，它<li>的 tabindex 为 0，-1这意味着它们无法获得焦点。我想添加<button>一些元素，以便自己实现焦点功能和内置 JavaScript，但由于我不能修改标记，我只能更新 tabindex 并创建一些keypress事件。其实还有更直接的方法，我计划在以后的文章中创建一个美观且易于访问的 JavaScript 手风琴式控件。

看看这个 Codepen 示例。它用点击操作非常流畅。但是，在我撰写本文时，我似乎无法使用键盘访问它。

情态动词

你是否遇到过这样的情况：弹出一个模态窗口，但焦点仍然“停留”在它后面？你不停地按 Tab 键试图退出，但不幸的是，它却在菜单中循环切换链接，而不是帮助你退出并阅读页面内容。

就用户体验而言，我个人对弹出式窗口有意见，这与无障碍访问无关。我不喜欢思路被打断。然而，它确实是一种有效的销售和营销策略，因此作为开发者，我们必须确保它们的无障碍访问。

当弹出模态框时（无论用户是否请求），焦点是否落在其后面的其他元素上？不看屏幕底部，能否看出焦点所在？当模态框在用户访问网站一段时间后弹出时，是否确保焦点始终位于该模态框上？如果用户不感兴趣，他们该如何退出模态框并继续浏览网站的其他内容？如果他们感兴趣呢？他们该如何注册优惠券或订阅邮件简讯？

如果你看一下上面的 Codepen 示例，你会注意到点击模态框后，焦点不会立即转移到模态框上。

你可能已经在使用 JavaScript 来创建模态弹出窗口了，那么为什么不添加几行额外的代码，确保用户能够轻松注册或退出呢？我可能会在 egghead.io 上做一个视频，并单独写一篇博客文章，来阐述我的想法，但这确实值得思考。

互动性

你有没有想过如何编写代码来实现一个需要点击才能手动移动的滑块？你可能正在使用 JavaScript 并为其添加点击事件。它们是否可聚焦？提示：<button>如果它们还不能聚焦，那么应该添加一个 `<div>` 标签。如果你想了解更多相关信息，请查看我的文章《提升键盘可访问性的 3 个简单技巧》。这将使滑块可聚焦并响应点击事件！

网站上是否有需要使用鼠标交互的功能？这是网站的核心功能吗？既然你已经在使用 JavaScript 来实现这个功能，而且你还用它来处理点击事件，那么不妨仔细考虑一下keypress事件、焦点等等相关问题！

结论

我在之前的文章中也提到过，无障碍设计是以同理心为驱动的。我认为将 JavaScript 与无障碍设计结合起来的妙处在于，它本身就是一种同理心练习。你会思考诸如“如果我是一个无法使用鼠标的用户，我希望这个超级菜单是什么样的？怎样才能让我的导航操作更便捷？”之类的问题。

我的目标是撰写一系列博客文章，更深入地探讨这些概念。但我想让大家明白，JavaScript 本身并不是无障碍访问的敌人，真正阻碍它的是缺乏同理心。只要你拥有同理心和出色的 JavaScript 技能，你完全可以让你的网站变得易于访问！

如果您想了解更多关于 JavaScript 和无障碍设计的知识，请务必订阅我的新闻邮件，我会及时发布即将推出的课程信息！如果您对这篇博文有任何疑问，欢迎随时在Twitter上联系我。