要約

  • W3Cは2026年8月27日、SVG Accessibility API Mappingsの新しいWorking Draftを公開した。本文が前回版として挙げるのは2018年5月10日版で、間隔は3,031日。技術的な変更も複数記録されている。
  • 次期SVG Working Groupチャーターの公開レビューでは、7月4日の意見が具体的な節目とテストへの約束を求めた。8月18日の反映コミットは「未定」を「テストの進展を目指す」に改めた。
  • この表現は優先方向を示すが、基準となる仕様リビジョン、規範機能の一覧、テストスイートのコミット、カバレッジ、独立実装、担当者、再検討時点を特定しないため、完了を監査できない。
  • チャーター案には、全機能への公開テスト、早期のテスト計画、Candidate Recommendationを越える前の二つの独立した相互運用実装という一般基準がすでにある。必要なのはSVG AAM固有の証拠との接続である。
  • W3C Processが求める予定日には「入手可能な場合」という限定がある。日付がないことだけを、手続違反、放棄、あるいは不誠実の証拠にはできない。
  • 仕様版、機能、テスト、実装結果、責任主体、見直し点をまとめた薄い「テスト節目の受領記録」なら、新しい拒否権を設けずに公開と実装証拠を区別できる。

更新されたのは文書だけではないが、すべてでもない

3,031日という数字は目を引く。だが、それを「8年間まったく作業がなかった」という意味に読み替えることはできない。/TRに固定された公開版が古い間にも、編集者の草案やリポジトリは動き得るからだ。

現行の2024年SVGチャーターは、2024年6月27日に始まり、2026年9月30日に終了する。SVG Accessibility API Mappingsの採用草案を2018年5月10日のWorking Draftとし、完了見込みを「未定」としている。これはチャーター上の表示を明らかにするが、公開版の間にあった作業量までは示さない。

次期チャーターの検討はW3C Strategy issue 559で公開された。7月4日のコメントは、2018年版と未定の完了見込みを挙げ、具体的な節目とテストへのコミットメントを求めた。8月18日、担当者は検討期間の終了と、提案を反映したことを知らせた。

反映内容はコミット806338で確かめられる。変更は3行で、一つはリンク修正、一つはWHATWGとの調整範囲の追記、残る一つがSVG AAMの完了見込みを「未定」から「テストの進展を目指す」へ変えたものだった。その固定コミットのチャーターでは、採用草案の参照はなお2018年版である。

その9日後、2026年8月27日版Working Draftが公開された。本文は2018年5月10日版を直前の公開版として明記する。両日付の差が3,031日である。

新しい公開版には、アクセシブルネームの計算、SVGのロール、要素や属性のマッピング、非表示あるいは表示上だけの内容の扱いなど、実質的な変更が並ぶ。レビューする人と実装する人が同じ固定点を参照できるようになった意義は小さくない。

同時に、Working Draftのステータスは、公開がW3Cやそのメンバーによる承認を意味せず、文書が更新、置換、廃止され得ると説明する。新しい草案が証明するのは、新しいレビュー対象が公開されたことだ。すべての規範機能にテストがあること、独立した製品間で相互運用できること、次の成熟段階へ進めることまでは証明しない。

したがって、長い公開間隔は閉じた。実装証拠に関する問いは、そのまま残っている。この二つを同時に認めるのが、今回の記録に最も忠実な評価である。

意図には向きがあるが、終了条件がない

「テストの進展を目指す」は無内容ではない。テストを優先事項として明示し、守れるか分からない日付を作らずに済む。参加者の時間、実装企業の優先順位、複数グループの調整が読めない局面では、無理な予定より誠実な表現になり得る。

それでも節目とは呼べない。節目には、何を基準に、どの状態になれば、その段階を終えたと判断できるかが必要である。現状の一文からは、対象仕様の固定版、規範機能の母集団、テストスイートの固定コミット、カバレッジの状態、必要な独立性、判断を担う責任主体が分からない。

そもそも「テストを進める」には複数の段階がある。リポジトリを用意する。回帰テストを一件追加する。テスト計画に合意する。規範要件とアサーションを対応付ける。特定の環境でスイートを走らせる。独立した二つの実装で比較可能な結果を得る。実装報告にまとめて成熟度の判断材料にする。

どれも仕事であり、前進である。ただし、証拠として同じ強さではない。テスト件数が増えても、同じ機能に集中すれば未検証領域は減らない。広い対応表があっても、一つのエンジンだけなら独立性は示せない。二製品の成功結果があっても、バージョンや実行環境を記録しなければ再現できない。

節目が必要なのは、活動を急かすためではない。異なる種類の前進を、同じ状態名で報告しないためである。

一般基準を新しく作る必要はない

次期チャーター案は、テストを付随作業として扱っていない。テストスイートと実装報告を成果物に含める。一般的な成功基準として、すべての機能への公開テスト、初期草案からのテスト計画、そしてCandidate Recommendationより先へ進む前に各機能について二つ以上の独立し相互運用可能な実装を求める。

この記述は、「テストが考慮されていない」という主張への明確な反証になる。W3C Processの実装経験に関する項目も、単純な合格率だけを見ない。各機能の実装、相互運用性、実装者の独立性、実験を越えた利用、エコシステムのどの層が対象か、報告された問題などを検討材料とする。また、テスト計画は早く始めるほど効果的な場合が多いとする。

足りないのは原則ではなく、原則の具体化である。「すべての機能」と言うなら、SVG AAMのどの時点の機能一覧かを示す必要がある。「二つの実装」と言うなら、その名称、版、環境、独立性の根拠が要る。「公開スイート」と言うなら、過去の判断を再現できるコミットが要る。

一般基準をさらに強い言葉に書き換えても、この欠落は埋まらない。成果物の欄から、現在の証拠へたどれる索引を置く方がはるかに小さく、実用的である。

日付を出せないことと、状態を示せないことは別である

Working Groupチャーターに関するW3C Processは、範囲、成功基準、期間、成果物とともに、入手可能な場合の予定節目日を求める。「入手可能な場合」という限定がある以上、SVG AAMに日付がないという一事から手続違反を導くことはできない。

この余白には理由がある。標準化では、テストによって規範文の欠陥が見つかり、依存する実装の都合が変わり、協力者が足りなくなる。見栄えのための期日は、未熟な完了宣言や、説明されない遅延を増やしかねない。

しかし、到着日を予測できなくても現在地は記録できる。どの版が基準か、機能一覧をどう版管理するか、どのテストコミットを使ったか、今ある結果と欠けている結果は何かを示せる。見直し日すら置けないなら、理由と、次に見直す契機を明記できる。例えば、新しい草案の公開、実装者からの結果提出、規範上の争点解消である。

必要なのは日付の強制ではない。不確実性を、誰も検証できない一語のまま放置しないことだ。

公開、カバレッジ、相互運用を別々に読む

Lu HengのRunning-Code Primacyは、SVGやARIAについての事実ではなく、記録を読むための統治上の視点を与える。公開、勧告、実装、検証、利用は別の状態として扱うべきだという視点である。

この区別は、2026年版を過小評価する誤りと過大評価する誤りの双方を防ぐ。固定したWorking Draftはレビューを組織し、実装を促す。実装済みでなくても価値がある。一方、文書は自分で動作しない。新しい公開版が、そのマッピングが独立したアクセシビリティ環境で一致することを代わりに証明することはない。

テスト内部でも同じである。テストが存在することはアサーションがコード化された証拠。機能との対応は意図した対象範囲の証拠。実行記録は特定実装の挙動の証拠。独立した比較結果は相互運用判断の証拠になり得る。実装報告はそれらを成熟度判断へ運ぶ器である。

SVG AAMでは、SVGの意味がアクセシビリティAPIへ届くまでに、ブラウザーエンジン、OSのアクセシビリティ層、支援技術が関わり得る。版と設定も結果を左右し得る。本稿は必要な組み合わせや現時点の合否を決めない。公開判断の根拠にした組み合わせだけは、再現可能な形で名前を残すべきだとする。

SVGとARIAが並ぶ記録だから、担当を明示する

公開記録には二つのグループが現れる。ARIA Working Groupの公開一覧は8月27日版を掲載し、ARIAを提供グループとして示す。次期SVGチャーターはARIAとの共同開発を記す。2024年の旧リポジトリのコミットでは、仕様作業をARIAのモノレポへ移し、旧リポジトリはissue追跡用に残し、Editor’s DraftのURLを維持した。現在のARIAリポジトリ内SVG AAMディレクトリも編集上の置き場所を示している。

これは権限争いの証拠ではない。共同作業やリポジトリ移転は通常の運用である。ただし、外部の人がチャーター、公開一覧、旧issue、現行ソースのどこから入っても、次の行動の担当へたどれる必要がある。チャーター責任、編集、テストレビュー、実装結果の提出先は分散してよい。見失わせてはならない。

十項目の受領記録で足りる

大規模な管理システムは要らない。成果物の行からリンクされた、版管理できるページまたはissueで足りる。

記録すべき項目は、基準仕様のURLと不変リビジョン、規範機能一覧とその版、テストスイートの場所と固定コミット、機能ごとのテスト対応と状態である。状態は、対象済み、部分的、未テスト、除外、阻害中を分ける。

さらに、実装名、版、実行環境、相互運用結果と再現材料、既知の失敗・除外・未解決issueを残す。次の各作業にはグループまたは担当者を付ける。見直し日、あるいは日付がない理由と再検討の契機も書く。最後に、その証拠がEditor’s Draftの確認、成熟度移行、実装報告のいずれを支えるものかを明示する。

新しい状態は古い状態を消してはならない。失敗が成功に変わり、機能が外れ、実装が撤退することもある。履歴があって初めて、ある決定がその時点で何に基づいていたかを説明できる。

2026年版は、8年の公開空白を終わらせた実質的な成果である。その価値を認めるために、未来の実装証拠を前借りする必要はない。テストの節目も同じ精度で示せばよい。分からない日付を約束するのではなく、今確かめられるもの、まだ欠けるもの、次に誰が何を変えるかを公開するのである。

出典

  1. ARIAリポジトリのSVG AAMディレクトリ
  2. コミット806338時点の次期SVGチャーター
  3. レビュー提案を反映したコミット806338
  4. W3C Strategy issue 559
  5. テストの節目を求めた公開コメント
  6. レビュー終了を知らせたコメント
  7. SVG AAM作業をARIAモノレポへ移したコミット
  8. Lu Heng, Running-Code Primacy
  9. 現行の2024年SVG Working Groupチャーター
  10. ARIA Working Groupの公開一覧
  11. W3C Process：グループチャーター
  12. W3C Process：実装経験
  13. 2018年5月10日版SVG Accessibility API Mappings Working Draft
  14. 2026年8月27日版SVG Accessibility API Mappings Working Draft