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

Slide 1

Slide 1 text

アクセシビリティ対応をプロジェクトに取り入れるには？ 2014年1月24日伊原⼒也

Slide 2

Slide 2 text

前置き • Webアクセシビリティ界隈、技術的な話、達成基準ごとの話は割とある – 楽しんで拝聴しています • しかし検討・対応プロセスの話が少ない – プロセス、いちおう JIS X 8341-3:2010（以降、JIS）に書いてあるが、あんまり詳しく書いてない • 受託のWeb制作において、実際のところどうやってるのか？今後どうしていったらいいのか？

Slide 3

Slide 3 text

今日のアジェンダ • ありがちなパターン • まず認識合わせ • 現状を調べ、⽅針を⽴てる • 提案と実⾏の壁 • 壁への対抗 • そのためには

Slide 4

Slide 4 text

自己紹介 • 伊原⼒也 – BA • シニアインフォメーションアーキテクト – アクセシビリティキャンプ東京実⾏委員 – @magi1125

Slide 5

Slide 5 text

ありがちなパターン

Slide 6

Slide 6 text

こういう感じが多い気が • Webアクセシビリティって – ディレクターが、設計時にいちおう気にしてる – デザイナーが、なんとなくコントラストなどを気をつける – フロントエンドエンジニアが、実装中にできるところをやる

Slide 7

Slide 7 text

俺調べ • 有効回答数：40名 • アクセシビリティ⽅針があるプロジェクトに関わったことがありますか？ – YES：15名 • クライアントから依頼があったから • 前のプロジェクト要件からコピペしたから – NO：25名 • そんなものを差し挟む余地がなさげだった • ある程度は対応するだろうから作らなかった

Slide 8

Slide 8 text

わりと問題が起きる • 基準がないのであとで揉める – 何か勝手にやることになってるんだけど… – お前の普通が俺の普通と思うなよ – やるって決まってないし。いつかやろう… – 後回しになって結局やらない • 結果「アクセシビリティ、面倒」という印象になったりする

Slide 9

Slide 9 text

わりと後で指摘される • ご指摘 – 公開直前にプロジェクトオーナーから指摘 – 公開後にユーザーから指摘 • 実例 – 例：実装終盤に画面遷移を変更 – 例：公開後にコントラストを修正 • しんどい – 納品に向けて盛り上がっているところ、または公開後にほっとしているところに – 検証→問題アリ→修正→たいへん

Slide 10

Slide 10 text

最初から考えよう最初 http://www.jjg.net/elements/translations/elements_jp.pdf

Slide 11

Slide 11 text

検討プロセス • 内側での認識合わせ → 外側への提案、の順で考える • 発注者から求められた場合に対応する。これは当たり前だし、やる動機がある – みんなの公共サイト運用モデル – グローバルなビジネス展開 – 親会社のガイドラインへの準拠 – 企業の社会的責任（CSR） • でもそういう案件ばっかりじゃない – 構築に携わる人たちが、このプロジェクトでどう考えて対応していくか、というのが先

Slide 12

Slide 12 text

まず認識合わせ

Slide 13

Slide 13 text

アクセシビリティはUXの土台 http://blog.iaspectrum.net/2013/06/25/ux_honeycomb/

Slide 14

Slide 14 text

アクセシビリティはUXの土台 http://blog.iaspectrum.net/2013/06/25/ux_honeycomb/

Slide 15

Slide 15 text

アクセシビリティはUXの土台 http://www.bookslope.jp/blog/2012/07/evaluationuxhoneycomb.html

Slide 16

Slide 16 text

アクセスできないと？ • アクセスできなかった＝体験が生まれない、ではない • 「アクセスできなかった」は最悪の体験

Slide 17

Slide 17 text

想定外の「使えない」が起きる現状 • 新しいデバイスが続々と出現。困る状況も、これから続々出現 • スマートフォンでアクセスしたら、Flashコンテンツが表示されない • プラグインが必要と表示されたが、会社では禁止されていてインストールできない環境が対応していない • スマートフォンで、リンクが小さくてうまく押せないそして拡大ができない • タブレットだと、マウスオーバーで動くメニューが使えない • キーボードで操作して済ませたいのに、マウスを使わないとタスクが⾏えない操作できない • 通信速度が遅くて画像が表示されない、または動画が再生されない • モノクロで印刷したら、色分けされたグラフの意味がわからない • 会社では音が出せない • コンタクトやメガネを失くしてて⾒えない情報にアクセスできない

Slide 18

Slide 18 text

アクセシビリティは「品質」だ、と考える • 想定の範囲でしかウェブサイトを利用できない… その状態でプロジェクトの「品質」を満たせているか？ • ターゲット、想定の状況、それで使えれば本当にOK？ – 「アクセスできない状態」を知ることが難しいという恐ろしさ – 今後もずっと「ウェブサイト」の形でサイトが使われるのか？ • たとえば、Wikipediaの中身が楽天で表示されたり、マッシュアップのネタにされたり • アクセシビリティは「暗黙に求められる品質」になっている – これからのウェブには、この観点が必須では？

Slide 19

Slide 19 text

アクセシビリティは「等級」ではない • たとえばスマートフォン。これ納得いく？ – エントリーモデル：壊れやすい、ハイエンドモデル：壊れにくい（いや、あるかもだけど） • ではウェブサイトは？ – 小規模サイト：アクセシビリティ低い大規模サイト：アクセシビリティ高いはヘン – Webアプリ：アクセシビリティ低い静的ページ：アクセシビリティ高いもヘン • 対応難易度がモノによって違うのは事実 – でもユーザーはそんなことはわからない

Slide 20

Slide 20 text

ガイドラインは敵じゃない • こうしておけば最低限OK、という線＝ガイドライン – JISやWCAGは読みづらい→めんどくさい→やりたくない – 確かに。 • でも、実は以下全てに触れている。ふつうに品質向上の役に⽴つ – 情報設計／機能設計、コンテンツ作成、デザイン、フロントエンド – アクセシビリティを高めると、同時にユーザビリティ向上になることも多い • 何もないところから手をつけるより、基準があるほうがラク – 目標に向かっているかをチェックできる – セーフなら自信が持てるし、説明もできる – 構築後に運用していくときも、基準があるほうがやりやすい

Slide 21

Slide 21 text

ここまでまとめ • 基準を決めないと面倒だし残念なことに（実際なった） • なので、最初から考えよう • まずプロジェクト内で認識をあわせよう – アクセスできない＝最悪の体験 – でも、最近はどの端末でどう使われるか把握しきれない – アクセシビリティは、暗黙に求められる品質になりつつある – そのためのガイドライン。うまく使えば役に⽴つ、ラクできる • そして⽅針⽴案→提案に

Slide 22

Slide 22 text

現状を調べ、⽅針を⽴てる

Slide 23

Slide 23 text

現状を⾒てから「やる」と⾔う • よくわからないのに「やる」って言っちゃうと、気まずい • だけじゃなく、プロジェクトが荒れる – スコープ外のところに手を入れないと対応できないとか – やるって書いてあるからと無理やり対応、想定外の期間／コスト増など

Slide 24

Slide 24 text

現状分析の⽅法 • 現状：リニューアルの場合は今のサイト – そうでない場合は、他社事例で近いもの • ただし、どういう対応の可能性があるかを探る、参考程度 • リニューアルしてしまうので、大量に⾒る必要はない • ⽅針定義の段階では、あまり細かくは⾒ない – 個別のコンテンツや機能の改修計画は、別途、たな卸しの段階で⾏う

Slide 25

Slide 25 text

みるべきページ • アクセス数の多いページ • ほか、カテゴリごと – ホーム、カテゴリトップ – 一連タスク系：商品検索、カート、購入、資料請求 – 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

Slide 26

Slide 26 text

みるべきポイント = 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

Slide 27

Slide 27 text

⾒た結果をまとめる • 達成基準チェックリストの例 2010年8月版を参考利用 – http://waic.jp/docs/jis2010-test-guidelines/201211/gcl.html – 等級A以外の項目はいったん一覧から削除 • 該当コンテンツが確認範囲にあった場合は「適用」に○をつける – 例：サイトに動画ファイルがあったときだけ○をつける • 確認した結果、概ね問題ない場合は「適合」に○をつける • 問題があった場合は✕をつけ、「備考」に問題点を記載する

Slide 28

Slide 28 text

そして⽅針を⽴てる • ウェブアクセシビリティ⽅針策定ガイドラインを参考 – (1) 対象範囲、(2) 目標を達成する期限、 (3) 目標とする達成等級 (4) 例外事項、(5) 追加する達成基準 • http://waic.jp/docs/jis2010/accessibility-plan-guidelines.html • 極端に言えば「やるのか・やらないのか」決める – 決めないことが一番の問題 – プロジェクト的には「曖昧にしない」ことが大事 – ⽅針から逸れる必要がある場合も、きちんと「検討」を持つ

Slide 29

Slide 29 text

注意したいこと • 「ここはできない」となっても「できないから載せない」はナシ – Webであるだけでかなりアクセシブル – まず載せる。可能性を潰さない、諦めない – サイトは作って終わりじゃない

Slide 30

Slide 30 text

⽅針に沿って提案

Slide 31

Slide 31 text

気にされるのは「コスト」と「時間」 • 社内で合意した⽅針をクライアントに提示した際、内容面で止められることはあまりない（経験上） – 専門家が「やったほうがいい」ということを無理に止めようとする人は、ふつうは居ない • しかし、ビジネスにおいて、コストが掛かるけど役に⽴つかどうかわからないものは、実⾏されない • 「コスト」と「時間」の妥当性が説明できなければ「やらなくていいよ」となる。これが現実 • プロジェクト管理側としても、それは同じなはず – 実装者の良⼼で対応する形では、安定して対応できない

Slide 32

Slide 32 text

構築プロセスに織り込めるもの • インタラクションをあまり伴わないページなら、 JISシングルAな項目は、ほとんど当たり前に達成できるはず – マークアップを適当にしたらコストが低い、⾒出しを適当に書いたらコストが低い、とかあんまりない – altはちょっとグレーだが、原稿をちゃんと作れば大丈夫（別の回で） – 運用時を考えると、テンプレート・ガイドライン・CMSなどは必要になるかもしれない – しかし、それらもアクセシビリティだけの対応ではないメインではないので、プロセスに織り込める • こういうのは少し気をつけながら（＝⽅針を⾒ながら）普通に対応すればOK

Slide 33

Slide 33 text

「今は」別コストが発生しそうなもの • 動画、音声 – 実はJIS的にはシングルA • 1.2.1 収録済の音声しか含まないメディア及び収録済の映像しか含まないメディア • 1.2.2 収録済の音声コンテンツのキャプション • 1.2.3 収録済の映像コンテンツの代替コンテンツ又は音声ガイド – 代替コンテンツを用意する作業そのものにコストが掛かる • PDF – 公開するならHTMLと同じ扱い • JISは特定のコンテンツに依存しないため – もともとWordとかで作ってれば良いが、紙もののスキャンとか、グラフィックデータの変換だと…

Slide 34

Slide 34 text

「今は」別コストが発生しそうなもの • リッチ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 プログラムが解釈可能な識別名・役割及び設定可能な値 – 設計と実装もそうだが、チェックにもコストが掛かる • 「コストが掛かるならやらなくていい」という「壁」への対抗が必要

Slide 35

Slide 35 text

ここまでまとめ • 現状を調べて⽅針を⽴てよう • そんなに細かく⾒ずとも、概ねつかめればOK • ⽅針はあいまいさを残さず、きっちり決める – WAICの各種ガイドラインを上手く利用しよう • いざ提案。当たり前のものは当たり前に対応でOK • しかしコストを掛けないと対応できないものもある • しかもシングルAだったりする。どうする？

Slide 36

Slide 36 text

壁への対抗

Slide 37

Slide 37 text

受け身を取る編 • 当たり前ラインの底上げ – 例：WAI-ARIA、roleの設定ぐらいなら織り込める • http://www.w3.org/TR/aria-in-html/ • 既にあるものを使う – 例：JQueryUIつかう • http://jqueryui.com/ • サイト制作プロセスを改善 – 例：テンプレート、モジュール、自動化

Slide 38

Slide 38 text

攻めにいく編 • コンテンツ／機能制作のプロセスを改善 – プロトタイピング、コンテンツ執筆プロセスに手を入れる • ROIを説明できるようにする – コントラストが高いほうがバナーがクリックされたという事例 • http://www.slideshare.net/marippe/dx-for-16804775 • ただし、資料でも示されている「なぜそうなったか」まで踏み込まないと、なかなか説明しづらい

Slide 39

Slide 39 text

ルールを変える編 • アクセシビリティ対応状況を白日の下に晒す – 例：自治体サイトアクセシビリティ調査 • 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

Slide 40

Slide 40 text

ルールを変える編 • 「価値」の⾒⽅を変える – 例：「日常のプチ不自由を⾒つけて解決する」という裏ワザとしてまとめる • Twitterで「アクセシビリティ」を検索すると、 iPhoneのアクセシビリティ機能が裏技として出回っている – http://zerobase.jp/blog/2013/01/accessibility.html • モチベーションの元になるウェブサービスを作る – Google • マシンリーダビリティの向上＝クローラビリティ／インデクサビリティの向上 – Facebook • OGP、一気に普及

Slide 41

Slide 41 text

そのためには

Slide 42

Slide 42 text

時にはおこせよムーブメント • たとえば「Web標準が流⾏って、定着したのはなぜだろう？」と考えてみる • 連続性を持って取り組む。 1回で諦めない。転んでも泣かない • [良エントリ紹介] アクセシビリティとコミュニティ、未来へのアプローチ – 私たちの持つ技術とWebをつかった「社会の仕組みへのアプローチ」を考える

Slide 43

Slide 43 text

http://www.hitoyam.com/web/2013/12/24_0240.html

Slide 44

Slide 44 text

http://www.hitoyam.com/web/2013/12/24_0240.html

Slide 45

Slide 45 text

今回の内容を含む書籍を執筆中！ワークスコーポレーションさんから出版予定。乞うご期待！