WP ZoomUP #14『誰もが使える』デザインを生み出すために

伊原 力也(いはら りきや)

  • freee プロダクトマネジャー/UXデザイナー
  • HCD-Net 評議委員、認定人間中心設計専門家

書籍

アクセシビリティとは

  • アクセシビリティ、あるていどご存知のかた多いと思います
  • 使える人の範囲が広いことを「アクセシビリティが高い」といいます
  • アクセシビリティを高めるための方法として、典型例としてはアクセシビリティガイドラインでチェックするというものがあります
  • いわゆるWCAG2.1とかJIS X 8341-3:2016とかというものです

デザインのアクセシビリティ対応=コントラストチェック?

  • ガイドラインでのチェックに有名なものの一つに、コントラストチェックがあります。チェックツールで背景とテキストの色を比較して、4.5:1を超えていればOKというもの
  • これまで、デザインでのアクセシビリティというと、これがイメージされることが多かったように思います
  • もちろん色も大事な観点。しかしそれ以外にもじつはデザイン時に押さえる「勘所」と言えるようなものが、いくつかあるんです

アクセシビリティガイドラインをとりまく状況

  • アクセシビリティガイドラインは、いろんな人や状況でのいろんな使い方に対するベストプラクティスをまとめたもので、非常に参考になるものです
  • なぜWebというメディアを使うかといえば、多くの人に見てもらいたいからですよね。その対象を最大化するためのガイドラインなので、ある意味、Webを正しく活用するガイドラインと言えるものです
  • しかし、実際にそのガイドラインを活用してアクセシビリティを高めようとすると、だいたい2つの壁にぶつかります
  • それは、「ガイドラインが難しい」というのと、「あとから突っ込まれる面倒なもの」というものです

ガイドラインが難しいのはなぜ?

  • ガイドラインを実際見てみると、確かに書きぶりが難しいと感じます。一回読んだだけだと、何を言っているのかよくわからないと思います
  • なぜ難しいかといえば、ひとつは技術に依存しない書き方になっているからです
  • 技術の移り変わりは激しいので、対応しなければならない「状況」と、それを達成するための「方法」は分離されています。そのため、何をどうすればいいのかわかりにくい書き方になっています
  • 本体と、UnderstandingとTechniquesという3つに別れていて、この全体を読むと「どういう原則で、それはなぜで、どういう実装をすれば達成できるのか」がようやくわかります
  • また、ガイドラインの対象はWebページとなっていますが、これはHTMLやCSSだけでなく、PDFとか、かつてはFlashなど、Web技術を使ってユーザーに届けられるものすべてを対象としています。また、閲覧が主となるWebページだけでなく、ユーザーがタスクをこなしていくためのWebアプリケーションも対象にしています
  • こういったことが、書きぶりや達成方法を複雑にしている原因です

なぜあとから突っ込まれることになる?

  • アクセシビリティ=あとからチェック、というイメージは強いかと思います。ガイドラインをもとにしたチェックリストで、作り終わったページをチェックしていって、問題がないかどうか確認するというものです
  • 実際、JISには試験に関する記載があります。あらかじめアクセシビリティ方針を立てて、それを満たすようにページを作って、ではその方針を満たせているのか?は自分たちで対象ページをピックアップしてガイドライン片手にチェックしていく。そして問題なければOK、というわけです。
  • しかし、これは作り手側からすると恐怖です。どこをどう気をつけたら良いのかわからずに作ったものに対して、あとから「これは違う」と言われるのは、視野の外からマサカリが飛んできたような気持ちになるでしょう
  • こういう経験がある(ないしは聞く)と、アクセシビリティ対応は恐ろしいもので、怒られないためにやるもの、という気持ちになってしまいます。これは本末転倒です。作る側もチェックする側も、多くの人に見てもらいたくてやっていることなのに、こういったすれ違いは避けたいところです

ガイドラインがチェックリストっぽい書きぶりなのが根本的な原因

  • ガイドラインの書きぶりは、かなりチェックリストっぽいものです。私はこれが「難しい」「あとからツッコミ」の根本的な原因なのではないかと睨んでいます
  • ガイドラインは「知覚可能」「操作可能」「理解可能」「堅牢」という原則で示されています。なので「作られたものに対して、◯◯可能だったらアクセシブルである」という書きぶりに感じられます
  • また、その原則に基づく達成基準は、WCAG2.1だと78個もあります。しかし、それらは上記の原則、つまりに沿って分類されているので、webサイト制作の進行においてどこで何を気をつけたら良いのかがよくわかりません
  • たとえば「1. 知覚可能」は「情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない。」となっていて、それは確かにそうだよねと思うわけです
  • しかし、この「1. 知覚可能」には、観点としては画像の代替テキストと動画とマークアップとコントラストとレイアウトの話が入っています
  • 実際のところ、制作のうえではこれらは一気にやるわけではないので、こういう書きぶりだと、いつ何をどうすればいいのかわかりません
  • これは、アクセシビリティガイドラインを噛み砕いた「この10項目をまずやってみよう」的な簡易チェックリスト的なものでも、本質的には同じ問題(いつ何をどうすればいいのか)をはらんでいると思っています
  • ちなみに、別に植木さんをDisっているわけではありません(いい記事です

デザイン時に押さえる「勘所」=ケースを絞ってプロセスで対応

  • 逆に言えば、ガイドラインが何を求めているかがわかっていて、あとからではなく先に対応するつもりで、どのフェーズで何をすればいいかが見えていれば、そのサイトは自動的にアクセシブルになるように作れるはずなのです。なので、今回は以下のようなお話をします
  • まず、何を求めているかを理解するために、今回は対象を絞り、HTML+CSS+JavaScriptで制作される一般的なWebサイト制作において何をすればいいのか?にポイントを絞って解説します
  • そして、あとからチェックではなく先に対応するために、ガイドラインを解体再構築し、制作時のプロセスに沿いながら、普通に作るだけでアクセシブルになるというアプローチで解説します