HTML焦点管理的基本原理
焦点与可访问性之间的关系
在前端无障碍优化中，焦点管理是实现键盘可访问性的核心。只有确保可聚焦元素在正确的顺序中出现，屏幕阅读器用户和键盘用户才能顺利遍历页面功能。若焦点跳转混乱，页面的可用性就会下降，导致用户错失重要控件。通过明确的焦点逻辑，可以让页面的交互行为对所有用户一视同仁。
无障碍设计的第一步通常是使用语义化的HTML控件，例如 <a>、<button>、<input>、<select> 等，再通过 tabindex 做必要的增强。过度使用自定义控件时，务必提供可聚焦的替代方案和可预测的焦点行为。
<!-- 示例：可聚焦的元素组合 -->
跳转到内容
<button id="searchBtn">搜索</button>
<input type="text" aria-label="输入关键词">
<div tabindex="0">自定义控件示例</div>
tabindex的三种基本取值与含义
在实现焦点管理时，tabindex 的取值极大地影响焦点排序与可聚焦性。常用的取值有三种：tabindex="0"、tabindex="-1"以及不使用 tabindex 的情形。推荐避免正整数取值，以免打乱浏览器的默认焦点顺序。
具体含义如下：tabindex="0" 使元素能够被聚焦，且进入浏览器的自然标签顺序。tabindex="-1" 使元素能够被脚本聚焦，但无法通过 Tab 键进入焦点环。对于不可见的对话框或隐藏控件，其不会干扰正常的 Tab 顺序。而未设置 tabindex 的元素，只有其原生聚焦能力，遵循自然顺序。
<!-- 纯链接的聚焦示例（不需要 tabindex） -->
<a href="#main">前往主内容</a><div id="custom" tabindex="0">自定义控件可聚焦</div><div id="hidden" tabindex="-1" aria-hidden="true">隐藏控件</div>
如何正确设置 tabindex
避免正值的陷阱
正整数 tabindex 值会人为地改变元素在标签页中的焦点顺序，这对残障用户尤其不友好，因为屏幕阅读器会把焦点读出顺序与视觉顺序不一致。实践中应避免使用 tabindex>0 的情况，除非确有必要将特定元素置于自定义的焦点序列中。
正确的做法是尽量让浏览器自然的 Tab 顺序承担大部分导航工作，仅在必要时使用 tabindex="0" 来揭示可聚焦性，并避免对现有表单控件之外的元素进行额外排序。
<!-- 不推荐的做法：对非交互元素设置正整数 tabindex -->
<div tabindex="2">自定义控件</div><!-- 推荐做法：尽量让元素在自然顺序中聚焦，必要时使用 tabindex="0" -->
<button id="ok" tabindex="0">确定</button>
何时使用 tabindex="0" 与 tabindex="-1"
在无障碍实践中，tabindex="0" 常用于让自定义控件变得可聚焦，例如自定义按钮、组合控件等，且希望其进入正常的键盘循环。tabindex="-1" 则适合需要通过脚本聚焦但不希望用户通过 Tab 键进入焦点的场景，例如在弹出层打开时将焦点移动到对话框，但在页面中仍保持原有焦点顺序。
一个典型的使用场景是模态对话框：打开时将焦点移动到对话框内部的首个可聚焦元素，同时将对话框容器设为 tabindex="-1" 以便程序性聚焦，关闭后再将焦点恢复到触发控件。下面给出一个简化的实现示例。
<!-- 模态对话框结构（示例） -->
<div id="modal" role="dialog" aria-modal="true" aria-labelledby="modalTitle" tabindex="-1" style="display:none"><h2 id="modalTitle">提示</h2><button id="confirm">确认</button><button id="cancel">取消</button>
</div>
焦点管理在常见组件中的实现
模态对话框的焦点管理
模态对话框是最需要严格焦点管理的组件之一。实现要点包括：将对话框容器设为 tabindex="-1"，在打开时将焦点聚焦到对话框的首个可聚焦元素，并使用焦点捕获机制确保用户在对话框内循环切换，关闭时恢复原始焦点。
具体实现要点说明如下：在打开对话框时，记录前一个聚焦元素，然后将对话框聚焦；使用键盘事件处理 Tab 循环，将最后一个聚焦元素的后续聚焦导回到第一个；在关闭时，撤销焦点陷阱并返回触发控件的焦点，确保用户的交互轨迹连续。
<div id="modal" role="dialog" aria-modal="true" aria-labelledby="modalTitle" tabindex="-1" style="display:none"><h2 id="modalTitle">示例对话框</h2><button id="confirm">确认</button><button id="cancel">取消</button>
</div>
下拉菜单的焦点逻辑
可聚焦的下拉菜单需要处理按钮的 aria-expanded 状态、菜单的可聚焦项，以及在打开时将焦点定向至菜单中的第一项。实现要点包括：保持按钮与菜单的语义关联，将菜单设置为 role="menu" 并让其菜单项具备 tabindex，使得键盘导航可预测地移动。
通过合理的焦点管理，用户在打开菜单后可以使用 Tab 或方向键在菜单项之间切换，按 Esc 关闭菜单并返回到触发按钮的焦点位置。
<button id="menuBtn" aria-haspopup="true" aria-expanded="false" aria-controls="menu" >菜单</button>
<ul id="menu" role="menu" hidden><li role="menuitem" tabindex="-1">项 1</li><li role="menuitem" tabindex="-1">项 2</li><li role="menuitem" tabindex="-1">项 3</li>
</ul>
// 简化的下拉菜单焦点逻辑
const btn = document.getElementById('menuBtn');
const menu = document.getElementById('menu');
btn.addEventListener('click', () => {const expanded = btn.getAttribute('aria-expanded') === 'true';btn.setAttribute('aria-expanded', String(!expanded));menu.hidden = expanded;if (!expanded) {// 打开时聚焦菜单的第一项const first = menu.querySelector('[role="menuitem"]');if (first) first.focus();} else {btn.focus();}
});
无障碍测试与调试方法
键盘导航测试
确保网页在键盘导航下的可用性是无障碍测试的第一步。常规操作应覆盖 Tab、Shift+Tab、Enter、Space、Esc等按键行为，确保所有可交互元素均可访问，且焦点轮转无死角。对于模态对话框，按 Esc 应能够关闭对话框并恢复焦点。
除了基础导航，跳过链接的可见性与可聚焦性也应验证。跳过导航的链接应在页面加载时可聚焦，且进入页面时优先出现，以帮助屏幕阅读器直接进入主内容。
/* 可见的焦点环样式，确保聚焦清晰可见 */
:focus { outline: 3px solid #4b8af4; outline-offset: 2px; }
屏幕阅读器与ARIA测试
在进行 ARIA 相关测试时，务必确保语义标签与属性的互相配合：role、aria-label、aria-labelledby、aria-hidden 等 的组合要正确，避免多余的叠加导致屏幕阅读器的重复读出或混乱信息。对话框、菜单等组件应正确使用 aria-modal、aria-expanded、aria-controls 等属性。
日常调试中可以通过浏览器开发者工具查看聚焦顺序、aria 属性是否随操作正确更新，以及在自定义控件上是否保留可聚焦性和可读性。
<div id="modal" role="dialog" aria-modal="true" aria-labelledby="modalTitle" tabindex="-1" aria-hidden="true"><h2 id="modalTitle">示例对话框</h2><button>确认</button>
</div>
