なぜ必要？まずはWebアクセシビリティについて知ろう 中編
3. Webを『使う人の特性』『使われ方のパターン』
「Webアクセシビリティ」。正しいことを言ってるのは分かるのに、では具体的にどこまでどんな対応が必要なのか、どうもいまいちピンと来ない。そんな人いませんか？
それは単純に
・自分以外がどんな使い方をしているかあまり知らないから
・使う人の特性と使われ方をそれほど丁寧に ”誰も教えてくれない” から
だと思います。
身近に経験できなければ、自分事に置き換えるのは難しいのが当然です。これらの解決策は単純です。まず”知る”こと、そして次に”想像する”こと。もう一歩踏み込むなら”実際に使ってみる、試してみる”や”インタビューする”ことも大事だと思います。
今回、なかなか長めの記事になってしまい、前編のあとの後編予定だった部分をさらに中編・後編に分割しました。即時的な実用度は後編が高いので、興味のあるところだけツマミ読みとかしてもらえると幸いです。
●『使う人の特性』を知る
・健常(日常生活に支援を必要としない)
・視覚障害(全盲、弱視、色覚多様性など)
・聴覚障害(全聾、難聴など)
・肢体不自由
・知的障害
・学習障害(読字障害、書字障害、算数障害など)
・高齢
・ほかあらゆる状況、条件
上記のように、さまざまな特性を持った人々(ユーザー)がWebを利用しています。このことを念頭にコンテンツ制作をすると最低限どうすべきか、どのラインを保つかなどがいろいろ見えてきたり、自然と気づくことがあったりするはずです。
障害者の具体的なWeb利用方法については、以下の記事のYouTube動画がとても参考になります ↓
また「マーケティングとアクセシビリティは相性が悪い」という意見を聞いたことがありますが、そもそもレイヤーの違う話です。売る仕組みとCSR・ホスピタリティに根差した話は、対比ではなく並列で考えることではないでしょうか ↓
●『使われ方のパターン』を知る
マウスカーソル操作 (トラックパッド含む)
おそらくPCユーザーの大半がこれにあたります。マウスはバリエーションが多く、ゲーミングマウスやトラックボールなどいろいろな種類があります。トラックパッドも挙動は同じです。ほかにジョイパッドやジョイスティック(ゲームコントローラー)などもあります。
カーソル/ポインタ操作ではカーソルがコンテンツ要素上に乗ったり、通過したりしたことを示すためのhover(ホバー/マウスオーバーとも)効果を適用できます。
タッチパネル(タップ)操作
スマホ、タブレットユーザーはほぼこれ。タッチディスプレイ搭載のデスクトップ/ノートPCも増えてきました。
指などで画面上の要素に直接触れてアクションを決定します。カーソルが介在しないためhoverという概念はないのですが、hover指定していると画面に触れ離した直後の一瞬に効果が表れます。これに関する対応法や見解はいろいろあります。
-----
多くの人が触れる一般的な操作方法だけあって、マウスカーソルとタッチパネルに関しては通常のWebコンテンツでもよく対応されています。では、以下のような使われ方をしていることはご存知でしょうか？デザインやコーディングをする際に考慮されているでしょうか？
-----
キーボード操作
Tabキーで移動、Enter(Space)キーで決定など簡易操作が可能。
キーボード操作をする人は一定数います(筆者含む)。何らかの障害や怪我・病気でマウスをうまく操作できない人もいます。アクセシビリティの規格・達成基準にも含まれますので対応していなければしましょう。
キーボードはスマホ、タブレットでも使えますし、ゲーム機やテレビなど他デバイスでの使用時も近い挙動になることもあるようです。ぜひ意識したいところです。
キーボード操作の要は、自分が今どの要素を選択しているかを明示する「フォーカス・インジケータ(シーケンシャル・フォーカス・ナビゲーション)」です。マークアップやスタイルのためにこのフォーカス/focus(フォーカスリング)が選べなかったり、消されたりすることもありますが、ユーザーに混乱をもたらすので望ましくありません。
PCでフォーム入力をするときなど、キーボード操作なら項目移動がしやすく重宝します。しかし、ラジオボタンやチェックボックスなどがカスタマイズされ、キーボードフォーカスが見えないサイトによく遭遇します。
・「スクリーンリーダー」や「音声ブラウザ」による音声読み上げ利用
おもに視覚障害向けの支援技術で、Webコンテンツの内容を機械が音声で読み上げます。PC利用が多そうですがスマホ、タブレットも対応しています。
テキストだけでなく文書構造や状態なども音声で説明するので、適当なマークアップやインタラクティブで複雑な動きをさせている場合、混乱を招きやすいです。
セマンティクスが求められ、WAI-ARIA(ウェイ-アリア / Web Accessibility Initiative - Accessible Rich Internet Applications)という仕様への適切な対応をすることで、コンテンツの正確な読み上げが行えます。ただし、ツールによる読み上げにも差があるようです。
●おもなスクリーンリーダーツール
・ナレーター (Windows10標準搭載・無料)
・VoiceOver (macOS/iOS/iPod標準搭載・無料)
・NVDA (無料)
・JAWS (有料)
・PC-Talker (有料)
・Android Accesibility Suite (TalkBack) (無料)
・点字ディスプレイ
スクリーンリーダーの延長上にある技術・機械で、表示すべき文字情報を画面から取得して点字に変換する(点字ドットがせり出てくる)仕組みです。音声読み上げ対応をしっかりやることで問題なく利用できる端末(けっこうなお値段！)です。
ハイコントラスト表示での利用
おもに弱視(ロービジョン)のユーザーが利用しているOS標準搭載の機能。Windows、macOS、iOS、Androidなどで利用可能です。
前景色と背景色の輝度(明るさ)の差によって文字などが視認しづらくなってしまうことがあり、この状態をコントラスト比が低いといったりします。これを解消する機能がハイコントラスト表示(モード)です。
OSハイコントラスト表示の使用方法のリンクがこちらのページにまとまっています↓
・そのほかの使われ方
・視線入力システム(アイトラッカー)
・テキストブラウザ
・マウス代替装置
・音声入力デバイス
など
4. Webアクセシビリティに対する誤解
Q. Webページ側で文字サイズの変更ボタン(大・中・小) などの支援技術は提供したほうが良いの？
A. Webページ側で提供する必要はありません。文字サイズ変更機能は、Webブラウザ側で提供するものとされているためです(テキストのサイズ変更:達成基準 1.4.4 を理解する参照)。事実大抵のブラウザには文字サイズ変更機能があります。ページ側で対応をするべきなのは、ブラウザのズーム機能で200％まで段階的(120％、140％、160％、180％)に拡大していったときに、コンテンツの閲覧や機能の操作に支障がないようにすることです。
ほかにも音声読み上げ機能やハイコントラスト表示といった支援技術を、Webページ側で提供するサイトを見ることもあります。ですが、これらも文字サイズ変更同様にOSやブラウザ側から提供されるべきものです。実装すべきでない、ということはありませんがWebページ側でやれることを優先した方がよいでしょう。
-----
Q. Webアクセシビリティをやると、いろいろと制約が多い上に、ビジュアルデザインがダサくなったり、インタラクションができなくなったりするよね？
A. はっきりと強くは言えませんが、そんなことないと思います。WebGLなどリッチな視覚表現を使ったサイトでも、たとえブラウザゲームであっても、究極アクセシビリティ対応との共存はできると思います。
要は、適切な情報の切り分け(情報設計・IA)や丁寧な説明(ガイダンス)だったりするかなーと。そのためにはやはり多様性やケースを”まずは知る”ことだと思います。
参考：
目が見えなくても『ストII』はできる。視覚障害者がいかにビデオゲームを楽しむのかを伝える「第10回 アクセシビリティキャンプ東京」レポート
https://automaton-media.com/articles/gamer-pick/20170409-44388/
-----
Q. 会社の人に「コストがかかる」「優先事項ではない」「うるさ方がいるからめんどう」と言われて、心が折れそうです。こんなこと言われるのに本当に必要なんですか？
A. 取り組もうとする心意気がすでに素晴らしいと思います。ご自身にも、会社での浸透もちょっとずつやっていき、でお願いします。
Webは土台・基礎をあとから作って付け足すこともいくぶん可能なところが救いだと思います。なので、アクセシビリティガイドラインのベースとなるようなものを準備して、そこに少しずつノウハウや考え方を足していけば、いつの間にかコストでも手間でもなくなるのではないでしょうか。最初は何だってコストです。
また、プロジェクトにおいてはどこまでを対応範囲としてWebアクセシビリティ対応するかの定義こそが大事だと思います。完璧に対応するなんて不可能に近いですし。
-----
後編へつづく