ウェブサイトをアクセシブルにする方法：WCAG 2.2の入門ガイド

ウェブサイトをアクセシブルにするには、マウスだけでなく、キーボード、スクリーンリーダー、ズーム、スイッチ操作の機器でも使えるように作りましょう。ボタン、リンク、見出し、フォームのラベルには本物のHTML要素を使い、画像には意味のある代替テキストを付け、テキストのコントラストを高く保ち、フォーカスを見えるようにします。目指すべき標準はWCAG 2.2のレベルAAです。自動チェッカーは問題の一部しか見つけられません。残りの多くは、10分間のキーボードとスクリーンリーダーのテストで見つかります。

実際に「アクセシブル」とはどういうことか

アクセシビリティは人に関することです。目が見えず、スクリーンリーダーを使う人、手が震えてキーボードで操作する人、200%まで拡大して見る弱視の人、明るい日差しの中で読む人、一時的に手首を骨折している人などです。良いアクセシビリティは、たいてい誰にとってもサイトを良くします。構造が明確になり、テキストが読みやすくなり、エラーを説明するフォームになります。

基準となるのは、W3CのWeb Content Accessibility Guidelines（WCAG）です。2026年9月時点での現行版はWCAG 2.2です（2023年10月公開、2024年12月更新）。WCAG 3は初期のドラフトです。WCAGは4つの原則を中心に組み立てられています。コンテンツは知覚可能、操作可能、理解可能、堅牢でなければなりません。また、3つの適合レベルがあります。

レベル	意味	目標とする対象
A	最低限。これがないと、一部の人はサイトをまったく使えない	すべての人
AA	一般的な目標。コントラスト、フォーカス、拡大縮小、エラー処理を含む	多くの組織や多くの法律
AAA	最も厳格。すべてのコンテンツで達成できるわけではない	特定のサービスや利用者層

いくつかの地域の法律はWCAGを参照しています。例えば欧州アクセシビリティ法は、2025年6月からEUの多くの消費者向けデジタルサービスに適用されています。どのルールがあなたに適用されるかは、どこで事業を行い、何を販売しているかによります。不明な場合は専門家に確認してください。このガイドでは、実践的な作業を扱います。

選択肢：どうやって到達するか

方法	向いている用途	トレードオフ
最初から組み込む	新しいサイトやアプリ	全体として最も手間が少ない。最初に意識する必要がある
監査して修正する	既存のサイト	実際の問題を見つけられる。ページごとに集中した作業が必要
専門家による監査	規制の対象となる業界、大規模なサイト、公的機関	徹底的で文書化される。費用がかかる
オーバーレイのウィジェット	推奨しない	基になるコードは修正できない

ほとんどの小規模なサイトでは、最初の2つで十分です。最初からアクセシブルに作るようAIに伝え、公開前に監査しましょう。

最も重要な修正

適切なHTML要素を使う

アクセシビリティの多くは、正しいHTMLを書けば無料で得られます。<button>はフォーカスでき、EnterキーとSpaceキーで動作し、ボタンとして読み上げられます。クリックのハンドラを付けた<div>は、そのどれにも当てはまりません。AIが生成したコードは、すべてにスタイル付きのdivを使うことがあります。意味のある要素を依頼しましょう。

操作には<button>、ナビゲーションには<a href>
ページごとに<h1>は1つ。その後は順番に<h2>、<h3>。スクリーンリーダーの利用者は見出しの間を移動します
ランドマーク：<header>、<nav>、<main>、<footer>
すべてのフォームフィールドに接続された<label>
<html lang="en">でページの言語を指定

ARIA属性は、ネイティブの要素が当てはまらない場合にだけ使いましょう。例えば、カスタムのタブセットやコンボボックスなどです。誤ったARIAは、何もないよりも悪い結果になります。

キーボード操作と見えるフォーカス

マウスでできることはすべて、キーボードだけでも操作できる必要があります（WCAG 2.1.1）。Tabキーでページを移動してみてください。すべてのリンク、ボタン、フィールドが論理的な順序で到達でき、フォーカスがどこにあるかが常に見えるはずです（2.4.7 フォーカスの可視化）。WCAG 2.2では、フォーカスされた要素が固定ヘッダーやクッキーバナーの裏に完全に隠れてはならないことが追加されました（2.4.11、レベルAA）。

よくある失敗は、ホバーでしか開かないメニュー、フォーカスを閉じ込めない、またはEscキーで閉じられないモーダル、そして代わりのものがないままCSSに書かれたoutline: noneです。

テキストによる代替手段

意味のある画像にはすべて、文脈の中で何を示しているかを説明する代替テキストが必要です（「試食メニューを盛り付けるシェフ」であって、「image1.jpg」ではありません）。装飾的な画像には、空のalt=""を付けて、スクリーンリーダーが読み飛ばすようにします。アイコンだけのボタンには、アクセシブルな名前（「閉じる」、「検索」）が必要です。動画には字幕、音声には文字起こしが必要です。

色とコントラスト

WCAG 2.2のレベルAAでは、通常のテキストに対して少なくとも4.5:1、大きなテキストに対して3:1のコントラスト比が求められます（1.4.3）。また、入力欄の枠線や意味を伝えるアイコンなどのインターフェース部分には3:1が求められます（1.4.11）。薄いグレーのプレースホルダーテキストや淡いボタンが、よくある失敗です。また、意味を色だけで伝えてはいけません。無効なフィールドの赤い枠線には、エラーメッセージも必要です。

拡大縮小とリフロー

200%に拡大したときもテキストが使えなければならず（1.4.4）、320 CSSピクセルの幅で横スクロールせずにコンテンツが機能する必要があります（1.4.10）。適切なレスポンシブなレイアウトで、これらの多くは解決します。

ターゲットサイズ、フォーム、エラー

ターゲットのサイズ：WCAG 2.2のレベルAAでは、ポインターのターゲットは少なくとも24×24 CSSピクセルであるか、小さいものの周りに十分な余白があることが求められます（2.5.8）。大きいほど、スマートフォンでは親切です。
フォーム：プレースホルダーだけでなく、表示されたラベル、明確な説明、そして何が問題で、どう直せばよいかを、フィールドのすぐそばに示すエラーメッセージ。
ログイン：代替手段なしで、パズルを解かせたり、コードを書き写させたりしないでください。パスワードマネージャーの利用や貼り付けを許可しましょう（3.3.8 アクセシブルな認証）。

効果のあるプロンプト

WCAG 2.2のレベルAAを満たすようにこのサイトを作ってください。意味のあるHTMLのランドマーク、ページごとに1つのh1と順番どおりの見出し、本物のボタンとリンクの要素、すべてのフォームフィールドのラベル、見えるフォーカススタイル、少なくとも4.5:1のテキストコントラスト、意味のある画像の代替テキスト、装飾的な画像にはalt=""、そしてhtmlのlang設定を行ってください。

/signupと/checkoutのページをアクセシビリティの観点で監査してください。キーボードだけでの操作、フォーカスの順序、見えるフォーカス、ラベル、エラーメッセージ、コントラスト、アイコンボタンのスクリーンリーダー上の名前を確認してください。問題ごとにWCAGの基準を挙げ、視覚的なデザインを必要以上に変えずに修正してください。

モバイルメニューはキーボードで操作できません。aria-expandedを持つボタンにして、開いたときにフォーカスをメニューの中に移し、Escキーで閉じてボタンにフォーカスを戻してください。

ステップごとの手順

自動チェックを実行する。 Chromeの開発者ツールのLighthouseのアクセシビリティセクション、またはaxeのブラウザ拡張機能で、主要なページごとに確認します。報告されたものはすべて修正します。
マウスを外す。 各ページをTabキーで移動し、すべての主要な操作（登録、検索、チェックアウト）を完了させます。到達できない、フォーカスが見えない、抜け出せない箇所をメモします。
200%に拡大し、ウィンドウをスマートフォンの幅に狭めます。何も切れたり、横スクロールが必要になったりしてはいけません。
10分間スクリーンリーダーを試す。 MacとiPhoneならVoiceOver、AndroidならTalkBack、Windowsなら無料のNVDAです。見出し、リンク、フォームフィールドを聞いてみてください。名前のない「ボタン」や「リンク、ここをクリック」は、修正が必要なサインです。
コントラストを確認する。 コントラストチェッカーで、テキスト、ボタン、入力欄を確認します。
修正し、同じ操作を再テストする。
アクセシビリティに関する声明を公開する。 どの基準を目指しているか、問題をどう報告すればよいかを書き、その報告には必ず返信してください。

よくある間違い

コードを直す代わりに、オーバーレイのウィジェットに頼る。
見た目が乱雑だからという理由で、フォーカスの枠線を消す。 代わりのものは用意されていません。
プレースホルダーのテキストを唯一のラベルにする。 入力が始まると消えてしまい、多くの場合コントラストも低いです。
「ここをクリック」や「続きを読む」のリンク。 文脈がないと、スクリーンリーダーの利用者には同じリンクが並んでいるように聞こえます。
キーワードを詰め込んだ代替テキスト。 代替テキストは人のためのものです。画像を説明しましょう。
一度しかテストしない。 新しい機能はどれもキーボード操作を壊す可能性があります。公開前のテストに、キーボードの確認を加えましょう。

アクセシビリティのチェックリスト

主要なページで自動チェック（LighthouseまたはaxeでOK）
すべての操作をキーボードだけで完了できる
フォーカスは常に見えて、固定要素の裏に隠れない
意味のある見出し、ランドマーク、ボタン、リンク。langを設定
意味のある代替テキスト。装飾的な画像はalt=""。動画には字幕
テキストのコントラストは4.5:1以上（大きなテキストは3:1以上）。UI部分は3:1以上
200%の拡大と320pxの幅で動作する
すべてのフォームフィールドに、見えるラベルと分かりやすいエラーメッセージがある
問題を報告する方法を示したアクセシビリティ声明がある

この背景にある考え方については、ウェブアクセシビリティとは何かをお読みください。アクセシブルな設計と見た目の良いデザインは大きく重なります。視覚的な側面については、AIで見た目の良いアプリを設計する方法で説明しています。

Mythexでのアクセシビリティ

Mythexは、求める標準に合わせて構築します。そのため、最初のプロンプトと後続のリクエストに「WCAG 2.2 AA」と書いてください。プレビューのスマートフォンサイズの枠を使って小さな画面を確認できます（プレビューとコード）。ただし、キーボード、ズーム、スクリーンリーダーのテストは、公開URLか、独立したタブで開いたプレビューで行うのが最も効果的です。エージェントにページの監査を依頼し、見つかったものを修正してもらい、修正内容は自分でテストしてください。自動チェックは出発点であって、承認の証明ではありません。

よくある質問

ウェブサイトのアクセシビリティに関する現在の標準は何ですか？

2026年9月時点で、W3Cの現在の標準はWCAG 2.2です。2023年10月に最初に公開されました。多くの組織や多くの法律では、レベルAAを目標としています。WCAG 3はまだ初期のドラフトです。

アクセシビリティオーバーレイを使えば、サイトは準拠しますか？

1つに頼らないでください。オーバーレイはページの上にツールバーを追加するだけで、基になるコードのラベルの欠落、壊れたキーボード操作、不適切な構造を修正することはできません。サイト自体を修正することで、初めて使いやすくなります。

自動チェッカーですべての問題が見つかりますか？

いいえ。Lighthouseやaxeのようなツールは、代替テキストの欠落、低いコントラスト、ラベルのないフィールドなどを検出できます。しかし、フォーカスの順序がわかりにくい、リンクのテキストに意味がない、代替テキストはあるが内容が間違っている、といった多くの問題は、キーボードとスクリーンリーダーで実際に確認する人が必要です。

WCAGではどのコントラスト比が求められますか？

WCAG 2.2のレベルAAでは、通常のテキストに対して少なくとも4.5:1、大きなテキストに対して3:1を求めています。また、入力欄の枠線や、意味を伝えるアイコンなどのUIコンポーネントには3:1を求めています。