前端与浏览器 / 进阶

可访问组件：从键盘、焦点和语义开始

以按钮、对话框和异步状态为例，建立语义、键盘操作、焦点管理和辅助技术测试的组件基线。 ARIA 能补充语义，但修不好错误的交互模型。

12 分钟Accessibility · ARIA · Keyboard · Focus

优先使用原生元素

button 天然可聚焦，支持 Enter 和 Space，并向辅助技术暴露按钮角色。用 div 模拟需要补齐 tabindex、键盘事件、禁用状态和名称，维护成本更高。链接用于导航，按钮用于执行当前页面动作。视觉外观不应决定语义。图标按钮必须通过可见文本或 aria-label 提供可访问名称。

EXAMPLE / 01Accessibility

<button type="button" aria-label="关闭设置">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

<p role="status" aria-live="polite" id="save-status"></p>

对话框的焦点闭环

打开时把焦点移到对话框内合适位置；Tab 和 Shift+Tab 不应跑到背景；Escape 通常关闭非强制对话框；关闭后把焦点还给触发元素。原生 dialog 配合 showModal 能提供模态语义和背景隔离，但仍要提供标题、关闭方式并测试目标浏览器。不要仅靠点击遮罩关闭。

只用键盘能完成全部操作，焦点始终可见；读屏能读出名称、角色、状态和值；200% 缩放和窄视口不丢内容；减少动态效果设置下没有强制动画；错误提示与对应输入建立程序化关联。

EXAMPLE / 02Accessibility

let trigger = null;

function openDialog(dialog) {
  trigger = document.activeElement;
  dialog.showModal();
  dialog.querySelector('[data-initial-focus]')?.focus();
}

function closeDialog(dialog) {
  dialog.close();
  if (trigger instanceof HTMLElement && trigger.isConnected) trigger.focus();
}

最后回到真实页面检查

自动化检查必须配合键盘和读屏人工测试