アクセシビリティ対応をプロジェクトに取り入れるには？

Transcript

1. アクセシビリティ対応を プロジェクトに取り入れるには？ 2014年1月24日 伊原 ⼒也
2. 前置き • Webアクセシビリティ界隈、 技術的な話、達成基準ごとの話は割とある – 楽しんで拝聴しています • しかし検討・対応プロセスの話が少ない – プロセス、いちおう JIS X 8341-3:2010（以降、JIS）に 書いてあるが、あんまり詳しく書いてない • 受託のWeb制作において、 実際のところどうやってるのか？ 今後どうしていったらいいのか？
3. 今日のアジェンダ • ありがちなパターン • まず認識合わせ • 現状を調べ、⽅針を⽴てる • 提案と実⾏の壁 • 壁への対抗 • そのためには
4. 自己紹介 • 伊原 ⼒也 – BA • シニアインフォメーションアーキテクト – アクセシビリティキャンプ東京 実⾏委員 – @magi1125
5. ありがちなパターン
6. こういう感じが多い気が • Webアクセシビリティって – ディレクターが、 設計時にいちおう気にしてる – デザイナーが、 なんとなくコントラストなどを気をつける – フロントエンドエンジニアが、 実装中にできるところをやる
7. 俺調べ • 有効回答数：40名 • アクセシビリティ⽅針があるプロジェクトに 関わったことがありますか？ – YES：15名 • クライアントから依頼があったから • 前のプロジェクト要件からコピペしたから – NO：25名 • そんなものを差し挟む余地がなさげだった • ある程度は対応するだろうから作らなかった
8. わりと問題が起きる • 基準がないのであとで揉める – 何か勝手にやることになってるんだけど… – お前の普通が俺の普通と思うなよ – やるって決まってないし。いつかやろう… – 後回しになって結局やらない • 結果「アクセシビリティ、面倒」 という印象になったりする
9. わりと後で指摘される • ご指摘 – 公開直前にプロジェクトオーナーから指摘 – 公開後にユーザーから指摘 • 実例 – 例：実装終盤に画面遷移を変更 – 例：公開後にコントラストを修正 • しんどい – 納品に向けて盛り上がっているところ、 または公開後にほっとしているところに – 検証→問題アリ→修正→たいへん
10. 最初から考えよう 最初 http://www.jjg.net/elements/translations/elements_jp.pdf
11. 検討プロセス • 内側での認識合わせ → 外側への提案、の順で考える • 発注者から求められた場合に対応する。 これは当たり前だし、やる動機がある – みんなの公共サイト運用モデル – グローバルなビジネス展開 – 親会社のガイドラインへの準拠 – 企業の社会的責任（CSR） • でもそういう案件ばっかりじゃない – 構築に携わる人たちが、このプロジェクトで どう考えて対応していくか、というのが先
12. まず認識合わせ
13. アクセシビリティはUXの土台 http://blog.iaspectrum.net/2013/06/25/ux_honeycomb/
14. アクセシビリティはUXの土台 http://blog.iaspectrum.net/2013/06/25/ux_honeycomb/
15. アクセシビリティはUXの土台 http://www.bookslope.jp/blog/2012/07/evaluationuxhoneycomb.html
16. アクセスできないと？ • アクセスできなかった＝体験が生まれない、 ではない • 「アクセスできなかった」は最悪の体験
17. 想定外の「使えない」が起きる現状 • 新しいデバイスが続々と出現。 困る状況も、これから続々出現 • スマートフォンでアクセスしたら、Flashコンテンツが表示されない • プラグインが必要と表示されたが、会社では禁止されていてインストール できない 環境が対応していない • スマートフォンで、リンクが小さくてうまく押せない そして拡大ができない • タブレットだと、マウスオーバーで動くメニューが使えない • キーボードで操作して済ませたいのに、 マウスを使わないとタスクが⾏えない 操作できない • 通信速度が遅くて画像が表示されない、または動画が再生されない • モノクロで印刷したら、色分けされたグラフの意味がわからない • 会社では音が出せない • コンタクトやメガネを失くしてて⾒えない 情報にアクセスできない
18. アクセシビリティは「品質」だ、と考える • 想定の範囲でしかウェブサイトを利用できない… その状態でプロジェクトの「品質」を満たせているか？ • ターゲット、想定の状況、それで使えれば本当にOK？ – 「アクセスできない状態」を知ることが難しいという恐ろしさ – 今後もずっと「ウェブサイト」の形でサイトが使われるのか？ • たとえば、Wikipediaの中身が楽天で表示されたり、 マッシュアップのネタにされたり • アクセシビリティは 「暗黙に求められる品質」になっている – これからのウェブには、この観点が必須では？
19. アクセシビリティは「等級」ではない • たとえばスマートフォン。これ納得いく？ – エントリーモデル： 壊れやすい、 ハイエンドモデル： 壊れにくい（いや、あるかもだけど） • ではウェブサイトは？ – 小規模サイト： アクセシビリティ低い 大規模サイト： アクセシビリティ高い はヘン – Webアプリ： アクセシビリティ低い 静的ページ： アクセシビリティ高い もヘン • 対応難易度がモノによって違うのは事実 – でもユーザーはそんなことはわからない
20. ガイドラインは敵じゃない • こうしておけば最低限OK、という線＝ガイドライン – JISやWCAGは読みづらい→めんどくさい→やりたくない – 確かに。 • でも、実は以下全てに触れている。ふつうに品質向上の役に⽴つ – 情報設計／機能設計、コンテンツ作成、デザイン、フロントエンド – アクセシビリティを高めると、 同時にユーザビリティ向上になることも多い • 何もないところから手をつけるより、基準があるほうがラク – 目標に向かっているかをチェックできる – セーフなら自信が持てるし、説明もできる – 構築後に運用していくときも、基準があるほうがやりやすい
21. ここまでまとめ • 基準を決めないと面倒だし残念なことに（実際なった） • なので、最初から考えよう • まずプロジェクト内で認識をあわせよう – アクセスできない＝最悪の体験 – でも、最近はどの端末でどう使われるか把握しきれない – アクセシビリティは、暗黙に求められる品質になりつつある – そのためのガイドライン。うまく使えば役に⽴つ、ラクできる • そして⽅針⽴案→提案に
22. 現状を調べ、⽅針を⽴てる
23. 現状を⾒てから「やる」と⾔う • よくわからないのに「やる」って言っちゃうと、 気まずい • だけじゃなく、プロジェクトが荒れる – スコープ外のところに手を入れないと 対応できないとか – やるって書いてあるからと無理やり対応、 想定外の期間／コスト増など
24. 現状分析の⽅法 • 現状：リニューアルの場合は今のサイト – そうでない場合は、他社事例で近いもの • ただし、どういう対応の可能性があるかを探る、参考程度 • リニューアルしてしまうので、 大量に⾒る必要はない • ⽅針定義の段階では、あまり細かくは⾒ない – 個別のコンテンツや機能の改修計画は、 別途、たな卸しの段階で⾏う
25. みるべきページ • アクセス数の多いページ • ほか、カテゴリごと – ホーム、カテゴリトップ – 一連タスク系：商品検索、カート、購入、資料請求 – UI系：フォームや JS による UI – 対応大変系：テーブル、動画、音声、PDF、Flash – 動的生成系：検索結果やイベントカレンダーなど – ユーティリティ系：問い合わせ、ヘルプ、サイトマップ http://waic.jp/docs/jis2010-test-guidelines/201211/index.html http://www.soumu.go.jp/main_sosiki/joho_tsusin/w_access/pdf/index_02_03.pdf
26. みるべきポイント = W3C Easy Check • Page title • Image text alternatives ("alt text") • Headings • Contrast ratio • Resize Text • Keyboard access and visual focus • Forms, Labels, and Errors (including Search fields) • Multimedia (video, audio) alternatives • Basic Structure Check http://www.w3.org/WAI/eval/preliminary
27. ⾒た結果をまとめる • 達成基準チェックリストの例 2010年8月版 を参考利用 – http://waic.jp/docs/jis2010-test-guidelines/201211/gcl.html – 等級A以外の項目はいったん一覧から削除 • 該当コンテンツが確認範囲にあった場合は「適用」に◦をつける – 例：サイトに動画ファイルがあったときだけ◦をつける • 確認した結果、概ね問題ない場合は「適合」に◦をつける • 問題があった場合は✕をつけ、「備考」に問題点を記載する
28. そして⽅針を⽴てる • ウェブアクセシビリティ⽅針策定ガイドラインを参考 – (1) 対象範囲、(2) 目標を達成する期限、 (3) 目標とする達成等級 (4) 例外事項、(5) 追加する達成基準 • http://waic.jp/docs/jis2010/accessibility-plan-guidelines.html • 極端に言えば「やるのか・やらないのか」決める – 決めないことが一番の問題 – プロジェクト的には「曖昧にしない」ことが大事 – ⽅針から逸れる必要がある場合も、きちんと「検討」を持つ
29. 注意したいこと • 「ここはできない」となっても 「できないから載せない」はナシ – Webであるだけでかなりアクセシブル – まず載せる。可能性を潰さない、諦めない – サイトは作って終わりじゃない
30. ⽅針に沿って提案
31. 気にされるのは「コスト」と「時間」 • 社内で合意した⽅針をクライアントに提示した際、 内容面で止められることはあまりない（経験上） – 専門家が「やったほうがいい」ということを 無理に止めようとする人は、ふつうは居ない • しかし、ビジネスにおいて、コストが掛かるけど 役に⽴つかどうかわからないものは、実⾏されない • 「コスト」と「時間」の妥当性が説明できなければ 「やらなくていいよ」となる。これが現実 • プロジェクト管理側としても、それは同じなはず – 実装者の良⼼で対応する形では、安定して対応できない
32. 構築プロセスに織り込めるもの • インタラクションをあまり伴わないページなら、 JISシングルAな項目は、ほとんど当たり前に達成できるはず – マークアップを適当にしたらコストが低い、 ⾒出しを適当に書いたらコストが低い、とかあんまりない – altはちょっとグレーだが、原稿をちゃんと作れば大丈夫（別の回で） – 運用時を考えると、テンプレート・ガイドライン・CMSなどは必要に なるかもしれない – しかし、それらもアクセシビリティだけの対応ではないメインではな いので、プロセスに織り込める • こういうのは少し気をつけながら（＝⽅針を⾒ながら） 普通に対応すればOK
33. 「今は」別コストが発生しそうなもの • 動画、音声 – 実はJIS的にはシングルA • 1.2.1 収録済の音声しか含まないメディア及び収録済の映像しか含まないメディア • 1.2.2 収録済の音声コンテンツのキャプション • 1.2.3 収録済の映像コンテンツの代替コンテンツ又は音声ガイド – 代替コンテンツを用意する作業そのものにコストが掛かる • PDF – 公開するならHTMLと同じ扱い • JISは特定のコンテンツに依存しないため – もともとWordとかで作ってれば良いが、 紙もののスキャンとか、グラフィックデータの変換だと…
34. 「今は」別コストが発生しそうなもの • リッチUIへの対応 – WAI-ARIA関連、実はJIS的にはシングルA • 1.3.1 情報及び関係性／1.3.2 意味のある順序 • 2.1.1 キーボード操作／2.1.2 フォーカス移動 2.4.3 フォーカス順序／3.2.1 オン・フォーカス • 3.2.2 ユーザインタフェース・コンポーネントによる 状況の変化 • 4.1.2 プログラムが解釈可能な識別名・役割 及び設定可能な値 – 設計と実装もそうだが、チェックにもコストが掛かる • 「コストが掛かるならやらなくていい」という 「壁」への対抗が必要
35. ここまでまとめ • 現状を調べて⽅針を⽴てよう • そんなに細かく⾒ずとも、概ねつかめればOK • ⽅針はあいまいさを残さず、きっちり決める – WAICの各種ガイドラインを上手く利用しよう • いざ提案。当たり前のものは当たり前に対応でOK • しかしコストを掛けないと対応できないものもある • しかもシングルAだったりする。どうする？
36. 壁への対抗
37. 受け身を取る編 • 当たり前ラインの底上げ – 例：WAI-ARIA、roleの設定ぐらいなら織り込める • http://www.w3.org/TR/aria-in-html/ • 既にあるものを使う – 例：JQueryUIつかう • http://jqueryui.com/ • サイト制作プロセスを改善 – 例：テンプレート、モジュール、自動化
38. 攻めにいく編 • コンテンツ／機能制作のプロセスを改善 – プロトタイピング、コンテンツ執筆プロセスに手を入れる • ROIを説明できるようにする – コントラストが高いほうがバナーがクリックされたという事例 • http://www.slideshare.net/marippe/dx-for-16804775 • ただし、資料でも示されている「なぜそうなったか」まで踏み込まないと、 なかなか説明しづらい
39. ルールを変える編 • アクセシビリティ対応状況を白日の下に晒す – 例：自治体サイトアクセシビリティ調査 • http://www.u-works.co.jp/jichitai/ • コストを分散する仕組みを作る – 例：youtube自動キャプション • http://youtubejpblog.blogspot.jp/2011/07/youtube.html – 例：Amara、mysmarteye • http://www.amara.org/ja/ • http://www.youtube.com/watch?v=Li3A3HY2vlw
40. ルールを変える編 • 「価値」の⾒⽅を変える – 例：「日常のプチ不自由を⾒つけて解決する」 という裏ワザとしてまとめる • Twitterで「アクセシビリティ」を検索すると、 iPhoneのアクセシビリティ機能が裏技として出回っている – http://zerobase.jp/blog/2013/01/accessibility.html • モチベーションの元になるウェブサービスを作る – Google • マシンリーダビリティの向上 ＝クローラビリティ／インデクサビリティの向上 – Facebook • OGP、一気に普及
41. そのためには
42. 時にはおこせよムーブメント • たとえば 「Web標準が流⾏って、定着したのはなぜだろう？」 と考えてみる • 連続性を持って取り組む。 1回で諦めない。転んでも泣かない • [良エントリ紹介] アクセシビリティとコミュニティ、未来へのアプローチ – 私たちの持つ技術とWebをつかった 「社会の仕組みへのアプローチ」を考える
43. http://www.hitoyam.com/web/2013/12/24_0240.html
44. http://www.hitoyam.com/web/2013/12/24_0240.html
45. 今回の内容を含む書籍を執筆中！ ワークスコーポレーションさんから 出版予定。乞うご期待！
46. ご清聴ありがとうございました
47. 次回につづく！