本文详解如何在按钮点击后动态替换为可聚焦输入框时，确保键盘导航、屏幕阅读器提示和 aria 语义均符合 wcag 2.1 可访问性标准，涵盖 tabindex、aria-live、aria-expanded 等关键实践。

把“点击按钮切换到输入框”这个交互做到位，听起来不算复杂，但可访问性上的坑，往往就藏在那些不起眼的细节里。如果处理不当，屏幕阅读器用户可能完全感知不到页面的变化，键盘用户的操作体验也会大打折扣，甚至直接踩到 WCAG 2.1 的红线，比如键盘可操作性（2.1.1）、名称角色与值（4.1.2）以及一致性识别（3.2.2）。下面这套方案，是经过多次验证的实战打法。

✅ 核心原则：状态明确 + 语义清晰 + 反馈及时

1. 保持 DOM 稳定性与语义连续性
   一个常见的错误做法是直接销毁一个元素再重建另一个，比如用 isOpen ? : 这种条件渲染。这会导致焦点丢失，屏幕阅读器的上下文也被粗暴打断。更稳妥的做法是：在同一个容器里做条件渲染，同时动态切换元素的角色。推荐的结构是这样的：

   setIsOpen(true)}  >    {isOpen ? 'Sa ve changes' : 'Edit'}    {isOpen && (     setIsOpen(false)}      aria-label="Edit the content"      // 必须声明 role="textbox" 以明确语义（尤其当父元素非 form）      role="textbox"      tabIndex={0}    />  )}

2. 强制键盘可访问性

• 按钮的 type 一定要是 button，防止意外触发表单提交。
• 输入框加上 tabIndex={0}，虽然原生 默认就能聚焦，但显式声明一下总是更稳妥。
• 处理 onBlur 时得小心，最好配合 setTimeout，防止用户点击输入框时，失焦事件先一步触发，导致编辑状态意外关闭。
• 支持 Esc 键退出编辑状态：在 input 上监听 onKeyDown，当按下 Escape 键时关闭编辑。

3. 主动通知屏幕阅读器状态变更
   光靠 autoFocus 自动聚焦是不够的，屏幕阅读器不一定会主动播报变化。需要结合 aria-live 区域，给用户明确的上下文反馈：

// 在组件顶部或页面公共区域添加（不可隐藏！）
  {isOpen ? 'Editing enabled. Type to modify, press Enter or Escape to confirm.' : ''}

这里有几个注意点：aria-live="polite" 确保不会打断当前正在进行的语音播报；aria-atomic="true" 保证整句播报，而不是一个字一个字地往外蹦；.sr-only 是辅助技术可见但视觉上隐藏的 CSS 类，确保不影响视觉布局。

4. ARIA 属性精准映射行为

• aria-expanded：绑定在触发按钮上，值设成 true 或 false，直观地告诉用户当前是否处于编辑状态。
• aria-controls：指向输入框的 ID，建立控件与被控元素之间的显式关联。
• role="textbox"：为 显式声明角色，尤其是在非表单上下文中，可以避免某些读屏软件把它误读成普通文本。
• ❌ 这里要特别提醒一下：不要滥用 aria-haspopup。它适用于菜单、下拉等弹出式内容，并不适用于行内编辑切换，用了反而会造成语义混淆。

? 总结：检查清单（上线前必验）

• [ ] 按钮与输入框共用同一逻辑容器（role="group" 或 fieldset）。
• [ ] aria-expanded 与 aria-controls 成对出现，且指向的 ID 准确无误。
• [ ] 输入框获得焦点后，屏幕阅读器能播报明确的引导语（通过 aria-live 实现）。
• [ ] 支持 Tab / Shift+Tab 键盘导航，Esc 和 Enter 键的响应符合预期。
• [ ] 使用 Chrome DevTools 的 Accessibility Inspector，或者直接用 NVDA/JAWS 实测播报逻辑。
• [ ] 移动端 VoiceOver 也要测试，确认双击激活与编辑流程是否连贯。

照着这套模式来，不仅能稳稳通过 WCAG AA 级的审计，更重要的是，能让所有用户——无论是否依赖辅助技术——都获得一致、可预测、可掌控的交互体验。