この記事は、Web Accessibility Advent Calendar 2015、3日目の記事です。
技術的なお話は別の人がするからもう俺はいいやってことで、毎年恒例だし、今年は技術的なところにはあまり触れずになんか書こうかなーと軽い気持ちで参加表明しちゃった Web Accessibility Advent Calendar なんですが、忘れてただけで去年、すでに今年考えてたような内容で書いてたことに気がついてネタがありません。どうしましょう。
ということで今回は完全に技術的な話は排除して、ゆる～くにアクセシビリティについて思うところを書いておくことにしました。とはいっても啓蒙的なお話についてはアクセシビリティ界隈の偉い方々が常々やってくださっておりますので、じゃあアクセシビリティってやつを制作者サイドはどのように捉えて制作業務に組み込めばいいの？ ってお話を少し。
一旦 「Web アクセシビリティ」 ってから言葉から離れてみる
Web Accessibility Advent Calendar で記事書いといて、一旦 Web アクセシビリティから離れようぜって、何をいきなりという感じではありますが、どうしても制作者サイドから Web アクセシビリティを考えるとなると、実装部分に目が行きがちで、やれ HTML がどうのとか、アクセシビリティガイドラインは読んだのかコノヤロウとか、WAI-ARIA とはなんちゃらみたいな話になりがちです。
もちろん、最終的な問題解決の手段として技術 （とそれを正しく使える能力） は大切なんですが、今回は少しだけ目先を変えて、あまり言葉の定義に囚われず、もう少し大きな目的に目を向けて考えてみると違った見え方するかもよという感じで話を進めていこうかなと。
より大きな目的から 「Web アクセシビリティ」 を考えてみる
そこで今回は、「Web アクセシビリティ」 を目的とはせず、もう少し大きな目的の中に組み込んで考えてみることにします。
そこで、下記のような目的を設定してみます。
利用者全員が使いやすくて便利な Web ページ（サイト）を作る
さて、どうでしょう。
- 全員が？ そんなの無理じゃね？
- そもそも何をもって 「使いやすい」 だよ。そんなの人によって評価違うじゃん
という印象をもつ方もいるかもしれませんが、そういう細かいことは今回は置いておいて、一旦目標は 「利用者全員が使いやすい」 にしてみましょう。これを目指した結果として、利用者層や利用シーン、あるいは Web サイトの内容によって 「全員」 や 「使いやすい」 の解釈が多少変わってもそれは仕方ありません。
それでも一度本気で、「全員が使いやすいってどういうことだろう」 って考えてみようとすれば、色々な想像力を働かせないといけないことに気がつくと思います。
利用者全員が使いやすいとは？
まず、利用者全員ってどういうことでしょう。例えばどんな人が Web サイトを使うのか、考えつくだけ挙げてみましょう。
- 若い人、中年、お年寄り
- 男性、女性
- パソコンの人、スマホの人
- 画面が大きい人、画面が小さい人
- インターネット接続環境が高速な人、低速な人
- 家やオフィスから使う人、外出先から使う人
- 目が悪い人、耳が悪い人
- スマホの操作にとても慣れている人、慣れていない人
- 全部キーボードで操作するのが好きな人、マウスしか使わない人
- Web ページを読み上げて使いたい人
- ロボット、プログラム ...etc
利用者の細かいセグメントは置いておいても、色々考えられます。
次にそれをもう少し掘り下げてみます。
- 若い人、中年、お年寄り
- 難しすぎる漢字が読めない人がいるかも
- 英語だとわからない人がいるかも
- 専門用語が理解できない人がいるかも
- 細かい字が見えない人がいるかも ...etc
- 男性、女性
- 性別によっては訴求すべきポイントが違うかも ...etc
- パソコンの人、スマホの人
画面が大きい人、画面が小さい人
インターネット接続環境が高速な人、低速な人
家やオフィスから使う人、外出先から使う人
- 回線が細くて画像の読み込みにすごく時間がかかる人がいるかも
- 動画が勝手に再生されたら通信費が大変なことになる人がいるかも
- オフィスで急に音が鳴ったら困る人がいるかも
- とにかく急いで特定の情報を探している人がいるかも
- JavaScript などの処理が重たいと正常に動かない人がいるかも
- 特定のプラグインが入っていない環境があるかも ...etc
- 以下省略
みたいな感じで考えていくと 「利用者全員が使いやすい」 を実現するために、まずは使っていてストレスを感じてしまうであろう点を排除するためのヒントは色々と出てくると思います。また、上記に挙げた点の中に、「Web アクセシビリティ」 の範疇として分類される項目がいくつか出てきているのもわかります。
ちなみに、この段階で Web アクセシビリティガイドライン （WCAG とか JIS X 8341-3 とか）を読んでみると、それを解決するための具体的な技術的アプローチやヒントが書かれているので、目的からガイドラインを読むことができるようになってより理解が進むと思います。プログラミングのお勉強などでもよくありますが漫然と参考書を読んだりするより、「こうしたいんだけど、どうすれば......」 という明確な解決すべき課題や目的があって調べると身につきやすかったりしますよね。それと同じです。
さて、ここまでつらつら書いて何が言いたかったかというと、「Web アクセシビリティ」 という範囲だけで物事を考えるのではなく、「より良い Web サイトを作るために何が必要か」 を考えていけば、自然と Web アクセシビリティに関連することも考えなければいけなくなりますよねと言うこと。
ここまでわかると、翻って Web アクセシビリティが、公開済みの Web サイトに後から手を入れていって何とかするような 「後付けの対策」、あるいは 「余裕があったら加えたい付加価値」 として取り組んでおけばよいというものではなく、本来 Web サイトの制作フローの中に最初から組み込まれていなければならない根本的な要件であるということがわかるんじゃないかなと。Web サイトや Web コンテンツの企画や設計段階から当たり前に考慮されるべきで、それによってコンテンツの内容や設計、デザインにも影響が出てくる場合もあります。
言葉の定義や範囲は無意味
無意味とか書くと色々言われそうですがあえて。少なくともあまりそれに囚われすぎると本質を見失いますよということ。
例えば情報設計、デザイン、コンテンツ企画、ユーザインターフェース、ユーザエクスペリエンス、ユーザビリティ、ファインダビリティ、SEO ...... etc 良い Web サイトに必要な要素を表すものとして様々な専門用語が出てきます。当然アクセシビリティもそこに含まれるもののひとつですが、これらはそれぞれが複雑に関係していて、その守備範囲も明確に別れているわけではありません。重複している部分も多分にありますし、また、Web サイトの目的や対象、役割などによってそれぞれの優先順位やアプローチの仕方も変わってきたりします。
よい Web サイトを作ろうとするとき、例えば 「UI」 だけを考えていればよいなんてことはないし、「アクセシビリティ」 さえ考慮していれば OK なんてことはないんですね。本当に極端な話ですが、アクセシビリティガイドラインに準拠してたって、デザインがコンテンツにマッチしていなければ魅力的な Web サイトにはならないでしょうし、導線の設計がまずく、目的のコンテンツを探しにくければ利用者にとってはストレスフルです。そもそもコンテンツがつまらない、役に立たなければ利用者からみたその Web サイトの価値は ない に等しいわけです。
また、ある言葉の範囲に限定しようとすると、例えば 「Web アクセシビリティ」 の範囲にかかるコストについての費用対効果みたいな話になりがちで、お金出す方の立場からすれば、「SEO」 は売上に直結するからバンバンお金出すけど、「Web アクセシビリティ」 はあまり売上には関係なさそうだから後回しで。みたいなことになりかねません。結果、例えば法律的に縛りなどができなければ積極的には取り組まない 「面倒なもの」 扱いになってしまう。
そうじゃなく、「利用者全員に気持ちよく Web サイトを使ってもらうため」「この Web サイトを誰が使っても使いやすく、みんなからいいサイトだねって思ってもらえる素晴らしい状態に近づけるため」 の必須要件の中にどうしたって含まれるんですよ、という認識を正しく持つことが Web アクセシビリティを当たり前にしていくために必要なんじゃないかなと思います。
なんかポエムっぽい感じになってしまいましたが、多分技術的な事は他の Web Accessibility Advent Calendar 2015 参加者の方が色々と書いてくださると思いますし、昨年以前の Web Accessibility Advent Calendar を含め、すでに巷には良質な記事があふれていますので今回はこのくらいで終わらせたいと思います。
この考え方がすべてではありませんし、当然、これが正解だとか、他の考え方が合ってるとか間違ってるとか、そういう話ではありませんので、ひとつの考え方として参考になったら幸いです。
