Webアクセシビリティの実践ガイド：読める・操作できる・直せるを確認する

2026年10月8日に、W3CのWCAG 2 overview、コントラスト解説、ARIA APGを再読しました。4原則・達成基準・適合レベルを検査しつつ、ネイティブ要素、キーボード、支援技術、実機確認を分け、検査合格を利用者の使いやすさや成果の保証とは扱いません。

Webアクセシビリティの実践ガイド：読める・操作できる・直せるを確認する

問い合わせフォームで入力ミスが起きたとき、赤い枠しか出なければ、どこをどう直すのか分からない人がいます。マウスでは送信できても、キーボードではボタンへ進めない場合もあります。見た目を整えることと、目的の手続きを完了できることは別です。

アクセシビリティは、障害や利用環境による違いを踏まえ、情報を得たり機能を使ったりできるようにする取り組みです。ここでは、サイトの改修を始める人に向けて、重要な手続きの確認から実装の論点へつなげます。意味から知りたい場合はアクセシビリティの入門記事も参照できます。

30秒で要点

• 見出しや色の点検を、入力・修正・送信・完了という利用者の手続きにつなげます。
• WCAGの達成基準と、作業を進めるための優先順位は別です。一部の合格だけでAA適合とは言えません。
• 文字の代替、意味のある構造、キーボード操作、エラーの説明を組み合わせます。
• 自動検査と静的HTML確認には限界があります。実際の操作や支援技術を含む人の評価が必要です。

最初に、一つの手続きを最後まで選ぶ

改修を小さく始めることはできます。ただし「フォームの先頭だけ」といった切り方では、完了できない原因を見逃します。問い合わせなら、入口、入力、内容確認、エラー修正、送信、完了までの経路を選びます。途中の別ページや確認ダイアログも対象です。

WCAG 2.2の適合要件は、ページの一部を除いて適合とは言えないこと、一連の手続きを構成するページがそのレベル以上で適合する必要があることを説明しています。まず一経路から作業するのは優先順位の決め方であり、サイト全体の適合宣言ではありません。

着手時には、対象URL、画面の状態、利用する端末や支援技術、確認者、日時を記録します。「どの操作で、何が起きるはずで、実際にどうなったか」が残れば、修正後に同じ条件で確かめられます。

WCAGの四原則を、具体的な困りごとへ翻訳する

WCAGはWebコンテンツのアクセシビリティ指針です。この記事では、2026年10月4日に確認したWCAG 2.2の正本に沿って、代表的な論点を扱います。全達成基準を列挙したチェックリストではありません。

表が収まらない場合は、横にスクロールできます

適合レベルはA、AA、AAAです。AA適合には、対象のページでAとAAの全達成基準などの適合要件を満たす必要があります。「AA項目を何個か実装した」とは違います。達成を目指す版とレベル、評価範囲、残る問題を明記してください。WCAGの説明だけから、特定の法律への適用や遵守が自動的に決まるわけでもありません。

見出しと画像は、見た目の順番と意味をそろえる

文字を大きくしただけでは、見出しとして扱われるとは限りません。見出しには内容を説明する文言を使い、h1〜h6の階層で関係を示します。ページの主題と、その中の節が分かる構造にします。

WAIの見出しの実装指針は、節を細分化するときにh2からh4へ飛ばすような構造を避けることを勧めています。一方、h4の小節を終えて次のh2へ戻ることは同じ問題ではありません。「h1が必ず一つなら適合」といった個数だけの判定にも置き換えません。

画像のaltは、ファイル名や検索用のキーワード欄ではありません。その場所で画像が伝える意味を補います。例えば「青い矢印」より、画像だけのリンクなら「料金表へ」のように行き先を示す必要がある場合があります。

表が収まらない場合は、横にスクロールできます

同じ画像でも用途で説明が変わります。WAIのalt判断ツリーも、すべての場合を網羅するものではないと留保しています。自動でaltの存在を調べるだけでは、内容が適切かは分かりません。

色は、比率と意味の両方で確認する

WCAG 2.2の1.4.3は、通常の文字と背景のコントラスト比を4.5:1以上、大きな文字を3:1以上とします。大きな文字は18ポイント以上、または14ポイント以上の太字などが基準で、日本語等では相当するサイズを考えます。ロゴや無効な操作部品などには例外があります。文字コントラストの基準

例えば、単色の白背景に灰色の通常文字を置く仮想例では、#767676は約4.54:1、#777777は約4.48:1です。4.48を丸めて4.5とし、基準を満たした扱いにはしません。実際には、背景画像、透明度、文字サイズ、状態変化も含めて確認します。この二色の計算だけでサイト全体の適合は分かりません。

操作部品の識別や内容理解に必要な図形には、1.4.11の非テキストコントラストも関係します。文字の4.5:1を全要素へ一律に当てはめるのではなく、対象と例外を確認します。また、エラーを赤色だけで伝えず、項目名と内容を文字でも示します。

キーボードでは、移動・実行・戻るを確かめる

Tabは主にフォーカスを移動するキーです。文字入力、EnterやSpaceによる実行、矢印キーによる選択など、部品に応じた操作も必要です。「Tabでボタンまで行けた」だけでは、手続きを完了できる証拠にはなりません。

確認するのは、目的の操作ができるか、意味に合った順序で進むか、今いる場所が見えるか、閉じたり戻ったりできるかです。フォーカスが入り込んだ部品から出られない状態は避けます。WCAG 2.2のAA基準2.4.11では、フォーカスを受けた部品が作成者のコンテンツで完全に隠れないことも求めます。「一部も隠れない」という上位基準とは区別します。

小さなクリック対象にも注意が必要です。2.5.8のAA基準は原則24×24 CSSピクセル以上ですが、十分な間隔や文章内のリンクなどの例外があります。余白を含む実際の対象範囲を確認し、「すべてのリンクを24pxの四角へ変える」という単純なルールにしないでください。対象サイズの基準

フォームは、入力方法と修正方法を伝える

次は架空の問い合わせフォームのメール欄の静的断片です。送信処理や入力検証のプログラムを含む完成フォームではありません。

<label for="contact-email">返信先メールアドレス（必須）</label>
<p id="contact-email-help">返信を受け取れるアドレスを入力してください。</p>
<input
  id="contact-email"
  name="email"
  type="email"
  autocomplete="email"
  required
  aria-describedby="contact-email-help"
>

labelのforとinputのidを一致させ、説明文のIDをaria-describedbyから参照しています。欄内の薄い文字であるplaceholderだけに、入力目的を任せません。WAIのラベルの実装指針は、目的を示すラベルと入力欄の関連付けを説明しています。

エラー時には「入力に誤りがあります」だけで終わらず、例えば「返信先メールアドレスの形式を確認してください」と対象と内容を示します。必要に応じて誤りの状態や説明との関連付けも更新し、修正後にその状態を解消します。サーバー側で受け付けられなかった場合も、利用者が次へ進む手段を確認します。

標準HTMLの属性があることと、エラーが適切なタイミングで伝わることは別です。動的なメッセージ、フォーカスの移動、読み上げ、送信の重複などは、完成した機能で調べます。HTMLの構文だけを検査して「スクリーンリーダーでも問題なし」とは言えません。

問題を直せる形で残す最小検証

最初は一つの重要な手続きと、そこで必ず通る画面を選びます。見出し、画像、ラベルなどの静的な関係を確認し、その後に実環境でキーボード操作、表示の拡大、エラー時の変化、必要な支援技術を使った確認へ進みます。未実施の項目は「問題なし」ではなく未確認と残します。

表が収まらない場合は、横にスクロールできます

この表は記録方法の例であり、当サイトを実際に検査した結果ではありません。WAIの評価ガイドも、ツール単独では適合を判断できず、知識のある人による評価が必要だと説明しています。

修正の優先度は、利用を止める問題か、代替経路があるか、影響する範囲はどこかから決めます。利用者が入口から完了まで進めるかを確かめながら範囲を広げ、対応した達成基準、残る問題、再確認日を記録してください。