結果とレポート

スキャン結果はすべて1つのプレーンなJSONオブジェクトとして返ります。以下の4つのレポート形式は、どれもこの同じオブジェクトから生成され、それぞれ別の読み手に合わせた形になっています。ブラウザーのタブで目を通す人、SARIFしか扱えないコード解析ダッシュボード、JUnitを読むCIのテストビュー、そしてW3C自身の実装報告形式です。実際に誰が見るのかに合った形式を選んでください。

出力スキーマ

すべてのランナーが返す厳密な契約であり、ほかのレポート形式はすべてここから導かれます。最上位の結果エンベロープ、ルールごとに1件のエントリー（passとnotApplicableもすべて含みます。違反だけのリストにはなりません）、指摘された要素まで追える検出箇所ごとの詳細、ルールが判定できなかったものに付く明示的な不確実性コード、そしてWCAG達成基準の複合集約です。コアのルールによる未判定の検出結果にはすべて人がどう答えるかが付き、一部にはページの根拠がどちらを指しているか（傾き）も付くので、レビューは平らな一覧ではなく、不適合の可能性が高いものから始められます。生の結果の上に何かを構築するなら、一度は読んでおく価値があります。全体の構造は出力スキーマを参照してください。

HTMLレポート

どのブラウザーでも開ける1つのHTMLファイルで、サーバーもビルド手順も要りません。冒頭に平易な言葉の概要、続いて不合格、その後にレビューが必要な検出結果を、不適合の可能性が高いもの、適合の可能性が高いもの、人にしか判断できないものに分けて、コアのルールのものにはそれぞれの確認手順を付けて示し、エンジン自身の複合ルールの結果をもとに適合レベルごとにまとめたWCAG集約、その下に詳しく調べたい人のための検索可能な全件の表があります。生の出力を読みたくないレビュー担当者に渡すのはこのレポートです。HTMLレポートを参照してください。

SARIFレポート

変換処理を自分で書かなくても、スキャン結果をGitHub Code Scanningやその他のSARIF対応ダッシュボードへ直接渡せます。違反は内容ベースの安定したフィンガープリント付きでSARIFの結果に対応付けられるため、ベースライン／許可リストのフィルタリングも確実に機能し、ダッシュボードは行番号がずれるたびに検出結果を見失うことなく、コミットをまたいで追跡できます。resultのないログは、実行されたチェックの中に不合格やレビューが必要なものがなかったことを意味するだけで、適合の表明ではありません。不適合の可能性が高い検出結果をerrorに引き上げるオプションもあり、すべての問いではなく、それらでビルドをゲートできます。SARIFレポートを参照してください。

JUnitレポート

アクセシビリティの結果を、CIにすでにあるテストビュー（GitLabのマージリクエストのウィジェット、Azure DevOpsのTestsタブ、Jenkins、CircleCI）に、ユニットテストと並べて表示できます。WCAGの達成基準ごとに1つのスイート、ルールごとに1つのテストになるため、ページ内で繰り返される不具合も1つの失敗したテストにまとまり、件数は実行ごとに安定します。cantTellはスキップされたテストとして表示され、ビルドを赤にせずに確認できます。ただし、不適合の可能性が高いものでビルドを失敗させることも選べます。スイート名はどのロケールでも同じなので、スキャンの言語を変えてもテストの履歴はリセットされません。緑のスイートは、その達成基準について実行されたルールが何も見つけなかったことを意味し、達成基準を満たしていることを意味するわけではありません。詳しくはJUnitレポートを参照してください。

EARLレポート

W3CのEARL/JSON-LD形式の実装報告で、失敗だけでなくすべてのルールの判定結果を表明します。ACT Rulesコミュニティグループが実装報告として受け付ける形式です。ACTのテストケースで実行すると、各テストケースの判定結果が記録されるため、エンジンが各ルールをどう実装しているかを、信頼に頼らずに検証できます。これは認証でも、WCAG適合性の証拠でもありません。ACTの実装として掲載されることは、W3Cによる承認ではありません。EARLレポートを参照してください。