Webアクセシビリティはどう広がってきたか — 意味づけ・操作・支援技術・評価の4つの変化

既存サイトのアクセシビリティ改善は、「HTMLの意味づけ → キーボード操作 → 支援技術との連携 → 継続的な評価」の順で手を付けるのが現実的です。これは好みの問題ではなく、標準と実務がこの順番で積み上がってきたからです。前の層が崩れていると、後ろの層にいくら手を入れても効果が出ません。この記事では4つの変化を history として整理し、最後に既存サイトでの着手順に落とします。

前提：標準と法制度は今どこにあるか

最初に現在地を確認します。国際的な指針であるWCAG（Web Content Accessibility Guidelines）は2.2が最新の勧告です。次世代のWCAG 3.0は、2021年1月の最初の公開草案から数えて改訂が続き、直近のWorking Draftは2026年9月10日に公開されました。W3Cは「完成した標準になるまでさらに数年かかる見込み」とし、WCAG 3が完成してもWCAG 2はすぐには廃止しないと明言しています。つまり、いま取り組むべき対象はWCAG 2系であり、WCAG 3を待つ理由はありません。

日本の規格はJIS X 8341-3です。デジタル庁のガイドブックによれば、2004年に日本語固有の課題を含む形で発行され、2010年にWCAG 2.0の内容を取り込む大改定を経て、2016年にWCAG 2.0およびISO/IEC 40500:2012と同一内容の一致規格になりました。同ガイドブックは、JIS X 8341-3はISO/IEC 40500の更新後に改正が予定されているため、WCAG 2.1・2.2で追加された達成基準にも対応するよう勧めています。

法制度の側も動いています。EUでは欧州アクセシビリティ法（Directive (EU) 2019/882）が2025年6月28日に施行され、ECサイト、消費者向け銀行サービス、電子書籍、旅客輸送のWebサイトやアプリなどが対象になりました。公的機関だけでなく民間企業も対象で、EU市場向けにサービスを提供するなら所在地は問われません。日本では2024年4月に改正障害者差別解消法が施行され、民間事業者にも合理的配慮の提供が義務づけられました。ただし同法がWebサイトに特定の規格への準拠を直接義務づけているわけではありません。国内企業にとっては「法が規格を名指ししていないが、説明責任は生じる」状態が続いています。

変化1：見た目のためのHTMLから、意味づけのHTMLへ

最初の変化は、HTMLを装飾の道具ではなく情報構造の記述として扱うようになったことです。見出しレベル、リスト、テーブルの見出しセル、フォームのラベルとコントロールの関連付け、ランドマーク（header、nav、main などページの領域を示す要素）。これらは見た目をCSSで再現できてしまうため軽視されがちですが、スクリーンリーダー（画面の内容を音声や点字で読み上げる支援技術）が文書を解釈する唯一の手がかりです。

ここで実務上の落とし穴が2つあります。1つは、JIS X 8341-3:2016に含まれるのは規格の「本文」だけで、達成基準の詳細な解説やテクニック集は含まれないことです。JISに準拠しているかを判断するには、WCAG 2の解説書と達成方法を読む必要があります。もう1つは適合の単位です。JIS X 8341-3:2016では適合はウェブページ全体に対するものであり、ページの一部を除外した適合は認められません。外部サービスの埋め込み動画やSNSボタンなど、第三者が提供するコンテンツも対象に含まれます。選定の段階でアクセシビリティを確認しておかないと、あとから「このウィジェットがあるので準拠と言えない」という事態になります。

変化2：マウス前提から、キーボードで完結する操作へ

2つ目は操作の変化です。JavaScriptでUIを組み立てるようになり、div要素にクリックイベントを付けただけのボタンが増えました。これはマウスでは動きますが、キーボードではフォーカスも当たらず、押すこともできません。

この層でまず確認すべきは「非干渉」の達成基準です。JIS X 8341-3:2016は、利用者がページの他の部分へアクセスすることを妨げていない状態を非干渉と呼び、該当する達成基準を4つ定めています。たとえば音声の自動再生はその一つです。非干渉に適合していないページは、特定の利用者がコンテンツ全体にたどり着けない状態なので、デジタル庁のガイドブックもリリース前の改修を必須としています。優先順位に迷ったら、ここから潰すのが合理的です。

操作に関する要求はその後も増えました。WCAG 2.1、2.2では、スマートフォンなど現在よく使われているデバイスを考慮した達成基準が追加されています。フォーカス位置が他の要素に隠れていないこと、ドラッグ操作に代替手段があること、ログイン時の記憶負荷を減らすことなどです。デジタル庁のガイドブックも、JISのレベルAAに加えて「2.1.3 キーボード（例外なし）」などを目指すことを推奨しています。既存サイトの改修では、モーダル、ドロップダウン、カルーセル、無限スクロールの4つが問題になりやすい箇所です。

変化3：支援技術との連携は「HTMLの補完」として設計されてきた

3つ目はWAI-ARIAの普及です。ARIAはロール・ステート・プロパティを付与して、HTMLだけでは表現しきれないUIの振る舞いや構造を支援技術に伝える仕様で、2014年にW3C勧告となりました。現在の安定版はWAI-ARIA 1.2で、2023年6月6日に勧告として公開されています。

重要なのは、ARIAの仕様自体が「HTMLとSVG2を補完するもの」と位置づけられている点です。ネイティブのHTML要素で表現できる意味づけをARIAで上書きする必要はありません。変化1の土台が崩れたままARIA属性を足すと、支援技術に二重・矛盾した情報が渡り、かえって悪化します。

次期仕様のWAI-ARIA 1.3は、2024年1月23日に最初の公開草案が出たあと、2026年6月4日に更新版のWorking Draftが公開されました。sectionheader / sectionfooter ロールの追加、通知用のariaNotify API、ドキュメントのルート要素への aria-hidden="true" の禁止などが盛り込まれています。ただしこれはドラフトであり、ブラウザや支援技術の実装状況はまちまちです。実務上は、1.3の新機能は検証環境で挙動を確かめたうえで、1.2の範囲で代替できるなら代替を選ぶのが安全です。

変化4：一度きりの検査から、運用に組み込む評価へ

4つ目が評価の変化です。JIS X 8341-3:2016では、対応度を示す方法として「準拠」「一部準拠」「配慮」の3つがあり、これらの表記を使う場合はウェブアクセシビリティ方針の提示または公開が必須です。方針で決めるのは最低限「対象範囲」と「目標とする適合レベル」の2つで、この2つが試験の難易度と作業量を決めます。試験の手順はWAIC（ウェブアクセシビリティ基盤委員会）の試験実施ガイドラインと実装チェックリストに沿って進められます。

ここが、工場の製品検査との決定的な違いです。Webサイトや情報システムは日々改修と更新が行われるため、その都度試験が必要になります。デジタル庁のガイドブックは、試験と改修に一般的に1か月程度を要するとしたうえで、公開2週間前のテストでは遅いので開発マイルストーンに段階的な試験を組み込むよう促しています。評価は「最後の工程」ではなく「継続する運用」だという整理です。

評価を担える体制づくりも同じガイドブックで触れられています。必要な知識として、JISの理解、WCAG 2の解説書と達成方法の理解、HTML・CSS・JavaScriptの仕様の理解に加えて、スクリーンリーダーや拡大機能といった支援技術の理解と操作が挙げられています。裏を返せば、自動チェックツールの結果を読むだけでは評価にならない、ということです。

既存サイトでは、どこから始めるか

4つの変化は、そのまま着手順になります。以下は、公開中のサイトを前提にした進め方です。

1. 対象範囲と目標適合レベルを決め、ウェブアクセシビリティ方針を書く。全ドメインを一度に対象にせず、主要導線のサブドメインやディレクトリから始めて構いません。対象外にする範囲は第三者が分かるよう明示します。
2. 代表ページをサンプリングする。トップ、一覧、詳細、フォーム、完了画面など、テンプレートの種類ごとに1〜2枚選びます。テンプレートを直せば同型のページがまとめて改善されます。
3. 非干渉の達成基準を最優先で潰す。音声の自動再生など、他の部分へのアクセスを妨げている実装は、方針策定を待たずに直します。
4. キーボードだけで主要導線を通す。Tabキーだけで申し込みや問い合わせを完了できるか、フォーカスが見えるか、モーダルから脱出できるかを手で確認します。
5. 意味づけを直してからARIAを足す。見出しレベルの飛び、ラベルのないフォーム、divで作られたボタンを先に修正します。
6. 第三者コンテンツの扱いを決める。埋め込み動画や外部ウィジェットは、除外して準拠を表明できません。差し替えるか、方針の対象範囲を見直すかを判断します。
7. 運用ルールに落とす。CMSの入稿ガイドに見出しレベルと代替テキストの決まりを書き、改修時の段階的な試験をスケジュールに組み込みます。

役割分担の目安も挙げておきます。Web担当者が決めるのは1・2・6・7、つまり範囲・目標・外部サービスの選定・運用ルールです。フロントエンドエンジニアが担うのは3・4・5、つまり実装の修正です。どちらか片方だけでは止まります。方針が決まらないと改修の終わりが定義できず、実装が追いつかないと方針が形だけになります。

まとめ

WCAG 3.0はまだWorking Draftで、完成まで数年かかる見込みです。いまWCAG 2.2／JIS X 8341-3のレベルAAに向けて積み上げた意味づけ・操作・支援技術対応は、そのまま次の標準の土台になります。まずは主要導線の1テンプレートをキーボードだけで通してみて、詰まった箇所を一覧にするところから始めてください。

出典

• デジタル庁: ウェブアクセシビリティ導入ガイドブック（2025年10月16日版・PDF）
• 国立国会図書館 カレントアウェアネス・ポータル: デジタル庁、「ウェブアクセシビリティ導入ガイドブック」を公開
• ウェブアクセシビリティ基盤委員会（WAIC）: JIS X 8341-3:2016 試験実施ガイドライン
• ウェブアクセシビリティ基盤委員会（WAIC）: ウェブコンテンツのJIS X 8341-3:2016 対応度表記ガイドライン
• ウェブアクセシビリティ基盤委員会（WAIC）: WCAG 2.2 解説書（日本語訳）
• W3C WAI: WCAG 3 の概要（WCAG 3 Introduction）
• W3C: WCAG 3.0 の公開履歴
• W3C WAI: WAI-ARIA の概要（WAI-ARIA Overview）
• W3C: WAI-ARIA 1.3（2026年6月4日 Working Draft）
• 障害保健福祉研究情報システム（DINF）: ［EU］欧州アクセシビリティ法施行