購入の前に、ベンダーのVPATをどう読み、何を尋ねるか

VPAT（Voluntary Product Accessibility Template）は、米国の業界団体ITI（Information Technology Industry Council）が公開している様式です。ITIは、特定の製品について記入したVPATをACRと呼んでいます。つまりベンダーから届く文書はACRで、VPATはその元になった空の様式です。様式の説明には、報告内容の正しさを保つのはベンダーの責任だと書かれています。ACRはベンダー自身の申告です。

2026年11月2日時点の最新版は、2025年4月付のVPAT 2.5Revで、4つの版があります。新しい版が出ていないかは、ITIのVPATのページで確認してください。

版	対象
WCAG	WCAG 2.0、2.1、2.2
Revised 508	WCAG 2.0と、改訂版Section 508基準（2017年公布、2018年訂正）
EU	WCAG 2.0、2.1と、EN 301 549 V3.1.1、V3.2.1
INT	上のすべて

2.5RevのEU版が対象とするのはEN 301 549 V3.1.1とV3.2.1です。ETSIは2026年9月にV4.1.1を発行しましたが、2.5Revのどの版にも載っていないため、これらの様式で作ったACRはV4.1.1に照らした報告にはなりません。

様式は、ACRに必ず含める項目を定めています。製品名とバージョン、報告日（少なくとも年と月）、連絡先、評価の方法（Evaluation Methods Used）、対象の規格、使った用語の定義、そして基準ごとのConformance Level欄とRemarks and Explanations欄の回答などです。これらがない文書は、名前が何であれ、様式のいうACRではありません。ACRと適合表明の違いは、ページがWCAGに適合するための条件で説明しています。

ACRの各行には、次のどれかの用語が入ります。英語のままの用語に、ITIの定義を訳して添えます。

用語	ITIの定義（訳）
Supports	製品の機能に、既知の欠陥なく基準を満たす方法、または同等の手段で満たす方法が少なくとも1つある。
Partially Supports	製品の機能の一部が基準を満たしていない。
Does Not Support	製品の機能の大部分が基準を満たしていない。
Not Applicable	基準が製品に関係しない。
Not Evaluated	製品をその基準で評価していない。WCAGのレベルAAAの基準にだけ使える。

行の読み方を変える決まりが、様式に3つあります。

• Partially SupportsとDoes Not Supportの行では、問題のある機能と、どう満たしていないかを備考に書くことになっています。備考が空のPartially Supportsからは、対策を立てる材料が得られません。
• WCAGの表では、製品に該当する内容がない基準にもSupportsと書いてよいことになっています。WCAG自身の適合の考え方に沿ったものです。動画のない製品のキャプションの行がSupportsでも、正しい書き方で、警戒すべき兆候ではありません。
• ITIと違う定義を使う場合、ベンダーはNotes欄にそう書くことになっています。表より先に、用語の欄を読んでください。

表より先に冒頭の項目を読みます。表の内容に意味があるかどうかは、ここで決まります。

• どの製品のどの版か： ACRが表すのは1つの版です。提案されている版のほうが新しければ、表は購入しないソフトウェアのことを書いています。
• いつか： 報告日と、改訂があればNotes欄の説明。
• どう試験したか： 評価の方法の欄に、試験した人が製品の使い方を知っていたか、どの支援技術を使ったか、どの手動・自動のツールを使ったか、公開された方法か社内の方法かが書かれているはずです。
• 誰が試験したか： 様式は試験した人の名前を求めていません。第三者が試験したなら、ここに書かれているはずです。何も書かれていなければ、ベンダー自身が試験したものと考えます。

当てにできない報告書の兆候は、見ればわかります。

• すべての行がSupportsで、備考がひとつもない。
• 評価の方法が自動スキャンだけ。スキャンでは確認できない基準が多いことは、自動テストではカバーできないことで説明しています。
• 製品のバージョンや報告日が、購入するものよりかなり古い。
• 様式の版が最新より古い、または必須の項目がない。「準拠しています」と書いた1枚の書面はACRではありません。
• ACRは本体のアプリケーションだけを扱っていて、製品に組み込まれたサポートチャットや同意バナーなど、他社の部品に触れていない。

様式によれば、ACRの目的は買い手の「予備的な評価（preliminary assessments）」を助けることです。次の質問で、予備的な評価を、根拠を示せる評価に変えます。

• 提供されるバージョンについて、最新の様式で、評価の方法を記入したACRを送ってください。
• 試験したのは社内のチームですか、第三者ですか。どの支援技術を使いましたか。
• Partially SupportsやDoes Not Supportの行について、問題は何か、回避方法はあるか、いつ直すかを教えてください。
• ACRは、製品に組み込まれた他社の部品も対象にしていますか。
• 利用者はアクセシビリティの問題をどこに報告でき、修正にはどのくらいかかりますか。
• 貴社のアクセシビリティの取り組みについて、自己評価を記入していただけますか。米国の州CIOの団体NASCIOのPDAA（Policy-Driven Adoption for Accessibility）には、そのためのベンダー向け自己評価があります。方針を持つことから、方針と進捗の情報を顧客に公開することまで、6つの中核基準に沿って答える形式です。

そのうえで、試用環境で自分たちの主要なタスクを試します。会議室を予約する、予約を取り消す、イベントを探す、といった操作です。キーボードだけ、スクリーンリーダー、200%の拡大表示で操作し、結果を該当する行と見比べます。試すのは実際に導入するものすべてで、組み込まれた部品も含みます。メッセージを読み上げないチャットウィジェットや、フォーカスを隠し、最後にしか届かないCookieバナーも、利用者が出会う製品の一部です。製品そのものがサイトに入れるアクセシビリティのツール（オーバーレイや監視ダッシュボードなど）なら、EaseWebの導入済みアクセシビリティ対策の検証で、ベンダーの説明と検証結果を並べることができます。

すべての基準を満たす製品は多くありません。たいていは、要件を最もよく満たす製品を、足りない点を書き出したうえで選ぶことになります。次の対策は、どれもW3C Accessibility Maturity Modelの調達の側面に挙がっている項目か、PDAAの中核基準です。

• 既知の問題の改善計画： 未解決の行ごとに修正の期日を付けます。PDAAも、アクセシブルでないICTについて、期日を含む計画をベンダーに求めています。
• 契約の条項： W3Cのモデルは、ベンダーによる試験の証拠、アクセシビリティを含む保証と救済の条項、導入前後のベンダーの是正措置と改善計画を挙げています。
• 代替手段の計画： 問題が直るまで利用者が使う代替手段を決めて、公開します。職員がメールや電話で予約を受け付けるなどです。書き方は掲載されていない、または中身のないアクセシビリティ方針を参照してください。
• 監視： 利用者からのアクセシビリティの苦情をベンダーに伝える手順を決め、大きな版が出るたびにACRと照らして試験し直します。
• 更新： W3Cのモデルは、Integrateの段階の条件に、契約更新の交渉にアクセシビリティの基準を含めることを挙げています。未解決の行を価格に反映できるのは、更新のときです。

成熟度モデルが評価するのは、製品ではなく組織です。W3Cのモデルは、Communications（広報）からSupport（サポート）までの7つの側面を、Inactive、Launch、Integrate、Optimizeの4段階で評価します。この段階の名前はPDAAに合わせたものだと、モデル自身が書いています。PDAAの成熟度モデルは、6つの中核基準をLaunch、Integrate、Optimizeの3段階で評価します。自分たちの調達の手順はW3Cのモデルの調達の側面で点検し、ベンダーの取り組みは、ACRに加えてPDAAの自己評価で比べるとよいでしょう。