摘要

  • W3C 将 9 月 8 日固定版式无障碍任务组会议及其整个系列标为取消，同时说明相关工作不会停止，而会并入无障碍任务组继续推进。
  • 8 月 20 日会议纪要点明合并缘由：两场会议造成困惑，有些文档属于 Community Group 报告，另一些可能成为 Working Group Note。
  • 与会者明确区分了发言与决定：CG 成员可以讨论 WG 事项，却不能据此参与 WG 的决定；任务组成果仍需 WG 批准。
  • Daniel Kade 建议给联合议程中的每一项附上“授权标签”，列出所属轨道、有权决定的人、承载文档、后续批准和最终处置。

取消的是系列会议，不是固定版式工作

W3C 的活动页面把 9 月 8 日会议标为“已取消”，并注明取消整个系列。页面紧接着解释，固定版式无障碍任务组将重新加入无障碍任务组，与后者并行开展工作，包括孵化新想法和维护既有文档；原任务组成员会收到另一场会议的邀请。

这不是项目终止通知，而是工作容器的调整。对成员规模不大的专业群体来说，两套日历、两份议程和两条会议记录会消耗编辑时间，也可能让同一个技术问题在两周之间来回等待。合并会议可以让辅助技术、阅读顺序、图像说明和阅读系统行为在一条连续讨论中相互校验。

但活动页面还把 FXL 任务组描述为 Publishing Community Group 与 Publishing Maintenance Working Group 的联合项目。这里的“联合”说明双方共同投入，不等于双方在同一时刻拥有同一种机构权力。会议链接可以共享，成员资格、知识产权承诺、文档身份和决定程序不能靠链接自动合并。

8 月纪要已经把边界说了出来

8 月 20 日的 PMWG 无障碍任务组纪要记录了直接原因：两个会议正在造成困惑，因为有些文档是 CG 报告，另一些则可能是 WG Note。讨论是否合并会议时，与会者说明，CG 成员可以参与 WG 事项的讨论，但不能对 WG 事项行使决定权；任务组的工作最终仍要得到 WG 批准。

会议作出的决议，是今后联合举行 PMWG 与 Publishing CG 的无障碍任务组会议。它没有宣布两个群体变成同一个成员集合，也没有为 CG 参与者新增 WG 表决权。

这里也不宜把“vote”机械理解为每个问题都要正式投票。现行 W3C Process以共识为常态，只有在技术讨论和妥协无法解除僵局时，才把实质性投票作为最后手段。默认有资格参与某项机构决定的，是相应小组的正式参与者。因此，联合会议中的关键问题不是谁能说话，而是谁的支持、反对或弃权构成 WG 主席判断共识时的有效集合。

PMWG 现行章程还把会议内外分成两步。电话会议形成的任何决议都是暂定的，随后必须开放五到十个工作日的共识征询，让未出席者和成员组织进行异步审议。期限结束且没有异议，结果才成为 Working Group 的决议。

这条程序没有排斥开放参与。相反，它允许 CG 专家在早期指出真实问题，又确保 WG 在自己的授权下承担采纳责任。技术贡献的重要性与机构决定资格是两种不同属性，不应相互冒充。

同一主题可能落在不同文档状态

Publishing Community Group 页面把自己称为出版工作的孵化区。其公开代码库说明，加入 CG 不要求 W3C 会员身份，参与者可以提出、记录和制作原型。该库仍列有无障碍任务组和固定版式无障碍任务组。

PMWG 则依据获批章程运作。章程授权它维护出版领域的 Recommendation 和 Note、吸收已经孵化的功能，并研究固定版式内容尚不能满足无障碍要求的问题。章程的维护清单明确包含 EPUB Fixed Layout Accessibility 这份 Working Group Note；当前任务组页面则列出更宽的 Publishing Accessibility Task Force，没有再把 FXL 单列成独立名称。

现有草案更能说明为什么必须追踪身份。Fixed Layout Challenges and Best Practices自称 EPUB Accessibility 1.1 的配套指导，并明确说它不是新的无障碍标准；它又指向一份独立的技术文档。8 月纪要为技术文档安排了新的编辑工作，同时强调“让固定版式支持辅助技术”和“把固定版式变成可重排版式”是两个问题。

一个想法可以先在 CG 中试验，再成为任务组建议，然后进入 WG 维护的 Note，甚至影响 Recommendation 轨道上的规范。每一次状态变化都需要明确的接收主体和版本。代码库出现一次合并，不能代替小组批准；正确的人在场，也不能让初步想法自动成熟。

给每项议程增加一枚授权标签

最小而有效的办法，不是恢复第二场会议，而是在议程与纪要中为每个事项保留同一枚标签。

标签首先说明事项属于哪条轨道：CG 孵化、WG 维护、可能形成 WG Note，还是会影响 Recommendation 的问题。其次列出有资格参与决定的群体，并把“仅参与讨论”明确写出。第三，链接具体 issue、代码库和文档版本，而不是只给一个项目首页。第四，说明当场可能形成的结果：探索性意见、编辑行动、任务组建议、WG 暂定决议或已经完成的 WG 决定。

如果仍需 WG 批准或五到十个工作日的 CfC，标签就应保留待办状态。事项跨越轨道时，纪要要记录交出的版本、接收它的主体和最后处置——采纳、延后、拒绝、并入或发布。这样，参与者可以共享上下文，后来者也能重建权力链。

目前没有证据显示无资格者已经参与 WG 决定，也没有证据表明合并会议违反 W3C 规则。授权标签是事前的治理设计，不是对违规行为的判决。

来源