出荷前に実施すべき5つのアクセシビリティチェック

出荷前に、以下の順序で5つのチェックを実行してください。キーボードでUI全体をTabキーで移動する、自動スキャンを実行する、セマンティックHTMLとラベルを検証する、色のコントラストを確認する、そして200%ズームでテストする。

キーボードユーザーを密かにトラップしてしまうモーダルを出荷し、数週間後にバグレポートで発覚した経験がある人なら、こうしたリストが存在する理由がわかるはずです。マウスを手にしている限り、誰も気づかない類の問題です。

これら5つを合わせても数分で終わり、最も一般的なアクセシビリティの不具合を捕捉できます。専門知識も、高価なツールも、数週間の学習も必要ありません。これは、すべてのプルリクエストで実行できる、出荷前アクセシビリティチェックリストであり、高速かつ自らの限界について正直であるように作られています。これによってアプリがWCAG 2.2（2023年10月にW3C勧告として公開され、ISO/IEC 40500:2025として採択された現行標準）に完全準拠するわけではありませんが、実際のユーザーに最も大きな損害を与える不具合は解消できます。少しでもやることは、何もやらないことより明確に優れています。

1. キーボードでUI全体をTabキーで移動する

最も速く実効性のあるテストは無料で、1分もかかりません。マウスを置き、Tabキーでページを移動し、フォーカスが見えること、すべてのインタラクティブ要素に到達できること、トラップされずにすべてのモーダルから脱出できることを確認します。次の4点に注意してください。各要素に可視のフォーカスインジケーターがあること、タブ順序が論理的であること、すべてのボタン/リンク/入力欄に到達できること、そしてドロップダウンやダイアログにフォーカストラップがないこと。

キーボード関連の不具合のほとんどは、2つのバグが原因です。1つ目は、再スタイリングのためにネイティブのアウトラインを隠したカスタムコントロール。もしそうしているなら、可視の:focus（または:focus-visible）スタイルを戻してください。

.custom-checkbox input:focus-visible + .box {
  outline: 2px solid #2563eb;
  outline-offset: 2px;
}

2つ目は、クリック可能な<div>です。これは<button>に置き換えましょう。<button>はデフォルトでフォーカスを受け取り、Enter/Spaceでの実行とbuttonロールをコストゼロで備えています。<div>にはそのいずれもありません。

// Not reachable by keyboard
<div onClick={handleClick}>Save</div>
// Focusable and operable by default
<button onClick={handleClick}>Save</button>

手動のTab移動でテストできるのは、あなたが設計したハッピーパスです。実セッションのセッションリプレイは、実環境でのみ現れるキーボードとフォーカスの不具合を表面化させます。モーダルにTabで入ったあと外へ戻れないユーザー、ダイアログを閉じた後にフォーカスがドキュメント先頭へ消え、キーボードユーザーが迷子になるケースなどです。リプレイは、実際のフォーカス挙動がスキャンで承認された内容とどこで乖離しているかを示してくれます。

2. 自動スキャンを実行する（Lighthouse + axe DevTools）

スキャナーが検出できるのはページ上のアクセシビリティ問題の3分の1から40%程度です。つまりスコアが緑になったということは、簡単に取れる成果（alt属性の欠落、ラベルのない入力欄、低コントラスト、lang属性の欠落）を片付けたという以上の意味はありません。この範囲はテストベンダーが一般的に報告している数値であり、上限ではなく下限です。Dequeの2021年の調査は、カバーされた達成基準の割合ではなく検出された問題の件数で数えると、自動化のカバレッジは57%近くになると主張しています。いずれにせよ、捕捉された問題は修正コストが最も安いものです。

スキャンはChrome DevToolsのLighthouseパネルから実行します。DevToolsを開き、Lighthouseパネルを選択し、Accessibilityにチェックを入れてレポートを生成します。アクセシビリティのみの実行はすぐに完了します。Lighthouseのアクセシビリティ監査はDequeのオープンソースのaxe-coreルールセットの上に構築されていますが、そのルールセットの一部しか実行しません。そこでaxe DevTools拡張機能を追加しましょう。こちらは完全なルールを実行し、アクセシビリティだけに焦点を当てています。まずCriticalとSeriousの問題を修正してください。

3. セマンティックHTMLとラベルを検証する

スクリーンリーダーはセマンティクスを通じて構造を伝えるため、目的に合った要素を使いましょう。アクションには<button>、ナビゲーションには<a href>、リストには<ul>/<li>、ランドマークには<nav>と<main>、見出しは順序どおりに（h1 → h2 → h3、レベルを飛ばさない）。すべてが<div>だと、スクリーンリーダーは「グループ、グループ、グループ」と読み上げ、ページは形を失います。

すべての入力欄には関連付けられた<label>が必要です。アイコンのみのボタンにはaria-labelが必要で、そうしないと単に「ボタン」とだけ読み上げられてしまいます。

<label htmlFor="email">Email</label>
<input id="email" type="email" />

<button aria-label="Copy to clipboard" onClick={copy}>
  <ClipboardIcon />
</button>

本番でよくある失敗パターン：見た目の洗練されたサードパーティのコンポーネントライブラリが、アクセシブルでないマークアップを出荷しているケースです。たとえばアコーディオンやコンボボックスの<input>に<label>がなく、スクリーンリーダーが何も読み上げないというものです。見た目のきれいなコンポーネントは保証にはなりません。ライブラリがレンダリングするDOMを検査し、ラベルが本当に存在することを確認しましょう。

4. 色のコントラストを確認し、色だけに頼らない

Level AAでは、WCAG達成基準1.4.3に従い、通常テキストは最低4.5:1、大きなテキスト（18pt/24px、または14pt/18.66pxの太字）は3:1のコントラスト比が必要です。どちらの数値も絶対的な下限として扱ってください。この値に向けた切り上げは認められないので、実測4.499:1は不合格です。インターフェースコンポーネントと意味を持つアイコンは、隣接する色に対して3:1という別のより低い基準に該当します（達成基準1.4.11 非テキストのコントラスト）。つまり、テキスト色が合格していても、ボタンやフォームの枠線が合格しているとは限りません。

Lighthouseは多くのテキストコントラストの不具合を指摘してくれます。WebAIM Contrast Checkerでは正確な比率を確認できます。具体的には、白地に#999999は2.85:1で不合格、白地に#595959は7:1で合格です。

コントラストだけが問題ではありません。エラーを色だけで示すことは決してしないでください。赤い枠線は多くの色覚に多様性のあるユーザーには見えないので、アイコンとテキストを組み合わせ、色なしでも意味が伝わるようにしましょう。赤い枠線だけでなく、フィールドの横に「⚠ メールアドレスは必須です」というメッセージを追加してください。

5. 200%にズームし、モーションの削減を尊重する

ブラウザのズーム200%で、要素が重なったり、切れたり、横スクロールを強制したりしてはいけません。Ctrl/Cmdを押しながら+を押してズームを200%にし、あちこちクリックしてみてください。固定幅のコンテナやピクセルベースのサイズ指定が通常の犯人です。remでサイズを指定し、overflow-wrapを追加すると、レイアウトが柔軟に保たれます。

.container { max-width: 60rem; padding: 1rem; }
p { overflow-wrap: break-word; }

次にprefers-reduced-motionを尊重しましょう。必須ではないアニメーションをメディアクエリで囲み、OSでモーションの削減を要求したユーザーがそれによって影響を受けないようにします。この設定が求めているのは装飾目的で存在するモーションを削ることであり、すべてのアニメーションを取り除くことではありません。意味を伝えるもの（ローディングスピナー、進捗インジケーター）は動かし続けてください。

@media (prefers-reduced-motion: reduce) {
  /* Target the decorative motion, not every animation on the page.
     Loading spinners and other essential feedback should keep moving. */
  .parallax,
  .carousel-autoplay,
  .hero-animation {
    animation: none;
    transition: none;
  }
}

おまけ、60秒： スクリーンリーダーをオンにして聞いてみましょう。macOSではCmd + F5でVoiceOver、Windowsでは無料のNVDAをインストールします。Tabキーで移動し、見出し、ラベル、入力欄が実際に意味の通る形で読み上げられることを確認してください。

出荷して、それから深掘りする

この5つのチェックは下限であり、上限ではありません。複雑なARIAパターン、シングルページアプリでのフォーカス管理、アクセシブルなデータテーブルは対象外で、いずれも別の日に取り組むべき実際の作業です。次の機能を選び、PRを開く前にこの5つを実行し、見つかったCriticalな問題を修正しましょう。さらに先へ進む準備ができたら、WCAG 2.2、WebAIM、そしてMDNのアクセシビリティドキュメントが、時間を費やす価値のある一次情報源です。アクセシビリティは進んでいく方向性であり、この5つのチェックを出荷することで、今日からその方向へ一歩進めます。

FAQ

アクセシビリティにはどのくらいのコントラスト比が必要ですか？

WCAG 2.2 Level AAでは、達成基準1.4.3に従い、通常テキストは背景に対して最低4.5:1、大きなテキスト（18pt/24px、または14pt/18.66pxの太字）は最低3:1のコントラスト比が必要です。インターフェースコンポーネントと意味を持つアイコンは別の基準1.4.11に該当し、隣接する色に対して3:1が求められます。どちらの数値も切り上げは認められないため、実測4.499:1は不合格です。

自動アクセシビリティツールはすべてを捕捉できますか？

いいえ。Lighthouseとaxeが表面化させるのはアクセシビリティ問題の3分の1から40パーセント程度で、その大半はalt属性の欠落、ラベルのない入力欄、低コントラスト、lang属性の欠落といった簡単に取れる成果です。altテキストが意味を持つか、タブ順序が論理的か、インタラクション後にフォーカスが管理されているかは判断できません。Lighthouseのスコアが緑になっても、それは安価に修正できる問題を片付けただけでページ全体を保証するものではないので、すべてのスキャンにはキーボードテストとスクリーンリーダーテストを組み合わせてください。

Lighthouseとaxe DevToolsの違いは何ですか？

Lighthouseのアクセシビリティ監査はDequeのaxe-coreルールセットの上に構築されていますが、その一部しか実行せず、パフォーマンス、SEO、ベストプラクティスの監査と並んで、すべてChrome DevToolsのLighthouseパネルから実行されます。axe DevToolsブラウザ拡張機能は完全なaxe-coreルールセットを実行し、アクセシビリティだけに特化しています。手早く確認するにはLighthouseを実行し、そのうえでより深いアクセシビリティ専用のカバレッジにはaxe DevToolsを使いましょう。

2026年にはどのWCAGバージョンに従うべきですか？

現行標準であるWCAG 2.2に従ってください。2023年10月にW3C勧告となり、2024年12月に更新され、現在はISO/IEC 40500:2025でもあります。これは2023年10月版と同一の内容です。WCAG 3.0はW3Cが定期的に改訂している草案（Working Draft）としてのみ存在し、勧告候補（Candidate Recommendation）は2027年後半の見込みで、最終勧告は2028年以前には見込まれていません。WCAG 3.0は現時点で何も規定していません。