アクセシビリティテストをレベルアップさせた方法

アクセシビリティの取り組みの初期段階では、アクセシビリティテストを一般的に 2 つのカテゴリに分類していました。自動テストと手動テストです。 前者は、アルゴリズムで検出可能な簡単な問題をすばやく見つけるためのもので、後者は、見つけるのにより多くの時間と注意が必要なその他すべての問題に対応するためのものです。 自動テストは、継続的インテグレーション (CI) などの迅速なプロセスに適していましたが、手動テストでは、自動ツールでは対応できないすべての項目をカバーするために、熟練したテスターとの慎重な調整が必要でした。

その過程で、この 2 つのアプローチの間に絶妙なポイントがあることがわかりました。 Assistiv Labs とのパートナーシップにより、より優れたプロセスとエンドツーエンドのサービステストを組み合わせ、自動化と手作業を再定義するテストワークフローを実現しました。 これは、自動化によるカバレッジを劇的に向上させ、手作業による調整のオーバーヘッドを削減する、両者を組み合わせたハイブリッド型のアプローチです。

今では、明確で簡単に修正できる問題を、数週間ではなく数時間で見つけることができます。 新しいプロセスでは、緊急の問題が自動的に特定され、適切なチームに送信されます。通常、チームは数日以内に問題を解決します。

技術的にも、文化的にも成果が得られています。 アクセシビリティに関するフィードバックの提供がはるかに迅速になり、チームはバグをより早く解決できるようになり、Asana 全体のエンジニアはアクセシビリティの問題についてこれまでとは異なる視点で考えるようになりました。

アクセシビリティのバグに優先順位を付けるプロセスの構築

Asana のような規模の組織では、プロセスとガバナンスの原則に支えられた強力な優先順位付けフレームワークが不可欠です。 チームは、バックログに何をいつスケジュールする必要があるか、そして今すぐ対応が必要なことは何かを把握する必要があります。

しかし、アクセシビリティのバグに優先順位を付けることがいかに難しいかを過小評価しがちです。 優先順位は、支援技術、ブラウザ、影響を受けるユーザーグループ、ユーザーフィードバック、製品エリア、修正の難易度、回避策、WCAG 適合性、過去の背景など、さまざまな固有の要因に基づいています。 長い間存在していたものの、最近になって初めて検出されたバグもあります。 新機能のリリースとともに発生するものもあります。 また、以前はアクセシビリティ対応だった機能が、現在は対応していないという「レグレッション」もあります。

フレームワークを作成するために、アクセシビリティバグの種類を正式に定義し、それぞれに合わせて合理化されたワークフローを設計できるようにしました。 重要なステップは、リグレッションとそうでないものの区別を定義することでした。

リグレッション (n)

文書化されており (以前のバグ、コメントスレッド、スクリーンショット、画面録画など、これが機能していたという記録はあるか？)、再現可能であり (同僚は記載されている手順を使用して再現できるか？)、以前は機能していたが、現在は機能しない問題。

当然ながら、アクセシビリティの低下は誰も望まないため、リグレッションは優先度が高くなる可能性があります。 これにより、多くの場合、優先順位付けが大幅に簡素化されます。

しかし、問題もあります。 リグレッションは、前後のスナップショットによって定義されます。 たとえば、機能が正常に動作している状態の動画を「前」のスナップショットとし、新たな問題が発生した状態の動画を「後」のスナップショットとすることができます。 バグには当然、アフターのスナップショットがあります。 しかし、「前」のスナップショットを見つけるには、通常、徹底的な調査が必要です。

信頼できる「前」のスナップショットの情報源がなければ、バグをリグレッションとして優先すべきかどうかを調査する時間を割く価値がないことが多かったのです。 そこで、新しいタイプのオートメーションが非常に役に立つことが判明しました。

エンドツーエンドのアクセシビリティオートメーション

完全に自動化されたテストは、アクセシビリティテストにとっても、Asana にとっても新しいものではありません。 従来、axe DevTools と React 用の jsx-a11y は、幅広く水平なカバレッジを提供してくれていました。 しかし、これらのツールは浅いものです。 業界全体の自動テストに関するトークン 30% の推定値は、私たちが達成していた WCAG 基準にかなり近いと感じました。 カバレッジが限られているため、自動化ツールが見落としたバグは、依然として手動テストで見つかっていました。

私たちには、より深く掘り下げることができるツールが必要でした。 当社のユーザーリサーチとガバナンスの原則により密接に関連するツール。 それが Assistiv で見つかったものです。 Assistiv のエンドツーエンドサービスのテストは、当社が提供するユーザーフローとテストパラメーターに基づいて、Assistiv のエンジニアによってゼロから作成されています。 このスイートには、キーボードショートカット、実際のスクリーンリーダー、ブラウザー、Assistiv Labs クラウドを搭載したマシンビジョンが組み込まれています。 その結果、単なるシミュレーションではなく、人間のユーザーと同じ方法でイベントがマシンに送信され、WCAG のカバレッジとより広範なアクセシビリティの懸念事項が最大限にカバーされます。

エンドツーエンドのアクセシビリティオートメーションは、従来のオートメーションとは根本的に異なり、手動テスターと同じ方法で Asana と連携してタスクを達成します。 テストシナリオに応じて、WCAG 基準の最大 75% をカバーすることが可能です。 そして、クリティカルシンキングの専門家が、すべてをリアルタイムで監視しています。 Asana と Assistiv の両社のスタッフが、代表的なユーザーアクションの設計と結果のレビューに携わり、自動テストの範囲、頻度、精度を大幅に向上させています。

力を合わせる

しっかりとした優先順位付けフレームワークと、少数のバグを見つけるのではなく、大多数のバグを見つけるようになった新しいオートメーションにより、強力な優先順位付けワークフローを実装しました。

まず、自動化されたテストは Asana の既存のエンジニアリングパイプラインと同期されます。 新しい問題はほぼリアルタイムで検出され、その原因と考えられるコードの変更と関連付けられます。

次に、Assistiv のエンジニアがレビューを行い、誤検出を除外し、Asana のバックログに、ユーザーへの影響と是正ガイダンスを文脈に沿って記載した課題を作成します。 自動化されたテストは継続的に実行されているため、変更前のスナップショットをすぐに入手でき、リグレッションを簡単に分類できます。 問題を適切なチームに割り当てる Asana の自動ワークフローを維持しています。

具体的には、通常、展開から 24 時間以内にリグレッションが報告され、アクセシビリティの経験のないエンジニアでも理解しやすい形で文書化されます。 これにより、アクセシビリティチームは、リグレッションに対処するための SLA を設定し、製品チームに任せることができます。 どのリグレッションを最初に、2 番目に、または最後に対応するかを誰かが決定する必要はありません。 要注意なバグであることに変わりはありません。

この分散化は、より持続可能なプログラムと、よりインクルーシブなエンドユーザーエクスペリエンスに直接つながります。 常にトラブル対応に追われることがないため、自主性やインパクトがはるかに高まり、クリエイティブな仕事をする余裕が生まれます。 その結果、私たちはより満足度が高く、より効果的に働けるようになります。

フィードバックループの高速化によって得られたもの

数週間または数か月間発見されないバグは、修正にコストがかかります。 誰かが適切なチームにトリアージし、優先順位が設定されていることを確認する必要があります。 割り当てられたエンジニアは、そのバグを引き起こしたエンジニアと同じ人物ではない可能性が高いでしょう。 同じエンジニアであっても、忘れ去られた背景を掘り起こしたり、方向転換したり、他のチームと連携してその間の数週間や数か月で生じた技術的な負債を解消したりするのは困難です。

この問題を数字で表すと、高い引用数を誇るIBMの調査によると、本番環境でバグを発見する場合、デザイン段階で発見する場合に比べて30倍のコストがかかることがわかりました。 それはもっともなことです。

エンジニアが午前中にアップデートをデプロイすると、通常はその日の終わりまでにリグレッションの兆候が現れ始めます。 フィードバックループが非常に短いため、スクリーンリーダーやキーボードナビゲーションに限らず、一般的な UI バグについて、エンドツーエンドテストが最初に警告を発することが何度もありました。

エンジニアがエンドツーエンドテストからより迅速なフィードバックを受け取り始めたことで、優先順位付けに伴う認知的オーバーヘッドが軽減されたことに気づきました。 曖昧さが解消されたのです。 エンジニアは「今朝リリースしたので、この責任は自分にある。 昨日までは動作していたのに、今日は動作しない。今すぐ修正する必要がある。」 アクセシビリティのバグを修正することは、筋肉の記憶のようになるのです。

Asana では、アクセシビリティのバグは単なるバグです。 そして修正されます。

アクセシビリティを自動化するためのよりよい方法

エンドツーエンドのアクセシビリティテストを導入する前から、Asana のアクセシビリティチームは大きな進歩を遂げていました。 オペレーション面では、デザインチームとエンジニアリングチームがレビュープロセス、レグレッションの定義、SLA を文書化していました。 テストに関しては、迅速ではあるが浅いレポートを作成するための自動化されたソリューションと、徹底的ではあるが時間のかかる監査を行うための手動 QA がありました。

エンドツーエンドのテストでは、既存の取り組みを補完し、その上に位置する技術的なソ��ューションを利用しています。 リグレッションは、より早く、より詳細に、より多くの証拠とともに文書化されています。 実質的に、アクションにつながらないバグレポートや再現不可能なバグレポートに時間を浪費する人は誰もいません。

新しいバグと古いバグ、影響を受けるユーザーフロー、修正の担当者を明確に把握できるようになりました。 私たちは時代の先を行き、将来の Asana のアクセシビリティに関するビジョンに集中することができます。

著者について:  Cameron Cundiff (テクニカルリード) と Jiaxin Zheng (テクニカルプログラムマネージャー) は、どちらも開発ライフサイクルグループのメンバーです。このグループは、デベロッパーがアイデアを迅速に、堅牢に、そして楽しく本番環境に反映させるためのツールを提供することに専念しています。