適合性

スキャン結果に問題がないことは、それだけではWCAG適合の主張になりません。そうでないふりをすることこそ、このエンジンが拒む行き過ぎです。このセクションでは、個々のルールの結果が達成基準の判定へどのように集約されるのか、その判定が何を正直にカバーし何をカバーしないのか、そしてすべてを一度に直すまで全ビルドを止めるのではなく、既知でレビュー済みの違反を踏まえて実際のCIパイプラインにゲートを設ける方法を説明します。

WCAG適合性との対応

アトミックルール、カバレッジのファセット、WCAG達成基準の複合集約ルールがどう組み合わさるのか、そしてチェックがすべて問題なかった達成基準が、漠然とした「問題なさそう」ではなく、一部のみ確認したcantTellになるのはなぜかを正確に確認できます。複合ルールは、どの部分をチェックしたかを示し、残りを人に委ねます。目標ではなくいくつかのチェックを指定したスキャンでも、それらが属する達成基準を報告し、一部だけチェックしたものはそう示します。1つのタグセットまたは名前付きのプロファイルで、どのWCAGバージョンについても適合レベル（A、AA、AAA）を指定できます。報告の基準がEN 301 549であれば、各結果を、その達成基準を再掲するEN 301 549の条項に対応付けられます。そして本当に重要な問いにまっすぐ答えます。この種の自動化された結果から何がわかり、どこまでしかわからないのか。WCAG適合性との対応を参照してください。

ベースライン／許可リスト

完璧ではない既存サイトの初回スキャンで、以後のビルドがすべて止まるのを避けられます。既知の違反を一度記録し、本当に新しい違反だけでCIを失敗させます。「完璧になるまで何もリリースできない」と「今日からリグレッションを検出できる」の違いであり、チームが実際にゲートを有効にできるのはこの仕組みがあるからです。不適合の可能性が高い検出結果も受け入れられ、アップグレード前に書いたベースラインは、検出結果の理由コードが分割されたり新たに付いたりしても、1つのマイナーリリースの間は引き続き一致します。ベースライン／許可リストを参照してください。