多步骤表单深层嵌套的HTML代码质量与DOM优化方案

在多步骤表单开发中，嵌套使用 fieldset 极易引发字段丢失与焦点跳转异常，这并非代码写法有误，而是浏览器和屏幕阅读器在底层实现上，默认不支持超过三层的 fieldset 嵌套结构。NVDA 与 VoiceOver 仅识别直接子级的 legend，第二层及更深层的 legend 几乎都会被忽略；Chrome 的 Tab 焦点流可能整块跳过，Safari 则可能将整个嵌套区块视为一个可聚焦项。更为严重的是，fieldset.elements 只返回直属子控件，深层 input 完全不在其中——JS 遍历时直接遗漏，导致表单数据丢失。

常见问题具体表现如何？用户朗读时听到“收货地址”→“电话”→“邮箱”，中间的“国内/国际”分支完全消失；document.querySelector('form').elements 无法获取嵌套结构中的 input 元素；禁用外层 fieldset 后，安卓 WebView 中的内层控件依然可操作。这些问题在开发阶段几乎不报错，上线后却集中爆发，排查起来相当棘手。

替代嵌套 fieldset 的三种实用方案

真正需要表达逻辑层级时，语义清晰比结构“看起来嵌套”重要得多。

• 采用平级 fieldset 配合 aria-describedby：视觉缩进通过 display: grid 或 flex 控制，语义层面借助属性关联上下文，例如
  国际信息

  +

  需填写护照号

• 使用 div 作为视觉副标题并结合 aria-labelledby：例如
  ，同时确保 id="subhead-1" 对应的元素为文本节点或包含文本的标签
• 强逻辑分支（如支付方式选择）改用 radio 组配合 JS 控制显隐：每组保持独立语义单元，DOM 结构平坦，form.elements 可靠，无障碍支持也更加明确

动态切换步骤时，hidden 属性比 display: none 更为可靠

hidden 是语义开关，display: none 是视觉开关，行为完全不同。

• 带有 hidden 属性的元素不参与 form.elements 遍历、不触发验证、也不会出现在 FormData 中
• 使用 display: none 的元素仍会被 new FormData(form) 序列化，提交时可能携带脏数据
• Safari iOS 9.3+ 及 macOS 10.11+ 才完全支持 hidden 属性，旧环境需降级处理：if ('hidden' in document.createElement('div')) { el.hidden = true; } else { el.style.display = 'none'; }
• 切换状态时优先修改 element.hidden = true/false，避免操作 class 或 style —— 可减少重排、防止样式冲突

多个 form 或 fieldset 共存时，定位控件需添加上下文限定

一个页面有“个人资料”“公司信息”两个区块，每个都有 email 输入框。直接用 input[name='email'] 会拿到第一个，根本不确定是哪一步的值。

• 使用 data-step 或 data-section 属性进行限定：form[data-step="2"] input[name="email"]
• 测试时优先采用 data-testid 而非 class 或 name：input[data-testid="step2-email"]
• JS 封装函数中统一调用 updateField(step, name, value)，内部通过上下文 selector 查找，避免全局污染
• 不要依赖 formdata 事件跨表单监听——它仅对当前 form 有效，且缺乏上下文标识

深层嵌套最危险之处并非渲染性能慢，而是 DOM 查找失效、状态不同步、辅助技术无法访问——这些问题在开发阶段几乎不报错，上线后却集中爆发。控制节点深度，本质上是在控制 JS 操作边界和语义可达性，而非单纯删除 div 元素。