legend必须是fieldset的第一个子元素，因为屏幕阅读器依赖DOM顺序将legend文本绑定为该fieldset的可访问名称，位置错误会导致整组控件失去上下文。
把 fieldset 和 legend 的配合理解为“美化技巧”是一个常见的误区。本质上，它们是语义结构与无障碍访问的刚性组合。在你动手删掉默认边框、修改样式之前，守住可访问性的底线，才是真正的第一步。
为什么legend必须是fieldset的第一个子元素
这背后不是什么浏览器兼容的小问题，而是无障碍树构建的硬性规则。屏幕阅读器——比如 NVDA 或 VoiceOver——会严格依赖 DOM 顺序，将 legend 的文本识别为这个 fieldset 分组的可访问名称。一旦放错位置，整组控件在读屏时就会失去上下文，变成一堆孤立无援的元素。
看看下面这几个典型的“翻车”例子：
- 比如写成
。猜猜会怎样？legend被一个div包裹，屏幕阅读器会直接忽略它，用户只能听到“编辑框”，却不知道要填什么地址。 - 或者像
这样，虽然legend还在，但已经不是第一个子节点。结果就是，在某些旧版本的 Safari 里，这个分组标题会被跳过不报。 - 在 React 等框架里更要小心。用 Fragment 或自定义组件包裹
legend，很容易破坏它与fieldset的直接父子关系，这跟直接移除语义标签几乎没区别。
禁用整个分组时，fieldset[disabled] 比手动加 disabled 更可靠
当需要禁用一整组表单元素时，直接给 fieldset 加上原生的 disabled 属性，往往比手动给每个控件添加要靠谱得多。这个属性会递归地禁用所有直属子级的表单控件——包括 input、select、textarea 和 button，并且会自动灰显、阻止焦点进入，还会将它们排除在提交的 FormData 之外。
- 手动操作的问题是容易遗漏，比如动态插入的控件，或者像
output、meter这类边缘元素，一不小心就忘了处理。 - 不过，
fieldset[disabled]也有它的作用范围：它不影响嵌套在div或p这些非表单语义元素里的控件。这其实是个特性而非缺陷。如果你的布局需要深层嵌套禁用，可能就需要额外的 Ja vaScript 逻辑来辅助。 - 还有个小细节值得注意：被禁用的
legend文本确实会变灰，但它本身默认仍然是可点击的（除非你额外加上pointer-events: none）。可别因为点了标题没反应，就误以为整个分组的功能失效了。
CSS 重置时最容易破坏的三个视觉线索
很多开发者在写样式时，会习惯性地来上一句 fieldset { border: none; padding: 0; }。问题来了：语义结构虽然还在，但用户却完全看不出屏幕上哪些元素是同一组的。视觉效果上的分组提示，这下得完全由你来承担了。
- 删掉边框后，至少得保留像
outline: 2px solid #999或box-shadow: inset 0 0 0 1px #ccc这样的视觉边界。否则，用户在通过键盘导航时，焦点框可能就无处附着。 legend元素默认是有margin-bottom的。如果你把所有margin和padding都清空，会导致标题紧贴在控件顶部，失去了作为标题的呼吸感。一个比较稳妥的建议是：只进行局部重置，比如legend { margin: 0.5em auto 0.75em; }。- 当
fieldset被放置在display: flex容器里时，legend很容易发生位置偏移或显示不全。这里有个小技巧：不要对legend直接使用display: flex，试试改用display: inline-flex并配合align-items: center，情况往往会好很多。
真正的难点，其实不在于第一次写对，而在于后续的迭代维护中。比如添加一个新控件、更换一套 CSS、或者把一部分逻辑抽离成 React 组件时，你是否还能记得去检查那几个关键点：legend 是否还稳稳地待在首位？fieldset 是否还包裹着所有应该属于它的元素？键盘的 Tab 键导航流是否依然连续、顺畅？这些细节，自动化工具常常难以完全覆盖，更多时候，靠的是每次代码改动后，多花那么一两秒钟，看一眼 DOM 结构的责任心。
