摘要

  • W3C 于 2026 年 8 月 27 日发布新版 SVG Accessibility API Mappings 工作草案。草案明确写明，上一版发布于 2018 年 5 月 10 日，两者相隔 3,031 天；新稿列出了多项实质性技术修改。
  • SVG 工作组新章程公开完善期间，一条 7 月 4 日的意见要求为 SVG AAM 给出具体里程碑和测试承诺。8 月 18 日的采纳提交把“未确定”改成了“争取推进测试”。
  • 新措辞表明了方向，却没有给出控制版本、规范功能清单、测试套件提交、覆盖状态、独立实现组合、行动负责人或复核时间，因而无法据此判断里程碑是否完成。
  • 拟议章程已经有良好的通用标准：每项功能应有公开测试，测试规划应尽早开始，越过候选推荐阶段前应有两个独立且可互操作的实现。缺的是把这些标准落到 SVG AAM 本身的证据索引。
  • W3C Process 对预期里程碑日期的要求带有“如可提供”的限定。没有日期本身并不能证明程序违规、项目弃置或参与者失信。
  • 一份轻量、可版本化的“测试里程碑回执”，足以区分发布、覆盖、实现经验和成熟度决定，不必另建审批机构，也不必增加否决权。

3,031 天说明了什么，又没有说明什么

日期最容易制造一个过度简化的故事：一份规范沉寂八年，然后突然复活。公开记录并不支持这种写法。

现行的 2024 年 SVG 工作组章程从 2024 年 6 月 27 日开始，到 2026 年 9 月 30 日结束。章程把 SVG Accessibility API Mappings 列为 2018 年 5 月 10 日采纳的工作草案，并把预期完成状态写成“未确定”。这能证明章程表格当时的状态，却不能证明八年间编辑仓库没有活动，更不能证明参与者放弃了工作。

下一届章程的公开完善过程记录在 W3C Strategy 第 559 号议题里。7 月 4 日，一条公开意见把 2018 年工作草案与“未确定”的完成状态并列，要求提出具体里程碑，并明确测试承诺。8 月 18 日，SVG 团队联系人表示完善阶段已经结束，相关建议已经采纳。

采纳提交 806338把变更范围保留得很清楚：总共改了三行。一行修复章程链接，一行扩充与 WHATWG 协作的表述，另一行则把 SVG AAM 的预期完成从“未确定”改成“争取推进测试”。在这份不可变提交所对应的章程里，采纳草案仍指向 2018 年版本。

九天后，W3C 发布了 2026 年 8 月 27 日工作草案。新稿自己标注的上一份工作草案是 2018 年 5 月 10 日版本，精确间隔为 3,031 天。

这个发布动作值得充分肯定。新版列出了可访问名称计算、SVG 角色、元素和属性映射、隐藏内容与展示性内容处理等方面的变化。一个带日期的固定版本，让审阅者和实现者不必仅靠持续变化的编辑稿来对齐讨论。

但工作草案的状态说明也同样重要：发布不等于 W3C 或其成员认可，文本仍可能更新、替换或失效。它证明的是“某一版本已公开供审阅”，不是“规范功能已有完整测试”，也不是“两个独立产品已经互操作”，更不是“成熟度升级已经有证据支持”。

因此，3,031 天既不应被写成 3,031 天毫无工作，也不能因为新版出现就被当作所有技术不确定性已经消失。它只精确关闭了发布层面的时间缺口。

“推进测试”没有定义何时算推进完成

把“未确定”改成“争取推进测试”是改善。新措辞把工作重点放到了测试，也避免凭空捏造一个未必能兑现的期限。标准制定受参与者时间、实现厂商优先级、技术依赖和跨组协作影响，承认日期未知往往比给出装饰性承诺更诚实。

问题在于，这句话没有验收条件。它没有说明正在测试哪个版本，没有说明哪些规范要求构成有限清单，没有指定哪个测试套件提交控制结果，也没有定义何种覆盖或何种实现证据足以支撑下一步决定。

“做测试”至少可以指六件不同的事：新建测试仓库；写入某个回归用例；通过一份测试计划；把每项规范功能映射到断言；在某个产品和环境中运行测试；用两个真正独立的实现取得可比较结果。最后还可能需要实施报告把证据汇总到成熟度审议中。

这些工作都真实，也都有价值。正因为如此，不能用一个进度动词把它们当成同一种证据。新增一百个用例，可能只是把已经覆盖的行为测得更细；覆盖率看似很高，可能所有结果都来自同一个引擎；两个产品都显示通过，若版本、操作系统无障碍层和辅助技术组合未记录，外界仍无法复现。

里程碑的作用并不是催促，而是说明“什么状态一旦出现，就可以结束这一轮判断”。“争取推进”只能开始谈话，不能关闭审查。

通用成功标准已经足够严格

拟议章程并没有忽视测试。它把测试套件和实施报告列为交付成果，也在通用成功标准中要求每项功能都有公开测试，鼓励从最早的草案阶段规划测试，并要求规范越过 Candidate Recommendation 之前，每项功能至少有两个独立且可互操作的实现。

这些内容是重要的反证：不能把目前的缺口描述成“W3C 或工作组根本不重视测试”。它们也与 W3C Process 对实施经验的讨论一致。Process 关注的不是一个简单总分，而是功能是否实现、实现之间能否互操作、实现者是否独立、是否有超出实验范围的部署、生态系统的哪些层次被覆盖，以及是否报告了问题。它还指出，测试规划通常越早开始越有效。

缺口发生在通用标准和具体交付物之间。章程说“每项功能”应有测试，但没有在 SVG AAM 行项目旁边链接一个可版本化的功能清单。章程说需要独立实现，但没有指明当前证据由哪些实现、版本和运行环境组成。章程要求开放测试，但如果结论只指向不断移动的默认分支，历史结果仍难以复现。

所以，这篇文章并不要求把成功标准写得更宏大。相反，应该把它们变得更薄、更具体：为 SVG AAM 公开一个索引，让每项标准都能找到当前对应的证据或明确的空缺。

“如可提供”不是漏洞，而是对虚假精确的约束

W3C Process 关于工作组章程的规定要求写明范围和成功标准、存续期、交付物，以及“如可提供”的预期里程碑日期。这个限定不能被省略。现有资料不足以支持“未给日期即违反程序”的指控。

这样的弹性有合理基础。规范测试可能暴露需要重写的规范文本，实现者可能调整资源，跨平台差异也可能让原定计划失效。为了让表格看起来完整而填入一个日期，反而可能诱导参与者缩小测试范围、过早宣布完成，或留下又一项无人解释的逾期承诺。

但“日期不可提供”不等于“状态不可描述”。即使无法预测何时会出现两个独立通过的实现，工作组仍可以说明：哪个规范版本控制当前测试、功能清单如何版本化、采用哪个套件提交、已经观察到什么、缺少什么，以及什么事件会触发下一次复核。

若连复核日期也无法确定，回执可以坦白说明原因，并列出触发条件，例如新版本发布、实现者提交结果或某项规范争议解决。这样既保留 Process 的弹性，也避免让“不确定”变成没有证据地址的永久状态。

从文档到运行结果之间有多道门

Lu Heng 关于运行代码优先的论述在这里提供的是治理视角，而不是关于 SVG 或 ARIA 的事实来源：发布、推荐、实现、验证和真实使用应当保持可区分。

这个视角可以同时防止两种错误。一种错误是因为新工作草案还没有证明互操作，就否定其发布价值。固定文本能够组织审阅、形成共同引用，并推动实现。另一种错误是把发布本身当成真实产品已经一致执行规范的证据。文档不会自行运行。

在测试链上，也要保留细分。测试存在，只能证明某个断言已经编码；功能与测试之间有映射，才说明意图覆盖何处；一次执行记录说明特定实现和环境的行为；两次独立且可比较的执行，才可能支撑互操作判断；实施报告再把这些材料组织成成熟度决定的依据。

SVG AAM 映射的是 SVG 语义如何进入无障碍 API，观察路径可能经过浏览器引擎、操作系统无障碍层和辅助技术。版本与配置都有可能影响结果。本文不判断哪些组合必须纳入，也不声称任何组合成功或失败；它只要求，未来若据此作出公开结论，就应标明证据来自哪些组合。

SVG 与 ARIA 的协作让责任字段更重要

这项工作的公开落点不只出现于一个组织标签。ARIA 工作组发布页列出了 8 月 27 日的 SVG AAM 工作草案，并把 ARIA 标为交付组；拟议 SVG 章程则写明，该规范将与 ARIA 协作开发。2024 年，一项仓库提交把规范工作移入 ARIA 单体仓库，同时保留旧仓库用于议题追踪，并保留 Editor’s Draft 地址。今天的 ARIA 仓库 SVG AAM 目录显示了实际编辑位置。

这些事实并不证明发生了有争议的权力转移。跨组协作和仓库迁移本来就是常见安排。它们只提出一个实际要求：里程碑回执应当给每项下一步行动标出负责组或具名负责人。章程责任、文本编辑、测试复核和实现结果可以分布在不同参与者之间，但不能因此变得无法定位。

十个字段即可形成可复核的里程碑

修复不需要新建委员会或大型看板。一页从交付物条目可达、能够版本化的记录就足够。

它首先应写明控制规范的 URL 和不可变修订；其次列出规范功能清单及其版本；第三指出测试套件仓库和控制提交；第四公开功能到测试的映射，把已覆盖、部分覆盖、未测试、排除和阻塞分开表示。

第五项是实现名称、版本与相关环境。第六项是互操作结果及可复现材料。第七项保留已知失败、排除项和未决问题。第八项把每个后续动作交给负责组或具名负责人。第九项给出复核日期，或明确解释日期为何不可提供，并写出触发事件。第十项说明这组证据能够支持哪一种决定：编辑稿审阅、候选推荐过渡，还是实施报告。

这份回执应保留历史。功能会改变，失败可能修复，实现也可能退出。新版可以取代当前状态，却不应删除旧版。否则，今天的绿色结果可能把昨天决策时的实际条件一并抹去。

2026 年工作草案应得到与其证据相称的肯定：它结束了长达八年的发布空档，提供了实质更新，也重新打开了共同审阅窗口。它不需要借用明天的测试证明来显得重要。下一步同样不需要夸张承诺，只需要把“推进测试”变成外界可以核对、参与者可以补齐、决策者可以引用的当前状态。

资料来源

  1. ARIA 仓库中的 SVG AAM 目录
  2. 采纳提交 806338 对应的拟议 SVG 章程
  3. 采纳完善意见的提交 806338
  4. W3C Strategy 第 559 号议题
  5. 要求测试里程碑的公开意见
  6. 团队联系人宣布完善结束的评论
  7. 将 SVG AAM 工作迁至 ARIA 单体仓库的提交
  8. Lu Heng：Running-Code Primacy
  9. 现行 2024 年 SVG 工作组章程
  10. ARIA 工作组发布页
  11. W3C Process：工作组章程
  12. W3C Process：实施经验
  13. 2018 年 5 月 10 日 SVG Accessibility API Mappings 工作草案
  14. 2026 年 8 月 27 日 SVG Accessibility API Mappings 工作草案