障害のある人とのテストでわかること、監査ではわからないこと

適合性の試験とユーザビリティテストは、別々の問いに答えます。片方の答えで、もう片方の問いには答えられません。

W3Cの「Involving Users in Evaluating Web Accessibility」は、障害のある人や高齢の人とテストすると、適合性の評価だけでは見つからないユーザビリティの問題が見つかると書いています。同時に、利用者に関わってもらうだけではWebサイトがアクセシブルかどうかは判断できないとし、WCAGへの適合性の評価と組み合わせるよう勧めています。適合性の試験の方法であるWCAG-EMも、利用者とのテストを必須とはしていませんが、幅広い能力の人に関わってもらうことを強く勧めています。

アクセシビリティの問題を探るユーザビリティテストは、一般的なテストとは進め方が違います。W3Cによると、進行役が積極的に関わりながら考えていることを声に出してもらう方法をとることが多く、集めるデータも、かかった時間や満足度より、アクセシビリティの障壁による間違いが中心になります。タスクも、障壁がありそうな部分に絞ります。また、障害の有無にかかわらず、すべての利用者に関わる問題も見つかりやすくなります。

WCAG 2.2はイントロダクションで、このガイドラインは「障害のあらゆる種類、程度及び組合せからくるニーズを満たすことはできない」とし、AAAに適合したコンテンツでさえ「特に認知、言語及び学習の分野において」すべての人にアクセシブルではないと述べています。レベルAAを満たすページでも、次のようなことが起こります。

この隙間を埋めるためにW3Cが用意しているのが補足ガイダンスで、「WCAGを満たすためには必要ないが、アクセシビリティを高める追加の方法」と位置づけられています。認知のアクセシビリティのガイダンスは、ワーキンググループノート「Making Content Usable for People with Cognitive and Learning Disabilities」（2021年4月29日）をもとにしたもので、次の8つの目的に分かれています。

• 何がどういうもので、どう使うのかを分かるようにする
• 必要なものを見つけられるようにする
• 明確で分かりやすいコンテンツにする
• 間違いを防ぎ、直し方が分かるようにする
• 集中できるようにする
• 記憶に頼らないプロセスにする
• 手助けとサポートを用意する
• 利用者に合わせた調整や個人設定に対応する

このノートは、これに従うことは「WCAGへの適合には必要ない」とはっきり書いたうえで、認知障害や学習障害のある人に内容やデザインが使えるかを知るには、ユーザビリティテストがいちばんの方法だとしています。自動テストではこうした人が使えるかどうかを判断できないことが多いため、自動テストだけに頼らないようにとも注意しています。

W3Cは、プロジェクトの最後だけでなく、最初から利用者に関わってもらうよう勧めています。開発の途中で何度も簡単な評価を行うほうが、最後に正式なユーザビリティテストを一度だけ行うより効果的だという考えです。利用者の関わり方を扱う2つのページは、段階ごとに次のような役割を挙げています。

• **調査：**障害のある人がWebをどう使っているかを学び、さまざまな特性の人を探します。自社と似た製品のうち、うまく使えるものと使えないものを実際に見せてもらいます。ユースケース、ペルソナ、シナリオ、作業の流れにも、障害のある人や高齢の人を含めます。
• **設計：**開閉するナビゲーションのような設計上の選択に迷ったら、すでにそれを採用している製品を探し、どこがうまくいき、どこがいかないかを利用者と一緒に確かめます。デザインのウォークスルーにも参加してもらいます。
• **プロトタイプ：**プロトタイプで具体的なタスクを試してもらいます。認知のアクセシビリティのノートは、ワイヤーフレーム、画面のラフスケッチ、テンプレートのページでテストすれば、問題を早く見つけられると付け加えています。
• **公開前：**決まった手順に沿う正式なユーザビリティテストで、利用者を代表する人に具体的なタスクを行ってもらいます。

W3Cは、セッションの前にアクセシビリティに詳しい人が一通り確認し、分かっている障壁を先に直して、問題がありそうな部分にセッションを絞るよう勧めています。監査で見つかるはずのラベルの抜けにセッションを使っても、監査以上のことはほとんど分かりません。認知のアクセシビリティのノートは、認知障害や学習障害のある人を、設計・開発チームそのものに加えることも求めています。

W3Cは、障害のある人もほかの人と同じように多様だと強調しています。障害の種類はさまざまで、複数の障害がある人もいて、同じ種類の中でも差が大きいからです。視覚障害だけでも、生まれつき全盲の人から、けがで一時的に視界がぼやけている人まで含まれます。認知のアクセシビリティのノートは、一つのグループだけでは足りない理由も例で示しています。文字を減らして数字を増やした内容は、自閉症やディスレクシアのある人の一部には合っても、ディスカリキュリア（算数障害）のある人には使えなくなります。そのため、記憶、注意、学習、数の処理、言語とコミュニケーション、知的機能に障害のある人を含めるよう勧めています。

障害の種類と同じくらい大事なのが、支援技術にどれだけ慣れているかです。初心者、中級者、上級者のだれに参加してもらうかは、サイトを使う人によって決まります。W3Cの例では、社内の経理担当者向けのWebアプリケーションなら上級者を、障害給付を申請する公共のサイトなら初心者を選びます。経験が少なすぎると支援技術を十分に使えないことがあり、熟練した人は普通の利用者には使えない回避策を知っていることがあります。チームがまだ障害のある人のWebの使い方を学んでいる初期の段階では、経験が比較的豊富な人が向いているとしています。

参加者の集め方と接し方について、資料は次のように述べています。

• **募集：**障害者団体や当事者の会、SNSのグループ、チームの知り合い、社内で支援技術や配慮の手配をしている部署などを通じて呼びかけます。当事者のピアリサーチャーと一緒に進めるプロジェクトもあります。障害のある参加者の募集を専門にする団体もあります。
• **謝礼：**ほかの参加者と同じように、相手の時間を尊重し、適切な謝礼を支払います。
• **インフォームド・コンセント：**プロジェクトの目的、参加者がすること、あればリスク、集める個人情報とその使い道、いつでもやめられることを、参加者が理解している必要があります。分かりやすい同意書を使い、理解できたかを確かめ、後見人がいる場合はその人からも同意を得ます。
• **配慮：**静かな部屋や休憩など、必要な支援と、合うテストの方法を事前に聞いておきます。介助者や友人が同席してもかまいませんが、タスクを代わりに行ってはいけません。

そして、W3Cの2つのページがどちらも繰り返している注意があります。障害のある一人の意見を、障害のあるすべての人に当てはまるものと考えないことです。同じ障害のある人でも、ほかの人がWebをどう使っているかを知っているとは限らず、ほかの障害についてはあまり知らないこともあります。

タスクとは、人がサイトに来てしたいことを、画面の言葉ではなく利用者の言葉で伝えたものです。「座席表を使ってみてください」ではなく、「3月14日のコンサートで、隣り合った席を2枚買ってください」と伝えます。認知のアクセシビリティのノートも、質問に答えてもらうだけでなく、使えることが分かる操作を実際に行ってもらうよう求めています。タスクの中で機能の名前を出すと、行き先を教えることになり、自分でそこを見つけられたかどうかが分からなくなります。

タスクの間に記録するものとして、ノートは、終えられたタスクと間違い、タスクごとにかかった時間（絶対的な時間より、タスク同士の比較のほうが参考になる）、そのときの気持ちや発言を挙げています。テストが終わった時点で、何がタスクを妨げたか、何が混乱を招いたか、どこで間違いが起きたか、いつ参加者がいらだったか、それをどう防げるかを説明できるようにします。参加者には、間違えても参加者のせいではなく、試されているのはサイトのほうだと伝えておきます。

うまくいかなかったとき、原因になりうる場所をW3Cは次のように挙げています。

• ページのマークアップやコード
• ブラウザーやメディアプレーヤーの処理
• 参加者の支援技術の処理
• ブラウザー、プレーヤー、支援技術の機能を、参加者が知らないこと
• 障害の有無にかかわらず、だれにとっても使いにくいデザイン

サイト自体の問題といえるのは最初と最後だけです。この区別ができないテストでは、チームが見当違いの問題を追うことになります。報告書には、調査の範囲、方法、参加者の特性を書きます。W3Cの例では、全盲の参加者だけの調査なら、適合性は評価していないこと、障害のあるすべての人に当てはまるわけではないことを明記します。小規模な調査も役に立ちますが、統計的に有意な結果にはなりません。