ウェブアクセシビリティ向上のためのインクルーシブデザイン

ウェブアクセシビリティに関連して、以前から インクルーシブデザイン (inclusive design) という手法に興味があります。

インクルーシブデザインとは、メインのターゲットユーザー想定から除外 (exclude) されてきた人々 (主に障害者) を、デザインプロセスに積極的に巻き込むこと (include) によって、ユニバーサルデザイン (UD) を推進しよう、というものです。

アセシビリティの定義 (ISO 9241-20) を、ユーザビリティの定義 (ISO-9241-11) と併せて読み解くと、「本当の意味でのアクセシビリティ」とは単に JIS X8341-3 や WCAG といった指針 (ガイドライン) に書かれている達成基準を満たすことではなく、ユーザーの最終的な目的達成までをも視野に入れる必要があることがわかります (参考記事 : 「アクセシビリティ」を「ユーザビリティ」との関係で考えてみる)。インクルーシブデザインを採り入れることは、「本当の意味でのアクセシビリティ」を実現するための有効な手段と言えそうです。

ウェブにおけるインクルーシブデザインとは

ウェブデザインの場合、UCD (User Centered Design : ユーザー中心設計) というプロセスが既に存在しています。これをベースに考えると、ウェブにおけるインクルーシブデザインとは、UCD プロセスの上流工程から、障害者にユーザーとして参加してもらうこと、と言えるでしょう。

この考えかたは以前からあって、「Just Ask : Integrating Accessibility Throughout Design」というサイトにノウハウがまとめられています (日本語訳もあります)。とても素晴らしい内容なので、ウェブアクセシビリティに関心がある人にはご一読をおすすめします。私自身、ここまできっちりやったことはありませんが、可能な機会があったらぜひやってみたいな...と思っています。

理想的だが難しそう

上記「Just Ask : Integrating Accessibility Throughout Design」に書かれている内容は素晴らしいと思う一方、インクルーシブデザインは理想的過ぎて、多くの組織やチームにとっては現実的に難しそう...と感じたのも事実です。基本的な UCD もままならないプロジェクトが多い中、ここまできちんとやらないとアクセシビリティは実現できない、と言ってしまうと、アクセシビリティの敷居をいたずらに高くしてしまう懸念もあります。

インクルーシブデザインが現実問題として難しいと感じたのは、主に以下の理由によります。

多くのサービスでは障害者をペルソナにしない

UCD の上流工程では、実際にユーザーを観察することを通じて、代表的なユーザー像とその行動を、ペルソナ、シナリオ (ストーリー) としてまとめ、プロジェクト関係者の間で共有することになります。サイトのビジネスゴールに応じた主要な顧客像がここに登場することになるので、特別に障害者向けサービスをうたっている場合を除いて、障害者がペルソナとして置かれるケースは非常に稀だろうと思います。

障害の種類や度合いは多様で「一般化」が難しい

UCD の経験が豊富で、かつユニバーサルデザインやアクセシビリティに理解のある組織の場合、障害者をペルソナに加えることはできるかもしれません。ただ、その場合も、「障害」という属性を持つという理由で安易にペルソナ化してしまうと、デザイン上の判断に偏りが生じてしまう恐れがあります。というのも、一口に「障害」と言ってもその種類や度合いは非常に多様で、「一般化」が難しいからです。たとえば :

また、抱えている障害が先天性か後天性か、障害の経験年数はどのくらいか、一時的なものか恒久的か、障害の度合いが重くなっているのか軽くなっているのか...といった様々な要因によっても、ユーザー行動や考えかたが大きく変わってくることでしょう。

障害者をペルソナ化すること自体はとてもよいことですが、一人ないし数人程度、「障害」という属性を持ったユーザーをペルソナに加えたところで、「アクセシビリティ上の問題をすべてカバーできる」と言えるほど単純なものではない...ということは理解しておく必要があると思います。

ユーザビリティテストに障害者に参加してもらう

インクルーシブデザイン (UCD プロセスの上流工程から、障害者にユーザーとして参加してもらうこと) は、可能な組織であればぜひ実施していただきたいですが、同時に、多くの組織やチームで無理なくできる、もっと現実的な手法があってもよいかもしれません。

大半のウェブサイトに求められるアクセシビリティ要件は、「障害の有無」や「支援技術の使用」がボトルネック (制約) にならずに、優れたユーザビリティを提供できていること (ある特定の目的を持った人が、障害を持っていようがいまいが、その目的をスムーズに/誤りなく達成できること) だと言えます。厳密にインクルーシブデザインを採り入れることができなくても、あらかじめアクセシビリティに配慮した制作を心がけておいて、そのうえで UCD プロセスの一部であるユーザビリティテストに (テスターとして) 障害者に協力していただく、といった形でも、それなりに大きな効果を得られるのでは、と考えています。

障害者に協力していただくテストと言っても、基本的には、一般的な (非障害者をテスターとした) ユーザビリティテストと、やることは同じです。ウェブサイトを利用して解決して欲しい課題 (タスク) をテスターに与えてみて、行動観察を通じてその達成度合い、取り組み中のつまづき、その他の問題点を抽出し、次の改善へとつなげます。

ただし上述の通り、障害の種類や度合いには多様性があり「一般化」が難しいので、あらゆるアクセシビリティ問題をカバーできるようなテスターのリクルーティングはそもそも不可能です。JIS X8341-3 や WCAG で定められた達成基準を満たすように (つまり基本的なアクセシビリティはクリアして) 制作しておき、そのうえで、可能な範囲で障害者テスターをリクルートし、問題を発見したら定性的に検討して都度改善する (できればそれをイテレーティブに継続する) ... というスタンスでよいのではないでしょうか。

カジュアルな簡易テストを、障害者に協力をお願いしてさらっとやってみる、というのも面白いと思います。私は時々、パソボラ (パソコンボランティア) の場をお借りしてカジュアルな簡易ユーザビリティテストをやってみることがあります (ターゲットユーザーでなくても、コンテキストを与えて、ごく短時間で1個から数個のタスクをやってもらう)。テスターとして協力いただく人にとっては、少々強引に架空のコンテキストが与えられた状態ではありますが、それでもやり方次第で、多くの気づきを得ることができます。

アクセシビリティをチームに根付かせる効果も期待できる

障害者にユーザビリティテストに参加してもらうことは、ウェブサイトのアクセシビリティを向上 (障害者ユーザーにとって目的達成までも含めて本当に役立つように) させる効果があるばかりでなく、プロジェクトチームによい刺激を与え、アクセシビリティをチームに根付かせる効果も期待できると思います。

障害者が実際にウェブを使っている様子を生で観察すると、JIS X8341-3 や WCAG といったガイドラインに書かれていることの意味や背景を (ユーザーに対する共感を伴う形で) 実感することができますし、ガイドライン (およびその関連文書) で要求されている実装を盛りこんでみたもののそれが本当にユーザーの役に立っているか、といったリアリティを伴った検証ができます (たとえば、代替テキストの内容は必要十分か？無意味な記述だったり、丁寧だけど過剰でかえってユーザーを苛立たせていないか？など)。少しずつ、可能な範囲でよいので、できれば繰り返し行なってみることで、いつしか、アクセシビリティを「当たり前」とする価値観がチーム内に醸成されるかもしれません。興味のある方は、ぜひ試してみてください。

関連記事