Slackは最近、障害を持つ人々のユーザーエクスペリエンスを向上させるために、自社のソフトウェア開発ライフサイクルに自動アクセシビリティテストを統合した。
SlackのソフトウェアエンジニアであるNatalie Stormann氏は、Slackのエンジニアリングブログで、ウェブコンテンツアクセシビリティガイドライン（WCAG）を継続的に準拠していることを伝えた。
Slackには内部基準があり、さらに外部のアクセシビリティテスターとも協力している。これらの基準は、ウェブアクセシビリティのベンチマークとして国際的な基準であるWCAGと一致している。微妙なアクセシビリティの問題を特定するために手動テストが重要であることに変わりはないが、Slackは自動化によってこれらの取り組みを補強する必要性を認識していた。
2022年、Slackはアクセシビリティ違反に積極的に対処するため、開発ワークフローに自動テストを組み込み始めた。同社は、その柔軟性とWCAGとの整合性から、アクセシビリティテストツールとして広く使用されているAxeを選択した。AxeをSlackの既存のテストフレームワークに統合するには、いくつかの課題があった。AxeのチェックをReact Testing Library（RTL）とJestに直接埋め込むと競合が生じ、開発プロセスがさらに複雑になった。
Slackのアクセシビリティチームは、@axe-core/playwrightパッケージを介してAxeと互換性のあるテストフレームワークであるPlaywrightを使用することを想定していた。しかし、AxeチェックをPlaywrightのLocatorオブジェクトに統合することは、独自の課題をもたらした。これらの課題を克服するために、Slackはカスタマイズされたアプローチを採用し、コンテンツが完全にレンダリングされていることを確認するために、主要なユーザーインタラクションの後にPlaywrightテストでアクセシビリティチェックを戦略的に追加した。また、SlackはAxeのチェックをカスタマイズし、関連性のないルールをフィルタリングして、重要な違反に最初に焦点を当てた。チェックはPlaywrightのフィクスチャモデルに統合され、開発者にはテスト仕様内でチェックをトリガーするためのカスタム関数runAxeAndSaveViolationsが提供された。
Hacker News上の技術コミュニティはこのブログに注目した。アクセシビリティテストエンジンAxeのメンテナの一人で、HNのユーザー名dbjorgeがこの投稿にコメントしている。
私たちのチームの仕事を基にして人々がどのように構築しているのか、これほど詳細に書いていただけるのは素晴らしいことです。Slackの方々がどの機能を優先してセットアップしたのか、そして特にPlaywrightとの統合を深く追求することでできるようになったことのいくつかを見るのはとても勉強になります。「私たちはエンジニアリングに多くの時間を費やすほど＜機能＞を気にかけている」というような強いフィードバックを得られる幸運は、そうそうあるものではありません。
レポートを改善するために、SlackはPlaywrightのHTML Reporterとカスタマイズされたエラーメッセージを使用して、違反の詳細やスクリーンショットを含めた。彼らのテスト戦略には、重要な機能テストをミラーリングした非ブロッキングテストスイートが含まれており、冗長性を避けるためにアクセシビリティチェックが追加されている。開発者はテストをローカルで実行したり、定期的に実行するスケジュールを組んだり、継続的インテグレーション（CI）パイプラインに統合したりできる。アクセシビリティチームは、さらに開発者と協力して、Jiraワークフローを使用して自動化された違反のトリアージを行う。
定期的な監査によってカバレッジを確保し、重複チェックを防止しているが、Slackはこのプロセスを自動化するAI駆動のソリューションを模索している。
Slackは、今後も自動テストと手動テストのバランスを取り続けることを目指している。今後の計画としては、キーボードナビゲーションなどのコア機能のブロックテストを開発すること、AIを使ってテスト結果を洗練させ、アクセシビリティチェックの配置を自動化することなどがある。
作者について
