fieldset 不可被 div+ARIA 替代，因其是唯一被主流屏幕阅读器一致识别为逻辑控件组的原生元素，能传递 legend 语义、影响表单提交及 form.elements 枚举。

为什么

和

不能被

+ARIA替代

因为浏览器和辅助技术只认 DOM 语义结构，不解析 CSS 类名或 role 属性是否“看起来像分组”。fieldset 是唯一被所有主流屏幕阅读器（NVDA、JAWS、VoiceOver）一致识别为“逻辑控件组”的原生元素；而 div 加 role="group" 只能触发基础分组播报，无法传递 legend 的标题语义，也不能影响表单提交行为或 form.elements 的分组枚举。

常见错误现象：

• fieldset 缺失闭合标签，导致后续所有表单控件被吞进该组，form.elements 返回错乱顺序
• 用 legend 包裹 h3 或图标，使可访问性名称为空或被截断
• 把 legend 放在 fieldset 中间或末尾，VoiceOver 直接跳过整组

实操建议：

• legend 必须是 fieldset 的第一个子元素，且内容为纯文本（无空格、无换行、无嵌套标签）
• 若需视觉隐藏但保留语义，用 clip-path: inset(100%) 或 position: absolute; left: -9999px，别删掉 DOM 节点
• React/Vue 中动态生成时，确保 id 和 for 值严格同步，避免大小写/下划线差异

单选/复选框组必须用

包裹的三个硬性原因

不是“建议”，而是浏览器行为强制要求：没有 fieldset，同一 name 下的多个 input[type="radio"] 在 form.elements 中仍被当作独立控件，JS 获取值时只能拿到最后一个；后端收到的也仅是单个值，而非预期的互斥选择结果。

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

使用场景中容易忽略的细节：

html-ppt-to-pdf

将使用 `

` 约定的 HTML 幻灯片转换为高保真、矢量文本 PDF（使用 Playwright + Chromium 原生 PDF 功能）。

下载

• 移动端 VoiceOver 进入 fieldset 时会自动朗读 legend，离开时再读一次——这是唯一能建立“上下文锚点”的机制
• 当组内含描述性文字（如“勾选即同意条款”），必须放在 fieldset 内但 legend 外，否则会被误读为标题的一部分
• 禁用整组时，用 fieldset[disabled] 比循环设每个 input.disabled = true 更可靠，但要注意 Chrome 旧版对 button[type="submit"] 的异常触发

aria-labelledby 和 aria-describedby 在分组中的实际效力边界

aria-labelledby 和 aria-describedby 是补丁，不是骨架。它们无法替代 fieldset+legend 提供的结构性分组能力，仅适用于已有语义结构但需补充说明的场景。

参数差异与风险点：

• aria-labelledby 引用多个 ID 时，值必须用空格分隔（不是逗号），且顺序决定屏幕阅读器播报顺序
• aria-describedby 只触发一次性播报，用户导航到组内第二个复选框时，不会重读关联说明，上下文立即丢失
• 若 legend 已存在，再加 aria-labelledby 指向同一元素，部分旧版 JAWS 会重复朗读两次

性能影响：这些属性本身无性能开销，但滥用会导致辅助技术缓存失效、重算名称树，尤其在动态渲染大量分组时响应变慢。

多层嵌套分组时 legend 的命名与焦点管理陷阱

嵌套 fieldset 不是禁止，而是极易出错。NVDA 在深度 >2 的嵌套中可能跳过中间 legend，导致“支付方式 > 信用卡 > Visa”变成“支付方式 > Visa”，丢失关键层级。

可操作方案：

• 优先拆解为平级 fieldset，用视觉样式（如缩进、边框）模拟嵌套感，而非 DOM 嵌套
• 必须嵌套时，每个 fieldset 都要有非空 legend，且内容需体现完整路径，例如外层写“支付信息”，内层写“信用卡详情（Visa/Mastercard）”
• 键盘焦点进入最内层 fieldset 时，不要自动聚焦第一个控件——这会打断用户对上层 legend 的接收；应保持焦点在 legend 文本上，由用户按 Tab 主动进入

复杂点在于：可访问性不是加多少 ARIA 就能解决的，而是从第一层 fieldset 开始，每一步结构选择都在决定后续所有交互路径是否成立。漏掉一个 legend，整组就对屏幕阅读器用户“隐形”了。