アクセシビリティテストの進め方｜義務化と実務手順

2026 8/12

2026年8月12日

「アクセシビリティ対応をお願いしたい」。クライアントからそう言われて、具体的に何を確認すればよいか即答できず、戸惑った経験はないでしょうか。

機能テストやバグ検出には慣れていても、「誰もが使えるか」を検証するアクセシビリティテストは、判断の物差しが違います。法令や規格が絡むため、感覚だけで進めると抜けが生じます。

しかも、対応の要否や範囲は案件ごとに異なります。公的機関の案件では規格準拠が要件になり、一般の民間案件では優先度の判断が求められます。何をどこまで確認すべきかを整理できていないと、見積にも工程にも織り込めません。

この記事では、受託開発の現場で使えるアクセシビリティテストの進め方を、対応義務化の背景から実務手順まで順に整理します。自動ツール・手動確認・支援技術による検証をどう組み合わせ、専門知識がない場合に何を外部に頼るかまで、PMが上長やクライアントに説明できる粒度で解説します。

なぜ今アクセシビリティ対応が求められるのか

まず押さえたいのは、アクセシビリティ対応が「善意のオプション」から「取引条件」へ変わりつつある点です。背景には、法令・公共調達・海外案件という3つの流れがあります。

ここを正確に理解しておくと、クライアントへの説明も、社内での優先度づけもぶれません。特に法令の位置づけは誤解が多いため、丁寧に整理します。

加えて、法令とは別に事業リスクの側面も無視できません。アクセシビリティが低いサイトは、一定の利用者を最初から取りこぼします。高齢化が進むなかで、拡大表示や音声読み上げに頼る利用者は着実に増えています。

操作できずに離脱した利用者は、多くの場合その理由を報告してくれない
「使えなかった」という体験は、そのままブランド評価の低下につながる
是正を求める声や指摘が公になれば、発注元の信用にも影響する

アクセシビリティは「一部の人への配慮」ではなく「取りこぼしを防ぐ品質管理」だと捉えると、社内の合意を得やすくなります。

改正障害者差別解消法と「合理的配慮」

2024年4月1日に施行された改正障害者差別解消法により、民間事業者による「合理的配慮の提供」が法的義務となりました。それ以前は努力義務でしたが、義務へと引き上げられています。

ここで誤解しやすい点があります。「ウェブアクセシビリティ対応そのものが義務化された」わけではありません。ウェブサイトの改善は、法律上は「環境の整備」（努力義務）に位置づけられます。

一方で、環境の整備は合理的配慮を的確に提供するための基礎とされています。つまり、あらかじめアクセシブルなサイトを用意しておくことが、義務である合理的配慮を果たしやすくする、という関係です。この整理はデジタル庁の資料でも示されています（ウェブアクセシビリティ導入ガイドブック（デジタル庁））。

合理的配慮を具体的にイメージすると分かりやすくなります。たとえば、読み上げに対応していない申込フォームがあり、利用者から代替手段を求められた場合、電話や別様式での受付を用意するのが合理的配慮にあたります。しかしフォーム自体を最初からアクセシブルにしておけば、そもそも個別対応の負担が発生しません。

「義務」なのは、求められたときに過重でない範囲で対応する合理的配慮
「努力義務」なのは、サイトを事前にアクセシブルにしておく環境整備
両者は対立せず、環境整備が進むほど個別対応の負担は軽くなる

クライアントに説明する際は、この2段構えを正確に伝えると、過剰な不安も過小評価も避けられます。「対応しないと即違法」でも「やらなくてよい」でもない、という現実的な立ち位置を共有することが大切です。

公共調達とJIS X 8341-3

公的機関のサイトには、日本産業規格「JIS X 8341-3:2016」への対応が求められています。総務省の「みんなの公共サイト運用ガイドライン」では、適合レベルAAへの準拠が目標として示されています。

そのため、官公庁・自治体案件を受託する場合、仕様書に「JIS X 8341-3 AA準拠」が要件として明記されることが増えています。要件を見落とすと、納品後の手戻りや検収不合格につながります。

発注元が公的機関の場合、AA準拠が事実上の前提になりやすい
「準拠」「一部準拠」など、試験結果に応じた表記ルールがある
準拠を主張するには、根拠となる試験の実施と結果公開が必要

詳細は総務省の情報アクセシビリティポータルサイトで確認できます（みんなの公共サイト運用ガイドライン（総務省））。

海外案件とWCAG要求

海外の顧客や、海外にユーザーを持つサービスでは、WCAG（Web Content Accessibility Guidelines）への準拠を契約要件とされるケースがあります。米国のADAや欧州のアクセシビリティ関連規制を背景に、発注段階でレベルAAが求められることも珍しくありません。

JIS X 8341-3はWCAG 2.0と技術的に一致しているため、WCAGを理解しておけば国内・海外の要求に横断的に対応できます。規格ごとに一から学び直す必要はありません。

アクセシビリティテストとは何か｜ユーザビリティテストとの違い

アクセシビリティテストとは、障害の有無や利用環境にかかわらず、誰もがコンテンツを利用できるかを検証する取り組みです。視覚・聴覚・肢体・認知など、多様な条件のユーザーを想定します。

ここで混同されやすいのがユーザビリティテストです。両者は目的も評価軸も異なるため、最初に切り分けておきましょう。

WCAGの4原則と適合レベル

WCAGは「知覚可能・操作可能・理解可能・堅牢」という4つの原則で構成されます。頭文字をとってPOURと呼ばれます。各原則の下に達成基準があり、それぞれに適合レベルが設定されています。

4原則は抽象的に見えますが、具体的な達成基準に落とすと現場の作業がイメージできます。代表的な例を挙げます。

知覚可能: 画像に代替テキストを付ける、動画に字幕を用意する、十分なコントラストを確保する
操作可能: キーボードだけで操作できる、時間制限に猶予を持たせる、点滅で発作を誘発しない
理解可能: 入力エラーを分かりやすく示す、一貫したナビゲーションにする、言語を明示する
堅牢: 支援技術が正しく解釈できるよう、適切なマークアップと役割（ロール）を付与する

4原則を「見える・操作できる・分かる・壊れない」と噛み砕くと、非エンジニアのクライアントにも伝わりやすくなります。

適合レベルは3段階です。案件で「どのレベルを満たすか」を最初に合意しておくことが、後の手戻りを防ぐ鍵になります。

適合レベル	位置づけ	実務での扱い
レベルA	最低限クリアすべき基準	満たさないと利用不能な利用者が出る
レベルAA	国際的な標準ライン	多くの案件・公的調達で目標とされる
レベルAAA	最高水準	全体一律の達成は現実的でなく部分適用が中心

迷ったら、まずレベルAAを目標に据えるのが実務上の定石です。国内のJISも公的調達もAAを基準としているためです。WCAGの各バージョンや原則の詳細はW3Cの公式解説が一次情報になります（WCAG 2 Overview（W3C））。

ユーザビリティテストとの違い

アクセシビリティは「そもそも使えるか」、ユーザビリティは「使いやすいか」を問います。前者は規格準拠という客観的な物差しがあり、後者は利用者の主観的な体験を評価します。

観点	アクセシビリティテスト	ユーザビリティテスト
主な問い	誰もが利用できるか	対象ユーザーが使いやすいか
評価の物差し	WCAG・JISなど規格・基準	タスク達成率・満足度など体験指標
主な検証手段	自動ツール・支援技術・基準チェック	被験者観察・インタビュー
法令・調達との関係	直接関係する場合が多い	直接の法要件になりにくい

両者は排他ではなく補完関係です。アクセシビリティで「誰もが使える」土台を整えたうえで、ユーザビリティで「より使いやすく」磨く、という順序が理想です。両者を混同すると、規格準拠のチェックだけで満足して体験の悪さを見逃したり、逆に感覚的な使いやすさだけを追って規格要件を落としたりします。役割を分けて捉えることが、抜け漏れを防ぐ第一歩です。

使い分けと外注判断の全体像は、ユーザビリティテストの進め方と依頼先の選び方を解説した記事もあわせて参考にしてください。

アクセシビリティテストの進め方【全体像】

検証の全体像は、「自動チェック → 手動チェック → 支援技術での確認」という3層で捉えると整理しやすくなります。どれか1つでは不十分で、3つを組み合わせて初めて実務水準に達します。

なぜ3層が必要かというと、検出できる問題の種類が層ごとに異なるからです。自動ツールは機械的に判定できる項目に強く、人間の判断が要る項目は手動と支援技術で補います。

層	主に検出する問題	カバー範囲の目安
自動チェック	コントラスト比・代替テキスト欠落・見出し構造の不備	機械判定可能な一部の基準
手動チェック	文脈依存の代替テキスト妥当性・操作順序の論理性	判断が必要な多くの基準
支援技術での確認	スクリーンリーダーでの読み上げ・キーボード操作の実際	実利用に近い最終確認

自動ツールだけで「アクセシビリティ対応済み」と判断するのは危険です。機械が判定できるのは基準の一部にとどまるためです。以下、各層を具体的に見ていきます。

最初に自動チェックで明らかな不備を洗い出す
次に手動チェックで判断が要る基準を確認する
最後に支援技術で実際の利用に近い形を検証する

進め方をもう少し具体化すると、次のような流れになります。まず対象ページを決め、自動ツールを一通りかけて機械的な不備をリスト化します。次にその一覧を修正しながら、ツールでは判定できない項目を手動チェックの観点表に沿って確認します。最後に、実際にキーボードとスクリーンリーダーで主要な操作をなぞり、利用者の体験として破綻がないかを見ます。

この順序には理由があります。自動チェックで直せる部分を先に潰しておくと、手動チェックの担当者が本質的な判断に集中できるためです。逆に手作業から始めると、機械で拾えるはずの単純な不備に時間を取られ、非効率になります。

自動チェックツールでできること・できないこと

自動チェックは、アクセシビリティテストの入口として費用対効果が高い工程です。短時間で広い範囲をスキャンし、明確な不備を機械的に検出できます。

代表的なツールには、ブラウザ拡張やCIに組み込める検査エンジンがあります。まずはここから着手すると、対応の全体量が見えてきます。

主な自動チェックツール

ツール例	形態	主な用途
axe系ツール	ブラウザ拡張・ライブラリ	開発中の随時チェック・CI組み込み
Lighthouse	ブラウザ内蔵	ページ単位の総合スコア確認
miChecker	デスクトップツール	JIS準拠の観点を含む診断

フロントエンド開発の工程では、テストコードにアクセシビリティ観点を組み込む方法もあります。吉井健文『フロントエンド開発のためのテスト入門』では、要素取得を役割（ロール）ベースで行う手法や、専用アドオンで機械的な検査を自動化する考え方が紹介されています。開発段階から検査を回す発想は、後工程の負担軽減に直結します。

自動チェックの限界

一方で、自動チェックには明確な限界があります。機械が判定できるのは達成基準の一部にすぎません。たとえば代替テキストは、存在の有無は検出できても、内容が画像を適切に説明しているかまでは判断できません。

代替テキストの「有無」は検出できるが「妥当性」は判断できない
見出しタグの使用は分かるが、文書構造として適切かは人が見る必要がある
操作の論理的な順序やエラーの分かりやすさは機械化しにくい

そのため、自動チェックは「ここまでは機械で担保し、残りは人が見る」という線引きの道具として使うのが適切です。機械判定できる達成基準は全体の一部にとどまり、残りは人の目でしか確認できない、という前提を関係者と共有しておきましょう。

運用のコツは、自動チェックを一度きりの検査で終わらせないことです。CIに組み込んで変更のたびに走らせれば、退行（デグレ）を早期に検知できます。手動チェックの負担も、機械で守れる範囲を常時担保することで軽くなります。CIへの組み込み方は、Webアプリのテスト自動化とE2E導入の手順をまとめた記事も参考になります。

自動チェックは「一度やって終わり」ではなく、変更のたびに回す仕組みにしてこそ効果を発揮します。

手動チェックと支援技術による検証手順

自動チェックで拾いきれない部分は、手動チェックと支援技術での確認が担います。ここがアクセシビリティテストの中核であり、品質の差が出るところです。

特別な機材は必須ではありません。キーボードと、OSやブラウザに標準搭載された支援機能があれば、多くの確認を始められます。まずは手を動かして体感することが理解への近道です。

ここで一つ、現場の心構えを共有します。手動チェックは「専門家しかできない難しい作業」ではありません。観点さえ決まっていれば、開発メンバーでも一次確認は十分に担えます。専門家に頼るべきなのは、判定が割れる微妙なケースや、最終的な準拠の判断です。

キーボード操作の確認

マウスを使わず、キーボードだけで全ての操作が完結するかを確認します。運動機能に制約のある利用者や、スクリーンリーダー利用者にとって不可欠な観点です。

Tabキーだけで全てのリンク・ボタン・入力欄に到達できるか
フォーカスが今どこにあるか視覚的に分かるか
操作の順序が画面の見た目と論理的に一致しているか
モーダルやメニューから抜け出せない状態にならないか

キーボードだけで最初から最後まで操作を完了できるかは、最優先で確認すべき観点です。ここが崩れると、他の対応が整っていても利用できない人が出ます。

スクリーンリーダーでの読み上げ確認

画面読み上げソフト（スクリーンリーダー）で、コンテンツが意味の通る順序と内容で読み上げられるかを確認します。視覚に頼らず情報が伝わるかを検証する工程です。

始めるにあたって、高価なソフトを買う必要はありません。多くのOSやブラウザには読み上げ機能が標準で備わっており、まずはそれで感覚をつかめます。実際に画面を見ずに読み上げだけで操作してみると、視覚利用では気づけない問題が次々と見えてきます。

確認観点	具体的なチェック内容
画像の情報	代替テキストが画像の意味を過不足なく伝えているか
フォーム	入力欄とラベルが正しく関連づき、読み上げで対応が分かるか
動的な変化	エラー表示や更新が発生時に読み上げへ反映されるか
リンク	リンク文言だけで遷移先が推測できるか

コントラストと文字の確認

視認性に関する基準は、自動ツールと目視を併用します。数値で判定できる部分はツールに任せ、実際の見え方は人が確認します。

文字色と背景色のコントラスト比が基準を満たしているか
色だけで情報を区別していないか（色覚特性への配慮）
文字サイズを拡大しても内容が崩れず読めるか

これらの観点は、テスト観点の洗い出し手順と観点表の作り方を解説した記事の考え方を応用し、観点表として整理しておくと抜け漏れを防げます。

完璧を目指しすぎない

手動チェックを始めると、次から次へと課題が見つかり、途方に暮れることがあります。しかし、すべてを一度に完璧にする必要はありません。まずは影響の大きい問題から順に潰していくのが現実的です。

利用そのものを妨げる問題（操作不能・情報が得られない）を最優先にする
使いにくさは残っても致命的でないものは、次のフェーズへ回す
課題を一覧化し、対応済みと保留を可視化して合意する

優先順位をつけて段階的に改善する姿勢が、限られた工数のなかでは結果的に最短の近道になります。障害となる問題を確実に取り除くことが、レベルAA達成への着実な一歩です。

受託開発にアクセシビリティテストの進め方をどう組み込むか

アクセシビリティ対応で最も失敗しやすいのは、リリース直前にまとめて確認しようとすることです。基準を満たすには設計や実装の見直しが必要な場合が多く、後工程での一括対応は手戻りを膨らませます。

有効なのは、開発の各フェーズに小さく確認を分散させる方法です。要件定義で目標レベルを決め、実装中に自動チェックを回し、テスト工程で手動確認を行う、という流れです。

フェーズ	やること	主な担当
要件定義	目標レベル（例:AA）と対象範囲を合意	PM・クライアント
設計	色・構造・操作の方針に基準を反映	設計者
実装	自動チェックを随時実行し早期修正	開発者
テスト	手動・支援技術で最終確認	テスト担当

この分散アプローチには、費用対効果の面でも利点があります。早期に問題を見つけるほど修正コストは小さく、上長への説明でも「後半の手戻りリスクを前倒しで潰す」と整理できます。

たとえば、色のコントラスト不足は設計段階なら配色ルールの調整で済みます。しかし実装が全画面で完了した後に発覚すると、影響範囲の広い修正になり、回帰確認まで必要になります。同じ問題でも、見つかる工程が後ろになるほどコストは膨らむのです。

見積の観点でも、アクセシビリティを独立した工数として最初から積んでおくことが重要です。「機能テストのついで」で吸収しようとすると、必ず時間が足りなくなります。要件定義で目標レベルを合意する際に、対応と検証の工数を明示的に見積へ組み込みましょう。

実際のプロジェクトでよくあるのが、検収直前にクライアントから「アクセシビリティは大丈夫か」と問われ、慌てて確認したら多数の不備が見つかる、というパターンです。設計に起因する問題まで含まれていると、短納期での修正は品質妥協につながりかねません。要件定義時に一言確認しておくだけで、この種の事故は大きく減らせます。

上長やクライアントへの説明では、次のように整理すると納得を得やすくなります。「対応範囲を最初に決め、工数を見積に含め、工程に分散して確認する。そうすれば後半の手戻りとリリース遅延のリスクを抑えられる」。費用の話も、後追いの緊急対応より前倒しのほうが安く済む、と説明できます。

要件定義で目標レベルを明文化し、見積の前提に含める
実装フェーズで自動チェックをCIに組み込む
テスト計画にアクセシビリティ観点を独立した項目として立てる
クライアントと「どのレベルまで対応するか」を書面で合意する

「どこまで対応するか」を契約段階で握っておくことが、無限の作業拡大を防ぎます。アクセシビリティは突き詰めると際限がないため、範囲の線引きが実務上きわめて重要です。

専門知識がない場合の外部専門家・ベンダー活用

社内に知見がない状態で、いきなり全てを内製しようとする必要はありません。アクセシビリティは専門性が高く、判断の難しい部分だけを外部の専門家に頼るのが現実的です。

とはいえ丸投げは避けたいところです。何を任せ、何を自社に残すかを切り分けると、費用も知見の蓄積もコントロールしやすくなります。

進め方	向いているケース	留意点
完全内製	継続的に案件があり知見を蓄積したい	立ち上げの学習コストが大きい
診断のみ外注	準拠状況を客観的に確認したい	修正は自社で行う前提の体制が要る
診断＋改善支援	短期でレベルを引き上げたい	費用は大きいが手戻りリスクは下げやすい

外部に依頼する際は、事前準備の質が成果を左右します。対象ページ、目標レベル、既存の課題を整理してから相談すると、見積の精度も上がります。依頼前の段取りは、テスト代行を依頼する前の準備と段取りの観点をまとめた記事が参考になります。

ベンダーを選ぶ際は、次のような点を確認すると認識のずれを防げます。診断のアウトプットが「合否」だけでなく、どの達成基準に対してどう不足しているかまで示されるかは特に重要です。