fieldset 嵌套语法合法但不可靠，会导致语义断裂、焦点混乱、控件不可访问；≥2层时问题集中爆发，读屏器仅识别直接子legend，elements不包含内层控件，禁用不级联，键盘导航易卡死。

fieldset 嵌套在语法上合法，但实际不可靠

HTML 标准允许 fieldset 嵌套，浏览器也不会报错或拒解析。但「能写」不等于「能用」——嵌套后语义断裂、焦点混乱、控件不可访问是常态，尤其 ≥2 层时问题集中爆发。

• 读屏器（NVDA、VoiceOver）通常只识别 fieldset 的**直接子级** legend，嵌套层的 legend 很可能被完全跳过
• fieldset.elements 只返回直属子控件，内层 input、select 等不会出现在该集合中
• 禁用外层 fieldset 时，部分安卓 WebView（如旧版 Chromium 内核）不会级联禁用最内层控件，导致逻辑与 UI 不一致
• legend 若未显式设 display: block，Firefox 可能渲染为 inline，文字错位甚至溢出边框

为什么键盘 Tab 导航会卡在嵌套 fieldset 里

Chrome 和 Safari 对嵌套 fieldset 的焦点流处理策略不同：Chrome 可能将整个嵌套块视为一个可聚焦项，Safari 则倾向逐层进入但难以退出；一旦某层缺失 legend 或其内容为空/隐藏，Tab 键极易卡死在内层，用户无法继续导航。

• ≥3 层嵌套时风险陡增，尤其当某层仅含 div 或 p（无任何可聚焦控件），该层会被辅助技术彻底忽略，焦点链中断
• 即使视觉上正常，tabindex 在嵌套结构中行为不可预测，不建议手动干预
• 测试时务必用真实键盘操作，不能只依赖鼠标点击或 DevTools 检查 focus 状态

替代嵌套的三种实用方案

真正需要表达层级关系时，优先放弃嵌套，改用语义清晰、辅助技术友好的组合方式。

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

• 对强逻辑分支（如“支付方式：信用卡 / PayPal / 银行转账”），用 radio 组 + 独立 fieldset 包裹每种子表单，配合 JS 控制显隐 —— 每组保持完整语义单元
• 做视觉副标题（非语义分层），用平级 fieldset + aria-describedby 关联说明性文本，避免引入额外分组层级
• 需跨区域关联时，用 aria-labelledby 指向页面中其他已有标题元素（如 h2），不依赖 legend 生成新语义

如果非嵌不可，必须手动补全语义链

遗留系统或特殊交互强依赖嵌套时，不能指望浏览器自动推断，必须显式加固语义。

立即学习“前端免费学习笔记（深入）”；

• 每一层 fieldset 必须有非空、有意义的 legend，且内容要概括整层意图（例如 <legend>国际收货信息</legend>，而非模糊的“更多”）
• 每层至少含一个可聚焦控件（input、select、button 等），纯展示性 div 或 p 会导致该层被跳过
• 禁用控制必须用 JS 手动遍历并设置内层控件的 disabled 属性，不能只依赖外层 fieldset 的 disabled

嵌套本身不是 bug，但它是语义脆弱点——你写的每一层 fieldset，都在增加屏幕阅读器理解失败和键盘用户迷路的概率。能扁平就别嵌套，能用 aria 就别硬塞 legend。