ユーザー中心設計におけるアクセシビリティ: ユーザビリティ・テストの準備

「アクセシビリティの評価」のページでは、標準のレビュー、ヒューリスティック評価、設計ウォークスルー、および障害のあるユーザーによる非公式の評価を含め、アクセシビリティを一般的な評価方法に含めるためのガイダンスを示しています。ユーザビリティ・テストのセクションは、障害者が参加するユーザビリティ・テストの概要です。

ユーザビリティ・テストの準備に障害者を参加させる場合、次のことを考慮する必要があります。

アクセシブルな場所の確保
テスト資料の作成
参加者のシステム構成のセットアップとテスト
支援技術に慣れる
パイロットテストの実施

アクセシブルな場所の確保

ユーザビリティ・テストを行う施設は、参加者にとってアクセシブルなものにしてください。参加者によって、ビル、テストルーム、トイレへのアクセス、サイドに車椅子リフトを備えたバンの駐車スペース、テストルームで通訳が最適な位置につけるためのスペースの確保などをチェックしてください。見落としがないように、下記の点を考慮してください。

チェックリストを使用して、潜在的な障壁を予測してください。「補遺: 参考文献」の「障害者との対話」セクションでは、テストルームを使いやすくするためのチェックリストを示しています。
似たようなアクセシビリティのニーズのある人とのウォークスルーをスケジュールしてください。たとえば、参加者基準を満たさなかったため、参加者のリクルートから外れた人に協力をお願いしてください。

必要に応じて、車椅子、支援技術、通訳、個人的な付添い人、盲導犬などのための十分なスペースを提供してください。室内の配置を変更できるように、モジュラーテーブルを使用することも考慮してください。

テスト資料の作成

ユーザビリティ・テスト資料は、わかりやすく簡潔な表現で書いてください。これは、情報や指示を処理することが難しい一部の認知障害のある参加者の場合に特に重要です。

すべての資料を代替フォーマットで提供する準備を行うようにしてください。資料の中には、施設への行き方、同意書、放映承諾書、機密保持契約書、参加者に対する指示、およびユーザビリティ・テストにおいて記入すべきタスクなどが含まれます。代替フォーマットとして次のものが挙げられます。

大文字印刷
点字
電子形式(HTML、プレーンテキスト、その他のフォーマット; eメール、CDなど)
音声(読み上げ、電子ファイル、カセットテープ)

障害者の中には、PDFフォーマットを好まない人がいることに注意してください。スクリーン・リーダーのユーザーにとってのPDFドキュメントのアクセシビリティを高める方法があります。ロービジョンの人は、フォントを大きくしたり、PDFドキュメントを印刷したりすることができません。したがって、ユーザーの好きなフォントおよびフォントサイズにあらかじめ設定されたPDFドキュメントを提供するか、あるいはユーザーが自分でフォントを設定できるフォーマットでドキュメントを提供する必要があります。

必要であれば、ドキュメントを「点字化」する時間を計画に入れてください。別の資料として点字化を行っている場合は、間際のテスト資料変更はできないことを念頭に置いてください。点字ページにはラベルを付けてください(一緒にしてしまうと、自分で点字が読める場合は別として、整理できなくなります)。

目の見えない人で点字を読める人は、ほんの一部です。生まれつき目が見えない人が点字を学ぶことは多いのですが、後で目が見えなくなった人のほとんどは点字を学んでいません。

参加者のリクルート条件に代替フォーマットの質問を含めてください。リクルート活動において参加者に尋ねるべき代替フォーマットに関する質問は、「参加者のリクルート条件」のセクションに示しています。

同意書およびその他のドキュメントを事前に余裕を持って送付してください。同意書、機密保持契約書、およびその他のドキュメントをテスト前に参加者へ送付することで、参加者は、自分の環境で、自分の支援技術を使用して、自分のペースでドキュメントを読むことができます。人によってはドキュメントを読むのに長い時間がかかるため、事前に送付しておけば、スケジュール作成が楽になります。タスクなど一部の資料は事前に送付できませんが、参加者が好むフォーマットで提供できることを参加者に説明してください。

通訳や付添い人のために、同意書およびその他のドキュメントを提供してください。ほとんどの場合、実際のテストにおいて参加者に同伴する手話通訳、個人的な付添い人、その他の人が、同意書、機密保持契約書、その他のドキュメントに署名する必要があります。

資料を事前に通訳へ送付しておいてください。手話通訳は、何を伝えたいか大まかな筋書きがあるだけで、準備がよく整います。細かい翻訳が重要である正式なテストの場合、通訳と一緒に正確な意味を話し合うためのちょっとした時間をスケジュールに入れることも検討してください。

参加者により異なるフォーマットのテスト資料

ほとんどすべてのユーザビリティ・テストでは、参加者が異なるフォーマットのテスト資料を使用しても問題ありません。たとえば、タスクを自分で読んでもいいですし、誰かに読んでもらってもかまいません。1人の参加者がタスクを読んでもらっているからという理由だけで、進行役が、タスクをすべての参加者に読まなければならないことは意味しません。各参加者にとって最良となるフォーマットでタスクおよびその他テスト資料を提供してください。

参加者のシステム構成のセットアップとテスト

「ユーザビリティ・テストの計画」のセクションの「支援技術の必要性の考慮」で述べたように、必要なシステム構成を提供することは複雑となる場合があります。ソフトウェアやWebベースの製品をテストする場合、参加者は、バージョンも構成も異なる支援技術を必要とすることがあります。支援技術を使用しない人は、大きなフォントや配色など、異なるシステム設定を使用している可能性があります。

本書の後半の「参加者のリクルート条件」では、参加者がどの支援技術を使用しているかに関する基本的な質問を示しています。支援技術をセットアップし、テストするためには、参加者の支援技術、構成、および設定に関する具体的な情報を手に入れる必要があります。

「ああ……それは私が使い慣れている支援技術ではありません」という言葉を聞くと、私は恐怖で背筋が寒くなります。われわれは、適切なATだけでなく、ATの適切なバージョンも用意するように必ずチェックしています。たとえば、JAWS 4.51とJAWS 6では非常に大きな違いがあります。

ユーザビリティ・テストを始める前に、十分余裕を持って、参加者のシステム構成に合わせて支援技術を入手し、セットアップし、テストしてください。早めに始めることで、ソフトウェアの旧バージョンを入手したり、異なるシステム構成を1台のコンピュータで稼動させたり、あるいは異なるシステム構成が1台のコンピュータで稼動しないため参加者の連続したスケジューリングのために複数のコンピュータを使用すること、複雑な問題に取り組む時間を確保することができます。

支援技術に慣れる

参加者がユーザビリティ・テストにおいて支援技術(AT)を使用する場合、進行役が多少そのATに慣れていれば、より効果的になります。多少慣れていないと、進行役は、参加者、AT、そしてテスト対象の製品のやり取りを理解できない可能性があります(また、ATの新しさにばかり気を取られてしまうかもしれません)。テストで使用するATにある程度慣れた人に参加してもらうことで、ユーザビリティ・テストの立会人、データ分析者などにとって有益な結果が出ます。

支援技術の使用を適切な形で経験してください。ATに関しては、下記の方法で、さまざまなレベルで体験することができます。

ATに関する文献を読み、ビデオを見ること。「補遺: 参考文献」の「障害者によるコンピュータの使用方法を理解する」では、インターネットで入手できる多くの無料の参考文献を挙げています。
経験豊富なATトレーナー、あるいは支援技術を定期的に使用している人(たとえば、参加者基準を満たさなかったため、参加者のリクルートから外れた人)に、ATを紹介してもらい、デモンストレーションを行うこと。可能であれば、テストで使用する製品と似た製品でATを使用してもらってください。
支援技術を用いて製品を使用する練習をすること。
ATに多少慣れた後、ATを定期的に使用するユーザーに、質問に答えてもらい、ATが製品でどのように使用されているかを学ぶこと。

パイロットテストの実施

パイロットテストは、障害者がテストに参加する場合特に重要です。うまく行かないことが多かったり、支援技術に伴う問題など、テストの設計者や進行役が初めて知ることがたくさんあったりするからです。

パイロットテストを早めに実施してください。障害者参加のユーザビリティ・テストを実施するのが初めての場合、また正式なテストを計画している場合は、問題を発見するための十分な時間を確保できるように、プロジェクトのかなり前に、少なくとも数回のパイロットテストを実施してください。リクルート活動において十分な参加者を集めることができない場合は、参加者基準をすべて満たさない人を参加させることもできます。

先に述べたように、パイロットテストは、リクルート活動の補助手段として使用することができます。というのは、障害のある人が参加して素晴らしい体験をした場合、他の人に伝える傾向が強いからです。また、タイミングを計るためにもパイロットテストを使うことができます。

パイロットテストを使用して、支援技術に伴う問題を発見してください。支援技術は、システム構成が異なると異なる動きをし、ユーザーの使用方法も大きく異なります。また、支援技術は、データ収集において調節が必要な場合もあります。たとえば、画面記録ソフトウェアの中には、一部の支援技術と衝突するものがあります。

パイロットテストを使用して、ロジスティックスを理解してください。パイロットテストを行うことにより、テストの参加者にとっての予期しない障壁や困難な点を発見することができます。たとえば、パイロットテストにおいて、視覚に頼らずにテストルームまでの行き先の指示を改善できること、盲導犬が室外に出るためのふさわしい場所を探すこと、あるいはテストルームまでのメインの通路に車椅子では通れない場所があることに気付かなかったことが発見できるかもしれません。

パイロットテストを使って、進行を理解してください。進行、観察、およびデータの記録を調整する必要があるかもしれません。たとえば、耳の聞こえない参加者がいる場合、通訳にマイクを使わせる必要があります。また、スクリーン・リーダーを使用する参加者がいる場合、音声を記録したいでしょう。

画面拡大表示を使用している参加者でテストを行っている間、一部の観察者は、動画を見て気分が悪くなり、テストの最後まで立ち会うことができませんでした。われわれは、注意を配るための観察者がさらに必要であることを学びました。

次の「ユーザビリティ・テストの実施」のセクションでは、実際のテストセッションで何を行うべきことに関してガイダンスを示しています。