アクセシビリティテストとは？WCAG2.2とJIS X 8341-3の基準とチェック手順

2026 8/11

2026年8月11日 2026年8月11日

Webサイトやアプリは、多様な利用者が使います。
拡大表示、音声読み上げ、キーボード操作を使う人もいます。

ところが機能テストだけでは、こうした利用の可否は分かりません。
画面が正しく表示されても、読み上げでは意味が通じない場合があるためです。

アクセシビリティテストは、機能が動くかではなく「誰でも使えるか」を確かめます。
判断のよりどころになる基準が、WCAGとJIS X 8341-3です。

この記事では、基準の読み方とチェック手順を整理します。
自動ツールの限界と、外部に任せる範囲の決め方まで解説します。

アクセシビリティテストとは何を確かめるテストか

アクセシビリティテストは、利用環境や身体の状況が異なる人でも情報を得られるかを確かめます。
対象は視覚だけではありません。

操作、聴覚、認知の面でも支障がないかを確認します。
一時的なけがや、屋外の明るさといった状況も含みます。

確認する側面	代表的な利用状況	確認の例
視覚	スクリーンリーダー、拡大表示、色の見え方の違い	画像の代替テキスト、文字色と背景色の対比
操作	キーボードのみ、音声入力、細かい操作が難しい	マウスなしで全機能を使えるか、押しやすい大きさか
聴覚	動画の音声が聞き取れない環境	字幕、書き起こしの有無
認知	専門用語が読みにくい、時間制限がつらい	平易な表現、入力時間の延長手段

これは非機能要件の一部です。
性能やセキュリティと同じく、要件として定義してからテストします。

非機能要件の全体像は、非機能要件とは？6分類の一覧と定義の進め方【非機能要求グレード対応】で確認できます。

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

アクセシビリティは「使えるかどうか」を見ます。
ユーザビリティは「使いやすいかどうか」を見ます。

読み上げで操作できない画面は、まずアクセシビリティの問題です。
操作できるが手順が多すぎる画面は、ユーザビリティの問題です。

ユーザビリティ側の進め方は、ユーザビリティテストの進め方｜誰に頼むかの判断軸で解説しています。

WCAG2.2とJIS X 8341-3の関係

WCAGは、W3Cが定める国際的なガイドラインです。
正式名称は Web Content Accessibility Guidelines です。

2023年10月に、WCAG 2.2 が W3C 勧告になりました。
2.1 の内容を引き継ぎ、達成基準が追加されています。

一方、日本の規格が JIS X 8341-3:2016 です。
この JIS は WCAG 2.0 と一致した内容になっています。

基準	位置づけ	対応関係
WCAG 2.0	W3C 勧告（2008年）	JIS X 8341-3:2016 と一致
WCAG 2.1	W3C 勧告（2018年）	2.0 に達成基準を追加
WCAG 2.2	W3C 勧告（2023年）	2.1 に達成基準を追加
JIS X 8341-3:2016	日本産業規格	WCAG 2.0 と同等

公共調達では、JIS X 8341-3 への準拠を求められることがあります。
民間サービスでは、WCAG の新しい版を目標にする例が増えています。

迷う場合は、JIS を土台にします。
そのうえで、WCAG 2.1 以降の追加基準を上乗せ目標にします。

法令との関係を正しく押さえる

2024年4月1日から、改正障害者差別解消法が施行されました。
民間事業者にも、合理的配慮の提供が義務づけられています。

ただし、Webサイトを特定の等級に適合させる義務が定められたわけではありません。
環境の整備は、努力義務として位置づけられています。

実務では「義務化されたから対応する」と説明すると誤解が生まれます。
問い合わせや申込みが誰でも完了できる状態にすることが目的だと共有しましょう。

適合レベルA・AA・AAAの選び方

WCAG の達成基準には、3段階のレベルがあります。
A が最低限、AA が実務上の標準、AAA が最も厳しい水準です。

レベル	目安	対応の例
A	満たさないと利用できない人が出る	画像の代替テキスト、キーボード操作
AA	公共・企業サイトの目標水準	文字色と背景色の対比比 4.5:1 以上、拡大表示への対応
AAA	すべてのページで満たすことは想定されない	手話通訳の提供、対比比 7:1 以上

多くのプロジェクトでは、レベル AA を目標にします。
WCAG 自身も、全ページで AAA を満たすことは推奨していません。

目標を決めたら、対象範囲もあわせて決めます。
全ページか、主要な導線のみかで工数が大きく変わるためです。

目標レベル（例：AA）
対象ページ（例：トップ、検索、申込みフォーム、完了画面）
対象環境（OS、ブラウザー、スクリーンリーダーの組み合わせ）
除外する範囲と、その理由

アクセシビリティテストの4ステップ

手順は4段階に分けると進めやすくなります。
自動と手動を混ぜる順番が重要です。

STEP1｜対象と基準を決める

目標レベル、対象ページ、対象環境を文書にします。
ここが曖昧だと、指摘の妥当性で議論が止まります。

対象環境は、実際の利用状況から選びます。
スクリーンリーダーは NVDA、PC-Talker、VoiceOver などが候補です。

STEP2｜自動チェックで機械的な不備を洗う

次に、自動チェックツールを全対象ページに流します。
代替テキストの欠落や、対比比の不足はここで大量に見つかります。

axe DevTools、Lighthouse、WAVE などが使われます。
まず機械的な不備を減らすと、手動確認の効率が上がります。

STEP3｜手動でキーボードと読み上げを確認する

続いて、マウスを使わずに主要な導線を最後まで操作します。
申込みや購入は、完了画面まで到達できるかを見ます。

そのあと、スクリーンリーダーで同じ導線をたどります。
読み上げの順序と、エラーの通知が伝わるかを確認します。

STEP4｜結果を記録し、優先度をつけて直す

最後に、達成基準の番号と対象箇所を対応づけて記録します。
再現手順と期待する状態も残します。

すべてを同時に直す必要はありません。
利用が止まる欠陥から順に修正します。

優先度	判断の目安	例
高	その手段では利用を完了できない	キーボードで送信ボタンに到達できない
中	利用はできるが誤解や手戻りが起きる	エラー内容が読み上げられない
低	理解の負担が増える	リンク文言が「こちら」だけ

自動チェックで見つかる欠陥・見つからない欠陥

自動チェックは有効ですが、万能ではありません。
機械が判定できるのは、形式的に判断できる項目だけだからです。

区分	内容	確認方法
自動で分かる	代替テキストの有無、対比比、見出しの階層、フォーム部品のラベル	チェックツール
自動では分からない	代替テキストの内容が適切か、読み上げ順序が自然か、操作の途中で迷わないか	手動確認

たとえば、画像の代替テキストが「画像」でも、自動チェックは通過します。
意味が伝わらない点は、人が見なければ判断できません。

自動チェックの合格は、アクセシブルであることの証明にはなりません。
自動と手動の両方を計画に含めましょう。

現場で頻出する指摘7例

実際の診断では、同じ指摘が繰り返し出ます。
先に確認すれば、指摘件数を減らせます。

代替テキストの欠落：意味を持つ画像に説明がない
色だけで情報を伝える：必須項目を赤字だけで示している
対比比の不足：薄いグレーの補足文が読み取れない
フォーカスが見えない：枠線を消していて現在位置が分からない
ラベルの未関連づけ：入力欄と項目名が結びついていない
エラーが伝わらない：入力エラーが視覚的にしか示されない
見出しの階層が飛ぶ：h2 の次が h4 になっている

いずれも、設計と実装の段階で防げます。
テストで見つけるより、作る前の指針に落としたほうが安く済みます。

外部に依頼するときの判断軸

アクセシビリティの確認には、専門の知識と支援技術の環境が必要です。
社内に経験者がいない場合は、外部に任せる選択肢もあります。

依頼内容	向いている進め方
現状把握だけしたい	主要導線に絞った診断を1回依頼する
公開前に基準適合を確認したい	目標レベルを指定し、全対象ページを診断する
継続的に品質を保ちたい	自動チェックを内製し、定期診断のみ委託する

依頼時は、報告書の形式を先に確認します。
達成基準ごとの判定と、修正案の有無で価値が変わるためです。

成果物の確認項目は、テスト代行の成果物7種類一覧｜発注前に確認する形式・契約・検収基準にまとめています。