CI/CD 開発ライフサイクルにおける自動および手動のアクセシビリティ テスト

年に 1 回だけ、1 回限りの手動レビューでチェックされるアクセシビリティは、ほとんどの場合すぐに損なわれます。コードの小さな更新によって、すでに修正されていたものが壊れる可能性があります。解決策: アクセシビリティ テストを自動化されたステップとして開発プロセス自体 (CI/CD) に組み込むことで、問題が本番環境に到達する前に検出されます。この記事ではその方法を説明します。

1 回限りのチェックでは不十分な理由

毎週、場合によっては毎日アップデートを配布する開発チームは、継続的なコンプライアンスを維持するために年次のアクセシビリティ監査に依存することはできません。アクセシビリティを考慮せずに追加された新しいコンポーネントや、誤ってコントラストを下げる CSS の変更により、すでに修正されていたアクセシビリティが損なわれる可能性があります。ユーザーや苦情によって明らかにされるまで、誰も気づきません。同じ原則がドキュメントにも当てはまります - に関するガイドを参照してください。マッピングの一般的なエラー.

CI/CD パイプラインの自動ツールがキャッチできるもの

axe-core、Pa11y、Lighthouse CI などのツールは、プル リクエストごと、またはデプロイ前に自動的に実行できます。色のコントラスト、不正または重複した ARIA タグ、代替テキストの欠落、フォーム ラベルの欠落、見出しの順序の誤りなどを数秒以内にチェックします。チェックが失敗した場合、通常のコード レビューや単体テストの失敗と同様に、プル リクエストのマージは自動的にブロックされます。

手動テストが依然として必要な場合

ドキュメント テストと同様に、CI/CD パイプラインの自動ツールは明確な構造上の問題を捉えますが、実際のユーザー エクスペリエンスを判断することはできません。キーボード ナビゲーションが意味をなすかどうか、スクリーン リーダーがページ上で「一貫したストーリーを伝える」かどうか、カスタム コンポーネント (カルーセルやモーダルなど) が実際の使用で本当に使用できるかどうかなどです。だからこそ、継続的な自動チェックと定期的な手動監査 (たとえば、四半期ごと) を組み合わせる価値があります。

実際に実装する方法

1. テクノロジー スタックに適合するテスト ツールを選択してください (ほとんどの JavaScript プロジェクトの場合は axe-core、ブラウザベースのプロジェクトの場合は Lighthouse CI)。
2. これを CI パイプラインのステップとして実行します。通常は、GitHub アクション、GitLab CI ジョブ、または使用する CI/CD ツールの同等のステップとして実行します。
3. チェックがブロッカーになる前に、明確な障害しきい値を設定します (例: 軸コアごとに「クリティカル」レベルの問題がない)。
4. PDF ファイルもカバーします。組織でドキュメント (請求書、レポート) が自動的に生成される場合は、公開プロセスの一環として、それらのドキュメントにも自動スキャンを追加することを検討してください。