適切なAxe DevTools Linterのセットアップを選ぶ

Axe DevTools Linterは多くの方法で使用でき、適切な組み合わせはチームがコードを書く、レビューする、リリースする方法に依存します。このガイドは主な選択肢を紹介し、自分の状況に合ったセットアップを選ぶ手助けをします。ほとんどのチームは、たった一つを選ぶのではなく、これらのオプションをいくつか組み合わせています。

決定は四つの領域に分類されます：

1. 分析を実行する場所（ファイルをローカルでリンティングするかサーバー上で行うか、そのサーバーの展開モデルはどれか）
2. ワークフロー内でリンティングが行われる場所（IDE、プレスコミットフック、CI/CD）
3. コンポーネントライブラリを構成する必要があるかどうか
4. 他の統合をいつ追加するか 例えばSonarQube

1. 分析を実行する場所を選ぶ

ここでは二つの関連する選択肢があります：ファイルが自分のマシン上で分析されるか、サーバーに送信されるか、そしてサーバーが関与する場合、どのタイプのサーバーがそれをホストするかです。

ローカルまたはサーバーベースのリンティング

ファイルがどこで分析され、その内容がマシンを離れるかどうかは、統合に依存します。以下の三つの統合ファミリーはそれぞれ異なる動作をします：

• IDE統合は常にローカルでリンティングを行います。 VS Code 拡張機能 と JetBrains プラグイン は、バンドルコンポーネントを使用して自分自身のマシン上でファイルを分析し、ファイルの内容がコンピュータを離れることはありません。これらはリンティングにAPIキーやライセンスキーを必要としません。
• コネクタはどちらの方法でもリンティングが可能です。 デフォルトでは、コネクタ はファイルをAxe DevTools Linterサーバーに送信しますが、その--local オプション がファイルをマシン上で分析し、内容がマシンを離れることはありません。ほとんどのケースでDequeはローカルリンティングを推奨します：それは大幅に速く、多数のファイルをリンティングする際に特にネットワーク問題に悩まされることが少ない。どちらの方法でリンティングするにせよ、コネクタは認証し、詳細はコネクタ認証 を参照してください。
• GitHub アクションは常にサーバーベースです。 GitHub アクション は変更されたファイルをAxe DevTools Linterサーバーに送信して分析します。ローカルリンティングモードはないため、このオプションでは必ずファイルの内容がサーバーに送信されます。

コネクタ認証

コネクタを使用する際、ローカルであれサーバーであれ、二つのクレデンシャルのいずれかで認証します：

• APIキー（--api-key オプション）：APIキーは自分のAxeアカウントの一環として自分で管理します。コネクタはキーを検証し、使用状況（リンティングされたコード行数）を報告するためにリモートサーバーに連絡します。これはローカルでリンティングする際でも行われます。
• ライセンスキー（--license-key オプション）：Dequeのヘルプデスク からライセンスキーを取得します。これはネットワーク活動を伴わず認証を行い、使用状況を追跡しないので、隔離ネットワークや厳しいアウトバウンドルールを持つ環境には最適です。これはローカルリンティングでのみ利用可能です。

これにより、コネクタは三つの方法で実行できます：

IDE統合にはリンティングに資格情報は不要です。GitHub ActionはAPIキーで認証し、そのセットアップガイドはSaaSとオンプレミスサーバーの両方のワークフローをカバーします。

サーバーデプロイメントモデル

サーバーに対してリンティングを行う場合や、ローカルでリンティングを行う際にAPIキーで認証する場合、どの種類のサーバーがAxe DevTools Linterをホストするかを選択します。これにより、セットアップの労力、ファイルがネットワーク外に出るかどうか、認証方法が影響を受けます。

SaaSを選択すると、最も迅速にスタートでき、インフラの維持が不要です。オンプレミスを選択すると、ポリシーによりソースコードをネットワーク内に留める必要がある場合や、サーバーを完全に制御したい場合に適しています。プライベートクラウドを選択すると、サーバーを自身で運用することなく、Dequeが管理する専用インスタンスを使用できます。

2. ワークフロー内でリンティングの場所を選択する

アクセシビリティのフィードバックは、早期かつ頻繁に受け取るのが最も有効です。以下の統合は開発ライフサイクルの異なるポイントで適用され、組み合わせると効果的です。入力中、コミット前、プルリクエストで問題をキャッチします。

一般的で層のあるアプローチは次のとおりです。

1. IDE拡張ことで、開発者はコードを書く際にすぐに問題を確認できます。
2. プリコミットフックまたはGitHub Actionをゲートとして設定し、問題がコードレビュー前または中に捕捉されるようにします。
3. コネクタはCI/CD内で使用され、全コードベースのチェックを強制し、他のシステムに情報を提供します。

すべてのレイヤーを一度に採用する必要はありません。チームは通常、まずIDE拡張から始め、チーム全体で標準を施行する準備が整ったらプルリクエストチェックを追加します。

3. コンポーネントライブラリを設定するかどうかを決定

デフォルトでは、Axe DevTools Linterは標準のHTML要素とフレームワークマークアップをチェックします。コードでカスタムコンポーネント（例えば、<custom-image>が<img>をレンダリングする場合）を使用する場合、各コンポーネントが標準の要素にどうマッピングされるかを教えるまで、リンターはアクセシビリティをチェックできません。

コンポーネントのリンティングを設定するべき場合：

• コードベースがデザインシステムまたはカスタムコンポーネントライブラリに依存している場合、および
• それらのコンポーネント内部のアクセシビリティ問題を指摘したい場合。

2つの方法があります：

• 事前設定済みコンポーネントライブラリ: Cauldron React、Material UI（@mui/material）、React Nativeを使用している場合は、サポートが組み込まれています。事前設定済みコンポーネントライブラリをご覧ください。
• カスタムマッピング: 独自のコンポーネントの場合、設定でマッピングを作成してください。カスタムコンポーネントのリンティングで概要を確認し、その後、VS CodeとJetBrainsまたはRESTエンドポイントのウォークスルーをご覧ください。

設定オプションはIDE統合、コネクタ、REST APIに共通であり、Axe DevTools Linterの設定に記載されています。

4. その他の統合を追加する時期を決定

ステップ2の統合はほとんどのチームのニーズをカバーしています。既に使用しているツールに合う場合は、次の追加統合を検討してください：

これらの統合はすべてコネクタに基づいており、各システムが消費するリント結果を生成します。一般的なルールとしては、それ自体のために新しいツールを追加するのではなく、チームが既に依存しているツールにアクセシビリティの所見を表示できる場合に別の統合を追加することです。

総合

SaaSを利用するチームの典型的なセットアップは次のようなものです：

• VS Code拡張（またはJetBrainsプラグイン）はすべての開発者のために、コーディング中のフィードバックを提供します。
• GitHub Actionはプルリクエストに付き、コードレビュー中にアクセシビリティ問題が表示されます。
• カスタムコンポーネントマッピングはチームがデザインシステムを使用している場合。
• チームがすでにそこにコード品質を集中させている場合のみ、SonarQubeを統合します。

より厳しいデータ処理要件を持つチームは、SaaSをオンプレミスの導入に置き換え、CI/CDパイプラインでコネクタを--localと共に使用し、ソースコードがネットワーク外に出ないようにすることがあります。

どの組み合わせがあなたの状況に適しているかわからない場合は、Dequeのヘルプデスクに連絡してください。