互換性のガイドライン

4.1.1 構文解析 (レベル A) ※WCAG 2.2で削除

HTMLのタグの閉じ忘れやIDの重複など、コードの文法エラーをなくす

作成日: 2024.4.10 / 最終修正日: 2026.5.12

【重要】この達成基準は、WCAG 2.2 で仕様から「削除（廃止）」されました。
かつては、支援技術（スクリーンリーダーなど）がページの内容を正確に解釈できるように、HTMLが仕様通りに正しく記述されている（タグの閉じ忘れがない、属性が完全である、IDが重複していない等）ことを求める基礎的な基準でした。しかし、現代のブラウザや支援技術の補正が進み、単なる構文エラーが直接的なアクセシビリティ上のハードルになることがほぼなくなったため、WCAG 2.2 からは項目自体が削除されています。

実践すべきこと ― 過去の参考

HTML/CSSの仕様への準拠

• HTMLタグの開始と終了を正しく対応させる（閉じ忘れをなくす）。
• 要素のネスト（入れ子）のルールを正しく守る。
• 同一ページ内で id 属性の値を重複させない。

運用者への注意

品質管理としてのチェック

• （アクセシビリティの対象基準からは外れましたが）Webサイトの品質管理やSEOの観点として、新規ページ作成時にW3Cのバリデーターツール等を用いて構文エラーをチェックする運用自体は、引き続き有効であり推奨されます。

開発者への注意

バリデーションとリンターの活用

• エディタの拡張機能や、ビルドプロセスへのリンター導入により、構文エラーを自動的に検知・修正する仕組みを構築する。
• ブラウザの開発者ツール（コンソール）にエラーが出力されていないかを確認する。

今のWeb環境で気をつけたい点（なぜ削除されたのか？）

• 削除は「品質を下げてよい」という意味ではない： WCAG 2.2 でなくなったのは、達成基準 4.1.1「構文解析」という独立の項目です。マークアップの不備が操作不能や読み上げの欠落につながる場合は、4.1.2（名前、役割、値） や 1.3.1（情報及び関係性） など、別の達成基準として問題になることがあります。
• 自動チェックのルールセット： ツールによっては、WCAG 2.0／2.1 のルールのまま「ID の重複」などを 4.1.1 に紐づけて報告するものがあります。監査や社内基準を WCAG 2.2 に合わせる場合は、4.1.1 そのものは対象外となり、報告の見方やツールの設定を揃えておくとよいです。

参考リンク

解説書 達成基準 4.1.1: 構文解析

4.1.2 名前（name）、役割（role）及び値（value） (レベル A)

独自で作ったボタンやメニューにも、支援技術が理解できる「名前・役割・状態」を持たせる

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、スクリーンリーダーなどの支援技術を使用する利用者が、ボタン、チェックボックス、アコーディオンなど画面上のUI部品に対して、「それは何という名前か（Name）」「どんな機能を持つ部品か（Role）」「現在どういう状態か（Value）」を正確に読み取れるようにすることを目的としています。見た目だけをCSSで作っても、プログラム側にその意味が伝わっていなければ、支援技術の利用者は操作しづらくなります。

実践すべきこと

標準HTMLコントロールの優先使用

• ボタンには <button>、リンクには <a>、入力には <input> といった、最初から名前・役割・値の機能が備わっている標準のHTML要素をそのまま使用する。

カスタムコントロールへの適切な意味付け

• デザイン上の理由でどうしても <div> や <span> を使って独自のコントロールを作る場合は、WAI-ARIAを用いて不足している意味（名前、役割、状態）をプログラム的に補う。

運用者への注意

新しいUIライブラリ導入時のテスト

• リッチなUI（カスタムセレクトボックス、独自のトグルスイッチなど）をサイトに導入する際は、見た目やポインタ操作だけでなく、スクリーンリーダーで「オン/オフ」や「選択中」といった状態が正しく読み上げられるかをテスト環境で確認する。

開発者への注意

「divボタン」を避け、ARIAを適切に適用する

• 単なる <div> や <span> に onclick イベントをつけてボタンとして振る舞わせる実装（いわゆるdivボタン）は避ける。やむを得ない場合は、role="button" と tabindex="0" を付与し、Enter キーや Space キーでも発火するようにキーボードイベントを追加する。

状態（Value）の動的な更新

• チェックボックスのチェック状態（aria-checked）や、アコーディオンメニューの開閉状態（aria-expanded）など、JavaScriptの処理でUIの状態が変化した際は、連動してこれらのARIA属性の値もリアルタイムに書き換える処理を実装する。

今のWeb環境で気をつけたい点

• 標準 HTML を優先する： WAI-ARIA の「第1の原則」は、同等の意味を持つネイティブ要素が使えるときはそれを選ぶ、という考え方です。<button> にさらに role="button" を重ねるなど、標準の役割と重なる ARIA は冗長になり、支援技術によっては挙動が想定とずれることがあります。まずは標準のコントロールで足りるかを検討するとよいです。
• 開閉などの「状態」： メニューボタンの役割は伝わっても、展開中かどうかが読み上げに反映されない実装がみられます。見た目を「×」に変えたタイミングで、aria-expanded などの値も連動して更新するとよいです。上の「状態（Value）の動的な更新」に沿い、支援技術で確認するとよいです。

参考リンク

解説書 達成基準 4.1.2: 名前（name）、役割（role）及び値（value）

4.1.3 ステータスメッセージ (レベル AA)

画面のどこかで起きた変化（カート追加や検索結果など）を、フォーカスを移動させずに音声で知らせる

作成日: 2024.4.10 / 最終修正日: 2026.5.12

この達成基準は、画面の一部が動的に更新された際（例：「商品をカートに追加しました」「検索結果は5件です」などのメッセージが表示された際）、スクリーンリーダーなどの支援技術を使用する利用者が、フォーカスをわざわざその場所へ移動させなくても、その変化（ステータスメッセージ）を音声で受け取れるようにすることを目的としています。

実践すべきこと

プログラムによる適切なマークアップ

• 画面上にステータスメッセージ（通知、結果件数の更新、エラーの発生など）が視覚的に表示された際、適切な role やプロパティを使用して、支援技術がそれを感知して読み上げられるようにする。

作業を中断させない配慮

• フォームの入力や文章の読み上げなど利用者が現在行っている作業を不用意に中断させないよう、メッセージの重要度に応じて適切な読み上げのタイミングを選択する。

運用者への注意

動的コンテンツの動作確認

• 「お気に入りに追加しました」という数秒で消えるポップアップや、検索条件を変えた際の「〇件見つかりました」という表示など、ページ遷移を伴わずに画面が変化する機能が追加された際は、スクリーンリーダー環境で適切にフィードバックが得られるかを定期的にチェックする。

開発者への注意

aria-live とロールの適切な使用

• 通知を表示する親要素に対して、メッセージの性質に合わせて role="status"（一般的な通知）、role="alert"（重要な警告）、role="log"（履歴の追加）などを設定する。

重要度（割り込み）のコントロール

• 通常の通知（検索結果の件数や保存完了など）には aria-live="polite"（現在の読み上げが終わってから通知）を使用し、利用者の作業を妨げないようにする。

今のWeb環境で気をつけたい点

• assertive の使いどころ： aria-live="assertive" は現在の読み上げを割り込みます。多用すると入力や読み上げの流れが切れやすくなるため、緊急のエラーなど本当に優先すべき内容に絞るとよいです。通常の完了通知や件数更新は polite や role="status" など、上の開発者向けのとおり控えめな手段を優先するとよいです。

参考リンク

解説書 達成基準 4.1.3: ステータスメッセージ

目次へ戻る