aria-live的polite与assertive模式的区别在于更新信息的紧急程度和干扰性。1.polite模式会延迟播报，等待用户完成当前操作后再通知，适合非紧急信息；2.assertive模式则立即中断用户当前任务进行播报，适用于需要紧急关注的信息。正确使用这两个模式能提升辅助技术用户的体验，避免不必要的干扰。
在HTML中正确使用aria-live区域，核心在于让辅助技术（如屏幕阅读器）能够感知并播报页面上动态变化的内容，从而确保用户不会错过重要的信息更新。它就像给屏幕阅读器一个信号，告诉它：“嘿，这里有东西变了，你可能需要告诉用户。”
解决方案
aria-live属性用于指示一个区域的内容是否会动态更新，以及这些更新的重要性。它有三个主要值：
-
off：默认值，表示辅助技术不应中断用户来宣布此区域的更新。 -
polite：表示辅助技术应在用户当前任务完成后宣布此区域的更新。这适用于非紧急的、背景式的更新，例如聊天消息、股票价格变动或进度条更新。 -
assertive：表示辅助技术应立即中断用户当前任务，并宣布此区域的更新。这适用于紧急的、需要用户立即注意的信息，例如表单验证错误、系统警报或关键状态变化。
通常，我们会将aria-live属性添加到一个容器元素上，例如<div>或<code><span></span>，当这个容器内部的内容发生变化时，屏幕阅读器就会根据aria-live的值来决定如何播报。
立即学习“前端免费学习笔记（深入）”；
<!-- 示例：polite 模式，用于非紧急通知 -->
<div aria-live="polite" id="status-message">
<!-- 动态更新的内容，例如：文件已保存 -->
</div>
<!-- 示例：assertive 模式，用于紧急错误提示 -->
<div aria-live="assertive" id="error-message" style="color: red;">
<!-- 动态更新的内容，例如：密码错误，请重新输入 -->
</div>在使用JavaScript更新这些区域的内容时，屏幕阅读器就会根据aria-live的设置进行播报。记住，这个区域必须在DOM中存在，即使最初是空的，这样屏幕阅读器才能“监听”它的变化。
aria-live的polite与assertive模式有何区别？
理解polite和assertive之间的差异是正确使用aria-live的关键。这两种模式反映了内容更新的“紧急程度”和对用户体验的“干扰程度”。
polite模式，顾名思义，它非常有礼貌。当屏幕阅读器用户正在阅读或与页面上的其他元素交互时，如果aria-live="polite"的区域内容发生变化，屏幕阅读器会等到用户完成当前操作，或者在用户暂停时，再播报这些更新。它不会打断用户的思绪，就像一个轻声细语的通知，告诉你“嘿，这里有新消息了，等你忙完可以看看”。这非常适合那些不需要用户立即响应的信息，比如实时聊天的新消息、一个自动刷新的新闻列表、或者一个后台任务完成的提示。如果我正在填写一个复杂的表单，我肯定不希望屏幕阅读器因为一个不重要的更新而突然打断我。
而assertive模式则截然不同，它更像一个“紧急警报”。当aria-live="assertive"的区域内容发生变化时，屏幕阅读器会立即中断当前正在播报的内容，转而播报这个区域的更新。这种中断是强制性的，意味着它会打断用户的任何当前操作或阅读流。因此，assertive模式应该只用于那些非常关键、用户必须立即知道并可能需要立即采取行动的信息。最典型的例子就是表单验证错误信息、系统级的严重警告、或者操作失败的提示。想象一下，你提交表单，系统告诉你“用户名已被占用”，这显然比一个“文件正在上传”的提示更需要即时关注。过度使用assertive模式会极大地干扰用户体验，让屏幕阅读器变得非常“吵闹”，甚至可能导致用户直接关闭它。所以，我的经验是，能用polite就用polite，assertive是最后的选择。
何时应结合使用aria-atomic和aria-relevant？
aria-atomic和aria-relevant是aria-live的补充属性，它们提供了更精细的控制，决定了当实时区域内容变化时，屏幕阅读器应该播报哪些部分。这对于确保信息传达的准确性和避免冗余播报至关重要。
aria-atomic（默认值为false）告诉屏幕阅读器，当实时区域内容更新时，是应该将整个区域作为一个整体来播报，还是只播报发生变化的部分。如果设置为true，即使只更新了区域内的一小部分文本，屏幕阅读器也会播报整个aria-live区域的完整内容。这在某些情况下非常有用，例如一个包含“用户名：[用户名称]”的区域，如果只更新了用户名称，但你希望屏幕阅读器仍然播报“用户名：”这个前缀，以提供完整的上下文。
aria-relevant（默认值为additions text）则指定了哪些类型的变化应该触发播报。它的值可以是additions（新增内容）、removals（移除内容）、text（文本内容变化），或者它们的组合，例如additions text。你也可以使用all来表示所有类型的变化。
举个例子，假设你有一个购物车总价的显示区域，像这样：<div aria-live="polite" aria-atomic="true" id="cart-total">购物车总计：<span>$120.00</span>
</div>。当商品数量变化导致总价从$120.00变成$150.00时，如果aria-atomic="true"，屏幕阅读器会播报“购物车总计：$150.00”，而不是仅仅播报“$150.00”，这提供了更清晰的语境。
再比如，一个动态日志区域，你可能只关心新增的日志条目，而不关心旧条目的移除，这时你可以设置aria-relevant="additions"。如果这个日志区域会显示时间戳和具体事件，并且你希望屏幕阅读器在任何文本更新时都能播报，那么aria-relevant="text"可能就更合适。
实际应用中，我发现aria-atomic="true"经常与aria-live一起使用，尤其是在播报状态消息或错误提示时，以确保整个消息都被完整地传达给用户，而不是只播报其中变化的部分。至于aria-relevant，虽然它的默认值已经覆盖了大多数常见场景，但在处理复杂、多变的动态内容时，明确指定其值能帮助你更精确地控制播报行为，避免不必要的干扰。
使用aria-live时常见的陷阱与最佳实践是什么？
即使理解了aria-live的基本用法，在实际项目中还是很容易踩到一些坑。这往往不是技术本身的问题，而是对用户体验和屏幕阅读器工作原理理解不足导致的。
一个常见的陷阱是滥用assertive模式。前面提过，assertive会打断用户。如果你的页面上到处都是assertive的实时区域，用户会感到非常沮丧，因为他们会不断被各种不那么紧急的通知打断。这就像你在图书馆里，每隔几分钟就有人在你耳边大声宣布一些小事，你根本无法集中精力。我见过一些网站，连一个简单的输入框提示都用assertive，这真是灾难。
另一个问题是实时区域的内容更新过于频繁或内容量过大。即使是polite模式，如果一个区域每秒更新几十次，或者每次更新都包含大量文本，屏幕阅读器也会持续播报，这同样会造成信息过载，让用户难以消化。设想一个实时股票价格列表，如果每只股票的价格都单独在一个aria-live区域里频繁更新，那听起来会是一团糟。
还有一种情况是实时区域在内容更新时才被添加到DOM中。aria-live区域必须在DOM中已经存在，屏幕阅读器才能“监听”它的变化。如果你通过JavaScript动态创建了一个aria-live的div，然后立即往里面填充内容，屏幕阅读器可能无法及时捕捉到这个变化并播报。最佳实践是让aria-live的容器元素始终存在于DOM中，即使它最初是空的或隐藏的。
最佳实践方面，首先，始终优先考虑使用polite模式。只有当信息确实是紧急且需要立即引起用户注意时，才考虑使用assertive。
其次，保持实时区域的内容简洁明了。播报的信息越少，用户理解起来就越容易。如果需要提供更多细节，考虑在其他地方提供链接或展开选项。
再者，确保实时区域在页面加载时就存在于DOM中，即使它是空的。你可以通过CSS将其隐藏（例如display: none;或visibility: hidden;，但要注意aria-hidden="true"是更推荐的隐藏方式，因为它明确告诉辅助技术忽略该元素），然后在需要时再通过JavaScript填充内容并显示。
最后，也是最重要的一点，进行实际的屏幕阅读器测试。仅仅在代码层面看起来没问题是不够的。下载并使用主流的屏幕阅读器（如NVDA、JAWS、VoiceOver），亲自体验你的网站，感受一下当动态内容变化时，屏幕阅读器播报的效果如何。你会发现很多在视觉层面无法察觉的问题。这不仅是遵循规范，更是真正站在用户角度去优化体验。毕竟，我们做这些，不就是为了让每个人都能更好地使用我们的产品吗？
