fieldset 必须搭配非空且为首个子元素的 legend 才能激活语义、键盘导航和原生 disabled 行为；legend 位置错误、为空或嵌套标签均导致可访问性失效，且 fieldset[disabled] 仅禁用直接子级标准表单控件。
fieldset 不是用来“加个边框”的视觉容器，它只有配对非空且为首个子元素的 legend 时，才真正激活语义、键盘导航和原生 disabled 行为。漏写、错位或空 legend，等于没写。
为什么legend必须是fieldset的第一个子元素
浏览器和读屏软件（如 NVDA、VoiceOver）只按 DOM 顺序绑定可访问性名称：它们扫描 fieldset 开头，遇到第一个 legend 就把它当作整组的标题。一旦中间插了 div、p 或 input，语义链就断了。
-
<fieldset><input name="email"><legend>邮箱信息</legend></fieldset>—— Chrome/NVDA 可能完全忽略该组 -
<fieldset><legend></legend><input name="email"></fieldset>—— 屏幕阅读器播报“空白分组”，比不写更误导 -
<fieldset><legend><h3>邮箱信息</h3></legend><input name="email"></fieldset>——h3干扰名称提取，部分读屏器跳过或静音 - 正确写法：
<fieldset><legend>邮箱信息</legend><input name="email"></fieldset>，纯文本、无嵌套、无空格占位符
fieldset[disabled]到底禁用了什么
加 disabled 属性不是“变灰样式”，而是触发原生表单行为：所有**直接子级的标准表单控件**自动失效、无法聚焦、提交时值被排除。但这个机制有明确边界，极易踩坑。
- 生效：直接子级的
input、select、textarea、button、input[type="radio"]组 - 不生效：
<div><input></div>中的input（div阻断继承链）、contenteditable元素、自定义 Web Component -
label点击行为在 Chrome 和 Firefox 中不一致：Chrome 允许穿透到内部控件（即使disabled），Firefox 完全拦截，务必真机测试 - 被禁用的控件值不会出现在
FormData或form.serialize()结果中；若业务要求提交，需 JS 手动补全，例如formData.append('email', input.value)
嵌套fieldset的隐患与替代方案
嵌套本身合法，但 ≥3 层极易破坏键盘 Tab 导航流，尤其当某层 legend 缺失、为空或被隐藏时，焦点可能卡住出不来——用户“进得去、出不来”。
立即学习“前端免费学习笔记（深入）”；
- 每层都必须有语义明确的
legend，且legend内不能放任何可交互元素（如button、input） - UI 框架（如 Ant Design、Bootstrap）常剥离
fieldset和legend，仅保留视觉结构；打开开发者工具检查渲染后 DOM，确认标签真实存在且未被 JS 清除 - 若框架不支持，绕过其表单组件，手写原生
fieldset+legend，再用 CSS 微调样式 - 优先用单层
fieldset分组，靠 CSS（如margin、border-bottom）做视觉分隔更稳妥
视觉隐藏legend但保留语义的正确做法
有些设计要求“不显示标题文字”，但又不能丢掉可访问性。这时候绝不能用 display: none 或 visibility: hidden —— 它们会彻底移除语义。
- 标准做法是用
clip技巧：position: absolute; clip: rect(1px, 1px, 1px, 1px); - 或者使用通用的
.visually-hidden类（内部也是基于clip+position） - 避免用
transform: translateY(-100%)或opacity: 0，前者可能影响焦点逻辑，后者仍会被读屏器朗读 - 如果只是纯说明文字（无交互控件），改用
div+aria-describedby更合适，别硬塞进fieldset
最常被忽略的是：每个 fieldset 必须至少包含一个可聚焦控件（input、select 等），否则浏览器可能忽略其分组语义，甚至不渲染默认边框——它需要实际参与交互的元素来“激活”分组逻辑。
