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

Transcript

1. アクセシビリティ対応を プロジェクトに取り入れるには？ アクセシビリティやるぞ！祭り by Yahoo! JAPAN・ミツエーリンクス・BA 2014年12月4日 伊原 力也
2. 自己紹介 • 伊原 力也 – BA – シニアインフォメーションアーキテクト – Twitter：@magi1125 – Facebookもやってます – クリエイティブユニット mokuva 所属
3. http://www.jjg.net/el ements/translations /elements_jp.pdf
4. サイトの目的 • プロジェクト要件定義を行う • 目的・目標・スコープなどを合意する • 基準・プロセス・スタンスを決める
5. アクセシビリティはどうするの？ • 特に決めてない • 何となく言い出してない • ある程度はやるだろうから決めてない • 他のプロジェクトからコピペして資料は出した
6. 結果A • 全員、華麗にスルー • 手癖・偶然・組み合わせに左右される • 安定度ゼロ
7. 結果B • 気にする人がいるケース – ディレクター、設計時にいちおう気にする – デザイナー、なんとなく配色などを気をつける – エンジニア、実装中にできるところをやる • 悲しきすれ違い – 勝手にやることになってるんだけど… – なんか後から文句つけられた – いつかやろう…（そして、やらない）
8. 結果C • 最初に決めてないので対応度バラバラ • そういうときに限って後から指摘が入る – 実話：公開後にコントラスト修正 – 実話：公開後に代替テキスト修正 • やってくれると思ってた的な反応も
9. アクセシビリティ、面倒 ……誤解だよ！
10. 問題はいつ起きているか • ビジュアルデザイン時やフロントエンド実装時 ……ではない！ • 良心でカバーしてる人 ≒ 手を動かす人 • ガイドラインに載ってるのは「具体例」 • でも、そこまで行ったらもう遅い
11. http://www.jjg.net/el ements/translations /elements_jp.pdf
12. http://blog.iaspectrum.net/2013/06/25/ux_honeycomb/
13. http://blog.iaspectrum.net/2013/06/25/ux_honeycomb/
14. http://www.bookslope.jp/blog/2012/07/evaluationuxhoneycomb.html
15. 最初に宣言しよう • まず「アクセシビリティ方針」を立てる • 最初にプロジェクト内で意思統一する
16. Q. 制作メンバーに面倒がられない？ • A. 特にそういうことはありません • 形になったものに対して 「後から文句言われる」のが問題 • 先に基準を決めていれば 後出しじゃんけんは起きない • むしろ初期段階において、 基準は「良い手がかり」になる
17. Q. クライアントに面倒がられない？ • A. 特にそういうことはありません • 専門家が「やっといたほうがいいよ」 というのを止める人はいない • ふつうに作る分には追加コスト不要 – 適当に作ると安くなる、というものではない ※ただし、お金が掛かる対応もある。後述。
18. 方針の立て方
19. 方針ってどう立てる？ • リニューアルなら、とりあえず現状調査 • そして「ウェブアクセシビリティ方針策定ガイ ドライン」を参照
20. なぜ現状調査？ • コンテンツを流用することがあるから – もともと駄目なコンテンツは何してもダメ – 動画や音声・PDF・複雑なUIへの対応はコスト発生 • 運用状況を知る必要があるから – NGなコンテンツが生まれてしまう理由がある – 運用フローを無視すると公開後に崩壊する
21. ざっくりでよい • あくまで、方針を立てるための下準備 • この段階ではざっくりした見方でかまわない • 作り変えてしまうので大量に見る必要はない
22. WCAG-EM http://www.w3.org/TR/WCAG-EM/
23. 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
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. そして方針を立てる • ウェブアクセシビリティ方針策定ガイドライン http://waic.jp/docs/jis2010/accessibility-plan-guidelines.html • 対象範囲 • 目標の達成等級 • 期限 • 例外事項 • 追加する達成基準
27. 方針でない方針に注意 • 「可能な限り配慮」 ←何も言ってないのと同じ • あいまいな書き方しない。目標はハッキリと。 • 今はできない部分も、いつやるかをふくめて ハッキリと。 • なんでも対象範囲外や例外にしたら意味なし
29. 「対応しない」と決めるのも方針 • 「無自覚に対応していない」「良心で対応す る」という構造が問題 • 自覚的にやらないならやらないと決めておくの も、プロジェクトとしては重要 • もちろん、それによる機会損失とかリスクとか 考えた上で
30. 注意したいこと • 「今はできない」「ここはできない」でも 「できないから載せない」はナシ – なんでWeb使ってるの？ってレベルの本末転倒 – コンテンツがWebにあるだけで超アクセシブル – まず載せる。可能性を潰さない、諦めない – サイトは作って終わりじゃない
31. 方針と共にメンバーに伝えてみよう • アクセシビリティは WebがWebであるための前提条件。 • アクセシビリティは「品質」基準。 プログラムが正しく動作するのと同じ。 • 制限のないデザインはない。 しかし、その制限こそが創造性を高める。
32. http://wired.jp/2011/11/22/%E3%80%8C%E5%88% B6%E9%99%90%E3%80%8D%E3%81%8C%E5% 89%B5%E9%80%A0%E6%80%A7%E3%82%92% E9%AB%98%E3%82%81%E3%82%8B%E7%90% 86%E7%94%B1/ WIRED：「制限」が 創造性を高める理由
33. ただし「言っといたからね」はナシ • 方針を了解＝対応できるって話じゃない。 オマカセにはしないこと • わかってる人（あなた！あなたですよ！）が エバンジェリストになること • 警察、関所、番人にならないこと。 マサカリ投げずに付き合うこと • 一人でやろうとしないこと！
34. 踏み出したあとは
35. http://www.jjg.net/el ements/translations /elements_jp.pdf
36. 問題の8割は「設計」に潜んでいる • 「形にする瞬間」にアクセシビリティの見地が あるかどうかが超重要 • 形が定着してしまってからアクセシブルにする のは至難のワザ＆非効率 • もともと分かりにくいコンテンツは、 マシンリーダブルになっても伝わりにくい
37. 書籍のご案内 • デザイニングWebアクセシビリティ アクセシブルな設計やコンテンツのための実践Q&A http://www.amazon.co.jp/dp/4862671756 • 鋭意執筆中！予約受付中！
38. もうひとつの課題
39. 「今は」別コストが発生しそうなもの • 動画、音声 – 実はJIS的にはシングルA • 1.2.1 収録済の音声しか含まないメディア及び収録済の映像しか含まないメディア • 1.2.2 収録済の音声コンテンツのキャプション • 1.2.3 収録済の映像コンテンツの代替コンテンツ又は音声ガイド – 代替コンテンツを用意する作業そのものにコストが掛かる • PDF – 公開するならHTMLと同じ扱い • JISは特定のコンテンツに依存しないため – もともとWordとかで作ってれば良いが、 紙もののスキャンとか、グラフィックデータの変換だと…
40. 「今は」別コストが発生しそうなもの • リッチUI – WAI-ARIAによるフォローが必要 • 1.3.1 情報及び関係性／1.3.2 意味のある順序 • 2.1.1 キーボード操作／2.1.2 フォーカス移動 2.4.3 フォーカス順序／3.2.1 オン・フォーカス • 3.2.2 ユーザインタフェース・コンポーネントによる 状況の変化 • 4.1.2 プログラムが解釈可能な識別名・役割 及び設定可能な値 – 設計と実装もそうだが、チェックにもコストが掛かる – ブラックボックスなフレームワークを使った開発
41. 壁への対抗 • 制作フローに織り込めるものは、 ただ普通にちゃんとやればよい • 「コストが掛かるならやらなくていい」 という「壁」が問題 • この状況の打破するためには、 アクセシビリティの機運を もっと高めることが必要
42. たとえば • 費用対効果ではなく 投資対効果のロジックを考える – future-proof：将来も使い続けられる • マルチデバイス、ウェアラブル、スクリーンの消滅、いろんな利用 状況、一時的な障害、法律、オリンピック、少子高齢化… – コンテンツの切片化と流通 • ソーシャルメディアやアプリによって「一部が切り取られて出回 る」という状況への準備 • 部分的に対応しながらROIを算定する
43. たとえば • 白日の下に晒す – 例：自治体サイトアクセシビリティ調査 http://www.u-works.co.jp/jichitai/ • コストを分散する仕組みを作る – 例：自動キャプションやクラウドソーシング http://youtubejpblog.blogspot.jp/2011/07/youtube.html http://www.amara.org/ja/ http://www.youtube.com/watch?v=Li3A3HY2vlw • ほかの言葉に言い換えてみる – 例：「日常のプチ不自由を見つけて解決する」 という裏ワザとしてまとめる http://zerobase.jp/blog/2013/01/accessibility.html
44. たとえば • 「Webアクセシビリティ」だけで考えない • 近しい方向を見ている人同士の 協調・乗り入れを生む – ユニバーサルデザイン（プロダクト）方面 – Linked Open Data (LOD)方面 – UX／HCD方面 – Makers／IoT方面
45. http://www.hitoyam.com/web/2013/12/24_0240.html
46. http://www.hitoyam.com/web/2013/12/24_0240.html
47. http://www.hitoyam.com/web/2013/12/24_0240.html
48. アクセシビリティやるぞ！