Let Equals Equal Equals：当封装性凌驾于无障碍访问之上

背景

在 Web 开发中，Shadow DOM（影子 DOM）被广泛用于封装组件的内部结构和样式，以实现真正的模块化。然而，当 Shadow DOM 与 ARIA（Accessible Rich Internet Applications）无障碍属性结合使用时，出现了一个令人困惑且严重的缺陷。

这篇文章源自 Hacker News 社区对 Web 平台规范（WHATWG HTML 规范）中一个特定行为的深入探讨。核心问题在于：当开发者尝试通过 JavaScript 命令式地（imperatively）设置 ariaDescribedByElements 等 ARIA 元素引用属性时，如果目标元素位于与源元素不同的 Shadow Root（影子根）中，赋值操作会静默失败（silently fails）。

这意味着浏览器接受了代码，没有抛出任何错误或警告，但属性实际上并未生效。对于依赖屏幕阅读器等辅助技术（Assistive Technology, AT）的用户来说，这意味着他们完全无法获取必要的上下文信息。这一行为违背了 W3C 设计原则中“用户优先”的核心精神，引发了关于“封装纯度”与“无障碍访问”之间权衡的激烈争论。

核心内容

1. 现象：静默失败的赋值

考虑以下 JavaScript 代码：

input.ariaDescribedByElements = [helpText];

直观上，开发者持有这两个节点，并执行了赋值操作，浏览器也接受了该语句。然而，如果 helpText 位于一个不是 input 所在 Shadow Root 祖先节点的 Shadow Root 中，赋值将被静默丢弃。

• 结果：getter 返回 null 或空数组。
• 后果：没有警告，没有错误，辅助技术用户得不到任何信息。

2. 规范中的“作用域”规则

ARIA 元素反射（Element Reflection）的规范定义了一条“作用域”规则：目标元素必须与源元素位于同一个 DOM 中，或者是源元素所在 DOM 的父级 DOM。

• 有效场景：

  • 同一 Shadow Root 内：input 和 help 在同一个 <template shadowrootmode="open"> 中，赋值成功。
  • 向上引用（Light DOM）：input 在 Shadow Root 内，而 help 在宿主元素之外的 Light DOM（更外层 DOM）中，赋值成功。

• 无效场景：

  • 兄弟 Shadow Roots：input 在 <x-input> 组件的 Shadow Root 中，而 tip 在 <x-tooltip> 组件的 Shadow Root 中。两者是兄弟关系，互不为祖先。此时赋值静默失败。

这种不一致性导致相同的 API、相同的语法、相同的意图，仅因树结构位置不同而产生截然不同的结果，且没有任何反馈告知开发者操作失败。

3. 设计初衷：防止 Shadow DOM 内部泄露

规范制定者引入这一限制的根本原因是为了维护 Shadow DOM 的封装性（Encapsulation）。

担忧的场景如下：

1. 组件内部将 ariaActiveDescendantElement 设置为 Shadow Root 内的某个子元素。
2. 外部脚本通过读取该属性，获取了对 Shadow Root 内部元素的引用。
3. 外部脚本利用该引用遍历并修改 Shadow Tree 内部结构（例如 appendChild），从而破坏了封装性。

规范作者认为，如果允许跨 Shadow Root 的 ARIA 引用，就会打开一个后门，让外部代码能够探测甚至修改组件内部实现。

4. 解决方案的权衡失误

针对“Getter 问题”（即如何安全地返回引用），WHATWG 社区（特别是 Alice Boxhall）提出了多种更优方案，但规范最终选择了一种破坏性最大的方式：

• 方案 A（推荐）：Getter 返回 null，但在内部保留对无障碍树（Accessibility Tree）的引用。这样 JavaScript 无法读取内部节点（保护封装），但辅助技术仍能正常工作（保护无障碍）。
• 方案 B（推荐）：类似事件冒泡时的“重定向”（Retargeting）。Getter 返回最近的可见宿主元素，并提供一个显式的 API（如 getAttrAssociatedElement）供已拥有访问权限的代码使用，以“撤销”重定向。
• 方案 C（补充）：使用 Reference Target 机制，由组件显式声明哪些内部元素应暴露。

然而，规范作者选择了类似“方案 0”的做法：静默丢弃 Setter 的赋值。

Alice Boxhall 在讨论中表达了强烈的挫败感：

“我同意 Nolan 的建议，开发者应该收到警告。支持跨根引用确实是我们希望该功能实现的目标；但由于其他标准工程师基于封装理由的反对，该功能现在处于一种半损坏状态。考虑到为此投入的大量工作，这非常令人沮丧，甚至我们可能根本不该尝试发布它。”

5. 命令式 API 的本质矛盾

当开发者编写 input.ariaDescribedByElements = [someNode] 时，他们已经持有这两个节点的引用。这意味着他们已经穿越了任何边界，获取了对这些节点的访问权。

• 封装性已被打破：获取节点引用的那一刻，封装性就已经被打破了。
• 静默修复无效：通过静默忽略赋值来“恢复”封装性，并不能真正恢复封装，反而破坏了无障碍访问。
• API 的设计意图：命令式 API 的存在正是为了连接属性（如 aria-describedby）无法触及的元素。如果元素在同一作用域，开发者会使用 ID 属性。跨根引用是命令式 API 的核心用例之一。

关键要点

• 静默失败是严重缺陷：浏览器在跨 Shadow Root 赋值 ARIA 元素引用时静默丢弃操作，且不提供任何错误或警告，导致开发者难以调试，无障碍用户直接受损。
• 封装性优先于无障碍性：规范制定者为了预防潜在的 Shadow DOM 内部泄露（理论上的封装纯度），牺牲了实际用户的无障碍访问需求。
• 违背 W3C 设计原则：W3C HTML 设计原则明确指出：“在冲突情况下，优先考虑用户，其次是作者，再次是实施者，最后是规范制定者和理论纯度。”当前行为完全颠倒了这一层级，将最低优先级的“理论纯度”置于最高优先级的“用户需求”之上。
• 存在更优的技术方案：社区已提出多种既能保护封装又能支持无障碍的方案（如 Getter 返回 null 但内部保留引用、事件重定向机制等），但未被采纳。
• Closed Shadow DOM 并非主要理由：虽然封装论点常引用 Closed Shadow DOM，但数据显示 Open Shadow DOM 的使用率远高于 Closed Shadow DOM（Chrome UseCounters 显示约 17.5% vs 5.3%）。即使考虑 Closed Shadow DOM，静默失败也是过度反应。
• Reference Target 不是替代品：虽然 Reference Target 是一个有益的补充机制，但它不能替代命令式赋值（=）的正常工作。开发者不应被迫重构整个 DOM 结构来规避此限制。

意义与影响

1. 对无障碍访问（a11y）的负面影响

这是最直接且严重的后果。屏幕阅读器用户依赖 aria-describedby 等属性来理解交互元素的功能。当这些属性因跨组件引用而失效时，应用变得不可用或极难使用。对于依赖辅助技术的用户群体而言，这是一个严重的可用性倒退。

2. 对 Web 组件开发者的困扰

开发者在使用 Web Components 时，经常需要将提示文本、标签等辅助信息放置在组件外部或另一个组件中。当前的规范行为迫使开发者：

• 要么将所有相关元素堆砌在同一个 Shadow Root 中，破坏组件的灵活性和复用性。
• 要么使用复杂的 hack 手段或依赖第三方库来模拟行为。
• 要么面临难以排查的“幽灵”Bug，因为代码看似正确却无效果。

3. 对 Web 平台规范制定过程的警示

这一事件暴露了标准制定过程中可能出现的“脱离用户”倾向。规范工程师过于关注理论上的封装纯洁性，而忽视了实际开发场景中的核心需求（无障碍访问）。Alice Boxhall 的沮丧言论反映了社区内部对这一决策的普遍不满。

4