2026.07.31 Webサイト

Webアクセシビリティ診断の進め方：自動・手動・当事者検証の三層設計と外注の判断基準

axe DevToolsでエラーが0件になっても、アクセシビリティの問題が0件になったわけではありません。Deque社が初回監査データを集計した報告では、自動テストで検出できたのは全体の57.38%です。この記事では、Webアクセシビリティ診断を自動チェック・手動検証・当事者検証の三層で設計する方法、JIS X 8341-3:2016の試験として実施する場合の対象ページの選び方と試験結果表示の書式、内製と外注の分岐を、WAICのガイドラインと公開事例から整理します。

まとめ：自動チェック57%の内訳と、手動・当事者検証まで含めた診断設計の結論

Webアクセシビリティ診断は3つの層で構成します。第1層は自動チェック。axe-coreを積んだツール（axe DevTools、Lighthouseのアクセシビリティ監査）を全ページに走らせ、コントラスト比・代替テキストの欠落・ARIA属性の誤りといった機械判定できる不具合を洗い出す層です。第2層は手動検証で、キーボードだけでの操作、miCheckerによるロービジョン模擬と音声読み上げの可視化、スクリーンリーダーでの読み上げ確認を行います。第3層が当事者検証。支援技術を日常的に使う人に、実際のタスクを実行してもらう段階です。

層を分ける理由は、それぞれが見つける不具合の種類が重ならないためです。自動チェックはalt属性の有無を判定しますが、代替テキストが画像の内容を説明できているかは判定できません。57.38%という数字も、達成基準の網羅率ではなく検出された問題の件数に占める割合です。「自動で6割終わった」と読むと、残りの工数を見誤ります。

JIS X 8341-3:2016への適合を対外的に表明するなら、附属書JBの試験方法に沿って対象ページを選びます。100ページ超のサイトなら代表ページとランダムページを併せて40ページ前後が相場。試験結果には表明日・依存したウェブコンテンツ技術・達成基準チェックリストなど11項目を並べます。ここまでやるなら外注、改善調査に留めるなら内製という分岐が素直です。

Webアクセシビリティ診断が判定する対象とJIS X 8341-3:2016との関係

「診断」は目的の異なる2つの作業を指す言葉です。どちらを頼んだのかが発注側と受注側でずれると、成果物が期待と食い違います。

適合試験としての診断と改善調査としての診断で変わる成果物の粒度

適合試験は、JIS X 8341-3:2016の達成基準を1つずつ満たしているかを判定し、結果を対外的に表明するための作業です。成果物は達成基準チェックリストと試験結果表示のページで、判定は基準ごとに「適合／不適合」の二値。不具合の直し方は含まれません。

改善調査は、どこにどんな不具合があり、どの順で直すかを出す作業です。成果物は不具合一覧と改修方針で、影響範囲と工数の見立てが付きます。多くの企業が最初に必要とするのはこちら。適合表明まで踏み込むべきかは法的な位置づけで決まるため、Webアクセシビリティは義務化されたのかで条文単位に整理した内容を先に確認してください。合理的配慮の提供が義務、ウェブアクセシビリティの確保は努力義務という線引きが判断の起点になります。

JIS X 8341-3:2016が参照するWCAG 2.0と最新版2.2との差分

JIS X 8341-3:2016は、ISO/IEC 40500:2012（＝WCAG 2.0）と一致した規格です。つまり国内でJIS準拠と表記した場合、技術的にはWCAG 2.0の達成基準を満たしたことになります。

一方、W3CのWCAGは2018年の2.1を経て、2.2が2023年10月5日に勧告となり、2024年12月12日に更新版が公開されました。2.2では9つの達成基準が追加され、そのうちレベルAAには「2.5.8 ターゲットのサイズ（最小）」（原則24×24 CSSピクセル）、「2.5.7 ドラッグ動作」、「3.3.8 アクセシブルな認証（最小）」が含まれます。逆に「4.1.1 構文解析」は廃止されました。

診断の実務では、この差分の扱いを最初に決めます。JIS試験としての合否は2.0相当で判定し、2.1・2.2の追加基準は推奨事項として別枠で報告する構成が扱いやすい形です。

準拠・一部準拠・配慮の表記が診断の対象範囲と工数を決める仕組み

WAICの「ウェブコンテンツのJIS X 8341-3:2016 対応度表記ガイドライン」（2016年3月版、2021年4月13日版が最新）は、対外表記を3種類に整理しています。表記を先に決めれば、診断の範囲も決まります。

表記 試験 条件 併記が必要なもの
準拠 必須 対象レベルの達成基準を全て満たす 方針と試験結果
一部準拠 必須 満たさない基準が残る 方針と改善計画
配慮 任意 規格を参照して制作 方針と対象基準

「準拠」は全達成基準の合格が条件のため、1つでも不適合が残れば表記は「一部準拠」に落ちます。実務では最初から一部準拠を前提に、改善計画とセットで公開する進め方が現実的。試験を伴わない「配慮」なら改善調査だけで足ります。

自動チェックツールで検出できる範囲と57%という数値の読み違え

自動チェックは診断の入口であって出口ではありません。ツールごとの守備範囲と、公表されている検出率の意味を押さえます。

axe DevToolsとLighthouseで検出結果が食い違う理由

LighthouseのアクセシビリティカテゴリはDequeのaxe-coreを内部で使っています。同じエンジンなのに結果が食い違うのは、Lighthouseが適用するルールがaxe-coreの一部に絞られているため。Lighthouseのスコアが100点でも、axe DevToolsで走らせると追加の不適合が出ます。

スコアは進捗管理の目安であって、合否判定の根拠にはなりません。全ページを定期的に走らせて回帰を検知するなら、CIに組み込むか監視型の製品を入れます。製品の選択肢はaxe Monitorの主な特徴と機能一覧で価格体系まで整理しています。

57.38%が示すのは達成基準の網羅率ではなく検出件数の割合

Dequeが公開している「The Automated Accessibility Coverage Report」は、同社の初回監査顧客のデータを集計したもので、平均57.38%の問題が自動テストで検出されたと報告しています。ここで数えているのは問題の「件数」です。

件数ベースの割合が高くなるのは、機械判定しやすい不具合が大量に発生しやすいからです。コントラスト比不足のリンクが全ページのフッタにあれば、それだけで数百件。一方、フォームのエラー通知が読み上げられない不具合は1件でも、申し込みが完了できない致命傷です。診断報告書は件数ではなく「どのタスクが完遂できないか」で重み付けを付け直して読んでください。

自動判定が原理的に届かない代替テキストの妥当性と操作順序の検証

axe-coreは判定に確信が持てない要素を「incomplete（要手動確認）」として返します。この扱いになる領域は、おおむね次の4類型です。

  • 代替テキストの妥当性：alt属性の有無は判定できても、内容が画像を説明しているかは判定できない
  • 操作順序と読み上げ順：DOM順とビジュアル順がずれていても機械的な不適合にはならない
  • 動画の字幕・音声解説：トラックの存在は分かるが、内容が同期し正確かは分からない
  • エラー通知の具体性：エラーが提示されたことは検出できても、修正方法が伝わるかは判定できない

4類型はいずれもユーザーが目的を達成できるかに直結します。自動チェックが0件になった段階は完了ではなく、手動検証の起点。ここを社内で共有しておくと工数見積もりのずれが減ります。

手動検証で押さえる確認項目とmiChecker・支援技術の実行環境

手動検証は道具立てを決めれば再現性が出ます。国内案件の起点は、総務省が無償配布するmiCheckerです。

miChecker Ver.3.20のロービジョン模擬と音声読み上げの可視化

miCheckerは総務省が開発・提供するアクセシビリティ評価ツールで、配布ページの最新版はVer.3.20（ファイル名 miChecker_v3.2.zip、約76MB）。ページには「令和6年3月29日時点の技術対応」と記載があります。動作要件はWindows 10または11、Microsoft Edge、Java 64bit版 Version 17、メモリ4GB以上、空き容量250MB以上です。

特徴は2つ。ロービジョンシミュレーションで白内障や視野狭窄を想定した見え方を再現できること、音声ユーザビリティの可視化で読み上げ順と到達時間を画面上に重ねて表示できることです。スクリーンリーダーを操作できない担当者でも読み上げ順のねじれを目で確認できるため、社内説明の材料になります。

miChecker 3.1.0以前に残るXXE脆弱性と診断端末の隔離条件

導入前に確認すべき点があります。総務省の「脆弱性の報告」ページによれば、miChecker 3.1.0以前の全バージョンにXML外部実体参照（XXE）の脆弱性があり、JVN#40688603、CVE-2026-14304、CWE-611として公表されています。CVSS 4.0の基本値は4.6です。

影響は、細工された字幕を読み込むことでアプリケーションから意図しない通信が発生し、外部の第三者にローカルリソースや内部ネットワークリソースへアクセスされる可能性、と説明されています。対処は旧バージョンをアンインストールしたうえで3.1.1以降を入れること、または字幕機能の使用を止めること。社内標準端末に古い版が残る組織は、診断の前に版数の確認から入ってください。

キーボード操作とスクリーンリーダーで確認する項目の切り分け方

手動検証の中心はキーボード操作です。Tabキーだけで端から端まで移動し、フォーカスが常に見えているか、視覚的な並びと移動順が一致しているか、モーダルやカルーセルでフォーカスが閉じ込められないかを見ます。ここで出る不具合は自動チェックにほとんど現れません。

スクリーンリーダーによる読み上げ確認は、国内ならNVDAとPC-Talker、macOS・iOSならVoiceOverが基本形です。全ページの読み上げは現実的ではないため、問い合わせフォーム、グローバルナビゲーション、検索結果、エラーメッセージの4か所に絞ります。ここが通れば主要タスクは支援技術で完遂できる見込み。当事者検証はこの2工程を終えてから実施してください。

JIS試験として診断する場合の対象ページ選択と試験結果の表示項目

対外的に適合を表明するなら、診断は「試験」の形式に沿わせます。手順を定めるのはWAICの「JIS X 8341-3:2016 試験実施ガイドライン」（2020年12月版）です。

附属書JBが示す4つの選択方式と100ページ超サイトの併用型

附属書JBが示す選び方は4通り。a）全てのウェブページを選択する、b）ランダムに選択する、c）ウェブページ一式を代表するページを選択する、d）代表ページとランダムページを併せて選択する、の4方式です。

a）が成立するのは総ページ数が100ページ程度までのサイトです。それを超えると試験工数が跳ね上がるため、ガイドラインは100ページ超の場合にd）を推奨しています。ランダム選択の件数にも目安があり、10ページ以下は試行的な試験、11〜24ページは合否判定に要する最低限、25〜39ページが標準的、40ページ以上で合否判定に十分、という段階です。

代表15ページ＋ランダム25ページで40ページを構成する実例

実際の公開事例は40ページ前後に収束します。法テラスが2024年5月に公開した試験結果表示では、ウェブページ一式を代表するページとして15ページ、ランダムサンプリングで25ページ、合計40ページが対象。依存したウェブコンテンツ技術としてXHTML 1.0、HTML 5、CSS 2.1および3、JavaScriptを挙げ、レベルAAを満たしていると表明しています。

代表ページに何を選ぶかは合否を左右します。トップページ、サイトマップ、問い合わせフォーム、検索結果、PDFを含むページ、動画を含むページ、ログイン後の画面など、テンプレートと機能の種類が異なるものを網羅してください。同じテンプレートのページを15本並べても、試験としての意味は薄くなります。

試験結果の表示に並べる11項目と依存したウェブ技術リストの書き方

試験結果として公開するページには、決まった項目が並びます。法テラスの例に載るのは、表明日、規格の規格番号及び改正年、満たしている適合レベル、対象となるウェブページ、依存したウェブコンテンツ技術のリスト、試験対象ページを選択した方法、試験を行ったウェブページのURI、達成基準チェックリスト、試験実施期間、表示レベルより上で満たしている達成基準のリスト、参考リンクの11項目です。

見落とされやすいのが依存技術のリストです。JavaScriptを無効にすると主要機能が動かないサイトは、JavaScriptを依存技術として明記しなければなりません。書かずに準拠と表明すると、後から指摘を受ける余地を残します。規格そのものの構成と達成基準の考え方は、JIS X 8341-3およびWCAGガイドラインに基づく対応で解説しています。

診断を内製で回すか外注に出すかの分岐条件と費用の見積もり単位

どこまでを社内でやるかは、公開表明の有無で切り分けると迷いません。

内製で成立する体制の条件と、社内リソースだけでは破綻する条件

内製で回せるのは、次の条件が揃う場合です。目的が改善調査、対象が20ページ以下、HTMLとARIA属性を読める担当者が社内にいる、結果を対外的に表明しない。この範囲なら、axe DevToolsとmiCheckerとキーボード操作の3点で相当な精度が出ます。

破綻するのは、適合レベルを公開表明する段階に進んだときです。達成基準チェックリストは1ページあたり50前後の判定項目を人が埋めるため、40ページなら2,000判定。解釈を揃えた検証者がいないと判定がぶれ、後で試験のやり直しを招きます。当事者検証の協力者を自社で手配できない点も、内製の限界になりやすい箇所です。

外注の見積もりを比べるときのページ単価・達成レベル・再試験費

診断サービスの見積もりは、前提条件が各社で異なるため、総額だけでは比較できません。揃えるべき変数は4つです。

  1. 対象ページ数と、その選定を誰が行うか
  2. 目標とする適合レベル（AかAAか）
  3. 成果物の形式（合否判定のみか、改修方法まで含むか）
  4. 改修後の再試験が含まれるか、別費用か

公開されているサービスでは、JIS X 8341-3:2016のレベルAAで初回検査10ページを前提としたコース設定が見られます。10ページの見積もりを40ページへ単純に4倍すると実態から外れる点に注意してください。代表ページの選定と依存技術の整理は初回に集中するため、ページ数が増えるほど1ページあたりの単価は下がります。診断から改修、試験結果の公開までを一括で任せる進め方は、Webアクセシビリティ対応のページにまとめています。診断だけでなく改修と運用まで含めた総額の見通しを立てるなら、Webアクセシビリティ対応の費用で三層に分けた見積の読み方を確認してください。

診断結果を改修計画に落とすときの優先順位と影響範囲の見立て方

改修はテンプレート起因の不具合から手を付けます。グローバルナビゲーション、フッタ、フォーム部品、見出し構造は全ページに複製されているため、1か所直すと検出件数が一気に落ちます。コントラスト比なら通常のテキストで4.5:1、大きな文字とUI部品で3:1が判定ライン。ブランドカラーの見直しに発展することもあるため、判断者を早めに巻き込みます。

次に着手するのは、タスクの完遂を妨げる不具合です。件数が1件でも、申し込みや問い合わせが完了できない箇所は最優先。個別ページの代替テキスト修正はその後で構いません。

改修の順序を件数順にしないこと。これが診断結果を無駄にしない一番の分かれ目です。

診断を見送ってよい場面と、オーバーレイに代替させた場合の失敗

診断はいつでもやるべき作業ではありません。費用が無駄になる場面と、道具の選択を誤る場面をはっきりさせます。

リニューアルを控えるサイトで本試験を見送ってよい条件と代替策

6か月以内にサイトリニューアルが決まっているなら、JIS試験としての本試験は実施しません。試験結果は対象ページ一式とその時点のHTMLに紐づくため、テンプレートが入れ替われば表明の根拠が失われます。40ページ規模の試験に投じた費用が、公開から半年で使えなくなります。

代わりに実施するのは、現行サイトの改善調査とリニューアル要件への落とし込みです。WAICは「JIS X 8341-3:2016 対応発注ガイドライン」と事例を公開しており、達成基準を発注仕様へ書き下ろす下敷きになります。選定段階でレベルAAを要件に入れておけば、公開後の手戻りが減ります。本試験は新サイトの公開後に一度だけ、という順序が合理的です。

オーバーレイ製品に診断と改修を代替させたときに残る不適合項目

タグを1行入れるだけで対応が完了すると訴求するアクセシビリティオーバーレイは、診断の代替になりません。導入しても、JIS試験の合格根拠にはできません。

理由は3つ。JavaScriptでDOMを書き換える方式は、元のマークアップの不備をそのまま残します。読み上げ順や見出し構造の誤りは、後付けの属性付与では解消しません。加えて、利用者が既に使っているスクリーンリーダーの設定とオーバーレイ側のキーボードショートカットが衝突し、かえって操作を妨げる報告もあります。海外ではオーバーレイを導入したサイトが訴訟対象になった事例も報告済みです。問題点と代替となる進め方は、ウェブアクセシビリティとはで章立てて整理しています。

導入してよいのは、改修の予算と時期が確定していて、それまでの暫定措置として文字サイズ変更やコントラスト切替を提供する場合だけ。恒久策として位置づけた時点で、診断の意味がなくなります。

年1回の定点観測へ切り替えてよい運用段階と自動監視の組み込み方

診断の頻度も段階で変わります。年1回の定点観測に落としてよいのは3条件が揃った段階です。レベルAAの一部準拠を公開済みであること。テンプレート起因の不適合を改修し終えていること。CIまたは定期クロールにaxe-coreベースの自動チェックを組み込み、回帰を日次か週次で検知できていること。

3条件目が欠けた状態で年1回に落とすと、1年分の変更が未検証のまま積み上がります。コンテンツを毎週追加するサイトなら、記事テンプレートへの自動チェックだけでも回しておくべきです。当事者検証は年1回で足りますが、フォームや決済フローの改修直後だけは規模を問わず再実施してください。

よくある質問

診断の実施を検討する段階でよく寄せられる質問を、費用・範囲・頻度の順にまとめます。

Webアクセシビリティ診断は無料のツールだけで完結しますか？

改善調査の目的であれば、無料のツールでかなりの範囲をカバーできます。axe DevToolsの無償版、Lighthouse、miChecker Ver.3.20、NVDAはいずれも無償。ただしJIS X 8341-3:2016の適合を対外表明するなら、達成基準チェックリストの判定と試験結果表示の作成は人手の作業になり、別の工数が発生します。無償ツールだけで「準拠」の根拠は作れません。

診断は何ページを対象にすれば足りますか？

WAICの試験実施ガイドラインは、ランダム選択の目安として40ページ以上を「合否判定に十分」としています。100ページ超のサイトでは代表15ページ＋ランダム25ページで合計40ページという構成が主流です。改善調査だけなら、テンプレートの種類ごとに1ページずつ、10〜20ページ程度でも判断材料は揃います。

診断の費用はどのくらいを見込めばよいですか？

公開されているサービスは、レベルAAで初回検査10ページを前提としたコース設定が一般的で、適合レベルとページ数で価格が動きます。比較の際は、対象ページ数・目標レベル・成果物の形式・再試験の有無という4つの前提を揃えてください。総額だけを並べると、合否判定のみの見積もりと改修方法まで含む見積もりを取り違えます。

診断はどのくらいの頻度で実施すべきですか？

テンプレート起因の不適合を改修し終え、CIに自動チェックを組み込めている段階なら、本試験は年1回で足ります。それ以前は改修のたびに範囲を絞った再検証が必要です。タスクの完遂に直結するフォームや決済フローの改修直後は、規模を問わず手動検証を回してください。

試験結果を公開せずに診断だけ実施しても意味はありますか？

あります。WAICの対応度表記ガイドラインでは、試験を伴わず規格を参照して制作した場合の表記が「配慮」です。公開表明をしない前提なら、達成基準チェックリストの作成を省き、改善調査に費用を集中させられます。入札条件や取引先からの要請で適合表明が要る段階になってから、適合試験へ切り替えて構いません。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る