“人工智能”和无障碍前端组件：细微差别是可生成的吗？

各公司都在争先恐后地在自己的产品中添加生成式人工智能（AI）功能。有些承诺可以为你生产前端组件。考虑到无障碍性和生成式人工智能的本质，这有可能吗？这是可取的吗？

对于这两个问题，简短的回答都是否定的。风险在于：我们对技术解决方案的追求是以牺牲用户利益为代价的。

为了找出原因，让我们考虑一下：构建无障碍组件的过程在人和机器之间有何不同？我们倾向于寻求技术解决方案的道德规范是什么？

人的方式

我们先来看看流程上的差异。编写无障碍前端代码的人，主要基于以下内容来编写 HTML 元素和属性：

• 他们对规范以及它们如何协同工作（包括 HTML 和 WAI-ARIA）的理解

• 他们想要传达内容

• 他们对辅助技术如何影响他们编写的代码的理解程度

• 熟悉浏览器和辅助技术支持的知识

• 查找语法并正确应用

因此，他们将自己或他们的设计师同行想要实现的东西转化为浏览器中符合这些意图的东西。意图是这里的一个关键词。准确传达作者意图和理解用户需求对于无障碍性来说至关重要。

他们可能还会参与编写 CSS，用于颜色、排版和间距等方面的设置，所有这些都会影响网站是否为用户设置了障碍。此外，还需要添加 JS 来处理交互性内容、管理状态等。

机器的方式

使用语言模型生成代码的工具基本上是基于统计可能性来预测代码行的，有点像自动完成功能。如果输出恰好是高质量的，那基本上是巧合。系统的成功率可以（而且通常）通过训练模型来提高，特别是通过训练非常好的用例。在某些情况下，系统非常接近高质量，因为它们拥有大量的训练数据。对于无障碍性性而言，这些数据很难获得——大多数网络都存在无障碍性问题：我们在 WebAIM Million 的自动测试中看到的只是冰山的一角。

虽然人类将意图映射到交互式内容，并在这个过程中应用了他们的理解，但大语言模型（LLM）没有意图或理解。它们只是输出与某些输入最匹配的文本块。我认为这是迷人的，令人印象深刻的，而且常常类似于魔术。而且输出看起来（有时是）是可以投入生产的高质量产品。但输出也可能包含问题，也就不足为奇了。作为理性的 Web 开发人员，我们必须审视我们所造成的问题。

为了更具体地说明这一点，让我们看看 v0，这是 Vercel 基于 LLM 的代码生成器产品，Vercel 首席执行官宣称该产品为：

v0.dev 生成了我们希望在自己的 @vercel 产品中发布的生产级代码。

（来源：Guillermo Rauch 的推文，2023 年 9 月 15 日上午 12:15）

我特别提到这一点，是因为我认为像“生产就绪”这样的说法是对技术的高估和对人类需求的低估。这对人们有现实的影响。

当我读到“生产级”时，我理解的是“无障碍的”。我简要地浏览了 v0“特色”部分的前六个组件，发现每个组件都违反了 WCAG，并且存在无障碍性障碍。

一些障碍的示例：

• 在数学学习应用程序的示例中：按钮被标记为链接，进度指示有视觉展示但没有文本替代，标题被标记为 div

• 在看板示例中：项目列表未被标记为列表、列标题对比度低、缩放时存在重叠文本

• 在辅助工具示例中：覆盖了现有的快捷方式，以及图标未被标记为装饰性图标

• 在终端 UI 中：按钮未被标记为按钮

• 在定价表中：图标未被标记为装饰性图标，按钮对比度不足

• 在音乐播放器的示例中：各种按钮未被标记为按钮，有些按钮仅在键盘上不可用，但按钮没有给出可访问的名称。

这不是一次完整的一致性审查，我只是列出了一些突出的问题。我不是在攻击，我只是想确切地展示下大语言模型（LLM）输出中常见的无障碍性问题。

你可能会说这并非全然糟糕，这是真的。我也发现了很多使事物无障碍的标记，比如对各种工具导航有用的标题、良好的对比度以及有用且有效的 ARIA。但是，这种程度的无障碍性通常也存在于没有使用大型语言模型（LLM）的网站上。许多网站都有相当有用的标题，在许多元素上有很好的对比度和有效的 ARIA。问题在于那些没有到位的部分，这些是网络用户界面为残疾人创造障碍的地方。细微差别至关重要。

自信问题

生成式 AI 可以帮助编写无障碍代码吗？Léonie Watson 研究了另外三种生成式 AI（ChatGPT、Bard 和 Fix My Code）的输出。和我一样，她发现了一些不是很糟糕的东西，一些实际上很有帮助的东西，以及一些构成无障碍性问题的东西。但 Léonie 指出了一个不同的问题：这些工具倾向于表现出权威。无论它们是否具有权威性。她解释道：

除了需要检查其响应的一般性陈述之外，这些生成式 AI 工具都没有给出任何提示来表明它们的答案可能是不正确的，也没有提供任何推荐的检查资源”。

相比之下，大多数关于无障碍编码的比较好的博客文章和资源都包含了很多细微差别。它们通常不会推荐一个保证始终有效的权威解决方案（它们会使用什么定义来衡量“有效”呢？）。这反映了通常情况下制作无障碍界面所涉及的情况。这涉及到深入探索的问题。一般而言，有多种方式和多种至少不那么糟糕的结果需要在它们之间取得平衡。

好吧，但是大型语言模型（LLM）至少可以部分有用吧？

或许权威性的问题可以得到解决。我们可以调整这些工具，使其输出的响应不会表现成自以为是的万事通。但这仍然会给我们带来其他问题：难以获得的建议、缺乏意图和理解，以及缺乏创新。

谎言和幻觉

正如我在上面分享的例子和 Léonie 帖子中的例子所展示的那样，大语言模型（LLM）给出了难以理解的建议。如果这些谎言是训练数据的后果，那么理论上可以通过不同的训练数据来改进（强调“理论上”）。但这也是由于“幻觉”造成的，这是这项技术所固有的问题，研究表明 是不可避免的。它们会编造错误的内容。输出可能是无意义的。以牺牲用户为代价。这不可能改善现状：即使没有“人工智能”，网络上也有很多针对特定漏洞或问题的无障碍性提示，自动添加虚假信息和幻觉似乎是很荒谬的。

缺乏意图

大语言模型（LLM）工具没有意图，而意图对于（大多数）“无障碍编码”来说是必要的。Alastair Campbell 在他的文章《为什么人工智能不能用于生成无障碍代码》中解释说，无障碍性不是一个平均值。这使得它与使用统计方法提出的建议不兼容。

缺乏创新

虽然有很多开源组件库，但许多 UI 模式及其含义还没有被发明出来。这些假设迫切需要进行测试。依赖大语言模型（LLM）来提供建议意味着依赖（重新混合）现有知识，因此不适合创建新模式的无障碍化。

基于这三个原因，我想知道：大语言模型（LLM）在帮助我们构建无障碍前端组件方面是有用吗？如果它是有用的话，可能是在于帮助开发人员发现了确实包含细微差别的资源，而不是在代码建议方面。也许在组件代码之外还有其他用途，但那是另一篇文章的内容了（另请参阅 Aaron Gustafson 的 《人工智能在无障碍领域的机会》）。

关注的焦点

这可能是另一篇文章的主题，但我觉得我应该在这里提一下：专注于试图寻找无障碍的“修复方案”或“解决方案”，会对无障碍的本质造成误解。当我们制作网站时，我们有责任让它们变得无障碍。如果我们想尝试将这项工作外包给一个工具（我们不能信任的工具），我们就是将责任推给了残疾用户（另请参阅：针对残疾的辅助设备）。

正如 Adrian Rosellli 在 《人工智能不能解决无障碍性问题》 一书中所写的那样，无障碍性关乎结果，而非输出：

无障碍性是关于人的。（……）当我们以产出而不是以结果为目标时，我们就辜负了我们的朋友、家人、社区和未来的自己。当我们试图免除自己的责任时，我们就是在排斥‍人类同胞。（……）-+

Eric Bailey 写道：

认为人工智能将“解决”无障碍性问题是一种源于技术能力主义心态的糟糕框架。

在我看来，这个行业似乎希望有一个神奇的二元解决方案（……）就我个人而言，我希望在这里以残疾的社会模式为指导：我们到底想要“修复”什么，为什么？

总结

无障碍性通常需要的细微差别是可生成的吗？我认为不是。无论如何，这并不可靠。如果你从这篇文章中学到了一些东西，我希望是这个警告：基于大型语言模型（LLM）的工具不能成为它们承诺的编写无障碍组件代码的灵丹妙药。因为细微差别、理解和传达意图是无障碍性所固有的，因此大型语言模型（LLM）无法在组件代码的无障碍性方面提供很大帮助。此外，它们不可避免地会产生幻觉，并倾向于在输出（偶尔但真实的）谬误时摆出权威的姿态。后者可能是危险的，并且可能以牺牲用户为代价。

对于那些希望帮助构建无障碍组件的开发人员，我的建议是什么？使用一个经过人们充分测试、有良好的文档记录并且（至少）在尝试捕捉细微差别的设计系统。或者参与构建一个。并不是每个人都愿意做这项细致而精确的工作，也不是每个组织都有这样的预算。这很好，但我们并不是说它可以神奇地自动消失。让我们珍惜让网络产品真正伟大的人类努力吧。

原文链接：

https://hidde.blog/ai-for-accessible-components/

今日好文推荐

砍掉百万行代码，这些巨头开始给自家 App “割肉瘦身”

重塑 Jamstack：打造更简单、更强大的 Web 架构

尘封多年，Servo 重磅回归！Rust 加持，执行速度可超过 Chromium

沉寂 600 多天后，React 憋了个大招