本文へ移動
easeweb
ご相談

サイト全体をWCAGで評価し、根拠を示せる結果を出す

WCAG-EMの5つのステップで範囲を決めてサイトを調べ、サンプルを選んで評価・報告する方法と、Trusted Testerのように手順が決まった試験の位置づけ、報告書に書くべきこと

要点:範囲と目標の適合レベル、対応すべきブラウザーと支援技術を決め、サイトを調べてから、代表サンプルとランダムサンプルを試験します。問題にはそれぞれ満たしていない達成基準を割り当て、実施日、範囲、サンプル、方法、ツールを報告書に書けば、ほかの人も同じ試験を再現できます。結果が示すのはサンプルについてで、適合そのものはページごとに定義されています。

01

使う場面

チケット販売会社が、来期に契約を更新します。契約にはWCAG 2.2レベルAAへの対応が条件として書かれています。サイトは1,240ページあり、トップページ、公演一覧、同じテンプレートで作った約1,100の公演ページ、会場ページ、会員登録、マイページ、別ドメインの決済画面、ヘルプセンターで構成されています。試験に使える期間は2週間です。

担当者が知りたいのは「うちのサイトは対応できていますか」という一点です。しかし1,240ページを2週間で手作業で試験することはできません。答えるには、どのページを、どう選び、どう試験したのか、そして試験していないページについて結果が何を言え、何を言えないのかを示す必要があります。

02

進め方

W3Cの評価方法であるWCAG-EM 2.0は、評価を5つのステップに分けています。2026年7月23日に公開されたグループノートで、Webサイトだけを対象にしていたWCAG-EM 1.0(2014年)に代わるものです。2.0はアプリ、キオスク端末、文書も対象に含め、Webページや画面などを「ビュー」と呼びます。新しい版が出ていないかは https://www.w3.org/TR/wcag-em-2/ で確認してください。ステップは通常は次の順に進めますが、製品の種類や評価の目的によって順序が変わることもあるとされています。途中で新しく分かったことがあれば、前のステップに戻ってかまいません。

  1. 範囲を決める(ステップ1)
    • 対象:範囲に入るページを、URLの一覧やパターンで書き出します。どのページについても、入るか入らないかが迷わず分かるようにします。第三者のコンテンツ、モバイル版や言語別の版、別ドメインにあっても製品の一部であるショップなども明記します。
    • 目標の適合レベル:A、AA、AAAのいずれかです。WCAG-EMは、AAが一般に受け入れられ、推奨される目標だとしています。
    • アクセシビリティ サポーテッドの基準環境:サイトが最低限対応すべきOS、ブラウザー、支援技術の組み合わせを、依頼者と合意して決めます。試験中に組み合わせを追加した場合は、基準環境もそれに合わせて広がります。
    • 追加の要件(任意):問題の例ではなくすべての発生箇所を挙げる、障害のある利用者とテストする、決まった報告書の書式を使う、などを最初に合意しておきます。
  2. サイトを調べる(ステップ2)
    • 共通のページ:トップページ、ログイン、問い合わせ、ヘルプ、規約類など、ヘッダー、ナビゲーション、フッターからよくリンクされているページです。
    • 主要な機能:なくなるとサイトの目的が変わってしまう機能です。チケットの購入やアカウントの作成がこれに当たります。
    • ページの種類:テンプレート、レイアウト、日付選択やダイアログ、カルーセルのような部品の違い、エラーメッセージなどの状態の違いを洗い出します。
    • 使われている技術:HTML、CSS、JavaScript、WAI-ARIA、PDFなどです。CMS、デザインシステム、フレームワークも、バージョンとともに書いておくことが勧められています。
    • そのほかの関係するページ:アクセシビリティ方針、使い方のヘルプや設定画面、ログイン、個人情報、支払いのように慎重な扱いが必要な画面です。
  3. サンプルを選ぶ(ステップ3) サイト全体を試験できるなら、WCAG-EMはそうすることを勧めており、その場合はサンプルを選ぶ必要はありません。
    • 代表サンプル:共通のページとそのほかの関係するページをすべて入れ、ステップ2で見つけた主要な機能、ページの種類、技術がそれぞれ含まれるまでページを足します。1ページで複数を兼ねることもできます。
    • ランダムサンプル:代表サンプルの10%のページを、サイト全体から規則性なく選んで追加します。選び方も記録します。
    • プロセス全体:手続きの標準の流れと、よく使われ、完了に欠かせない分岐(新しい配送先の追加など)のページをすべて入れます。URLだけでは同じ画面にたどり着けないことが多いため、次のページへ進む操作も記録します。
  4. サンプルを評価する(ステップ4)
    • 各ページを、操作や入力を始める前の状態で、目標レベルの5つの適合要件に照らして確認します。ヘッダーのように繰り返し出てくる部分は、見た目や動きが違う場合だけ確認し直せば足ります。
    • プロセス全体は、実際に操作しながら確認します。入力欄、エラーメッセージ、ダイアログ、確認画面が対象です。
    • ランダムサンプルと代表サンプルを比べます。ランダムサンプルにだけ、新しい種類のコンテンツや新しい問題が出てきたら、代表サンプルが全体を代表できていなかったということです。ステップ3に戻り、ページを追加します。
  5. 結果を報告する(ステップ5)
    • 各ステップの結果を記録します。ここは必須です。
    • 以下は任意です。試験したページを保存し、ツール、ブラウザー、支援技術とそのバージョンを記録する。評価についての表明を出す。点数を付ける(WCAG-EMは、信頼できる単一の指標はまだなく、点数は誤解を招きうると注意しています)。EARL形式の機械可読な報告を出す。
    • W3CのWCAG-EM Report Toolは、ステップを順にたどりながら報告書を作れるツールです。2026年8月11日公開のバージョン4.1.0から、WCAG-EM 2.0の用語に変わりました。

JIS X 8341-3:2016で試験する場合、ページの選び方は日本独自の考え方に沿うのが一般的です。附属書JB(参考)「試験方法」のJB.1.2は、ウェブページ一式の選び方を4つ挙げています。

  • a) 全てのウェブページを選択する
  • b) ランダムに選択する
  • c) ウェブページ一式を代表するウェブページを選択する
  • d) 代表するウェブページとランダムに選択したウェブページとを併せて選択する

WAICの「JIS X 8341-3:2016 試験実施ガイドライン」(2020年12月版)は、a)を使えるのは多くとも100ページ程度までとし、総ページ数が100ページを超えるならd)を推奨しています。b)でランダムに選ぶページ数の目安は次のとおりです。

選ぶページ数 WAICの説明
10ページ以下 試行的な試験。母数が大きいと合否の判定には少ない
11〜24ページ 合否判定に要する最低限のページ数
25〜39ページ 合否判定に要する標準的なページ数
40ページ以上 合否判定に十分なページ数

d)では、両方を合わせて40〜50ページ程度を目安にします(例:ランダム25ページと代表15ページ)。WCAG-EMのランダムサンプルが代表サンプルの10%にとどまるのに比べると、ランダムに選ぶページの比重がずっと大きい方法です。ガイドラインはさらに、ランダムに選ぶページは試験のたびに選び直すこと、制作を複数の会社で分担したサイトでは担当範囲ごとに選ぶと有効なこと、ツールで安く確かめられる達成基準は全ページを試験しておくと有効なことも挙げています。

03

自動チェック、検査、支援技術を組み合わせる

WCAG-EMは特定のツールに依存せず、ほとんどのアクセシビリティのチェックは完全には自動化できないとしています。どの方法も一つだけではすべての達成基準を確かめられないため、1ページの試験には3つの方法を使います。

方法 確かめられること 残ること
自動チェック コードから判定できるルールを、多くのページでまとめて確認できる。alt属性のない画像、計算できる文字のコントラスト、名前のない入力欄など 言葉が適切かどうか、人が操作しないと分からないこと
検査 コードと、それが支援技術に渡す情報。名前、ロール、見出しの構成、フォーカス順序、カラーピッカーで測るコントラスト 基準環境のスクリーンリーダーで、実際に読み上げられ、操作できるか
支援技術 基準環境の組み合わせで実際に動くか。適合要件4が扱うのはこの点 試験する人がその支援技術をどこまで使いこなせるかに左右される

ツールで見つかることと見つからないことは自動チェックに、実装がアクセシビリティ サポーテッドと言える条件はその実装が、実際に使われているスクリーンリーダーで動くかにまとめています。

表の最後の行には、2つの限界があります。一つは試験する人の腕です。WCAG-EMは、支援技術と、障害のある人がデジタル製品をどう使うかを十分に理解している人が評価することを前提とし、一人ですべてを備えていなければ、チームで知識を持ち寄ってよいとしています。スクリーンリーダーの、ページを読むときのモードと入力するときのモードの違いを知らなければ、自分の押し間違いを不適合として報告しかねません。W3Cの「Involving Users in Web Projects」は、熟練した利用者は普通の利用者には使えない回避策を知っていることがあると書いています。慣れた試験者も同じように、気づかないまま障壁を回避してしまうことがあります。

もう一つは画面拡大ソフトの設定です。ZoomTextのフォーカス強調機能は、フォーカスのあるコントロールに独自の目印を描き、色の強調機能は色、コントラスト、明るさを変えます。これらをオンにしたままだと、フォーカス表示を描いていないページにも目印が見え、拡大画面で目で判断したコントラストはページ本来のものではなくなります。達成基準2.4.7(フォーカスの可視化)と1.4.3(コントラスト (最低限))は、強調機能をオフにするか、拡大ソフトを使わずに確認してください。拡大ソフトは、高倍率でフォーカスを追い、文章を読むという本来の用途で使います。フォーカス表示がないページの例はフォーカス表示が見えない独自デザインのボタンにあります。

04

Trusted Tester:試験手順が決まった方法

WCAG-EMが決めるのは、どのページを試験し、何を報告するかです。達成基準ごとの試験方法は試験する人に任されていて、W3Cの達成方法集は使っても使わなくてもかまいません。この空白を埋めるのが試験手順です。米国国土安全保障省(DHS)のTrusted Tester Section 508 Conformance Test Process for Web 5.1.3(2024年4月)はその一つで、section508.govは、再現性のある結果が得られる手作業の試験方法だと説明しています。この記事の日付の時点では5.1.3が最新です。新しい版はsection508.govで確認してください。

  • 試験する範囲:Section 508のWebの要件41項目です。内訳はWCAG 2.0のレベルAとAAの達成基準38と、Section 508独自の要件3で、これを63のテスト条件で確かめます。
  • 判定のしかた:テスト条件はそれぞれ真か偽かで判定できる記述で、手順が決まっています。結果は「合格」「不合格」「該当なし」「未試験」(Pass、Fail、Does Not Apply、Not Tested)のいずれかで、「未試験」はツールの制約で試験できない場合にだけ使えます。すべてのテスト条件に結果が付くまで、試験は完了しません。
  • ツール:名前や説明など、ページが支援技術に渡す情報を表示する無料のブックマークレットANDI(Accessible Name & Description Inspector)と、Colour Contrast Analyser(コントラストはAccessibility Insightsでも可)です。手順書は自らを、実質的にはアクセシビリティ属性のコード検査だと説明しています。
  • 順序:最初にテスト1(適合している代替版)を行い、続いて自動再生、点滅、キーボード操作とフォーカスのテストを行うよう勧めています。後の3つは、非干渉の適合要件がページ全体に求める達成基準を扱います。テスト1の後は、どの順序で試験してもかまいません。
  • 扱わないこと:どのページを試験するかです。試験の範囲を明記するよう求めてはいますが、選び方は定めていません。

WCAG 2.2を目標にするなら、知っておくべき点が2つあります。Section 508はWCAG 2.0を採用しているため、Trusted Testerが試験するのもWCAG 2.0です。1.4.10(リフロー)や2.5.8(ターゲットのサイズ (最低限))のように2.1と2.2で加わった達成基準には、別の試験が必要です。また、4.1.1(構文解析)は「未試験」と記録する決まりですが、この達成基準はWCAG 2.2では削除されています。組み合わせるなら、WCAG-EMでページを選び、各ページのWCAG 2.0の達成基準をTrusted Testerで試験する形になります。

JIS X 8341-3の試験は、また別の組み立てです。附属書JBのJB.2 c)は、達成方法とその検証方法を特定できる技術的根拠を示すよう求めています。WAICの試験実施ガイドラインは、その例として、達成方法と検証方法の一覧である「実装チェックリスト」を挙げています。結果は達成方法ごとに記入し、それを「達成基準チェックリスト」にまとめます。決まったテスト条件で判定するTrusted Testerとも、達成方法を問わないWCAG-EMとも違い、WCAG 2.0の達成方法集が試験の土台になっています。

05

問題ごとに達成基準を一つ割り当てる

問題は、テーマが近い達成基準ではなく、試験で満たしていないと分かった達成基準に割り当てます。フォームでは3つの達成基準が隣り合っていて、Trusted Testerもそれぞれに別のテスト条件を用意しています。

達成基準 入力欄に求めること Trusted Tester
3.3.2 ラベル又は指示(A) ラベルか説明が画面にあり、欄にフォーカスがある間も見えている 5.A(ラベルがある)
2.4.6 見出し及びラベル(AA) ラベルの言葉で、何を入力するのかが分かる 5.B(ラベルが具体的)
1.3.1 情報及び関係性(A) ラベルがコード上で欄と結び付いている 5.C(プログラムで解釈されるラベル)

そのため、同じフォームでも、3つの違う指摘になりえます。

  • 「郵便番号」のラベルのforが別のidを指しているなら、1.3.1の不適合です。言葉はあり、内容も正しいのに、何のラベルにもなっていません。ラベルがない・表示と食い違うフォームの入力欄がこの例で、入力を始めると消えるプレースホルダーだけのラベルが3.3.2の不適合になることも扱っています。
  • 二人分の情報を入れるギフトカードのフォームで、ラベルが「名前」だけなら、不適合は2.4.6だけです。ラベルは欄と結び付き、画面にも残っているので、1.3.1と3.3.2は満たしています。問題は言葉です。何を入力するのか分からない、あいまいなフォームのラベルで扱っています。
  • 見出しも同じように分かれます。Trusted Testerは、見出しの言葉を2.4.6(10.A)、マークアップとレベルを1.3.1(10.B、10.C)で試験します。ページの構成と食い違う見出しでは、div要素で見た目だけを整えた項目名が1.3.1を、「その他」とだけ書いた見出しが2.4.6を満たしていません。

同じガイドの中身のないh2のように、一つの問題が2つの試験で不合格になる場合は、両方に記録し、直すのは1か所だと書き添えます。フォームの問題をすべて1.3.1に入れたり、同じ問題を3つの達成基準に重ねて数えたりすると、報告書の不適合の数が実際より増え、開発者は見当違いの修正をすることになります。

不適合か、推奨事項か。 不適合とは、目標レベルの達成基準を満たしていないことです。それ以外の指摘、つまり目標より上のレベルの達成基準、参考達成方法、使いにくさなどは、推奨事項として区別して書きます。ヘルプページかホバーでしか読めない入力欄のヘルプは実際の障壁ですが、該当する3.3.5(ヘルプ)はレベルAAAなので、目標がAAなら推奨事項として報告します。WCAG-EMは、目標を超えて評価しておくと改善の計画に役立つとしています。Trusted Testerも、別のサイトへのリンクのようにSection 508の範囲外の問題は、不適合ではなくコメントとして伝えてよいとしています。W3Cの達成方法を使っていないことも、それだけでは不適合になりません。WCAG-EMは特定の達成方法を求めていないためです。

06

報告書に書くこと

WCAG-EMのステップ5.1は報告書に含める内容を挙げ、Trusted Testerは、それに基づく報告書に試験方法、範囲、試験環境を明記するよう求めています。

項目 書く内容 根拠
日付 試験の完了日、または期間 WCAG-EM 5.1
実施者 評価した人と、依頼した人 WCAG-EM 5.1
範囲 対象と対象外のページ、目標の適合レベル、基準環境 WCAG-EM 5.1、Trusted Tester
技術 使われている技術 WCAG-EM 5.1
サンプル 代表サンプル、ランダムサンプルとその選び方、プロセス全体 WCAG-EM 5.1
方法 評価方法と試験手順、そのバージョン WCAG-EM 5.1(任意)、Trusted Tester(必須)
ツールとバージョン 試験ツール、ブラウザーと拡張機能、支援技術、OS WCAG-EM 5.2(任意)、Trusted Tester(必須)
結果 満たしていない達成基準ごとに少なくとも1つの例。繰り返し出る問題はそうと分かるように WCAG-EM 5.1

不適合については、WCAG-EMが、分かりやすい説明、再現手順、深刻度、スクリーンショットがあると修正が早く進むとし、Trusted Testerは、問題の場所と、可能なら原因となった箇所を示すよう求めています。これらの項目で作った報告書の一例が、EaseWebの適合性の記録です。

日本では、JIS X 8341-3:2016への対応を表すのに、WAICの「対応度表記ガイドライン」(2021年4月版)の3つの言い方がよく使われます。

表記 試験 ほかに書くこと
準拠 試験を行い、目標レベルの達成基準をすべて満たしたことを確認して、結果を公開する なし
一部準拠 試験を行い、達成基準の一部を満たしたことを確認する。結果の公開は任意 今後の対応方針。部分適合を使う場合はその記述
配慮 試験の有無や結果は問わない 目標とした適合レベル、または参照した達成基準の一覧

どの表記でも、アクセシビリティ方針の提示または公開が前提です。同じガイドラインは、JIS X 8341-3:2016で適合はウェブページに対してだけ定義されているため、サイト全体の適合を表明するには全ページの試験が必要だと説明しています。そのうえで、JB.1.2に沿ってページを選んで試験すれば、サイト全体の対応度を「準拠」と表記できるとしています。

報告書と、評価についての表明は別のものです。WCAG-EMのステップ5.3は、必須のステップをすべて行い、サンプルのすべてのページが目標を満たし、サイトの所有者が表明の正確さを保つと約束した場合にだけ、表明を出せるとしています。それでもこれは評価についての表明で、サイトの適合表明ではありません。適合はWebページごとに定義されているためです。適合表明に必要なことはページがWCAGに適合するための条件で扱います。

07

実例

チケット販売サイトを、5つのステップに沿って評価します。

  1. 範囲:tickets.example.comのすべてと、別ドメインですが製品の一部であるpay.example.comの決済画面。座席表は他社の埋め込みですが、ページの一部なので範囲に含めます。目標はWCAG 2.2のAAです。基準環境は依頼者と合意し、WindowsのChromeでNVDAとJAWS、macOSとiOSのSafariでVoiceOver、AndroidのChromeでTalkBackとしました。
  2. 調査:共通のページは9つ(トップ、ログイン、会員登録、検索、ヘルプ、問い合わせ、アクセシビリティ方針、規約、プライバシー)。主要な機能は、公演を探す、チケットを買う、アカウントを作る、チケットを譲渡するの4つ。ページの種類は、公演ページのテンプレート、会場ページ、一覧、マイページ、座席表、PDFのチケット。技術はHTML、CSS、JavaScript、WAI-ARIA、PDFです。
  3. サンプル:代表サンプル30ビューと、サイトマップからスクリプトで選んだランダムサンプル3ビュー。さらに決済の5つの段階と「新しいカードを追加」の分岐のうち、まだ入っていなかった6ビューを加え、合計39ビューです。
  4. 評価:各ビューに自動チェックを行い、WCAG 2.0の達成基準はTrusted Testerのテスト条件で、2.1と2.2の達成基準は別の試験で確かめ、基準環境のスクリーンリーダーでも確認しました。ランダムサンプルの1つは動画のある古い公演ページで、代表サンプルにはない種類のページでした。動画には字幕がありませんでした。そこでステップ3に戻り、動画のある公演ページを2つ追加したところ、どちらでも同じ問題が確認できました。最終的なサンプルは41ビューです。
  5. 報告:指摘は、それぞれ該当する達成基準に割り当てました。
指摘 達成基準 ガイド
決済の2段階目で、「郵便番号」のラベルが別の欄を指している 1.3.1 ラベルがない・表示と食い違うフォームの入力欄
二人分の情報を入れるギフトフォームで、ラベルが「名前」「メール」だけ 2.4.6 何を入力するのか分からない、あいまいなフォームのラベル
公演ページのテンプレートで、項目名がdiv要素で作られている 1.3.1 ページの構成と食い違う見出し
「購入」ボタンにフォーカス表示がない 2.4.7 フォーカス表示が見えない独自デザインのボタン
公演の動画に字幕がない 1.2.2
注文番号のヘルプがホバーでしか表示されない 推奨事項(3.3.5、AAA) ヘルプページかホバーでしか読めない入力欄のヘルプ

見出しの問題は公演ページのテンプレートにあるため、繰り返し出る問題として記録しました。試験したすべての公演ページで見つかりましたが、直すのは1か所です。「購入」ボタンは、拡大ソフトのフォーカス強調機能をオンにしていると、フォーカスがあるように見えました。オフにするとページは何も描いていなかったため、2.4.7の不適合としました。

報告書には、最後に試験した日、範囲、基準環境、41ビューの一覧、ランダムサンプルを選んだスクリプトとそのシード値、方法(WCAG-EM 2.0、WCAG 2.0の達成基準はTrusted Tester 5.1.3)、すべてのツール、ブラウザー、スクリーンリーダーとそのバージョンを書きました。「対応できていますか」への答えは、試験した41ビューはWCAG 2.2のAAを満たしておらず、満たしていない点は一覧のとおり、というものです。ほかのページについては何も表明せず、サンプルのすべてのビューが目標を満たしてはいないため、評価についての表明も出していません。

WAICの試験実施ガイドラインに沿って、同じサイトをJIS X 8341-3:2016で試験するなら、1,240ページは100ページを超えるので方式d)を使い、たとえばランダム25ページと代表15ページの計40ページ前後を選ぶことになります。対応度は「AAに一部準拠」とは表記できません。対応度表記ガイドラインは、AAに一部準拠と表記するにはレベルAに準拠していることを前提としていますが、この例では1.2.2や1.3.1のように、レベルAの達成基準も満たしていないためです。試験の有無や結果を問わない「配慮」であれば、目標としたAAを示して表記できます。また、JIS X 8341-3:2016はWCAG 2.0と同じ内容のため、2.5.8のようにWCAG 2.1と2.2で加わった達成基準は、JISの試験結果には入りません。

08

よくある間違い

  • サンプルの結果を、サイト全体の適合表明として扱う。 WCAG-EMは、試験していないページに問題が残っている可能性が常にあるため、サンプルだけを根拠にサイト全体の適合は表明できないとしています。サンプルで分かったことを報告し、表明についてはページがWCAGに適合するための条件を参照してください。
  • ランダムサンプルを省く、または比べない。 ランダムサンプルは、代表サンプルが見落とした種類のコンテンツを見つけるためのものです。比べるのがステップ4.3で、違いが出たらステップ3に戻ります。
  • 購入手続きの最初の画面だけを試験する。 WCAG 2.2のプロセス全体の適合要件では、手続きのどのページも、すべてのページが適合しない限り適合しません。
  • フォームの問題をすべて1.3.1に入れる。 あいまいなラベルは1.3.1を満たし、2.4.6を満たしません(あいまいなフォームのラベル)。割り当てを誤ると、言葉を直すべきところで、開発者がコードを直しに行くことになります。
  • 目標がAAなのに、AAAの達成基準を不適合に数える。 入力欄のヘルプのように、推奨事項として報告します。
  • 拡大ソフトの強調機能を通して、フォーカスやコントラストを判断する。 強調機能は独自の目印を描き、色を変えます。フォーカス表示の確認は、強調機能をオフにして行います。
  • 自動チェックだけの結果を、試験結果として報告する。 ツールで判定できるのは一部の達成基準だけです。何が分かり、何が分からないかは自動チェックにあります。
  • Trusted Testerの結果を、WCAG 2.2の結果として報告する。 Trusted Testerが試験するのはWCAG 2.0のAとAAです。2.1と2.2の達成基準には別の試験が要ります。
  • 報告書にバージョンを書かない。 ブラウザー、スクリーンリーダー、ツールのバージョンがなければ、誰も試験を再現できません。ソフトウェアが更新されれば、結果も古くなります。

09

規格の定め

  • WCAG 2.2 5.2(要件):「ウェブページが WCAG 2.2 に適合するためには、次に挙げる全ての適合要件を満たしていなければならない」(WAICの日本語訳)。要件は、適合レベル、ページ全体、プロセス全体、技術のアクセシビリティ サポーテッドな使用方法だけ、非干渉の5つです。5.2.3は「プロセスに含まれるいずれかのページが特定のレベル以上で適合していない場合、そのレベルでの適合は不可能である」としています。
  • WCAG 2.2 5.3(表明する場合の要件):「適合は、ウェブページに対してだけ定義されている。しかし、適合表明は 1 ページ、一連のページ群、又は複数の関連するウェブページを対象に行ってもよい」。表明には、日付、ガイドラインの名称、バージョンとURI、適合レベル、対象ページ、依存している技術を書きます。
  • **WCAG-EM 2.0(助言):**WCAGの要件に何かを加えたり変えたりするものではないと明記したグループノートです。サンプルとして選んだページと機能の評価だけでは、サイト全体のWCAG 2適合は表明できないとしています。各ステップは評価方法としての要件の形で書かれ、評価についての表明を出すには、任意でない要件をすべて満たす必要があります(ステップ5.3)。
  • **Section 508 E205.4(米国連邦政府のICTへの要件):**電子コンテンツは、WCAG 2.0のレベルAとAAの達成基準と適合要件に適合しなければならないと定めています。試験やサンプリングの方法は定めておらず、Trusted Testerはこの規則に対する試験手順の一つで、規則の一部ではありません。
  • **EN 301 549:**WCAG-EMは、V3.2.1をWCAG 2を参照して取り込んでいる規格の一つに挙げています。WCAG以外に求めることはEN 301 549では、WCAGのほかにWebサイトに何が求められるかで扱います。
  • **JIS X 8341-3:2016:**ISO/IEC 40500:2012の一致規格で、WCAG 2.0と技術的に同等です。WAICによると、ISO/IEC 40500が2025年9月に改訂されたことを受け、順調なら2027年、遅くとも2028年に改正される予定です(2026年9月時点)。試験方法は附属書JB(参考)にあり、ページの選び方、試験の手順、試験結果の表示を定めています。参考の附属書なので、ここに沿った試験は規格の要件ではありません。

10

制限

この記事が扱うのは、サイトをどう試験し、どう報告するかです。どの問題から直すかはどの指摘から直すか、いつ作り直しを選ぶかで、障害のある人とのユーザビリティテストで何が分かるかは障害のある人とのテストでわかること、監査ではわからないことで扱います。WCAG-EMは、サイトの規模、古さ、複雑さ、一貫性、求める確からしさなど、サンプルの大きさを左右する要因を挙げていますが、ランダムサンプルの10%以外に数は示していません。サンプルの大きさは試験する人が判断し、依頼者と合意して決めます。どの基準環境がサイトに合うかも、両者で決めることです。報告書が契約や苦情への対応に十分かどうかは、依頼者の弁護士が判断します。

11

用語

アクセシビリティ サポーテッドの基準環境
試験の前に合意する、サイトの機能が動作すべきOS、ブラウザー、支援技術の組み合わせ。
代表サンプル
よく使われるページ、主要な機能、ページの種類、使われている技術がすべて試験されるよう、意図して選ぶページ。
ランダムサンプル
代表サンプルに漏れがないかを確かめるため、サイト全体から規則性なく選ぶページ。
プロセス全体
購入手続きのように、一つの作業を終えるまでに順に進む一連のページのすべて。
テスト条件
Trusted Testerで、ページについて真か偽かで判定する一つの記述。判定の手順が決まっている。
推奨事項
報告書には書くが、目標の適合レベルの外にあるため不適合には数えない助言。

12

出典とガイド

関連するガイド

この記事は実務の進め方を、再現した例で説明するものです。法的な助言ではなく、特定の顧客についての指摘でもありません。