【アクセシビリティ】WCAG 2.2 第4章「堅牢（Robust）」を分かりやすく解説

はじめに

この記事を開いていただきありがとうございます！
この記事では WCAG 2.2 日本語訳（WAIC） をもとに、第4章「堅牢（Robust）」について解説します。
第4章は原則「堅牢」のもとに ガイドライン 4.1 が置かれており、達成基準も他の章に比べて少数ですが、コード品質に直結する重要な内容です。

ガイドライン 4.1: ユーザエージェントとの互換性を最大化する

「ユーザエージェント」とはブラウザやスクリーンリーダーなど、ユーザーがコンテンツを利用するためのソフトウェアのことです。
このガイドラインでは 現在および将来の支援技術とも正しく連携できるよう、堅牢なコードを書くこと が求められます。

達成基準 4.1.1 構文解析（Parsing）【削除済み】

• WCAG 2.0/2.1 には存在していましたが、WCAG 2.2 で削除されました。
• 理由：HTML仕様やブラウザのエラー補正能力が進化し、必須性が下がったため。

参考：以前の内容
「開始タグ・終了タグの不一致がない」「要素は入れ子構造を守る」など、正しいHTML構文を用いること。

達成基準 4.1.2 名前・役割・値（Name, Role, Value）

内容

• 各UIコンポーネントがプログラム的に「名前」「役割」「状態・値」を持ち、支援技術が正しく読み取れること。

具体例（OK例 / NG例）

<!-- NG例: divで見た目だけボタン -->
<div onclick="sendForm()">送信</div>

<!-- OK例: button要素を使用 -->
<button type="submit">送信</button>

<!-- さらに: ARIAを正しく付与する例 -->
<div role="button" aria-pressed="false" tabindex="0">
  メニューを開く
</div>

• NG例では、スクリーンリーダーは「ボタン」と認識できず、操作方法が伝わらない。
• OK例では、<button>タグやrole="button"を用いることで、支援技術に役割が伝わる。

達成基準 4.1.3 ステータスメッセージ（Status Messages）

内容

• ステータスメッセージ（エラー通知、成功通知、進行状況など）は、フォーカス移動なしにユーザーへ伝わらなければならない。
• 例：フォーム送信後の「送信完了」や、バリデーションエラー時のメッセージ。

具体例（OK例 / NG例）

<!-- NG例: ただp要素を表示 -->
<p id="error">必須項目を入力してください</p>

<!-- OK例: aria-liveを活用 -->
<div role="alert">
  必須項目を入力してください
</div>

• NG例では、スクリーンリーダー利用者にメッセージが伝わらない。
• OK例では、role="alert" により自動的に読み上げられる。

実装のポイントまとめ

1. セマンティックHTMLを優先する

   • 例：<button>、<form>、<input> を正しく使う。

2. ARIAは補助的に使用する

   • 本来の要素で実装できるならARIAは不要。

3. 状態や結果を自動で通知する

   • 進行状況バー、フォームエラー、成功メッセージには aria-live や role="alert" を活用。

最後に

今回は、WCAG2.2の第４章についてまとめてきました。
「正しいマークアップ」と「支援技術への配慮」 が主に記載されており、実際に反映させるための一例が記載されています。
興味がある方は実践してみてください。
ここまで読んでいただきありがとうございました！！

👉 第1章〜第3章の記事はこちら

• 第1章「知覚可能（Perceivable）」
• 第2章「操作可能（Operable）」
• 第3章「理解可能（Understandable）」