fieldset和legend是唯一能真正实现语义化表单分组的原生html方案，legend必须为首个子元素且纯文本，否则屏幕阅读器无法识别分组；disabled仅禁用直属子级表单控件，不穿透div，且空legend或错序会导致语义失效。
fieldset 和 legend 是唯一能真正实现语义化表单分组的原生 HTML 方案，不是加边框的视觉容器——它直接影响可访问性、form.elements 的结构、FormData 提交逻辑，以及键盘导航流。
为什么 legend 必须是 fieldset 的第一个子元素
浏览器和读屏软件靠 legend 文本识别这组控件的用途，它是该分组的可访问性名称（accessible name）唯一来源。顺序错或内容空，整组就“失活”了。
-
<fieldset> <input name="email"><legend>邮箱信息</legend> </fieldset>—— 语义断裂，Chrome/NVDA 可能完全忽略该组 -
<fieldset> <legend></legend> <input name="email"> </fieldset>—— 屏幕阅读器播报“空白分组”，比不写更误导 -
<fieldset><legend><h3>邮箱信息</h3></legend></fieldset>——h3干扰名称获取，部分读屏器跳过或静音 - 正确写法：
<legend>邮箱信息</legend>，纯文本、无嵌套、前后无空格
fieldset[disabled] 禁用整组时哪些控件真失效
原生 disabled 属性只作用于 fieldset 的**直接子级标准控件**，且有明确继承边界。
- 生效：直接子级的
<input>、<select></select>、<textarea></textarea>、<button></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 导航流，尤其在移动 Safari 或旧版 Edge 中更明显。
- 某层
legend缺失、为空或被display:none隐藏时，焦点可能卡在某一层出不来 - 深层嵌套会让键盘用户陷入“进得去、出不来”的状态，尤其当某层没可聚焦控件时（
fieldset至少得有一个input/button等才构成有效分组） - UI 框架（如 Ant Design、Bootstrap）常剥离
fieldset和legend，仅保留视觉结构——打开开发者工具检查渲染后 DOM，确认标签真实存在且未被 JS 清除 - 若框架不支持，绕过其表单组件，手写原生
fieldset+legend，再用 CSS 控制样式
最常被忽略的一点：如果只是视觉分组（比如纯展示、无交互），用 div + CSS 更轻量，别硬套 fieldset；一旦用了，就必须配对非空 legend，否则等于没写。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
