设计师Eric谈如何让LLM全屏聊天体验更易用

关于作者 Eric 是一位常驻波士顿的设计师，致力于打造直截了当的解决方案，满足人们在实用、身体、认知和情感层面的需求。 了解更多关于 Eric ↬ 每周推送的前端与 UX 技巧。 已有 182,000+ 人信赖。

可访问性是功能性数字体验的核心组成部分。随着 LLM 聊天模式在网络上迅速蔓延，如果我们不把可访问性作为核心考量来构建这些体验，就有可能将一部分人排除在外。

这里也值得再次强调“排除”意味着什么：它意味着知识的丧失、机会的丧失、实用性的丧失、就业能力的丧失、娱乐的丧失，等等。

“沉浸式 LLM 聊天体验”是一个统称，指 Claude、ChatGPT、GitHub Copilot、Gemini、America.gov、Glean 等类似网站和 Web 应用那样的全屏体验：

本文涵盖的大部分内容同时适用于 Web 应用和原生应用。这是因为这类体验通常使用 Web 技术构建，然后通过 Electron 或 Tauri 等框架放入原生外壳中。

沉浸式 LLM 聊天体验不包括弹出式聊天、内联文本生成工具或摘要工具等模式。这些 LLM 技术的较简单应用会有不同的考量和期望。相反，本文是让那些其他体验变得可访问的起点。

从《Web 内容可访问性指南》的视角来看，基于聊天的 UI 并没有什么特别之处。它们是使用 Web 技术构建的交互式体验。我所描述的损失——以及与之相关的法律责任——与其他任何 Web 内容可能构成的访问障碍一样，都是访问障碍。

我还想在这里提一下残疾的社会模型：即排除可能由建成环境造成的这一理念。例如，设想一个用缓坡代替台阶的高架入口。

建成环境也延伸到数字体验，社会模型同样适用于此。操作 LLM 聊天所进行的主要活动早已确立：

关键在于我们如何促进——或未能促进——这些交互。

每周一次。实用的前端与 UX 技巧。已有 207,000 位友好人士信赖。

在进入技术层面之前，我们必须考虑渗透在软件创作中的压倒性视觉偏见。

我们生活在一个高度视觉化的文化中，因此我们的产出会无意识地反映并强化这一点。我们需要做的是意识到并思考非视觉层面的考量。

虽然并非所有残疾都是失明或低视力状况，但 LLM 聊天的许多核心交互确实需要针对这两类残疾做出特定适配。

回想一下这里提到的残疾社会模型，以及它如何适用于使用基于 LLM 的聊天的主要流程。你：

让我们在高层面上演示一下，能完全看到屏幕的人与使用屏幕阅读器、看不到整个屏幕或大部分屏幕的人所经历的体验有何不同：

在视觉上，我们可以看到 LLM 的回复出现。使用屏幕阅读器的人不知道有新内容出现，因为：

那么，我们如何为使用屏幕阅读器的人创造一种与能完全看到屏幕的人等效的体验？首先，我们使用 live region。

live region 播报可以让用户无需将焦点从用于输入提示的输入框移开，就能知道 LLM 回复了什么。这相当于能看到屏幕的人在 LLM 回复出现时抬眼阅读。

首先，如果这是你第一次尝试让 live region 播报正常工作，请阅读 TetraLogical 的这篇优秀文章。它们很难做对，而这篇文章澄清了误区。

我想特别提请注意一个常见的陷阱：在每条 LLM 回复消息上应用 aria-live。不要这样做。相反，使用一个专门的 live region 区域来播报每条消息的内容。

live region 区域应放在 DOM 的末尾，并用于所有 live region 消息。这种方法要稳定可靠得多，这对于确保每个人都理解体验所传达的内容很重要。

在此基础上：我们想要做的是，当 LLM 的聊天回复完整显示在屏幕上时，触发一次 live region 播报。

这样就能实现一个结果：能看到屏幕的人可以阅读消息，看不到的人可以听到或通过触觉感受到消息。

在为依赖这些 live region 播报的人创造良好用户体验时，有几件事要做。这些考量决定了结果是“合规但不可用”还是真正对使用者有效。

试图在消息流式传输时就播报，可能会造成抖动且令人困惑的体验，让人难以理解。

更好的做法是等到消息流式传输完成，然后完整播报消息内容。

LLM 的回复通常需要时间才能完成。一般来说，有三种方式表明回复仍在处理中：

这些体验通常只以视觉方式呈现。如果你看不到屏幕，可能会感觉体验停滞或崩溃了——尤其是当回复针对的是需要较长时间处理的大型或复杂请求时。

为解决这个问题，我们需要使用 live region 播报：

如果屏幕上以视觉方式显示文本：确保在显示加载消息文本的同时也触发配套的 live region 播报。live region 播报的文本字符串应与视觉显示的内容相同，以确保体验的一致性：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）