結論：Webアクセシビリティ（a11y）対応は「正しい順序」で進めれば外注や専門知識がなくても着手でき、Claude Codeは既存UIの問題洗い出し・セマンティックHTMLへの書き換え・WAI-ARIAの当て方・コントラスト改善を一気通貫で支えてくれます。ただし最終確認は自動チェックと支援技術の両輪が前提です。
- 要点1：WCAG 2.2（W3C勧告・2023年10月公開、2024年12月更新）の4原則「知覚可能・操作可能・理解可能・堅牢」を基準にする。まずAA準拠を目標にすると現実的です。
- 要点2：Claude Codeには「現状把握→方針→実装→確認→落とし穴」の5フェーズで指示を出す。各フェーズで生成されたコードは必ず人がレビューします。
- 要点3：axeなどの自動チェックで拾えるのはWCAG課題の一部だけ。キーボード操作とスクリーンリーダーでの実機確認を組み合わせて初めて「使える」状態になります。
対象読者：自社プロダクト・社内ツール・コーポレートサイトのアクセシビリティ対応を始めたいフロントエンドエンジニア・PM・実装担当。
今日やること：手元のページを1枚選び、Claude Codeに「このHTMLのアクセシビリティ上の問題点をWCAG 2.2の観点で洗い出して」と投げて、現状の課題リストを作るところから。
「アクセシビリティ対応、やった方がいいのは分かってるけど、何から手をつければいいのか分からない」——フロントエンドの現場で、これは本当によく聞く声です。正直に言うと、私自身も最初は「とりあえずalt属性を埋めればいいんでしょ」くらいの理解でした。でも実際に支援技術で自分のサイトを触ってみると、キーボードだけでは押せないボタン、読み上げ順がぐちゃぐちゃなフォーム、コントラストが足りなくて読めないラベルが山ほど出てきます。
この記事では、Claude Code（Anthropicのエージェント型コーディングツール）を使って、Webアクセシビリティ対応を「現状把握→方針→実装→確認→落とし穴の回避」という5つのフェーズで現実的に進める方法を、実際に投げる指示例とコード例つきで解説します。2026年6月時点のClaude Codeの挙動とWCAG 2.2を前提にしています。
そもそもWebアクセシビリティ（a11y）とは何か
アクセシビリティ（accessibility）は、頭の「a」と末尾の「y」の間に11文字あることから「a11y」と略されます。Webの文脈では「障害の有無や利用環境にかかわらず、すべての人がWebコンテンツを知覚・操作・理解できる状態」を指します。視覚障害のある人がスクリーンリーダーで読み上げる、手が不自由な人がキーボードだけで操作する、色覚特性のある人がコントラストで情報を区別する——こうした多様な使い方に耐えられる作りにすることが目的です。
判断の拠り所になるのが、W3C（World Wide Web Consortium）が策定するWCAG（Web Content Accessibility Guidelines）です。2026年6月時点の最新勧告はWCAG 2.2で、2023年10月5日に公開され、2024年12月12日に更新版が出ています（W3C公式）。WCAGは次の4原則で構成されます。
- Perceivable（知覚可能）：情報やUIは、ユーザーが知覚できる形で提供されること（例：画像の代替テキスト、十分なコントラスト）
- Operable（操作可能）：UIは操作できること（例：キーボードだけで全機能にアクセスできる）
- Understandable（理解可能）：情報と操作は理解できること（例：エラーメッセージが分かりやすい）
- Robust（堅牢）：支援技術を含む多様な環境で確実に解釈できること（例：正しいマークアップ）
各達成基準（Success Criteria）にはA・AA・AAAの3つの適合レベルがあります。Aが最低限、AAが多くの公的・商用サイトで目標とされる現実的なライン、AAAは最も厳格です。まずはAA準拠を目標にすると、コストとインパクトのバランスが取りやすいです。
注意したいのは、WCAGの達成基準を満たすことと「実際に使いやすい」ことはイコールではない、という点です。基準はあくまで最低限の足切りで、実際の利用者視点での確認が別途必要になります。この前提は記事を通じて繰り返します。
フェーズ1：現状把握 — 既存UIの問題点を洗い出す
いきなり直し始めるのではなく、まず「どこに、どんな問題があるか」を棚卸しします。ここがClaude Codeの得意領域です。既存のHTML/JSX/Vueテンプレートを読ませて、WCAGの観点で問題を構造的に列挙させます。
実際に投げる指示の例です。
このディレクトリのコンポーネント（src/components/）を読んで、
Webアクセシビリティ上の問題点をWCAG 2.2の観点で洗い出してください。
出力は次の表形式でお願いします：
- ファイル名 / 該当箇所（行）
- 問題の内容
- 関連するWCAG達成基準（例: 1.1.1 非テキストコンテンツ）
- 重大度（高/中/低）
- 修正方針の概要
判断に迷う箇所や、コードだけでは分からない点（実際の見た目・色・動的挙動など）は
「要・人による確認」と明記してください。仮定した点は必ず「仮定」と書いてください。ポイントは2つあります。1つはWCAGの達成基準番号を紐づけさせること。「altがない」だけでなく「1.1.1 非テキストコンテンツ違反」と紐づくと、後で公式ドキュメントを引いて裏取りできます。もう1つは「コードだけでは判断できない箇所を明示させる」こと。コントラスト比や動的なフォーカス移動は、静的なコードを読むだけでは確定できません。ここを正直に「要確認」と書かせることで、自動判定の限界を可視化できます。
よく挙がってくる典型的な問題は以下のようなものです。
<div onClick>でボタンを作っていて、キーボードで操作できない- 画像の
alt属性が空、または「image1.png」のようなファイル名のまま - フォーム入力欄に
<label>が紐づいていない - 見出しレベル（h1〜h6）が階層を飛ばしている、または見た目だけ大きい
<div> - 色だけで状態（エラー・必須）を伝えていて、色覚特性のある人に伝わらない
フェーズ2：方針 — WCAG/WAI-ARIAの当て方を決める
問題リストができたら、次は「どう直すか」の方針です。ここで大事な原則が1つあります。「ARIAを足す前に、まずネイティブのHTML要素で解決できないか考える」ということです。
WAI-ARIA（Accessible Rich Internet Applications）は、ネイティブHTMLだけでは表現しきれない役割や状態を支援技術に伝えるための仕様です。ただしMDNやW3CのARIA Authoring Practices Guide（APG）でも繰り返し強調されているのが、「No ARIA is better than Bad ARIA（誤ったARIAを付けるくらいなら、付けない方がまし）」という考え方です。<button> を使えば済むところに <div role="button"> を当てると、キーボード操作やフォーカス管理を全部自前で実装する羽目になり、かえって壊れやすくなります。
方針決めをClaude Codeに手伝わせる指示例です。
洗い出した問題のうち「キーボード操作不可のボタン」について、
修正方針を2案出してください。
案A: セマンティックなネイティブHTML要素に置き換える方針
案B: 既存のdiv構造を維持してWAI-ARIAで補う方針
それぞれのメリット・デメリット、実装コスト、壊れやすさを比較し、
どちらを推奨するか理由つきで述べてください。
ARIAを使う場合は、なぜネイティブ要素では解決できないのかも説明してください。このように「ネイティブHTML案」と「ARIA案」を必ず両方出させて比較することで、安易にARIAへ流れるのを防げます。多くの場合、答えは「まずセマンティックHTMLで直し、本当に必要な動的UI（タブ・モーダル・自動補完など）にだけARIAを使う」になります。
フェーズ3：実装の進め方 — 4つの主要領域
方針が決まったら実装です。アクセシビリティ対応で頻出する4領域を、Claude Codeで進める順に並べます。手順は次の<ol>の通りです。
- セマンティックHTMLへの書き換え：
<div>や<span>で組まれたUIを、<button><nav><main><header><ul>など意味を持つ要素に置き換える。これだけでキーボード操作・読み上げの多くが自動的に改善します。 - 代替テキストの整備：画像・アイコン・図表に文脈に合った
altを付ける。装飾目的の画像はalt=""で読み上げ対象から外す。 - キーボード操作とフォーカス管理：すべての操作がキーボードだけで完結するか、フォーカスの当たる順序が論理的か、フォーカスリングが見えるかを整える。
- コントラストと色以外の手がかり：テキストと背景のコントラスト比を確保し、色だけに依存しない表現（アイコン・テキスト併記）にする。
セマンティックHTMLへの書き換え指示
「クリックできるdiv」を直す典型的なケースです。修正前のコードを見せて、こう投げます。
次のコードをアクセシブルに書き換えてください。
キーボード操作（Enter/Spaceでの実行、Tabでのフォーカス）に対応させ、
可能な限りネイティブのHTML要素を使ってください。
【修正前】
<div class="btn" onClick={handleSubmit}>送信</div>
変更点と、なぜその書き換えが必要か（関連WCAG基準）も説明してください。期待される修正後はシンプルです。
<button type="button" class="btn" onClick={handleSubmit}>
送信
</button><button> にするだけで、フォーカス可能・EnterとSpaceでの実行・スクリーンリーダーへの「ボタン」role通知が、ブラウザ標準でついてきます。<div> + role="button" + tabindex + キーイベントハンドラ、という自前実装が丸ごと不要になります。これがセマンティックHTML優先の威力です。
代替テキストとフォームラベルの整備
フォーム周りは離脱率にも直結する重要領域です。<label> と入力欄を for/id で紐づける、エラーを aria-describedby で関連づける、といった対応をまとめて指示します。
このフォームのラベルとエラー表示をアクセシブルにしてください。
- 各入力欄に対応する<label>を紐づける（for/id）
- 必須項目は色だけでなくテキストでも示す
- エラーメッセージをaria-describedbyで入力欄に関連づける
- エラー発生時にスクリーンリーダーへ通知する仕組み（aria-live等）も検討
各変更について、対応するWCAG達成基準を併記してください。キーボード操作・フォーカス管理とコントラスト
モーダルやドロワーなど動的UIは、開いたときにフォーカスを内部へ移し、閉じたら元の位置へ戻す「フォーカストラップ」が必要です。コントラストについては、WCAG 1.4.3（達成基準）で通常サイズのテキストは4.5:1以上、大きいテキスト（約18pt以上、または太字14pt以上）は3:1以上のコントラスト比が求められます（AAレベル）。Claude Codeに既存のCSS変数を読ませて、この基準を満たすか試算させ、満たさない組み合わせの代替色案を出させることができます。
このCSSのカラーパレット（:root の変数）について、
テキスト色と背景色の主要な組み合わせのコントラスト比を計算してください。
WCAG 2.2 AAの基準（通常テキスト4.5:1、大きいテキスト3:1）を満たすか判定し、
満たさない組み合わせには、ブランド印象を保ちつつ基準を満たす代替値を提案してください。
※算出したコントラスト比は、実機のツールでも必ず再確認する前提で出してください。フェーズ4：確認 — チェックツールと支援技術の両輪
実装したら確認です。ここを軽視すると「直したつもり」で終わります。確認は自動チェックと手動・支援技術の確認の2段構えにします。
自動チェックツール
代表的なのがaxe-core（Deque社のオープンソースエンジン）と、それをChrome DevToolsに統合したLighthouseのアクセシビリティ監査です。Claude CodeにCIへの組み込みも頼めます。
このプロジェクトに、Playwrightとaxe-coreを使った
アクセシビリティの自動テストを追加してください。
- 主要ページ（トップ、フォーム、一覧）でaxeを実行し違反を検出
- GitHub ActionsのCIで自動実行されるよう設定
- 検出された違反は、関連WCAG基準とともにレポート出力
自動チェックで拾えるのはWCAG課題の一部である点を、
READMEにも注記として書き加えてください。支援技術と手動での確認
自動チェックは強力ですが万能ではありません。研究や各種調査でも繰り返し指摘されているように、自動ツールで検出できるアクセシビリティ問題は全体の一部にとどまり、残りは人の目と支援技術での確認が必要です。最低限、次の3つは手で確認してください。
- キーボードだけで操作：マウスを使わず、Tab・Shift+Tab・Enter・Space・矢印キーだけで全機能が使えるか。フォーカスが今どこにあるか目で追えるか。
- スクリーンリーダーで読み上げ：macOSのVoiceOver、WindowsのNVDAなどで、読み上げ順が論理的か、ボタンやリンクの役割が正しく伝わるかを聞く。
- 拡大・コントラスト：ブラウザを200%に拡大しても崩れないか、OSのコントラスト設定で破綻しないか。
Claude Codeはコードを直せますが、「VoiceOverで実際にどう聞こえるか」は人間にしか確認できません。ここは必ず自分の手と耳を使います。
フェーズ5：落とし穴 — ここでつまずく
最後に、現場で繰り返し見てきた失敗パターンと回避策をまとめます。
失敗1：自動チェックが通ったから「対応完了」と判断する
❌ axeで違反0件 → 「アクセシブルになった」と公開
⭕ axe 0件は出発点。キーボード操作・スクリーンリーダーでの実機確認まで終えて初めて完了
なぜ重要か：自動ツールはコントラストやalt欠落のような機械判定できる項目に強い一方、「altの文章が文脈に合っているか」「読み上げ順が自然か」は判定できません。自動チェックだけに頼ると、機械的には合格でも実際には使えないUIが残ります。
失敗2：とりあえずARIAを盛る
❌ <div role="button" aria-label="送信" tabindex="0"> を多用
⭕ まず <button> などネイティブ要素で解決し、ARIAは本当に必要な箇所だけ
なぜ重要か：誤ったARIAは、付けないより害になることがあります（No ARIA is better than Bad ARIA）。roleを宣言するとキーボード操作やフォーカス管理を自前で完成させる責任が発生し、抜けると壊れます。
失敗3：生成されたコードを確認せずにマージする
❌ Claude Codeが直したから正しいはず、とそのままコミット
⭕ 生成された差分は必ず人がレビューし、WCAG基準と挙動を確認してからマージ
なぜ重要か：AIは文脈の取り違えや、もっともらしく見えて不正確なaria-*属性を提案することがあります。アクセシビリティは利用者の体験に直結するため、最終的な妥当性判断は人が担う必要があります。
失敗4：基準（WCAG）を確認せず「だいたいこんな感じ」で進める
❌ コントラスト比や達成基準をうろ覚えのまま実装
⭕ 数値や条件はW3CのWCAG/MDNの公式ドキュメントで都度確認する
なぜ重要か：コントラスト比の閾値や「大きいテキスト」の定義など、細部は記憶で誤りがちです。基準は必ず一次情報で確認してください。
関連記事と次のステップ
アクセシビリティ対応は、フロントエンド開発全体のワークフローの一部として組み込むと定着します。実装の土台となるフロントエンド開発の進め方はClaude Codeで爆速フロント開発｜React/Next.jsガイドに、多言語サイトでのlang属性や読み上げ言語の扱いは国際化i18n対応をClaude Codeで進める実践ガイドにまとめています。生成コードを安全にマージするレビュー運用はClaude Codeでコードレビューを効率化する実践ガイドが、Claude Code全体の使いこなしはClaude Code 実践テクニック完全ガイドが参考になります。
まとめ
Webアクセシビリティ対応は、「現状把握→方針→実装→確認→落とし穴の回避」という順序で進めれば、専門家でなくても着実に前進できます。Claude Codeは問題の洗い出し・セマンティックHTMLへの書き換え・WAI-ARIAの当て方の検討・コントラスト試算・自動テスト整備まで広く支えてくれる一方で、最終確認は自動チェックと支援技術の両輪が前提で、生成コードは必ず人がレビューします。基準（WCAG 2.2）の細部はW3C・MDNの公式情報で都度確認してください。今日はまず手元の1ページをClaude Codeに読ませ、WCAGの観点で課題リストを作るところから始めてみてください。
よくある質問（FAQ）
Q1. WCAGとWAI-ARIAは何が違うのですか？
WCAGはアクセシビリティの「達成すべき基準・ガイドライン」、WAI-ARIAは「ネイティブHTMLで表現しきれない役割・状態を支援技術に伝えるための技術仕様」です。WCAGがゴール、ARIAは手段の一つという関係です。
Q2. まずどのレベル（A/AA/AAA）を目指せばいいですか？
多くの公的・商用サイトではAA準拠が現実的な目標とされます。Aは最低限、AAAは最も厳格で全コンテンツでの達成は難しい場合が多いため、まずAAを目標にするのが一般的です。
Q3. 自動チェックツールだけで対応は完了しますか？
いいえ。axeやLighthouseなどの自動ツールで検出できるのはWCAG課題の一部です。altの文脈適合性や読み上げ順、キーボード操作の自然さは機械判定できないため、支援技術での実機確認が必須です。
Q4. Claude Codeが直したコードはそのまま使って大丈夫ですか？
必ず人がレビューしてください。AIはもっともらしく見えても不正確なaria-*属性や役割を提案することがあります。WCAG基準と実際の挙動を確認してからマージするのが安全です。
Q5. コントラスト比の基準は具体的にいくつですか？
WCAG 2.2 AAでは、通常サイズのテキストで4.5:1以上、大きいテキスト（約18pt以上、または太字14pt以上）で3:1以上が求められます（達成基準1.4.3）。正確な値は実機のコントラストチェックツールで確認してください。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』（SBクリエイティブ）。
