这可能是因为aria-relevant 的“添加”定义说（强调我的）：
元素节点被添加到实时的可访问性树中
地区。
如果我从字面上理解，那么您必须添加一个新的 DOM 元素才能宣布“添加”。但听起来您只是将文本添加到 <pre> 而不是新节点。如果是这样，那么“text”应该是aria-relevant 的值。
我通常不指定aria-relevant 并使用默认的“添加文本”。如果您要将节点/子节点添加到 <pre> 并且您不希望它们被宣布，那么使用“文本”将阻止节点被宣布。但是很少有节点和文本都被添加到一个元素中并且两者都不希望被宣布。我会先从一个简单的现场区域开始，看看它听起来如何。
<pre id="winOutput" role="region" aria-live="polite" class="outputText"></pre>
顺便说一句，我会使用aria-live="polite"（如上所示），因为很少有公告如此重要以至于需要“自信”。使用“自信”can blow away 任何待处理的屏幕阅读器公告。
用户代理或辅助技术可以选择在发生断言更改时清除排队的更改。
aria-atomic 只是说是宣布只是更改还是整个文本。对于倒数计时器之类的文本从“您有 60 秒”变为“您有 50 秒”的内容非常方便。 没有aria-atomic，屏幕阅读器会宣布“You have 60 seconds”进行第一次更改，然后仅显示“50”进行第二次更改（因为“50”是句子中的全部变化）。 使用aria-atomic="true"，第二个更改将宣布为“你有 50 秒”。
更新：
回答 cmets 部分的几个问题。
如果您依靠“自信”来清除待处理的公告，请回到我之前的报价：
用户代理或辅助技术可以选择在发生断言更改时清除排队的更改
规范中的“MAY”是大写的。我没有强调这一点。因此，这表示待处理的公告可能会被清除，也可能不会。这取决于浏览器和/或屏幕阅读器。无法保证它们会被清除，因此您不能依赖这种行为。
关于role="log"，spec 说
具有log 角色的元素有一个隐含的aria-live 值礼貌。
所以如果你同时拥有role="log" 和 aria-live="assertive"，那么你会得到什么行为是不确定的。您有竞争的 aria-live 值。
如果你有role="alert" 和aria-live="assertive"，那么aria-live 是多余的。您已经通过警报获得了该设置。
如果您指定任何类型的role不是活动区域（即不是警报、日志或状态），那么它不应该影响aria-live 是否被接受。但是您必须非常仔细地阅读spec for aria-live。有很多警告说明用户代理或辅助技术应该做什么，但“应该”不是必需的。它可能会也可能不会像您希望的那样工作。规范甚至说用户的屏幕阅读器设置可能会影响 aria-live 的工作方式。
关于焦点，它确实不必必须在实时区域中才能宣布更改。这就是现场区域的伟大之处。无论焦点在哪里，他们都会在任何时候进行更改。如果设置了aria-live="off"，则焦点必须位于活动区域中的唯一时间。
因此，在您的情况下，您的示例代码看起来是正确的（现在您已确认将 DOM 元素添加到 <pre>）。我建议在几个不同的浏览器（firefox、chrome、safari）上进行测试，并尝试使用几个不同的屏幕阅读器（jaws、nvda、画外音），看看它们中的任何一个是否表现得如你所愿。