【2025年9月】WCAG 3.0をアクセシビリティ初心者の視点で読んでいく

アクセシビリティ
この記事は約10分で読めます。

こんにちは！
今日は「WCAG 3.0（次世代のアクセシビリティ・ガイドライン）」の動向を、2025年9月4日に出たドラフト版を見ながらまとめたいと思います。

何が変わってきているのか。
WCAG 2.xとの関係はどうなるのか。
そして現場では何から始めればよいのか。

そんな疑問を解決すべくまとめていきたいと思います。
むずかしい言葉も出てきますが、「ざっくり」とかみ砕きます。

まずは要約

WCAG 3.0は、まだ“完成版の規格”ではありません。
現時点の公開文書は、方向性や考え方を説明する「Explainer（解説）」と、草案レベルのドラフトです。つまり、いまは途中段階ということです。

目玉はアサーション（Assertion）という考え方です。
これは「私たちはこういう手順でアクセシビリティを担保しています」と、責任者・日付・対象範囲まで添えて事実として記録・主張する仕組みのことです。実装の合否だけでは拾いきれない“良い取り組み”を、透明に見える化する狙いがあります。

評価の切り口も整理されています。
ボタンなどのアイテム、ページに相当するビュー、購入などのタスクフロー、そしてサービス全体というプロダクト。この4階建てで「どこで困るか」を見ます。さらにテストは定量と定性を組み合わせます。

適合モデルはA/AA/AAAの三段階から発想を広げています。
基礎要件を土台に、補助要件やアサーションで上位を組み立てる方向で検討が続いています。Bronze/Silver/Goldなどの段階名や、Fail/Pass/Exceptionalといった形容評価の案も話題に上ります。
この手の評価というかバッジというかランクみたいなところはあまり良い手法ではない気もしますが、個人の感想レベルなのでどのように運用するのか今後に期待したいところです。

実務のポイントはシンプルです。
当面はWCAG 2.2をしっかり維持しながら、すでに行っているユーザーテストやレビューをアサーションとして言語化しておくことです。これが、3.0時代への現実的な流れになりそうです。

「自動テスト＝安心」に対するWCAG3.0なりのアンサー？

6. Testing Exploratory

6.5 Testing Assertions

The results of the process stated in an assertion cannot be tested. Instead, the quality of an assertion statement can be tested based on how well the assertion meets the documentation requirements for assertions (See Documenting Assertions). Conforming to WCAG does not require testing supporting documentation; however, organizations may decide to adopt additional documentation requirements based on the procedure being asserted.

Explainer for W3C Accessibility Guidelines (WCAG) 3.0
The Explainer for WCAG 3.0 accompanies the draft of W3C Accessibility Guidelines (WCAG) 3.0. It provides an overview of the history and goals of WCAG 3.0. This ...
www.w3.org

「自動テストを全部通ればOK」と言われることがあります。
ただ、実際のユーザー体験はもう少し複雑です。読み上げで文章が分かりやすいか。エラー時の導線で迷わないか。購入フロー全体で詰まらないか。こういった点は人の目や耳で確かめる定性テストが必要になります。

たとえば、画像に代替テキストが“あるかどうか”は自動でわかります。
でも、そのテキストが本当に内容を伝えているかは、実際に読み上げてみないと判断できません。数字では測りにくいけれど、ユーザーには効く。ここに自動テストの“盲点”があります。

もちろん自動化は強力です。
繰り返し検査や基本的な見落としの防止には欠かせません。問題は「それだけで十分」と誤解されやすいことです。WCAG 3.0はここを踏まえ、定量と定性の両輪で評価する方向に舵を切っていこうとしているようです。

だからこそ、“やっていることを記録する”ということが重要だと考えているのでしょうか。
ユーザーテストやレビューの実施を、担当者・日付・対象フローと結びつけてアサーションとして残す。コードの外側にある“良い習慣”を、適合の文脈で語れるようにするわけです。

つまり、結果だけを提示してクリアするこれまでのガイドラインチェックからの脱却を目指しているようにも思えます。

アサーションとは？

アサーションを一言で言うと、「手続きの事実を責任つきで言語化する仕組み」です。
実装の成否ではなく、プロセスの実行を証拠つきで主張します。代替にはなりませんが、基礎要件を支える“補強材”として効きます。

たとえばECサイトでの例を考えます。
「チェックアウトのタスクフローを、音声読み上げユーザー3名で四半期ごとにテスト。担当は○○。直近は2025/8/20実施。結果は社内Wikiに公開。修正チケットは#1234〜#1236」——こんな書き方なら、誰が・いつ・どこを・何のために行ったのかが一目でわかります。

ポイントは“第三者が追跡できること”です。
主張本文、実施日（または期間）、対象スコープ（ビューやフローの範囲）、連絡先、ひも付く要件やガイドライン。少なくともこのあたりは必ず揃えると良いです。

アサーションは、ベストプラクティス（良い例）とも相性が良いです。
たとえば「読みやすい日本語で書く」「難解な漢字にルビを振る」などは、数値で合否を出しにくい領域です。こうした取り組みをやりっぱなしにせず、事実として残すことで、再現性と継続性が生まれます。

ただし、この第三者が追跡できることというのをどこまで開示するのかは意見が分かれそうです。特に担当を具体的にしてしまうのは企業として開示できるものなのか意見や姿勢が分かれそうです。

テストの“4つのスコープ”で迷子を防ぐ

WCAG 3.0は、評価の単位をアイテム／ビュー／タスクフロー／プロダクトの4層に分けて考えます。

現実に困りごとが起きやすいのは、多くの場合タスクフローです。
入力欄は見えるのに、次へ進むボタンが固定ヘッダーに隠れてタップしづらい。音声読み上げで、確認画面の合計金額だけ読み飛ばされる。部品ごとはOKでも、流れで詰まる。こうした“合格の継ぎ目”にこそ注意が要ります。

そこで、定量×定性の出番です。
コントラストやフォーカス可視などは定量でチェック。代替テキストの通じやすさや、エラー導線の分かりやすさは定性で確認。4つのスコープのどこで問題が出るかを地図のように整理すると、手戻りが減ります。

適合モデルの方向性：A/AA/AAAの次に来るもの

WCAG 2.xの三段階は分かりやすい反面、“WCAGを知らない人”には伝わりにくい課題がありました。
WCAG 3.0では、基礎要件（Foundational）を土台に、補助要件（Supplemental）やアサーションを重ねる発想が検討されています。

さらに、Bronze / Silver / Goldのような段階名や、Fail / Pass / Exceptionalといった形容評価も話題に上っています。
要は、最低ラインを越えた先で「どれくらい良いのか」を伝える指標を持ちたい、ということです。

もう一つ注目は、Accessibility Support Setの考え方です。
「どのブラウザや支援技術の組み合わせで検証したか」を、適合主張の中で明示していく流れです。NVDA、VoiceOver、TalkBackなど、現実の利用環境を前提に“動作保証の範囲”を透明化します。

この仕組みによって、よくある“環境差のせいで再現しない問題”を減らせます。
同時に、検証の責任範囲が見えるようになるので、社内の合意形成も少し楽になります。

UGC（ユーザー生成コンテンツ）への向き合い方

掲示板やレビュー、画像アップロードなど、UGCは運営者がすべてを制御できません。
WCAG 3.0では、UGCの扱いをガイドラインごとに別ステップで配慮する方向が示されています。

実務で必要なのは、“促すUI”と“逃げ道の用意”です。
たとえば画像アップロードに「代替テキスト（写真の説明）を書いてもらう欄」を最初から置く。入力が難しければ「後から編集できます」と添えて、敷居を下げる。自動タグ提案を出すなら、誤りを簡単に直せるようにする。こうした小さな仕掛けで、全体の体験はかなり変わります。

重要なのは、完璧な管理を狙いすぎないことです。
UGCは変動が前提です。だからこそ、方針の明示と最小限のガードレールが現実解になります。

今日からできる“やさしい7ステップ”

① WCAG 2.2を堅持
ここが3.0の基礎要件に近い土台になります。既存の監査やガイドラインチェックはそのまま継続します。

② アサーションの雛形を作成
「誰が／いつ／どの範囲（ビューやフロー）／何のために（関連要件）」を1枚シートで書けるようにします。用意したテンプレートをドキュメントとしてNotionやWikiに置くと、全員が迷いません。

③ サポート・ツールの検証
自社で現実的に確認するUA/ATの組み合わせを列挙します。まずはNVDA、VoiceOver、TalkBack等のよくあるものだけでも初めていいでしょう。

④ タスクフローの準備
購入、予約、資料請求などの主要フローを、読み上げON/OFFの両方で実施検証します。詰まりを“場所と理由”で記録します。

⑤ 定性レビューを習慣化します。
代替テキストは「第三者が声に出して読んで意味が通るか」を一定周期で確認します。読みにくい文章はユーザーの動向や声をベースに直します。

⑥ 小さい改良を積んでいく
画像アップロードに説明文入力を促す。エラー時のフィードバックをわかりやすく。まずは“いま一番利用者が多い画面”から着手します。

⑦ 共有会を短く有効に
定期的に“アクセシビリティふりかえり”を設定します。課題1つ、改善1つ、次回の小さな約束1つ。この三点セットでこつこつ積み上げていくことが有効と考えます。

継続できる運用設計が最強

「全部整ってから公開したい・実行したい」という気持ちはとても自然です。
ただ、WCAG 3.0の設計思想自体が継続的な改善を前提にしています。長距離走なら、まずは歩いてもいいのです。

小さく始めるほど、続きます。
アサーションも、最初はお試しの記録で構いません。読み上げで困った箇所を1つ直す。次の月も1つ直す。そうやって積み上がった“地味な1歩”が、半年後に誰もが使いやすい体験になります。

“できる範囲で、確実に”を合言葉に進めていきましょう。

まとめ

  • WCAG 3.0は設計図を磨いている段階です。完成版の規格ではありません。
  • 重要キーワードはアサーションです。実装の外側にある“良い手順”を、責任者・日付・範囲つきで事実として残します。
  • 評価はアイテム／ビュー／タスクフロー／プロダクトの4層で捉え、定量×定性でチェックします。
  • 適合モデルは基礎要件＋補助要件＋アサーションの組み合わせで“良さ”を表現する方向です。
  • 実務では、まずWCAG 2.2 AAを維持しつつ、アサーションの雛形づくりから始めるのが現実的です。
  • これまでのWCAGに比べてだいぶ寄り添いを感じる内容なので、興味を持ってくれる人々が増えれば良いなと個人的に思います。

参考リンク

タイトルとURLをコピーしました