上位100万件のウェブサイトのうち、ほぼ96%で検出可能なWCAG違反が見つかっており、しかも毎年、その大多数が同じ6種類の問題によって引き起こされています。このガイドでは、それぞれの違反について具体的なコードレベルの修正方法を解説し、今日から本当にアクセシビリティ上の負債を減らせるようにします。

今すぐ上位100万サイトのどれかを開くと、数秒で自動スキャナーが検出できるWCAG違反が見つかる確率は100件中96件です。100万のホームページ全体で、56,114,377件の個別のアクセシビリティエラーが検出されました — 1ページあたり平均56.1件のエラーです。特に注目すべきなのは、検出されたエラーの96%がわずか6つのカテゴリに集中しており、その最も一般的な6種類のエラーは過去7年間ずっと変わっていないという点です。つまり、よく理解された少数の問題を修正するだけで、ウェブ全体のアクセシビリティを劇的に改善できる — そしてそれは、あなたのサイトから始まります。

なぜ同じ6つの失敗が繰り返し現れるのか

高度な開発ツールが普及し、法的な監視も強まっているこの時代に、なぜ同じエラーが年々大規模に残り続けるのか、不思議に思うかもしれません。その答えはシステム的なものです。このエラーの密度は、アクセシビリティの欠如がウェブ開発の慣行にどれほど深く組み込まれているかを反映しています。テンプレートの問題はすべてのページに増殖し、コンポーネントの不具合はサイト全体で繰り返されます。アクセシビリティに意図的に注意を払わない限り、標準的な開発ワークフローは体系的にアクセシブルでない結果を生み出します。

また、自動化によって進歩しているという誤った感覚もあります。自動テストが検出できるのは、潜在的なWCAG違反の30〜40%にすぎません。自動テストに合格したサイトであっても、キーボード操作、スクリーンリーダー、認知アクセシビリティに関する重大な問題を抱えている可能性があります。つまり、書類上は準拠しているように見えるごく一部のサイトでさえ、実際には要件を満たしていない可能性が高いということです。

法的なリスクは現実的で、しかも高まっています。Seyfarth Shawによると、2024年にはADA Title IIIに基づく連邦訴訟が8,800件提起され、そのうち約2,452件がウェブアクセシビリティを直接対象としていました。Eコマースサイトは不釣り合いなほど高いリスクにさらされており、ウェブアクセシビリティ訴訟の77%がオンライン小売を対象としています。準拠はもはや「あれば望ましい」ものではありません。事業継続の問題です。

その一方で、心強い側面もあります。この集中には実務的な意味があります。組織は、少数の問題タイプに集中することで、アクセシビリティ問題の大半に対処できます。包括的なWCAG準拠には78のすべての達成基準への配慮が必要ですが、最もインパクトの大きい改善は、これらの一般的な失敗を修正することから生まれます。では、それぞれについて、今日から実装できる実践的な修正方法とともに見ていきましょう。

失敗その1 — コントラスト不足のテキスト（WCAG 1.4.3）

コントラスト不足のテキスト — 背景との色の差が十分でないテキスト — は、調査対象のホームページの83.6%に見られました。これは最も一般的なWCAG違反であり、5サイト中4サイト以上に影響しています。 WCAG 1.4.3（最小コントラスト）は非常に明快です。通常のテキストは背景とのコントラスト比が少なくとも4.5:1を達成しなければならず、大きなテキスト（18ptまたは14ptの太字）は少なくとも3:1に達する必要があります。

コントラストの不備は、多くの場合、可読性よりも美観を優先するデザイン上の判断から生じます。白い背景に薄いグレーのテキストは、視力が完璧なデザイナーには洗練されて見えます。しかし、ロービジョンのユーザー、高齢のユーザー、あるいは画面に反射がある環境で読む人にとっては、判読不能です。セカンダリラベル、フォームのプレースホルダー、フッターテキスト、無効状態のボタンなどが典型的な犯人です — 目立たないようにスタイルされる結果、オーディエンスのかなりの割合には見えなくなってしまいます。

修正はほとんどの場合、CSSの調整だけです。WebAIMのコントラストツールやブラウザのDevToolsのアクセシビリティパネルなどのコントラストチェッカーで色の組み合わせを確認し、合格するまで前景色または背景色の値を少しずつ調整します。よくある失敗パターンと、その修正方法は次のとおりです。

/* 不合格 — 比率はおよそ 2.3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* 合格 — 比率はおよそ 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

プレースホルダーテキストについては、WCAGはそれを装飾的なヒントではなく「実際のテキスト」として扱うことを忘れないでください。そのため、4.5:1の閾値を満たす必要があります。プレースホルダーだけに指示を頼るのは避け、必ず可視の<label>要素と組み合わせてください。テキストを画像として使用している場合、CSSではコントラストを修正できません — 画像を再生成する必要があります。これは、テキストをグラフィックに埋め込むのではなく、生のHTMLテキストを好むべき理由のひとつでもあります。

失敗その2 — 画像の代替テキスト不足（WCAG 1.1.1）

代替テキストのない画像は、ホームページの58.2%に見られます。画像にaltテキストがないと、スクリーンリーダーユーザーは、本来意味のあるコンテンツがあるべき場所で、沈黙か意味のないファイル名に遭遇することになります。この問題は新しいものではありません。altテキストは、1999年のWCAG 1.0以来、基本的なアクセシビリティ要件とされてきました。それから25年経った今でも、ほとんどのウェブサイトは一貫して実装できていません。

この問題が残り続ける理由は、知識のギャップではなく、ワークフローのギャップです。この失敗率は、コンテンツワークフローに体系的な抜けがあることを示しています。ライターや編集者は、altテキストが必要であることを知らないことが多く、コンテンツ管理システムは必ずしもそれを入力するよう促しません。品質保証も、その欠如を見逃します。したがって、修正には技術的なレイヤーとプロセスのレイヤーという2つの層があります。

技術面では、意味のあるすべての画像に、その画像が伝える情報と同じ内容を伝えるalt属性が必要です。装飾的な画像 — 情報を追加しない純粋なビジュアル要素 — には、スクリーンリーダーが完全にスキップできるよう、空のalt=""を指定します。この区別を正しく行うことは、属性を追加することと同じくらい重要です。多くの画像は、altテキストが欠落しているか不正確です。意味のある画像に説明がまったくない一方で、装飾的な画像が意味のあるコンテンツとして扱われていることもよくあります。どちらの問題も、知覚可能なコンテンツに関するWCAG準拠を損ないます。

<!-- 意味のある画像: 画像が伝える内容を説明する -->
<img src='team-photo.jpg' alt='The Accsible engineering team at their 2024 offsite in Lisbon' />

<!-- 装飾的な画像: altは空、roleは不要 -->
<img src='wave-divider.svg' alt='' />

<!-- リンク付き画像: 画像ではなく遷移先を説明する -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='View pricing plans' />
</a>

プロセス面では、CMSのテンプレートを更新し、コンテンツ画像に対してaltフィールドを必須にし、アセットをアップロードするすべての人にトレーニングを行いましょう。Accsibleのような自動ツールを使えば、サイト全体でaltテキストが欠落している、または空になっている画像を検出でき、チームが体系的に対応できる監査可能なリストを提供できます。

失敗その3 — フォーム入力ラベルの欠如（WCAG 1.3.1, 3.3.2）

48.6%のウェブサイトでフォーム入力ラベルが欠落しています。この失敗は特に深刻です。なぜなら、フォームはユーザーが実際に行動する場所 — サインアップ、チェックアウト、問い合わせ、サポートリクエストの送信 — だからです。多くのフォームはアクセシブルなラベルを欠き、プレースホルダーだけに頼り、指示やエラーメッセージをプログラム的に公開せず、キーボードのみの利用をサポートしていません。フォームはほとんどのデジタル体験にとって不可欠であるため、これらの失敗は重大なユーザビリティ障壁を生み出します。

最も一般的な間違いは、<label>の代わりにプレースホルダーテキストを使うことです。プレースホルダーはユーザーが入力を始めると消えてしまうため、短期記憶に障害のある人や、単にフォーム入力中に気が散ってしまった人は、そのフィールドが何のためのものか分からなくなります。スクリーンリーダーがプレースホルダーをどう扱うかは製品によって異なり、どのアプローチも適切なラベル関連付けほど信頼できるものではありません。

正しいパターンは、for属性とid属性を一致させて、<label>要素を入力と関連付けることです。デザイン上の理由で可視ラベルが使えない場合は、aria-labelやaria-labelledbyを使用します — ただし、<label>を使えるのにARIAに頼るのはやめましょう。

<!-- 正しい: 明示的なラベル関連付け -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- 誤り: プレースホルダーのみ -->
<input type='email' placeholder='Email address' />

<!-- デザイン上ラベルを視覚的に隠す必要がある場合の許容パターン -->
<label for='search' class='visually-hidden'>Search the site</label>
<input type='search' id='search' name='q' />

エラーメッセージもプログラム的に関連付ける必要があります。フォームをバリデーションしてエラーを検出した場合、そのメッセージはaria-describedbyを使ってフィールドに紐付け、理想的にはフォーカスを最初の不正なフィールドに移動させるべきです。フォームのバリデーションエラーは効率的で直感的かつアクセシブルである必要があります — エラーが明確に特定され、問題のある要素への素早いアクセスが提供され、ユーザーが簡単にエラーを修正してフォームを再送信できなければなりません。

失敗その4 — 空のリンクとボタン（WCAG 2.4.4, 4.1.2）

44.6%のウェブサイトに空のハイパーリンクがあります。空のボタンはページのほぼ30%で見つかり、この数値は前年から増加しています。これは、送信、リセット、フィルター、検索といったボタンの目的を、視覚障害のあるユーザーが理解できないことを意味します。空のリンクとボタンは合わせて、スクリーンリーダーユーザーにとって最もフラストレーションのたまる体験のひとつです — 名前のないインタラクティブ要素に遭遇するのは、ラベルも行き先も分からないドアノブを押すようなものです。

空のリンクは、<a>タグの唯一の子要素がアイコンや画像であり、テキストの代替が提供されていない場合に最もよく発生します。空のボタンは、ハンバーガーメニュー、閉じるアイコン、ソーシャル共有ボタンなどのアイコンのみのボタンに、アクセシブルネームがまったくない場合に発生します。どちらも修正は単純です。

<!-- 空のリンク — 不合格 -->
<a href='/dashboard'><svg>...</svg></a>

<!-- aria-labelで修正 -->
<a href='/dashboard' aria-label='Go to dashboard'><svg aria-hidden='true'>...</svg></a>

<!-- 空のボタン — 不合格 -->
<button><svg>...</svg></button>

<!-- 視覚的に隠したテキストで修正 -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Close menu</span>
</button>

修正例のSVGにはいずれもaria-hidden='true'が付いていることに注目してください。aria-labelや視覚的に隠したテキストでテキスト代替を提供する場合、SVGをアクセシビリティツリーから除外したいのです — そうしないと、スクリーンリーダーがラベルとSVG自身のtitleやdescriptionの両方を読み上げ、混乱を招く二重アナウンスが発生する可能性があります。「click here」「read more」「learn more」といった曖昧なリンクテキストも関連する失敗です。曖昧なリンクテキストなどのハイパーリンクの問題は、ホームページのほぼ14%で見つかり、前年から増加しています。リンク先がどこなのかをユーザーが理解できるよう、適切なテキストを持つハイパーリンクが重要です。各リンクのアクセシブルネームは、文脈から切り離しても意味が通じる必要があります。なぜなら、スクリーンリーダーユーザーは、ページ上のすべてのリンクのリストを呼び出してナビゲートすることがよくあるからです。

失敗その5 — 文書の言語指定の欠如（WCAG 3.1.1）

コントラストやaltテキストに比べると些細に思えるかもしれませんが、約16%のページで文書の言語が設定されていません — そしてその影響はスクリーンリーダーユーザーにとって即時かつ衝撃的です。スクリーンリーダーユーザーが特定の言語パックをインストールしていれば、コンテンツは正しく読み上げられます。そうでなければ、ひどいアクセントのように聞こえ、理解できない可能性があります。

修正は1つのHTML属性 — 文字通り1行のコードであり、これを欠落させる言い訳はありません。<html>要素に、適切なBCP 47言語タグを指定したlang属性を追加します。ページの一部がページ全体とは異なる言語で書かれている場合は、その特定の要素にもlang属性を追加します。

<!-- 欠落: lang属性なし -->
<html>

<!-- 正しい: 英語ページ -->
<html lang='en'>

<!-- 正しい: フランス語ページ -->
<html lang='fr'>

<!-- ページ内でのインライン言語切り替え -->
<p>The French phrase <span lang='fr'>joie de vivre</span> means a cheerful enjoyment of life.</p>

CMSや静的サイトジェネレーターを使用している場合、lang属性はベーステンプレートで設定すべきです。一度テンプレートを確認して修正すれば、サイト上のすべてのページが即座に是正されます。これはおそらく、このリストの中で最も費用対効果の高い修正です — テンプレートを1カ所変更するだけで、ドメイン全体の問題を解消できます。

失敗その6 — アクセス不能なキーボードナビゲーションとフォーカス管理（WCAG 2.1.1, 2.4.7）

キーボードアクセシビリティは、自動テストと実際のユーザビリティのギャップが最も大きい領域です。自動ツールは、非セマンティックなタグで構築されたインタラクティブ要素など、一部のキーボード関連の失敗を検出できますが、タブ順序やフォーカストラップ、矢印キーだけでドロップダウンメニューを操作する体験などをシミュレートすることはできません。サイトはしばしば、代替を提供することなくデフォルトのフォーカスインジケーターを削除しており、キーボードナビゲーションをほぼ不可能にしています。これは、運動障害のあるユーザーだけでなく、キーボード操作を好む人、パワーユーザー、スイッチデバイスを使用する人にも影響します。

最も一般的なキーボード関連の失敗は、フォーカスを受け取らない<div>や<span>タグで構築されたカスタムインタラクティブコンポーネント、outline: noneやoutline: 0でブラウザのデフォルトフォーカスリングを削除しながら、同等に視認性の高い代替を提供していないCSSルール、フォーカスをトラップしないモーダルダイアログ（そのためキーボードユーザーがオーバーレイの背後にタブ移動できてしまう）、マウスなしでは操作できないカルーセルやアコーディオンなどです。

<!-- キーボード非対応のカスタムボタン — 不合格 -->
<div class='btn' onclick='doSomething()'>Submit</div>

<!-- 正しい: 本物のbuttonを使う -->
<button type='button' onclick='doSomething()'>Submit</button>

<!-- フォーカススタイルの削除 — WCAG 2.4.7に違反 -->
* {
  outline: none; /* グローバルには絶対にやらないこと */
}

<!-- より良い: 美観を保ちつつフォーカスを視認可能にスタイルする -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

:focus-visible疑似クラスは、ここでの最良の味方です。キーボードでナビゲートしているときにフォーカススタイルを表示し、マウスクリック時にはそれを抑制します — これにより、アクセシビリティを犠牲にすることなく、クリーンな見た目を実現できます。モーダルやドロワーについては、ダイアログが開いている間タブ移動をその中に制限し、閉じたときにトリガー要素へフォーカスを戻すフォーカストラップ用ユーティリティを使用してください。ポップアップは、適切なフォーカス管理やラベル、キーボードナビゲーションのサポートなしに表示されることがよくあります。これは、サインアップ、ログイン、チェックアウトなどの重要なユーザーフローにおいて、重大な中断を引き起こします。

個々のコンポーネントを超えて、「スキップナビゲーションリンク」の追加も検討してください。これは、フォーカス時にのみ表示される視覚的に隠されたリンクで、キーボードユーザーが繰り返しのナビゲーションを飛ばしてメインコンテンツにジャンプできるようにするものです。繰り返しのナビゲーションを飛ばせるスキップリンクは、ほとんどのサイトで欠落しています。 HTML数行と少量のCSSで実装でき、キーボードでコンテンツの多いページをナビゲートする人にとっては大きな違いを生みます。

<!-- <body>内の最初の要素として配置 -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- CSS -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

ARIAについての注意: 慎重に使う

多くのチームは、アクセシビリティのギャップを手早く埋める手段としてARIA（Accessible Rich Internet Applications）属性に飛びつきます。しかしデータは、これが役に立つどころか逆効果になることが多いと示しています。評価対象のホームページの約79%がARIAを使用しており、これは前年から増加しています。ARIAを使用しているホームページは、使用していないページの2倍以上のエラーを抱えていました。問題はARIAそのものではなく、たいていはARIAの誤用や不適切なARIAです。多くの善意の開発者は、ARIAを追加することでコンテンツをよりアクセシブルにしていると思っていますが、実際にはその逆になっていることがよくあります。

指針はシンプルです。まずセマンティックHTMLを使うこと。<div role='button'>よりも<button>の方が優れています。<div role='navigation'>よりも<nav>の方が優れています。ネイティブのHTML要素には、キーボード動作、フォーカス管理、暗黙のARIAロールが組み込まれており、カスタムマークアップではそれらを手作業で再現する必要があります — そして、その手作業の再現こそがエラーの温床になります。ARIAは、ライブリージョン、複雑な複合ウィジェット、動的な状態変化など、HTMLだけでは本当に表現できないセマンティクスが必要な場合に限って使用してください。

アクセシビリティをワークフローに組み込む

既存の違反を修正することは必要ですが、新たな違反が発生しないようにすることこそが、成熟したアクセシビリティプログラムと一度きりのコンプライアンス対応を分けるものです。アクセシビリティは一度直せば終わりというものではありません。コンテンツの更新、デザインの変更、コードのデプロイのたびに、新たな問題が持ち込まれる可能性があります。このガイドで取り上げた6つの失敗カテゴリは、テンプレートレベルの問題であることが多いです — ヘッダー、フッター、共有コンポーネントを修正すれば、数百ページにわたって問題を一気に解消できます。

自動スキャンをCI/CDパイプラインに統合し、本番環境に到達する前に違反を検出するようにしましょう。axe-coreのようなツールは、ユニットテストやE2Eテストスイートに組み込むことができます。これに、定期的な手動のキーボードウォークスルーやスクリーンリーダーテスト（macOSとiOSのVoiceOver、WindowsのNVDA）を組み合わせてください。なぜなら、自動テストは一般的なアクセシビリティエラーを検出できますが、手動テストはその隙間を埋めるのに役立つからです。より迅速な立ち上がりを必要とするチームにとっては、Accsibleのようなアクセシビリティオーバーレイウィジェットを使うことで、レンダリングレイヤーで多くの問題を表面化・是正しつつ、長期的なコードレベルの修正を計画・展開することができます。

最後に、コードベースの中で最もレバレッジの大きいポイント — テンプレートに取り組みましょう。ほとんどのウェブサイトはテンプレートを使用しています — すべてのページで繰り返し使われるヘッダー、フッター、ナビゲーション、ページレイアウトです。これらのテンプレートに問題があると、サイト全体に増殖します。最大の効果を得るには、まずテンプレートを修正してください。ベーステンプレートを1つ修正するだけで、1回のデプロイで10,000件のWCAG違反をゼロにできます。

重要なポイント

6種類の問題が大半を占めている。 コントラスト不足のテキスト、altテキストの欠如、ラベルのないフォーム入力、空のリンクとボタン、文書の言語指定の欠如、壊れたキーボードナビゲーションが、WCAG違反の圧倒的多数を占めています。これら6つのカテゴリを修正することで、投入労力に対して非常に大きな成果が得られます。
ほとんどの修正はCSSか1行のHTML変更で済む。 <html>タグにlang='en'を追加すること、outline: noneを:focus-visibleスタイルに置き換えること、ラベルを入力と関連付けることは、数カ月ではなく数時間の作業です — それでも、サイトを訪れるすべての障害のあるユーザーに影響する違反を取り除くことができます。
テンプレートは最もレバレッジの高い修正箇所。 共有コンポーネントやページテンプレートのアクセシビリティバグは、サイト全体に複製されます。まずヘッダー、フッター、ナビゲーション、フォームを監査しましょう — そこを直せば、どこもかしこも直ることになります。
ARIAは第一選択ではなく最後の手段。 強固なセマンティックHTMLの基盤なしにARIAに大きく依存しているサイトは、アクセシビリティエラーが少ないどころか、むしろ大幅に多い傾向があります。可能な限りネイティブHTML要素を優先してください。
自動スキャンが捉えられるのは実際の問題の半分未満。 ツールに加えて、手動のキーボードウォークスルーやスクリーンリーダーテストを行い、フォーカストラップ、論理的でないタブ順序、変更がアナウンスされない動的コンテンツなど、どのスキャナーも表面化できない失敗を見つけてください。

あらゆるウェブサイトで発生する最も一般的なWCAG違反6つの修正方法