ログイン

アクセシビリティ監査とは何か？あなたのウェブサイトがWCAGに準拠しているかを確認する方法

2 min read
監査Wcagコンプライアンス

ほとんどのウェブサイトは基本的なアクセシビリティ基準を満たしておらず、法的およびビジネス上のリスクは急速に高まっています。このガイドでは、WCAGアクセシビリティ監査とは何か、その実施方法、そして結果をどのように活用すればサイトがすべてのユーザーにとって使いやすくなるのかを、具体的に解説します。

最新の WebAIM Million レポートによると、100万件のホームページ全体で5,600万件の個別のアクセシビリティエラーが検出されており、1ページあたり平均56件のエラーがある計算になります。これは、圧倒的多数のウェブサイトが、障害のあるユーザーに対して毎日積極的に不利益を与えていることを意味します。自分のサイトが WCAG に準拠しているかどうかを知りたいウェブサイトのオーナー、開発者、コンプライアンス担当者であれば、その答えはほぼ確実に、適切なアクセシビリティ監査を実施することに関わってきます。問題は、それが実際には何を意味し、どのように正しく行うのかという点です。

アクセシビリティ監査が「やらない」という選択肢のないものになった理由

ウェブアクセシビリティは、もはや善意の領域をはるかに超えています。現在では、拡大し続ける多くの法域で法的要件となっており、不遵守の結果は具体的かつ測定可能です。2024年には、4,000件以上のウェブアクセシビリティ訴訟がアメリカで提起されており、この傾向は上昇し続けています。アメリカの裁判所は一貫して、一般に公開されている事業者のウェブサイトは ADA Title III の下でアクセシブルでなければならないと判断してきました。一方で、European Accessibility Act は2025年6月にすべてのEU加盟国で施行され、要件は政府サイトを超えて、銀行アプリ、eコマースプラットフォーム、SaaS製品などにも拡大されました。

数字は厳しい現実を示しています。世界人口の約16% — およそ13億人 — が何らかの障害を抱えて生活しています。アメリカだけでも、成人の約4人に1人が障害を持っています。彼らは「レアケース」のユーザーではありません。顧客であり、従業員であり、学生であり、市民であり、多くの開発者が考えたこともないような障壁に、ウェブサイト上で日々直面しています。

法的リスクを超えて、ビジネス面でも測定可能なメリットがあります。アクセシブルなウェブサイトは検索エンジンでより良いパフォーマンスを発揮します。スクリーンリーダーを助ける構造的な明確さ — セマンティックな見出し、説明的な代替テキスト、クリーンなマークアップ — は、クローラーにとっても有益だからです。インクルーシブデザインは一貫して、すべての人にとってのユーザビリティを向上させます。字幕は騒がしい環境にいる人に役立ち、高コントラストは明るい日光の下にいる人に役立ち、キーボードナビゲーションはパワーユーザーにとって有益です。アクセシビリティ監査は、これらすべてのメリットを得るための第一歩です。

もう1つ重要な変化があります。ADA Title II は現在、アメリカの州および地方自治体に対してウェブアクセシビリティを明示的に要求しており、DOJ は技術標準として WCAG 2.1 レベルAAを採用しています。人口5万人以上にサービスを提供する組織には、2026年4月26日というコンプライアンス期限が設けられています。公共部門のクライアントと仕事をしている、あるいは規制産業で事業を行っているのであれば、監査はもはや任意ではなく、喫緊の課題です。

WCAG アクセシビリティ監査とは具体的に何か？

ウェブアクセシビリティ監査とは、W3C が策定したデジタルアクセシビリティの国際的に認められた技術標準である Web Content Accessibility Guidelines（WCAG）への、あなたのウェブサイトの準拠状況を体系的に評価することです。実務的には、監査は、障害のあるユーザーがあなたのコンテンツを知覚し、理解し、ナビゲートし、操作することを妨げている具体的な障壁を特定します。それらの障壁を WCAG の達成基準にマッピングし、重大度レベルを割り当て、是正のためのロードマップを作成します。

WCAG は現在バージョン2.2であり、2023年末に公開され、2025年5月に W3C によってウェブアクセシビリティの最高水準として正式に再確認されました。WCAG 2.1 に比べて9つの新しい達成基準が追加されており、キーボードフォーカスの可視性、最小タッチターゲットサイズ、ドラッグ操作の代替手段、一貫したヘルプメカニズムなどの領域をカバーしています。重要なのは、WCAG 2.2 は後方互換であるという点です。2.2を満たせば、2.1と2.0も同時に満たすことになります。

WCAG は3つの適合レベルで構成されています。レベルAは最も重大な障壁をカバーしており、このレベルでの不適合は、一部のユーザーにとってコンテンツを完全に利用不能にします。レベルAAは、ADA、European Accessibility Act、Section 508 を含む世界中のほとんどのアクセシビリティ関連法で義務付けられている目標レベルです。レベルAAAは最も高いハードルを表し、通常は法的要件というよりも理想的な目標として位置づけられます。誰かが自分のサイトは「WCAG 準拠だ」と言うとき、それはほぼ必ず WCAG 2.1 または 2.2 のレベルAAを意味します。

WCAG は4つの中核原則に基づいて構築されており、頭字語 POUR で覚えられることが多いものです。コンテンツは、Perceivable（知覚可能）（ユーザーが感知できる）、Operable（操作可能）（ユーザーが操作できる）、Understandable（理解可能）（ユーザーが理解できる）、Robust（堅牢）（支援技術と確実に連携して動作する）でなければなりません。すべての達成基準はこれら4つの原則のいずれかに紐づいており、徹底した監査ではそれぞれに対する適合状況を確認します。

監査で最もよく見つかる不適合

検出されるアクセシビリティエラーの約96%は、わずか6つのカテゴリに集中しています。何を探すべきかを知ることが、監査の労力に優先順位を付ける最速の方法です。

  • コントラストの低いテキスト。これは一貫して最も一般的な不適合です。ホームページの約84%において、通常のテキストが WCAG 2 AA のコントラスト閾値である 4.5:1 を下回っています。監査担当者は、TPGi Colour Contrast Analyser のようなツールを使って前景色と背景色のコントラスト比を確認します。
  • 代替テキストの欠如。ホームページ上の画像の16%以上に alt 属性がまったく設定されておらず、スクリーンリーダーユーザーは画像の内容を理解する手段を持てません。リンク付き画像に alt テキストがない場合は特に深刻で、意味のないナビゲーションターゲットになってしまいます。
  • 空のリンク。可視テキストもアクセシブルネームも含まないリンクは、キーボードユーザーやスクリーンリーダーユーザーにとって行き止まりを生み出し、そのリンクがどこへ行くのか判断できなくなります。
  • フォーム入力ラベルの欠如。プログラム的に関連付けられたラベルのないフォームは、スクリーンリーダーユーザーにとって利用不能です。これは、可視ラベルだけでなく、aria-label や aria-labelledby を用いた非表示ラベルも含みます。
  • 空のボタン。アクセシブルネームのないアイコンのみのボタン — ナビゲーションやスライダーでよく見られます — は、非視覚ユーザーがそのボタンの機能を特定できない状態にします。
  • 文書の言語指定の欠如。<html> 要素の lang 属性は、スクリーンリーダーにどの言語を使用すべきかを伝えます。これがないと、テキスト読み上げに依存するユーザーにとって、誤った発音や混乱を引き起こします。
監査では一貫して、最も深刻な不適合が、同時に最も修正しやすいものであることが明らかになります。低コントラスト、代替テキストの欠如、ラベルのないフォームフィールドは、多くの場合、数か月ではなく数日で是正できます。

これら6つに加えて、徹底した監査では、スキップナビゲーションリンクの欠如（キーボードユーザーに、すべてのページであらゆるヘッダー要素をタブで通過することを強いる）、不適切な見出し階層、フォーカスを誤って閉じ込めてしまうアクセシブルでないモーダルやダイアログ、字幕のない動画、タグ付き構造のないPDF、ARIAを通じてアクセシブルなロールや状態を公開していないカスタム JavaScript ウィジェットなども検出します。

アクセシビリティ監査の進め方：ステップバイステップ

適切なアクセシビリティ監査は、単一のスキャンではありません。自動化ツールと専門家の人間による判断を組み合わせた多段階のプロセスです。体系的に取り組む方法は次のとおりです。

ステップ1：スコープを定義する

テストを1つでも実行する前に、何を監査するのかを決めます。大規模なサイトでは、すべてのページをテストするのは現実的ではありません。その代わりに、W3C が策定した WCAG-EM（Website Accessibility Conformance Evaluation Methodology）のアプローチを適用します。すべてのユニークなページテンプレート、重要なユーザージャーニー、異なるコンテンツタイプを網羅する代表サンプルを定義します。eコマースサイトのサンプルには、ホームページ、カテゴリページ、商品詳細ページ、カート、チェックアウトフロー、アカウントログイン、お問い合わせフォーム、ブログ記事などが含まれるかもしれません。動的な状態も必ず含めてください。開いたメニュー、フォームエラーメッセージ、モーダルダイアログ、読み込まれた検索結果などもすべて評価が必要です。

ステップ2：自動スキャンを実行する

自動化ツールは、効率的な監査の基盤です。HTML を素早くスキャンし、明確なルール違反をフラグし、問題のベースラインリストを提供します。主なツールには次のようなものがあります。

  • axe DevTools（ブラウザ拡張機能または CLI） — 広く利用されており、誤検出率が低く、CI/CD パイプラインと統合可能
  • WAVE（WebAIM） — ページ上にエラーアイコンを視覚的に注釈として表示し、非技術メンバーにも直感的
  • Lighthouse（Chrome DevTools に内蔵） — パフォーマンスやSEO指標と並んでアクセシビリティスコアを提供
  • Colour Contrast Analyser（TPGi） — 画面上の任意の色を取得し、WCAG の閾値に照らしてチェック
  • PAC 2024 — ダウンロード用ドキュメント向けの専用 PDF アクセシビリティチェッカー

重要な制約として、自動化ツールが検出できるのは WCAG の問題の30〜40%に過ぎません。これらは、欠落した属性、不正な ARIA ロール、コントラスト比など、ルールベースの不適合をフラグすることに優れています。しかし、alt テキストが意味のあるものかどうか、フォームが論理的に構造化されているかどうか、ユーザーが実際にタスクを完了できるかどうかを判断することはできません。これが、自動化がステップ2であり、監査のすべてではない理由です。

ステップ3：専門家による手動テスト

知識のある人間 — 理想的にはチーム — による手動テストこそが、監査の深さを決定する部分です。これには次のようなものが含まれます。

  • キーボードのみのナビゲーション。マウスを外し、Tab、Shift+Tab、Enter、Space、矢印キーだけを使って、すべての主要なユーザージャーニーを完了できるか試します。すべてのインタラクティブ要素に到達できますか？フォーカスインジケーターは常に見えますか？フォーカスがコンポーネントの中で消えてしまうことはありませんか？
  • スクリーンリーダーテスト。Windows では Chrome または Firefox と組み合わせた NVDA を、macOS と iOS では Safari と組み合わせた VoiceOver を使用します。見出し、ランドマーク、リンク、フォーム単位でナビゲートします。視覚的な文脈がなくてもページは理解できますか？すべてのインタラクティブ要素は正しくアナウンスされますか？
  • 視覚的および認知的レビュー。見出し階層が論理的な構造になっているか確認し、エラーメッセージが記述的で正しいフィールドに関連付けられているか検証し、時間ベースのメディアに字幕とトランスクリプトがあるか確認し、指示が色や形、位置だけに依存していないかをレビューします。
  • コードの検査。HTML セマンティクス、ARIA の使用、カスタムウィジェットにおけるフォーカス管理、ランドマーク領域を確認します。フォーカスをトラップしないモーダルや、キー入力のたびに発火する ARIA ライブリージョンなどは、このレベルでしか検出できません。

ステップ4：実際のユーザーによる支援技術テスト

ゴールドスタンダードであり、しばしば最も示唆に富む段階が、日常的に支援技術に依存している実際のユーザーによるテストです。スクリーンリーダー、スイッチアクセスデバイス、音声コントロールソフトウェアを使用する人々は、専門家による手動テストでも完全には再現できない方法でナビゲートします。評価に障害のあるユーザーを含めることで、ツールやチェックリストでは予測できない現実世界の摩擦が明らかになります。

ステップ5：結果の文書化と優先順位付け

不適合の生のリストは監査レポートではなく、出発点に過ぎません。有用な監査ドキュメントは、影響を受けるURLまたはコンポーネント、違反している WCAG 達成基準、重大度（クリティカル、高、中、低）、影響を受けるユーザーへの影響、そして可能であればコード例を含む具体的な是正ガイダンスを明示すべきです。優先順位は、技術的な都合ではなく、まずユーザーへの影響に基づいて付ける必要があります。チェックアウトを妨げる壊れたフォームラベルは、ブログのサイドバーにおける最適でない見出しレベルよりも緊急度が高いのです。

ステップ6：是正、検証、モニタリング

修正を実装したら、それを検証します — 是正がうまくいったと仮定してはいけません。元の監査で使用したのと同じツールと手動チェックの組み合わせで、各修正を再テストします。基礎的な適合レベルを達成したら、継続的なモニタリングを導入します。新しいコンテンツ、CMS のアップデート、サードパーティスクリプトは、いつでもリグレッションを引き起こす可能性があります。アクセシビリティはセキュリティと同じように、「維持するもの」であって、「一度達成して終わり」のものではありません。

自動スキャンとフル監査：違いを理解する

この区別は、特に法的な文脈では非常に重要です。自動スキャンは、レンダリングされた HTML に対してルールベースのチェックを実行します。数秒から数分で完了し、検出された違反のリストを返します。これは、明白で大量に発生する問題を検出するのに優れており、新たなリグレッションがリリースされるのを防ぐために CI/CD ワークフローに統合するのにも適しています。多くのオーバーレイやウィジェット製品 — アクセシビリティツールを含む — は、機能セットの一部として自動スキャンダッシュボードを提供しており、継続的なモニタリングには実際に有用です。

対照的に、フル監査は、自動スキャン、専門家による手動レビュー、スクリーンリーダーテスト、キーボードのみのナビゲーションを組み合わせて、適用可能なすべての WCAG 達成基準に対するサイトの状況を評価します。自動と手動の方法を組み合わせた包括的な監査は、自動化だけでは30〜40%にとどまるのに対し、アクセシビリティの問題の90%以上を明らかにすることができます。法的な警告書、調達要件、規制当局からの照会に直面した場合、必要な文書を提供できるのはフル監査だけです。

多くの組織は、実務的なハイブリッド戦略を採用しています。自動スキャンを CI/CD で継続的に実行してリグレッションを早期に検出しつつ、大規模なサイトリニューアル後や年に一度、フルの手動監査を実施するというものです。これにより、徹底性と効率性のバランスを取りつつ、長期的にコンプライアンスを管理しやすくなります。

ツールだけで、サイトがアクセシビリティ標準を満たしているかどうかを判断することはできません。サイトが真にアクセシブルであるかどうかを判断するには、知識のある人間による評価が必要です。 — W3C Web Accessibility Initiative

監査結果をどう活かすか：是正計画

完了した監査は、それが行動につながる場合にのみ価値があります。是正作業の優先順位付けは、問題を特定することと同じくらい重要です。実務的な是正の優先順位付けフレームワークは次のようになります。

  1. クリティカル（即時対応）：ユーザーが主要なタスクを完了することを完全に妨げる問題 — 壊れたチェックアウトフォーム、アクセシブルでないログインモーダル、キーボードで到達できないナビゲーションメニューなど。これらは最も高い法的リスクと最大のユーザー影響を伴います。
  2. 高（現在のスプリントまたはリリースサイクル内に修正）：障害のあるユーザーのユーザビリティを大きく損なうが、完全には妨げない問題 — 商品画像の alt テキストの欠如、本文テキストの低コントラスト、インターフェース全体にわたるラベルのないアイコンボタンなど。
  3. 中（計画的な是正）：摩擦を生むが回避策が存在する問題 — 一貫性のないフォーカスインジケーター、スキップリンクの欠如、最適でない見出し階層など。
  4. 低（担当者を定めたバックログ）：多くの場合ユーザビリティに影響しないが、ベストプラクティスとして改善が望ましい問題 — AAA レベルの改善、軽微な ARIA の冗長性改善など。

すべての修正が完了する前であっても、是正計画とタイムラインを文書化しておきましょう。規制当局や裁判所は、何もしていない状態と比べて、継続的で誠実な改善の取り組みが示されている場合を概して好意的に評価します。警告書を受け取った場合でも、監査レポートと是正スケジュールを手元に持っていることは、何の文書もない状態よりはるかに強い立場になります。

Accsible が提供するようなオーバーレイウィジェットや SDK ツールは、是正フェーズで意味のある役割を果たすことができます。特にコントラスト、フォントサイズ、行間などの視覚的な好みに関する一般的な問題のかなりの部分について、即時の修正を提供しつつ、開発チームがより深いコードレベルの是正に取り組むことを可能にします。重要なのは、オーバーレイが得意とする領域を理解し、重大な障壁に対するコードレベルの修正の代替ではなく、多層的な戦略の一部として活用することです。

アクセシビリティ監査はどのくらいの頻度で行うべきか？

一度きりの監査は、特定の日におけるサイトのスナップショットに過ぎません。ウェブサイトは生きたプロダクトであり、コンテンツは変化し、サードパーティスクリプトは更新され、コンポーネントは置き換えられ、新機能がリリースされます。これらのイベントのそれぞれが、新たなアクセシビリティ障壁を生み出す可能性があります。持続可能なアクセシビリティプログラムは、一般的に次のような形になります。

  • 継続的な自動スキャンを CI/CD パイプラインやモニタリングダッシュボードに統合し、本番環境に到達する前にリグレッションを検出
  • 四半期ごとの手動スポットチェックを、トラフィックとリスクの高いページ（チェックアウト、ログイン、お問い合わせフォーム、主要なランディングページ）で実施
  • 年次のフル監査を、特に大規模なリデザインやプラットフォーム移行後に、資格を持つアクセシビリティ専門家によって実施
  • 設計段階での監査を、主要な新機能やリデザインごとに行う — アクセシビリティは、後付けで修正するよりも、最初から組み込む方が圧倒的に安価です。

最も費用対効果の高いアプローチは、アクセシビリティを左側にシフトすること — つまり、ローンチ後のコンプライアンス対応としてではなく、最初から設計と開発プロセスに統合することです。WCAG の要件を理解している開発者は、問題を発生源で検出します。コントラストやタッチターゲットサイズについて知っているデザイナーは、デフォルトでアクセシブルな選択を行います。監査は、緊急対応ではなく、品質ゲートとして機能するようになります。

重要なポイント

  • ほとんどのウェブサイトは WCAG に不適合。ホームページの95%以上に検出可能なアクセシビリティエラーがあり、最も一般的な6つの不適合 — 低コントラスト、代替テキストの欠如、空のリンク、フォームラベルの欠如、空のボタン、文書言語の欠如 — が大部分を占めています。これらはすべて修正可能です。
  • 自動ツールは必要だが、それだけでは不十分。自動スキャナーが検出できる WCAG の問題は、良くても30〜40%です。完全な監査には、キーボードテスト、スクリーンリーダーテスト、コードとUXフローに対する専門家による人間のレビューが必要です。
  • WCAG 2.2 レベルAAが目標。これは ADA、European Accessibility Act、Section 508、および世界中のほとんどのアクセシビリティフレームワークで参照されている標準です。2.2 AA を目指せば、下位バージョンは自動的にカバーされます。
  • 是正には優先順位付けのフレームワークが必要。まずは主要なユーザージャーニーを完全に妨げる問題から着手し、その後、高インパクトかつ高頻度の問題に取り組みます。すべてを文書化してください — 監査レポートと是正計画は、法的な観点から最大の防御手段になります。
  • アクセシビリティは継続的な取り組みであり、一度きりではない。継続的な自動モニタリングと定期的な手動監査を組み合わせ、アクセシビリティを最初から設計と開発プロセスに組み込みましょう。Accsible のようなオーバーレイウィジェットは、より深い是正作業が進行している間のギャップを埋める役割を果たせます。