嵌套 fieldset 虽合法但语义支持差：读屏器常忽略中间层 legend，焦点流不一致，dom api 无法获取深层控件，且禁用与渲染存在兼容问题；推荐单层 fieldset 配合 aria-labelledby、平级 fieldset 加 aria-describedby 或 radio 组动态显隐来替代。

fieldset 嵌套本身合法，但浏览器和读屏软件对多层 legend 的支持极弱——嵌套层级一深，外层 legend 很可能被跳过，内层分组语义反而被削弱。

为什么

嵌套容易让屏幕阅读器“迷路”

多数主流读屏器（NVDA、VoiceOver）只识别直接子 fieldset 的 legend，不会递归解析嵌套结构。例如三层嵌套时，第二层 legend 可能被忽略，用户听到的只是“收货地址”→“电话”→“邮箱”，中间“国内/国际”这个逻辑分支完全丢失。

更麻烦的是：Chrome 和 Safari 对嵌套 fieldset 的焦点流处理不一致，键盘 Tab 顺序可能跳过某一层，或把整个嵌套块当单个可聚焦项。

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

• 嵌套后 fieldset.elements 只返回直属子控件，不包含深层嵌套内的 input
• 禁用外层 fieldset 时，部分安卓 WebView 不会级联禁用最内层控件
• legend 在嵌套中若未显式设 display: block，Firefox 可能将其渲染为 inline，导致文字错位甚至溢出

替代嵌套的三种可行方案

真正需要表达层级关系时，优先用结构清晰、语义明确、辅助技术友好的方式，而不是硬套嵌套 fieldset。

• 用单层 fieldset + h3 或 h4 做视觉副标题，并通过 aria-labelledby 显式绑定到对应控件组（如 <div aria-labelledby="subhead-1">...</div>）
• 拆成多个平级 fieldset，用 CSS Grid/Flex 控制视觉间距与缩进，再靠 aria-describedby 关联上下文（例如“以下为国际收货信息，需填写护照号”）
• 对强逻辑分支（如“支付方式：信用卡 / PayPal / 银行转账”），改用 radio 组 + fieldset 包裹每个选项的子表单，用 JS 控制显隐 —— 这样每组仍是独立语义单元

如果非嵌不可，必须守住这三条线

真有遗留系统或特殊交互必须嵌套，那就得手动补全语义链，不能依赖浏览器自动推断。

• legend 必须是每一层 fieldset 的第一个子元素，且文本不可为空；哪怕写 <legend>（国际）</legend> 也比留空或用 span 强
• 外层 fieldset 加 aria-label，内容要概括整层意图（如 aria-label="国际订单信息：含清关与币种选择"），弥补嵌套导致的语义衰减
• 所有嵌套 fieldset 内部至少含一个可聚焦控件（input、select 等），纯 div 或 p 会导致该层被跳过

复杂分组真正的难点不在 HTML 标签怎么嵌，而在于如何让「人」和「机器」同时理解同一套逻辑。用多层 fieldset 换来的那点视觉缩进，往往要靠三倍的 ARIA 补丁和测试成本来填坑。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！