要約

  • W3Cは2026年8月11日、ARIA in HTML の更新勧告を公開し、三つの適合性チェッカーを扱う実装報告へリンクした。
  • 報告の表示は「最終更新 2026年3月22日」だが、5月20日のコミットでは311行が追加され126行が削除され、5月27日にも6行が変わった。
  • この差だけで手続違反や実装不足とは言えない。明らかなのは、観測の締切日と公開成果物の改訂日には別々の表示が必要だということだ。

勧告から見えるのは3月だけ

ARIA in HTML は、HTML要素にWAI-ARIAやDigital Publishing ARIAの属性を使う際の著者適合要件を定める。主な目的は、ウェブ制作者が使う適合性チェックツールのために規則を示すことだ。ブラウザーや支援技術そのものの動作一覧ではない。

8月11日の固定版は、冒頭の文書情報から実装報告へ案内する。そこに並ぶのはW3C HTML checker、ARC Toolkit、IBM Accessibility Checkerである。表の直前には「Last updated 22 March 2026」とあり、続く文章も、同日現在で掲載機能を仕様の現状に照らして検証し、実装不足によるリスク項目はないとしている。

勧告からこのページを開いた読者は、3月22日を報告そのものの鮮度と受け取りやすい。ところがリポジトリは、別の時間軸を残している。

5月20日のコミット 89f8e75e9d35 は、報告ファイルに311行を加え、126行を削った。古い2021年8月の日付を2026年3月22日に置き換え、「リスク項目なし」という総括も書き直した。多数の表項目が更新され、HTMLの selectedcontent に関する行もこの差分で加わった。

5月27日には 7998c77749cf が続いた。こちらは6行を変更し、二種類の select を属性の組み合わせではなく「drop-down box」と「list box」で表すよう直した。関連仕様との整合を取る変更だが、ページ上部の3月表示は動いていない。本稿の調査時点では、これが実装報告ファイルに触れた最後の公開コミットである。

したがって、直ちに「日付が誤り」と断定するのも適切ではない。3月に観測を締め、5月に結果を整理し、さらに説明だけを修正した可能性がある。その場合、3月は証拠の有効時点を、5月は成果物の改訂を示す。二つを区別できない「最終更新」という見出しが、来歴を曖昧にしている。

selectedcontent の行が示す三つの状態

selectedcontent は、カスタマイズ可能な select の中で使われるHTML要素である。実装報告は、想定された配置の内外で許されるARIAの役割と属性を記し、テストケースと各チェッカーの課題票を結び付けている。

W3C Validatorは yes で、関連issueは2026年3月17日に完了として閉じた。ARC Toolkitは in progress で、issueは調査締切時も開いていた。IBM Accessibility Checkerは not yet implemented とされ、こちらのissueも開いたままだった。

三列が揃っていないからといって、十分な実装経験がなかったとは限らない。W3C Processは、全仕様に共通する単純な個数基準を設けていない。各機能の実装、独立性と相互運用、仕様著者以外による実装、公開展開、エコシステムの複数段階での経験、困難の報告などを総合的に見るとしている。三製品の表以外の材料も判断に入り得る。

また、この表はブラウザーと支援技術の互換性認証ではない。仕様を支持すると表明するチェッカーには規則の実装を求める一方、用語や重大度の表現は各ツールが定められる。yes は製品全体のアクセシビリティ保証ではなく、公開issueが開いていることも未公開ビルドの状態まで証明しない。

確実な事実はもっと狭い。5月にファイルへ加わった行が、3月を最終更新とするページに載っている。ページだけでは、3月がテスト日、結果確認日、issueの確認日、編集日、あるいは証拠の締切日のどれなのか復元できない。

審査期間の途中でファイルが変わった

ARIA Working Groupは4月7日、selectedcontent とカスタマイズ可能な select の規則を含む修正・追加案を公開した。Last Callは6月8日までで、実装経験を含むコメントを募った。

5月20日と27日の変更は、その公開審査期間内に起きている。8月11日の勧告では、追加案の表示が外れ、2021年以降の実質的変更として本文に組み込まれた。

W3C Processは、コメントを正式に処理し、十分な実装経験と勧告文書の他の条件を満たした後に、提案修正を規範本文へ取り込めるとしている。公開情報から審査と最終公開は確認できるが、更新要求がどの報告コミットとどの観測締切を使ったかは一意に結べない。これは決定が無効だという証拠ではない。外から追跡できる連結情報が薄いという指摘である。

二つの日付を明記する

必要なのは大きな制度ではない。報告改訂日には不変のコミットとファイル変更時刻を置く。証拠基準日には表が反映する最新の観測日を置く。行ごとにはチェッカーの版、テスト、観測日、結果語彙を添え、報告全体で照合対象の仕様スナップショットを固定する。

Last Callや更新要求が報告を利用したなら、その時点の版へリンクする。その後の差分も、実装結果の更新、テスト差し替え、仕様整合、純粋な編集に分類すればよい。3月の証拠と5月の文書は、役割を分ければ矛盾しない。

この二重時計は新しい承認手続ではない。Working GroupとW3C Teamの判断権を保ったまま、判断の時間的根拠だけを読者に返す。

出典