設定

どのランナーも同じプレーンなengineOptionsオブジェクトを受け取ります。管理すべき設定ファイルも、同期し続けなければならないCLI専用のフラグ体系もありません。CLIと各バインディングは、それぞれのフラグやビルダーメソッドからこのオブジェクトを組み立てるだけなので、ここで学んだことはどこでスキャンを実行しても通用します。早い段階で押さえておきたいのは次の4点です。

エンジンオプション

WCAGのバージョンとレベルの指定（WCAG 2.2 AAを1つのオプションで。必要ならベストプラクティスも追加）、ID、タグ、またはWCAG 2.2 AA、Section 508といった適合性プロファイルの名前で、スキャン対象を必要なルールだけに絞れます。実行結果には、実際に責任を負う範囲だけが過不足なく出ます。コアのEN 301 549プロファイルは引き続き使えますが、非推奨です。この規格は現在パックとして提供されています。いくつかのチェックだけを実行しても、それらが属するWCAGの達成基準を、求められるレベルで得られ、スキャンが何を報告するかを実行前に一覧にできます。ノイズが多いと分かっているウィジェットは、全体でも特定のルールだけでも除外でき、それ以外のカバレッジは失われません。コントラストチェックの厳しさは、人間の監査担当者向けと無人のCIゲート向けで調整できます。カタログにない重要な項目があれば、組織独自のルールを組み込みルールと並べて追加できます。ページが読み取れない別オリジンのスタイルシートのCSSを、ルールに渡すこともできます。詳しくはエンジンオプションのリファレンスを参照してください。

パック

エンジンをフォークせずに、WCAG以外の基準でもテストできます。パックは、国の規格、組織のアクセシビリティ方針、あるいはいくつかの独自ルールを、それ自身のパッケージとして提供します。エンジンはそれを自身のルールと同じように実行します。パックのプロファイルが実行対象を選び、チェックリスト項目はそれぞれ1つの結果として返り、すべてのレポートでWCAGの達成基準と並んで表示されます。同じパックがNode、各バインディング、test-matchers、CLIのどこからでも動作し、npx surea11y-pack newは生成した時点で自身のテストに合格するパックを書き出します。規格はルールの検出結果をそれが属する要件に振り分けられ、パックのルールは自分が判定できずに残したものに人がどう答えるかを示せます。パックを使う方法と書く方法はパックを参照してください。

CI連携

アクセシビリティのゲートを一から書かずにパイプラインへ組み込めます。そのまま貼り付けられるGitHub ActionsとBitbucket Pipelinesのテンプレートが、CLIの終了コードでビルドを判定し、既存サイトにもともとある違反をベースラインとして記録して本当に新しい違反だけで失敗させ、SARIFの結果をチームが普段見ているGitHub Code Scanningへ直接アップロードします。GitLab CIとAzure DevOps向けのレシピでは、結果をJUnitとしてそれぞれのテストビューに表示できます。JUnitは同じステップでCLIが書き出します。JUnitレポートは、未判定のうち不合格寄りの検出結果を不合格にすることもできるため、不合格の可能性が高いものがスキップされたテストとして見過ごされません。テンプレートの全体はCI連携を参照してください。

ロケール

検出結果を、チームが最も速く読める言語で届けられます。ルールのタイトルと、各検出箇所の概要とヒントはすべてキーベースの辞書から解決され、訳がない文字列は空欄やエラーにならず、文字列ごとに英語へフォールバックします。現在エンジンに同梱している言語は5つ（英語、フランス語、ドイツ語、スペイン語、日本語）です。結果には使用したロケールが必ず記録されるため、気づかないうちに品質が落ちることはありません。未判定の検出結果に答えるための手順（「確認方法」）も、同じ5つの言語で提供されます。対応範囲と独自の辞書を渡す方法はロケールを参照してください。