摘要

  • 8 月 11 日，无障碍指南工作组宣布就一致性章节的基本分工形成“存在一项反对意见的共识”，并给未参会者五个工作日补充反对意见。
  • 8 月 18 日，工作组继续讨论页面、路径、流程、组件和一致性声明；主席明确表示当天不会形成决议，现场只做了探索性倾向调查。
  • 8 月 25 日，工作组通过三项决议，要求在解决 Google 文档中的相关评论之后，更新编辑草案第 3、3.1 和 3.2 节。授权是真实的，文本仍可在授权范围内继续编辑也同样真实。
  • 官方 w3c/wcag3 第 826 号拉取请求在会后继续出现整合、编辑和反馈处理提交，并于 8 月 26 日合并。仓库证明执行过程，却不能单独说明每一处差异的制度依据。
  • 工作组决议、代码合并、Editor’s Draft、W3C Decision 和最终 Recommendation 是不同权力状态。轻量的决议—差异对照可以把它们连接起来，而不把数据库误当作权力来源。

决议中的“之后”不是修辞

8 月 25 日会议纪要最值得注意的，并不是那个 Google Doc 链接，而是链接后面的限定语。工作组三次写下相同结构：使用文档中的文字更新相应章节，但要在解决相关评论之后。

这句话同时完成两件事。第一，它给出实质指令。编辑不是得到“继续想一想”的模糊建议，而是获得了修改公开编辑草案的方向。第二，它保留一项有边界的执行任务：部分评论尚未关闭，编辑必须先处理它们。只承认第一层，会把条件式决议说成逐字批准；只承认第二层，又会把正式记录的工作组行动贬成非正式讨论。

会议上有人直接指出记录问题：工作组是否可以对没有完整复制进 IRC 记录的 Google 文档文字作出决定？得到的回答很实际——材料太长，不适合全部放进 IRC。这足以解释会议为什么使用链接，却不足以给协作文档建立不可变身份。同一个网址可以在会前、会中和会后展示不同文字。

正确的补充并不是强迫会议逐句朗读。它只需保存决议当时的版本导出、内容哈希、相关章节锚点，以及决议明确留下的评论集合。参与过程可以保持高效，审计对象也可以保持准确。

这项决议有两周的公开前史

8 月 25 日不是突然出现的权力时刻。8 月 11 日，AGWG 已经宣布就一致性章节的分工形成“存在一项反对意见的共识”。规范性一致性章节将聚焦一致性本身，包括具有明确范围的一致性声明；对于作者不能完全控制的内容，面向监管者的建议主要放入信息性材料，也可能进入具体的 WCAG 结果说明。

公开记录没有抹去反对意见。反对者认为，在工作组尚未完整定义“一致性”之前作出重大结构决定过早。公告随后给缺席者五个工作日提出其他反对意见，并说明下一步只有两种：记录该决定，或者根据反馈将议题重新带回工作组。

“存在反对的共识”不是一致通过，也不是一票否决。W3C 流程允许主席在尽可能合理地处理正当关切之后，即使仍有异议，也认定工作组决定成立。持续存在的异议还可以通过 Formal Objection 机制进入另一个审查层级。把这些状态混在一起，会同时伤害决定能力和异议可见性。

8 月 18 日的记录进一步证明文字尚未固定。参与者讨论了页面、路径、流程、组件、声明和报告，多种提案在会议中被重写。接近尾声时，主席明确表示当天不会形成决议。随后进行的倾向调查支持继续探索一个范围更有限的一致性章节，但“探索”不是“通过”。

因此，25 日的三项决议应理解为一次状态转换：此前的方向、反对期、继续讨论和问卷材料，转化为一项可执行的编辑指令。它不是突发公投，也不是最终标准。

+1 记录支持，却不自动构成投票

会议记录中出现了 +1、0 和 -1。这些符号为主席判断现场支持、保留和反对提供证据，但不能因为可计数，就自动被称为正式投票。

W3C Process Document 区分共识形成与实质投票。投票是技术讨论和妥协均无法推进之后的最后手段；若采用，决定投票、投票规则、结果和 Formal Objection 都应记录。8 月 25 日的纪要使用的则是“决议草案”、参与者信号和“决议通过”等语言。

精确命名很重要。参与者带来技术判断、使用者经验、支持和反对；主席依据程序判断是否形成工作组决定；工作组在章程与流程范围内约束自身工作。出席会议并不会让任何人成为监管者、法院、采购机构或所有网络使用者的主权代表。

W3C 内部也不是单一权力平面。流程文件分别定义主席决定、工作组决定或决议、Team Decision 和 W3C Decision。把 25 日的行动称为“AGWG 工作组决议”，既不会把它降格成聊天，也不会把它抬升成最终 Recommendation 或外部法律。

仓库留下的是执行回执

官方 w3c/wcag3 仓库第 826 号拉取请求，为会后的执行提供了细密记录。它在 8 月 25 日会议之前已经开启，标题是更新一致性章节，最终在 8 月 26 日 23:57（UTC）合并。最终分支头与合并提交都有稳定标识。

中间过程不是一次静态上传。公开提交说明包括删除第 4 节、编辑性调整、整合会后一致性内容、重构、更新通俗摘要、修改编辑说明、处理具体审阅意见，以及最后的“回应反馈”。

这些提交不能证明编辑偏离授权。决议本身就要求先解决相关评论。提交标题也不能告诉我们一个变化是规范性的、机械性的，还是早已被问卷与讨论覆盖。基于现有公开证据，不能合理指控越权、隐藏修改或程序无效。

但提交历史确实证明：最终合并文字是在工作组行动之后，通过执行阶段完成的。Git 能精确保存字节、作者、时间和父子关系，却不会自动说明某一项评论由哪句话授权、哪一处修改改变了范围、后续是否另有工作组确认。

数据库不是王座，合并按钮也不是。仓库是极好的执行回执，不是决定权的原点。

编辑草案自己拒绝“最终文本”标签

8 月 28 日的公开 Editor’s Draft 对其状态写得很清楚：发布编辑草案不表示 W3C 或其成员背书；文档可能随时更新、替换或废弃；除了“进行中的工作”，不应以其他身份引用它。

一致性章节还标有 Developing。按照草案自己的状态说明，这意味着工作组对主题大体认同，具体内容尚未完成。这与 25 日存在真实决议并不矛盾。恰恰相反，决议把工作推进到了一个仍在发展中的状态。

还要区分当前 Editor’s Draft 与最新正式发布的 WCAG 3 Working Draft。前者展示日常工作，后者保存另一个程序节点。未来 Recommendation 还需要跨越更多状态。如果监管者、公共采购方或合同后来让 WCAG 文字具有约束力，那项约束来自它们自己的采纳行为，而不是工作组在仓库中合并了一段文字。

一份准确记录必须同时容纳两个判断：工作组确实决定了下一步；对外展示的结果仍不是最终 W3C 标准。两者缺一，都会扭曲权力边界。

决议—差异对照不需要很重

所需的公共层可以很薄。它不必给每个逗号建立宪法档案。

第一组字段保存议题与决议的稳定 ID、决议原文、决定类型、适格参与集合、时间窗口，以及主席宣布结果的时点。

第二组字段固定工作组实际审阅的文字。如果起点在仓库，就是提交 ID 和章节锚点；如果起点在协作文档，就是版本化导出与内容哈希。动态链接可以保留，但不能成为唯一证据。

第三组字段界定决议后仍可处理的评论。无需公开个人批注或受保护材料，但必须能判断哪些问题尚未关闭、谁有权关闭、其范围是否扩大。

第四组字段给会后变化分类：直接执行决议、解决指定评论、编辑性修正、构建修复或范围改变。分类不是价值判断，而是把审阅者带到正确的授权与证据位置。

最后，记录应连接最终 head、merge commit、发布状态，以及之后可能出现的 Call for Consensus、Formal Objection 处理、重开或替代决定。审阅快照到合并结果之间的机器可读差异，会让整条链路能够复现。

索引是状态投影，不是行动本身

本文研究时，AGWG 的公开 Decisions 页面显示最后编辑日期为 8 月 17 日，所以尚未列出 8 月 25 日的三项决议。这个时间事实不能被夸大。一个早于行动的索引，不能证明后来的决议无效、被隐藏或遭遗忘。

它说明的是投影延迟。会议纪要回答“工作组做了什么”；决定索引回答“去哪里找”；拉取请求回答“文字怎样执行”；Editor’s Draft 回答“现在展示什么”；正式发布页面回答“进入了哪个发布节点”。没有任何一个表面可以独自取代其余部分。

合适的动作是对账，而不是指控。索引更新后，应连接决议、被审阅快照和最终合并；分钟记录与拉取请求应互相反向链接。这样，读者就不用从日期和页面漂移中猜测权力链。

来源

  1. AGWG — 2026 年 8 月 11 日会议记录与决议
  2. AGWG 2026 年 8 月 11 日会议纪要
  3. AGWG 2026 年 8 月 18 日会议纪要
  4. AGWG 2026 年 8 月 25 日会议纪要
  5. 无障碍指南工作组决定政策
  6. W3C 流程文件
  7. AGWG Decisions 页面
  8. w3c/wcag3 第 826 号拉取请求
  9. 第 826 号拉取请求提交历史
  10. WCAG 3 Editor’s Draft
  11. 最新正式发布的 WCAG 3 Working Draft
  12. W3C — 2025 年流程文件更新