表单摘要必须用 aria-describedby 显式关联且 ID 严格匹配，动态内容需配合 aria-live="polite"；摘要区域应包裹在 <div role="region" aria-labelledby="summary-label"> 中，提交按钮也须关联同一摘要 ID。
表单提交前用 aria-describedby 关联摘要区域
用户没看清就点了提交，不是他们手快，是摘要没真正“被读到”。屏幕阅读器只会在聚焦表单控件时自动朗读 aria-describedby 指向的内容，而不是靠视觉位置猜测。必须显式绑定，不能只靠 DOM 邻近或 CSS 浮层。
-
aria-describedby的值必须严格匹配摘要区域的id，大小写、空格、连字符一个都不能错 - 摘要区域建议用
<div role="region" aria-labelledby="summary-label">包裹，避免被当成普通文本跳过 - 不要把摘要放在
<fieldset>外面再用 CSS 拉进来——视觉上近，AT（辅助技术）眼里远 - 如果摘要内容动态变化（比如选了不同选项后提示不同），记得同时调用
aria-live="polite"
用 aria-live 实时更新关键确认信息
用户改选地址类型、切换发票开关时，摘要文字变了，但焦点还在输入框里，屏幕阅读器不会主动重读。这时候静态的 aria-describedby 就失效了，得靠 aria-live 推送变更。
- 设为
aria-live="polite"，避免打断用户当前操作；别用assertive，否则可能强行中断语音 - 摘要容器必须有稳定
id，且不能在每次更新时被整个innerHTML替换——那样会重置 live 区域状态 - 更新内容尽量简短，例如“已选电子发票，发送至 test@example.com”，超过两句话容易被截断或忽略
- ChromeVox 和 NVDA 对
aria-live的触发时机略有差异，务必在两者中都测试光标离开/选项切换两个动作
避免用 title 属性做确认提示
title 在多数屏幕阅读器中默认不朗读，尤其在表单控件上，它常被忽略或仅作为悬停补充。把它当摘要用，等于没写。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 移动端几乎不触发
title，iOS VoiceOver 默认关闭该行为，Android TalkBack 也不支持自动播报 - 即使开启，
title文本会被截断（通常限 100 字符内），长摘要直接变“已选……” - 和
aria-describedby混用会导致重复播报——一个读 label + title，一个读 label + describedby，用户听两遍 - 真要用提示，优先走
aria-describedby+ 真实 DOM 节点，其次考虑aria-label（仅限无可见标签的极端情况）
提交按钮需明确关联摘要，而非仅靠位置
很多人把摘要放按钮上方，觉得“看着近就等于有关联”，但 AT 不看布局，只认语义连接。按钮本身没描述，用户按下去前根本不知道自己确认了什么。
立即学习“前端免费学习笔记（深入）”；
- 给提交按钮加
aria-describedby="summary-id"，和输入框用同一个摘要 ID，确保焦点落到按钮时也能听到确认内容 - 不要只给按钮加
aria-label="提交订单（电子发票已选）"——这种硬编码无法响应动态变化 - 如果摘要含多个要点（如“收货地址：北京朝阳区…｜发票类型：电子｜金额：¥299”），确保每个分项用
<br>或<p>分隔，否则可能连成一句难懂长串 - 部分旧版 JAWS 对按钮上的
aria-describedby支持不稳定，可额外加aria-labelledby="btn-label summary-id"做兼容
最常漏掉的是摘要区域本身的可访问性角色——没加 role="region" 或 aria-labelledby，它就只是段落，不会被识别为独立信息区块。用户想回头再听一遍确认内容时，根本找不到入口。
