<fieldset>+<legend>是唯一能为表单字段组提供语义归属的原生方案，必须作为<fieldset>首个子元素且仅一个，纯文本内容，不可用ARIA覆盖或CSS破坏其DOM位置与语义绑定。
直接加 <legend> 是最有效、最低成本的改进方式，但必须配合 <fieldset> 且放在第一位，否则屏幕阅读器会跳过或误读。
为什么单靠 label 不够用
表单字段多时，仅靠每个 <label for="xxx"> 只能告诉用户“这个输入框叫什么”，但无法说明“它属于哪一组、为什么和旁边几个字段一起出现”。比如「收货地址」区块里有省、市、区、街道四个输入框，屏幕阅读器逐个读出“省”“市”“区”“街道”，缺乏上下文，用户容易迷失位置和目的。
常见错误现象包括：用户反复问“我现在填的是 billing 还是 shipping？”；辅助技术把多个逻辑组混成一长串无结构字段；测试中发现 WCAG 1.3.1（信息与关系）不达标。
-
<label>解决单个控件的可识别性，<legend>解决字段组的语义归属 - 嵌套
<label>（即把<input>包在<label>里）虽可行，但无法表达组间关系，且对复杂控件（如<select>多选项）支持不稳定 - 用
<h2>或<div class="group-title">替代<legend>，视觉上像标题，但不会被屏幕阅读器识别为该组的“官方标题”
<fieldset> + <legend> 的硬性规则
这不是建议，是浏览器解析和辅助技术依赖的底层约定。违反任一条，<legend> 就失去语义效力。
立即学习“前端免费学习笔记（深入）”；
-
<legend>必须是<fieldset>的第一个子元素；放后面会被忽略 - 一个
<fieldset>只能有一个<legend>；多个会导致只读第一个 -
<legend>内容必须是纯文本或行内元素（如<span>），不能含块级标签如<p>或<div> - 不要给
<legend>加aria-label或aria-labelledby—— 它本身已是可访问的标题，额外 ARIA 会覆盖原语义
示例正确写法：
<fieldset> <legend>账单地址</legend> <label for="b-street">街道</label> <input type="text" id="b-street" name="bill[street]"> <label for="b-city">城市</label> <input type="text" id="b-city" name="bill[city]"> </fieldset>
多层分组与嵌套的实操边界
真实表单常有「主组 → 子组」结构（如「支付方式」下再分「信用卡」「支付宝」），但 <fieldset> 不支持语义化嵌套——子 <fieldset> 的 <legend> 不会自动继承父级上下文。
- 浏览器和 NVDA/JAWS 等主流读屏器，对嵌套
<fieldset>的支持不一致；部分会丢弃内层<legend> - 更稳妥的做法：用单层
<fieldset>+ 清晰层级文案，例如<legend>支付方式：信用卡信息</legend> - 若必须视觉分层，可用 CSS 隐藏外层边框（
border: none），但保留 HTML 结构，确保读屏器仍能按顺序读出所有<legend> - 避免用
disabled属性禁用整个<fieldset>来控制子组显隐——这会让其中所有控件不可聚焦，也导致<legend>被静音
CSS 样式化时容易破坏可访问性的点
<legend> 默认渲染在 <fieldset> 左上角边框上，很多人第一反应是“太丑”，立刻用 CSS 覆盖。但某些改法会切断其与组的关联。
- 绝对定位
<legend>时，若脱离文档流且未配position: relative在父<fieldset>上，部分读屏器可能无法将其绑定到该组 - 用
clip-path或visibility: hidden隐藏<legend>再用伪元素重绘标题——这会让屏幕阅读器完全读不到标题 - 正确做法：用
transform: translate()微调位置，或通过padding/margin控制间距，保持其 DOM 位置与语义绑定不变 - 颜色对比度低于 4.5:1 会违反 WCAG 1.4.3，但更隐蔽的问题是：用
background-color盖住默认边框后，若未重设border，<legend>可能视觉悬浮、失去锚点感
复杂表单的屏读体验瓶颈，往往不在技术上限，而在是否愿意把 <legend> 当作必填字段来对待——它不渲染在界面上最显眼的位置，但却是辅助技术唯一能用来构建表单心智地图的坐标原点。
