表单错误提示必须用strong而非b，因strong触发屏幕阅读器加重朗读和停顿，支持WCAG合规；b仅视觉加粗，无语义，易致无障碍失败。
表单错误提示必须用 strong，不能用 b
错误提示不是“看起来醒目就行”，而是用户（尤其是视障用户）依赖的关键反馈信号。strong 会触发屏幕阅读器加重朗读、插入停顿，b 则完全被平读过去。比如提交失败时：<strong>邮箱格式不正确</strong> 是合规写法；换成 <b>邮箱格式不正确</b>，WCAG 1.3.1 检查直接报错。
常见踩坑点：
- 富文本编辑器点“加粗”按钮，默认输出
b，上线前没做后处理替换 - 用 JS 动态插入提示时手快写了
el.innerHTML = '<b>请填写</b>'，实际应为<strong> - 把
strong当成“加粗开关”，整段校验文案全包，反而稀释语义密度
strong 的合法嵌套和语义层级要克制
strong 允许嵌套，但不是“越套越重要”。<strong>删除<strong>后不可恢复</strong></strong> 中内层表示后果的强化，有逻辑递进；而 <strong><strong>危险</strong></strong> 纯属冗余，读屏器不会叠加停顿，SEO 工具可能判定为关键词堆砌。
真正需要多层强调的场景极少，多数时候单层 strong 已足够表达风险等级。嵌套前先问：这个子句是否在信息结构中独立承担更高权重？
立即学习“前端免费学习笔记（深入）”；
b 的可用场景其实非常窄，多数该换 CSS
b 在 HTML5 中明确定义为“无语义的视觉加粗”，它不参与可访问性链路，也不影响 SEO。合法使用仅限于：产品型号首次出现（如段落中第一次提 <b>iPhone 16 Pro</b>）、代码块里纯样式突出命令词（<pre>git <b>commit</b> -m "fix"</pre>）。
但要注意：
- 这些场景更推荐用
class="highlight"+ CSS 控制，而非依赖b - 给
b设置font-weight: normal是自相矛盾的操作 - CMS 或低代码平台里，“加粗”功能若默认输出
b，且项目有无障碍要求，必须确认能否配置或拦截替换
CSS 覆盖 strong 时别误判它“失效”
全局重置了 font-weight: 400 后，strong 看起来没加粗，不是标签坏了，是 UA 默认样式被覆盖了。语义仍在 DOM 中，只是视觉锚点丢失。
稳妥做法是显式声明：
strong {
font-weight: 600;
/* 避免用 inherit 或 normal，否则等于主动放弃语义对应的视觉反馈 */
}如果项目用 Design Token，确保 strong 映射到 font-weight-emphasis，而不是随意指派为 heading 字重。
真正容易被忽略的不是“选哪个标签”，而是语义如何贯穿整个技术链路：从富文本编辑器的输出规则、JS 动态插入逻辑，到自动化文档解析工具是否能识别 strong 标记的必填字段——这些地方一旦断开，strong 就只剩一个空壳。
