最近，知乎在桌面端网页上陆续增加了一些快捷键：
- 在首页、个人页和搜索结果页等页面浏览时[1]：按 J、K 来选中列表中的条目，按 O 来展开或收起全文，按 V、D 来赞同与反对等。另外，按 Esc 也可以退出大部分弹窗与弹出式菜单。
- 在播放视频时：按 F 让播放器全屏，按 M 让视频静音，按数字 0-9 可以跳转到对应的视频进度（0%-90%）等。
- 在回答与文章的编辑器中也有一些快捷键：比如按 ?+K 可以插入链接等。把光标移动到工具栏中的按钮上可以查看介绍。
在非输入状态下按 ？（Shift+/）就可以查看快捷键列表
在开发快捷键的过程中，有一些值得分享的经验。
开发快捷键
快捷键的作用域
实现快捷键不困难，因为监听键盘事件很简单。大部分时候，我们只需要在希望响应事件的最外层元素上注册事件就行，而响应事件的回调（比如关闭模态框）也都可以在这个最外层组件内实现。
知乎首页的组件结构
但是这次的情况要更加复杂。以在首页按 V 赞同答案为例：列表内的时间线条目（FeedItem）包括了回答（AnswerItem）在内各种类型的内容，而在回答里的赞同按钮（VoteButton）才是适合响应快捷键事件的地方。在最外侧的 FeedItem 上容易注册事件却无法响应事件，在最内侧的 VoteButton 中可以响应事件却不能简单地注册事件。
如何在 React 的组件关系中优雅地实现子组件（赞同、收藏按钮等）注册快捷键和回调函数、同时直到父组件（整个回答甚至 Feed 条目）的范围内都可以响应快捷键是比较有趣的。
一种简单的想法是：放弃在子组件中注册快捷键，全部在父组件中注册快捷键，在回调的时候调用子组件的实例方法。这会造成以下这些问题：
- 几乎放弃了组件的层级抽象：从外向里调用子组件实例方法比较 anti-pattern、难以管理（更别提在 React 中，越过接入 connect 等函数的 HOC 来获取真正的组件实例了）。
- 快捷键会被重复定义和实现：比如在想法、文章和答案等所有引用赞同按钮的父组件中，都注册和实现同样的按 V 赞同的快捷键。
- 在知乎的组件结构中，这种实现最多只能在位于层级中部的 AnswerItem 范围内进行，因为 FeedItem 的实现不关心子组件内部的业务。
现在知乎使用的方案是：基于 React context 来为所有子组件共享一个「快捷键实例」，在这个「作用域」下的所有子组件声明快捷键时，都会注册到这个实例上面。
参考下方的伪代码：
function FeedItem() {
const feedItemElement = useRef(null)
return (
<ShortcutContext value={feedItemElement}>
<div className="FeedItem" ref={feedItemElement}>
<AnswerItem />
</div>
</ShortcutContext>
)
}在 FeedItem 中，以自身的 HTML element 来初始化一个新的快捷键实例并设置在 context 中，实际的 keydown 等键盘事件是注册在这个 element 上。所以子组件都可以通过 context 在这个实例上注册新的快捷键。
function VoteButton() {
const handleVote = () => console.log('voting')
// 在 useShortcut 中查找当前 context 中存在的快捷键实例，并注册在实例上
useShortcut('v', handleVote)
return <button onClick={handleVote}>赞同</button>
}在 VoteButton 中，就可以像响应点击事件一样注册并响应快捷键事件，看起来和写起来都非常清爽。
列表导航的快捷键
使用 J、K 进行 Vim 风格的列表导航是许多网站常见的快捷键设计[2]。下面是一些如果从零开始实现时，可能会遇到的细节问题：
- 直接使用 element.focus() 方法会由浏览器决定一个合适的滚动位置，这通常是不符合预期的（对于知乎来说，是因为顶部有一个固定的导航栏，原生滚动经常会被这个导航栏挡住）。我们使用 preventScroll: true 参数禁用了这个原生的滚动，并使用自己计算的结果来 window.scrollTo() 到指定位置。
- 不是所有元素都是可以被 focus 的。如果只是普通的 <div> 元素的话，可以设置 tabIndex 为 0 或 -1 使其可被 focus。如果设置为 -1 的话则只可以被 focus，但是不能被 Tab 键选中[3]。是否希望被 Tab 选中，主要在于该元素内是否有可以被阅读的元素，或者该元素本身有可交互的行为。
- 如果在 focus 到某个列表元素后，又用滚轮或者触摸板移动了网页到很远的距离，再按 J、K 进行导航时就需要放弃已经 focus 的元素的，尽可能地 focus 在视图区域内可见的元素上[4]，或者采用别的策略[5]。
- 和其他类似产品不同，知乎大部分列表元素不是整个区域都可以点击并进入详情页，而是鼓励在当前页面展开并消费内容的（否则可以直接使用一个 <a> 标签包裹。这次特意实现了 focus 在列表项时，按 Enter 键可以进入详情页的快捷键。
- 如果因为点击而 focus 在某个列表项时（比如第 2 项），按 J、K 导航时最好只是先在该元素上显示 focus outline，而不是直接进行快捷键导航（到第 1 项或者第 3 项）。因为此时用户不一定知道自己已经 focus 在这个列表项上。这和知乎不为点击行为导致的 focus 添加 outline 有关。
Focus Outline 该在什么时候展现
当使用快捷键进行浏览时，「知道光标在哪里」很重要。屏幕阅读器可以阅读当前 focus 元素的内容。如果不通过声音的话、就只能通过视觉样式来知道当前正在 focus 的元素是什么。
Chrome 为 Input 标签默认添加的 focus outline
浏览器默认会为可 focus 的元素通过 :focus 伪类增加一个 outline 样式，因为这个样式不是很好看，再加上可 focus 的元素往往也会单独设计一些响应点击的样式，所以一般产品或设计会要求工程师取消掉该样式。但是如果简单取消所有 focus 样式后，用鼠标当然知道「我在点哪里」，但在使用键盘访问的场合就根本不知道「我在哪里」了。
最优雅的方案是使用 CSSWG 的 :focus-visible 伪类来添加 focus 样式（同时禁用原先的 :focus 样式），在 WICG 对该样式的 polyfill 中有详细的介绍。简单来说，就是「只有用键盘触发的 focus 才应该添加 focus 样式」。
知乎按钮的 focus 样式
知乎通过和该 polyfill 类似的思想实现了这一设计：在使用键盘操作后，会为 <html> 元素添加 data-focus-visible 属性。只有在包含该属性的情况下，各个元素才会添加 focus 样式。而且知乎还修改了默认的样式、更为美观。你可以使用 Tab 键 tab 到赞同按钮上查看这个效果。
在开发这一部分功能的时候，还有一个特殊的设计：使用 ?+C 等快捷键进行复制粘贴操作（准确地说，是按键中包括 Control 或 Shift 等 Modifier Key）时，不认为是一般的键盘操作，也不展现 focus outline，否则 outline 会过于频繁地时有时无。有意思的是，Twitter 其实也已经做了类似的处理，让人感到大洋两岸的工程师都在为用户体验而努力…
快捷键和可访问性的关系
很多关于快捷键的讨论都会有视障用户的参与，因为使用屏幕阅读器浏览网页、必须使用包括 Tab 键在内的各种键盘快捷键进行光标定位与操作，他们是「最会用键盘刷知乎」的人。但是，对视障用户的支持远不止添加快捷键这么简单。
@devil缠
在一个答案的评论区[6]提到：
如果只是单个按键，（快捷键）基本上没有任何用处。以 V 为例：当用 Tab 到达「赞同」按钮时，直接（按）空格就可以点赞同。（另外）如果在查看内容区点击 V，焦点不会跑到「赞同」按钮上。
合理的快捷键有可能用处不大，而不合理的快捷键不但不能帮助视障用户，还会帮倒忙。
@殷晓波
和
@devil缠
都提到「使用 V 赞同之后，希望可以 focus 到赞同按钮」，如果不真正使用屏幕阅读器浏览网页，是无法想象这句话的原因的：
快捷键赞同后，需要转移焦点
简单来说，屏幕阅读器只有在焦点改变时才会阅读焦点内的文字，它监控不到「赞同按钮变深蓝」这样普通人可以轻松理解的设计反馈。如果使用快捷键赞同后不改变焦点，连按下键盘发生了什么都不知道，也就不会知道「已经赞同了答案」。此时 tab 到赞同按钮上阅读到「已赞同」的文字才知道发生了什么就很奇怪。
浏览器的点击行为会自动 focus 在可交互的元素上（例如 <button> 或 <a>），而此时按 Enter 或 Space 等快捷键可以「模拟一次点击」，这套现成的体系很容易被忽略。在实际体验中，tab 到「阅读全文」按钮再按 Space 来展开全文并不比用快捷键 O 来展开全文麻烦很多。
除此之外，很多读屏软件或者视障用户也会定义、开发个性化的快捷键[6]。这么来看，使用 <button> 等语义化标签使元素可交互元素也可以被 focus、尽可能使用 <a> 而不是在监听 onClick 事件时使用 location.href 进行页面跳转、配置好 aria 属性等…对 Accessibility 更有意义。
总的来说，实现快捷键和实现其他功能一样也要注意视障用户的使用、交互体验，比如：
- 任何快捷键操作后都要像点击一样转移焦点。
- 转移焦点后，还需要配置 aria-label 等属性来阅读出有意义的提示文字，比如赞同还是已赞同、反对还是已反对。
快捷键只是 Accessibility 的一部分，而可访问性又是一个更加系统和复杂的工程。知乎做了一些努力[7]，但还远远不够。也欢迎对这个领域有更多了解的朋友提出建议。
Q & A
可以关闭快捷键吗？
是的。如果你使用 Vimperator 或者 Vimium 等浏览器扩展定制了快捷键而不想和知乎的冲突，可以在桌面端网页的个人偏好设置（https://www.zhihu.com/settings/preference）中关闭快捷键[8]。
这篇文章的注释与参考是如何做到的？
这是编辑器的新功能，会在开放后再行介绍。
参考
^这些快捷键在迁移到新版 Web 页面时没有同步迁移，在很长一段时间内都没有实现。
^包括 Twitter、Facebook、Gmail 与新浪微博等，知乎从这些网站的实现细节中受益良多。
^一个叫 tabbable 的库中有关于这两者区别的介绍，这个库在实现 focus trap 等效果时很有用。 https://github.com/davidtheclark/tabbable
^如何高效地查找离视窗最近、滚动距离最小的元素，这个算法比较有意思，这里不赘述了。
^知乎和 Facebook 与新浪微博一样，会选中视野内可见的新元素，而 Twitter 会放弃滚动。
^ab根据 @devil缠 在这个答案评论区中的说法，他使用的读屏环境还会定义包括 K 下跳 10 个链接、Shift+K 上跳 10 个链接等快捷键 https://www.zhihu.com/question/19842222/answer/17152043
^@长天之云 的答案介绍了一些知乎对 a11y 的支持 https://www.zhihu.com/question/20487917/answer/15265930
^只在当前使用的浏览器中生效。
作者:孙北吉
出处:https://zhuanlan.zhihu.com/p/59928288
