html可访问性快捷键存在多个局限性，1. 快捷键易与浏览器或系统默认快捷键冲突，导致用户困惑；2. 可发现性差，用户难以知晓快捷键设置；3. 不同浏览器和操作系统间组合键不一致，增加学习成本；4. 不符合wcag推荐的主要导航机制，可能影响可用性。更推荐的替代方案包括：1. 使用语义化html标签提升结构清晰度；2. 添加跳过链接方便键盘用户快速定位；3. 管理键盘焦点顺序并提供可视指示；4. 利用aria属性补充复杂组件的语义信息；5. 保持导航模式的一致性和可预测性。为提升键盘可访问性，应从设计阶段考虑交互逻辑，确保所有可交互元素可通过键盘访问，优化焦点顺序，合理使用aria，并进行充分测试以保障用户体验。
HTML可访问性快捷键，简单来说，就是通过键盘上的特定组合键，让用户能够快速跳转到网页上的某个特定元素，比如一个搜索框、一个主导航链接或者某个重要区域。它主要依赖于HTML中的accesskey属性来实现。这就像给网页上的关键点设置了一些秘密通道，方便那些不便使用鼠标，或者习惯键盘操作的用户。
在HTML中设置可访问性快捷键，主要是通过在HTML元素上添加accesskey属性。这个属性的值是一个字符，当用户按下浏览器预设的快捷键组合（通常是Alt + accesskey字符，或者Shift + Alt + accesskey字符，Mac上可能是Ctrl + Option + accesskey字符）时，浏览器会将焦点移动到带有该accesskey属性的元素上。
比如，你想让用户按一个快捷键就能跳到搜索框：
立即学习“前端免费学习笔记（深入）”；
<label for="search">搜索:</label> <input type="text" id="search" accesskey="s">
或者，为一个重要的导航链接设置快捷键：
<a href="#main-content" accesskey="m">跳到主要内容</a> <a href="/contact" accesskey="c">联系我们</a>
需要注意的是，accesskey的值应该是一个单个字符，可以是字母（大小写不敏感）、数字或符号。但实际应用中，字母更常见。浏览器会根据操作系统和自身的设置来决定具体的组合键。
HTML accesskey 在实际应用中有什么局限性？
谈到accesskey，我总觉得它是个有点“生不逢时”或者说“理想很丰满，现实很骨感”的特性。它初衷很好，想为键盘用户提供便利，但实际用起来，问题可真不少。
首先，最大的痛点就是快捷键冲突。每个浏览器、每个操作系统，甚至每个辅助技术，都有自己一套默认的快捷键。比如，Ctrl+S在浏览器里是保存页面，在很多应用里也是保存。如果你把accesskey="s"设给一个元素，用户按下Alt+S，到底是触发你的快捷键，还是浏览器的保存功能？这完全是不可预知的，而且极易导致用户困惑甚至操作失误。想象一下，用户想用快捷键跳到“搜索”框，结果网页突然开始保存，那体验简直是灾难。
其次，可发现性极差。用户怎么知道你给某个元素设置了快捷键？除非你在页面上明确地标注出来，否则他们根本无从得知。而一旦你标注出来，比如“搜索 (Alt+S)”，那整个页面可能会充斥着这些提示，显得非常冗余和不美观。这本身就违背了“简洁高效”的设计原则。
再来，跨浏览器和操作系统的一致性问题。前面也提到了，激活accesskey的组合键在不同环境下是不同的。Windows上可能是Alt+键，Mac上可能是Ctrl+Option+键，有些浏览器甚至需要Shift+Alt+键。这让开发者很难给出一个统一的、明确的指导，用户也得花时间去记忆和适应，这无疑增加了学习成本。
最后，可用性与可访问性的权衡。W3C的Web内容可访问性指南（WCAG）在关于accesskey的建议上，其实是比较谨慎的。它们并没有强烈推荐广泛使用accesskey来作为主要的导航机制，因为潜在的冲突和用户困惑确实是难以避免的。相反，它们更倾向于强调其他更可靠、更普适的可访问性技术。所以，尽管它存在，但在现代网页开发中，除非有非常特定的、小范围的需求，否则我个人是很少会去主动使用它的。
除了 accesskey，还有哪些更推荐的网页可访问性导航方式？
既然accesskey有这么多不足，那我们自然要寻找更优的替代方案。实际上，现代网页可访问性实践中，有很多比accesskey更强大、更可靠、也更符合用户直觉的导航方式。
最基础也最重要的是语义化HTML。这几乎是可访问性的基石。正确使用HTML5的语义化标签，比如<header></header>, <nav></nav>, <main></main>, <aside></aside>, <footer></footer>, <article></article>, <section></section>等，就能天然地为屏幕阅读器和辅助技术提供清晰的页面结构。屏幕阅读器用户可以利用这些地标（landmarks）直接跳到页面的不同区域，这比任何自定义快捷键都来得直观和强大。例如，他们可以通过“跳到主内容区”的命令，直接定位到<main></main>标签。
其次是跳过链接（Skip Links）。这是一个非常简单但极其有效的技术。通常是一个隐藏在页面顶部，只有当键盘用户按下Tab键时才会显示的链接，它指向页面的主要内容区域。
<a href="#main-content" class="skip-link">跳到主要内容</a> <!-- 页面其他内容 --> <main id="main-content"> <!-- 主要内容 --> </main>
这样，键盘用户就不必每次都Tab过冗长的主导航菜单，可以直接跳到核心内容。
再者，良好的键盘焦点管理和可见的焦点指示器。确保所有可交互元素（链接、按钮、表单控件）都能通过Tab键按逻辑顺序访问，并且当前获得焦点的元素有清晰的视觉提示（比如一个边框或背景色的变化）。这是最基本也是最重要的键盘可访问性要求。
ARIA（Accessible Rich Internet Applications）属性也是不可或缺的。当语义化HTML不足以表达复杂的UI组件（如自定义下拉菜单、模态框、选项卡等）时，ARIA属性可以补充语义信息，告诉辅助技术这些组件的角色、状态和属性。例如，role="navigation"可以明确一个div是导航区域，aria-expanded="true"可以指示一个折叠菜单当前是展开状态。
最后，一致且可预测的导航模式。无论用户身处网站的哪个页面，导航菜单、搜索框、页脚链接等都应该出现在相似的位置，并以相似的方式运作。这种可预测性极大地降低了用户的认知负担，让他们能够更快地熟悉和操作网站。
总的来说，我们应该优先考虑那些对所有用户都有效、且不易产生冲突的通用可访问性实践，而不是依赖于像accesskey这样可能带来更多问题的特定技术。
如何在不影响用户体验的前提下，提升网站的键盘可访问性？
提升网站的键盘可访问性，绝不是为了合规而合规，它直接关乎到用户体验，特别是那些依赖键盘、屏幕阅读器或有运动障碍的用户。关键在于如何将这些可访问性特性融入到整体设计中，让它们显得自然、无缝，而不是突兀或碍事。
首先，从设计阶段就考虑键盘交互。这不仅仅是开发者的任务，设计师也需要参与进来。在设计稿中，就应该考虑每个可交互元素的焦点状态是什么样子？Tab键的导航顺序应该如何？模态框弹出后，焦点应该如何管理？这些前置思考能避免后期大量的返工。例如，按钮的 hover 状态和 focus 状态应该有明确但不过度的视觉差异，让用户一眼就能知道当前焦点在哪里。
其次，确保所有可交互元素都可被键盘访问。这意味着不仅仅是链接和按钮，任何通过JavaScript实现点击效果的元素（比如自定义的div作为按钮），都需要添加tabindex="0"属性，使其能够被Tab键聚焦，并且要能够通过Enter或Space键激活。同时，要避免“键盘陷阱”，即用户Tab进入某个区域后，无法通过Tab键离开，这会让用户感到非常沮丧。
<!-- 错误的示例：无法通过键盘激活 --> <div onclick="doSomething()">点击我</div> <!-- 正确的示例：可键盘访问的按钮 --> <button onclick="doSomething()">点击我</button> <!-- 或者，如果必须用div，确保可访问性 --> <div role="button" tabindex="0" onclick="doSomething()" onkeydown="handleKeyDown(event)">点击我</div>
这里的handleKeyDown函数需要检查按键是否是Enter或Space。
再者，优化焦点顺序和逻辑流。默认情况下，Tab键会按照HTML文档的源码顺序进行导航。大多数情况下，这符合用户的视觉顺序。但如果页面布局复杂，或者使用了CSS来改变元素的视觉位置，那么就需要通过调整HTML结构或使用tabindex属性（如tabindex="-1"用于可编程聚焦，tabindex="0"用于普通聚焦，避免使用tabindex="1或更大的正值，因为它会打乱自然顺序）来确保焦点顺序的逻辑性和预测性。
利用WAI-ARIA补充语义。正如前面提到的，当原生HTML语义不足以描述复杂的交互时，ARIA是你的好帮手。但切记“第一条ARIA规则”：能用原生HTML就用原生HTML。只有当原生语义无法满足需求时，才考虑使用ARIA。例如，一个自定义的标签页组件，你需要用role="tablist"、role="tab"、role="tabpanel"等来正确地描述其结构和状态，并管理aria-selected、aria-controls等属性，确保屏幕阅读器用户能理解并操作。
最后，进行充分的测试。不要只用鼠标点击，要尝试完全脱离鼠标，只用键盘来浏览你的网站。模拟屏幕阅读器用户的体验，比如使用NVDA（Windows）或VoiceOver（macOS）来测试。你会发现很多平时注意不到的键盘可访问性问题。这能帮助你从用户的角度去发现问题，并进行迭代优化。
总之，键盘可访问性是网站质量的重要组成部分。它不是一个可以后期“打补丁”的功能，而应该贯穿于整个设计和开发流程中，成为我们构建网站的内在品质。
