Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Rikiya Ihara
December 04, 2014
7

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

Rikiya Ihara

December 04, 2014
Tweet

Transcript

  1. アクセシビリティ対応を
    プロジェクトに取り入れるには?
    アクセシビリティやるぞ!祭り
    by Yahoo! JAPAN・ミツエーリンクス・BA
    2014年12月4日
    伊原 力也

    View Slide

  2. 自己紹介
    • 伊原 力也
    – BA
    – シニアインフォメーションアーキテクト
    – Twitter:@magi1125
    – Facebookもやってます
    – クリエイティブユニット mokuva 所属

    View Slide

  3. http://www.jjg.net/el
    ements/translations
    /elements_jp.pdf

    View Slide

  4. サイトの目的
    • プロジェクト要件定義を行う
    • 目的・目標・スコープなどを合意する
    • 基準・プロセス・スタンスを決める

    View Slide

  5. アクセシビリティはどうするの?
    • 特に決めてない
    • 何となく言い出してない
    • ある程度はやるだろうから決めてない
    • 他のプロジェクトからコピペして資料は出した

    View Slide

  6. 結果A
    • 全員、華麗にスルー
    • 手癖・偶然・組み合わせに左右される
    • 安定度ゼロ

    View Slide

  7. 結果B
    • 気にする人がいるケース
    – ディレクター、設計時にいちおう気にする
    – デザイナー、なんとなく配色などを気をつける
    – エンジニア、実装中にできるところをやる
    • 悲しきすれ違い
    – 勝手にやることになってるんだけど…
    – なんか後から文句つけられた
    – いつかやろう…(そして、やらない)

    View Slide

  8. 結果C
    • 最初に決めてないので対応度バラバラ
    • そういうときに限って後から指摘が入る
    – 実話:公開後にコントラスト修正
    – 実話:公開後に代替テキスト修正
    • やってくれると思ってた的な反応も

    View Slide

  9. アクセシビリティ、面倒
    ……誤解だよ!

    View Slide

  10. 問題はいつ起きているか
    • ビジュアルデザイン時やフロントエンド実装時
    ……ではない!
    • 良心でカバーしてる人 ≒ 手を動かす人
    • ガイドラインに載ってるのは「具体例」
    • でも、そこまで行ったらもう遅い

    View Slide

  11. http://www.jjg.net/el
    ements/translations
    /elements_jp.pdf

    View Slide

  12. http://blog.iaspectrum.net/2013/06/25/ux_honeycomb/

    View Slide

  13. http://blog.iaspectrum.net/2013/06/25/ux_honeycomb/

    View Slide

  14. http://www.bookslope.jp/blog/2012/07/evaluationuxhoneycomb.html

    View Slide

  15. 最初に宣言しよう
    • まず「アクセシビリティ方針」を立てる
    • 最初にプロジェクト内で意思統一する

    View Slide

  16. Q. 制作メンバーに面倒がられない?
    • A. 特にそういうことはありません
    • 形になったものに対して
    「後から文句言われる」のが問題
    • 先に基準を決めていれば
    後出しじゃんけんは起きない
    • むしろ初期段階において、
    基準は「良い手がかり」になる

    View Slide

  17. Q. クライアントに面倒がられない?
    • A. 特にそういうことはありません
    • 専門家が「やっといたほうがいいよ」
    というのを止める人はいない
    • ふつうに作る分には追加コスト不要
    – 適当に作ると安くなる、というものではない
    ※ただし、お金が掛かる対応もある。後述。

    View Slide

  18. 方針の立て方

    View Slide

  19. 方針ってどう立てる?
    • リニューアルなら、とりあえず現状調査
    • そして「ウェブアクセシビリティ方針策定ガイ
    ドライン」を参照

    View Slide

  20. なぜ現状調査?
    • コンテンツを流用することがあるから
    – もともと駄目なコンテンツは何してもダメ
    – 動画や音声・PDF・複雑なUIへの対応はコスト発生
    • 運用状況を知る必要があるから
    – NGなコンテンツが生まれてしまう理由がある
    – 運用フローを無視すると公開後に崩壊する

    View Slide

  21. ざっくりでよい
    • あくまで、方針を立てるための下準備
    • この段階ではざっくりした見方でかまわない
    • 作り変えてしまうので大量に見る必要はない

    View Slide

  22. WCAG-EM
    http://www.w3.org/TR/WCAG-EM/

    View Slide

  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

    View Slide

  24. View Slide

  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

    View Slide

  26. そして方針を立てる
    • ウェブアクセシビリティ方針策定ガイドライン
    http://waic.jp/docs/jis2010/accessibility-plan-guidelines.html
    • 対象範囲
    • 目標の達成等級
    • 期限
    • 例外事項
    • 追加する達成基準

    View Slide

  27. 方針でない方針に注意
    • 「可能な限り配慮」 ←何も言ってないのと同じ
    • あいまいな書き方しない。目標はハッキリと。
    • 今はできない部分も、いつやるかをふくめて
    ハッキリと。
    • なんでも対象範囲外や例外にしたら意味なし

    View Slide

  28. View Slide

  29. 「対応しない」と決めるのも方針
    • 「無自覚に対応していない」「良心で対応す
    る」という構造が問題
    • 自覚的にやらないならやらないと決めておくの
    も、プロジェクトとしては重要
    • もちろん、それによる機会損失とかリスクとか
    考えた上で

    View Slide

  30. 注意したいこと
    • 「今はできない」「ここはできない」でも
    「できないから載せない」はナシ
    – なんでWeb使ってるの?ってレベルの本末転倒
    – コンテンツがWebにあるだけで超アクセシブル
    – まず載せる。可能性を潰さない、諦めない
    – サイトは作って終わりじゃない

    View Slide

  31. 方針と共にメンバーに伝えてみよう
    • アクセシビリティは
    WebがWebであるための前提条件。
    • アクセシビリティは「品質」基準。
    プログラムが正しく動作するのと同じ。
    • 制限のないデザインはない。
    しかし、その制限こそが創造性を高める。

    View Slide

  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:「制限」が
    創造性を高める理由

    View Slide

  33. ただし「言っといたからね」はナシ
    • 方針を了解=対応できるって話じゃない。
    オマカセにはしないこと
    • わかってる人(あなた!あなたですよ!)が
    エバンジェリストになること
    • 警察、関所、番人にならないこと。
    マサカリ投げずに付き合うこと
    • 一人でやろうとしないこと!

    View Slide

  34. 踏み出したあとは

    View Slide

  35. http://www.jjg.net/el
    ements/translations
    /elements_jp.pdf

    View Slide

  36. 問題の8割は「設計」に潜んでいる
    • 「形にする瞬間」にアクセシビリティの見地が
    あるかどうかが超重要
    • 形が定着してしまってからアクセシブルにする
    のは至難のワザ&非効率
    • もともと分かりにくいコンテンツは、
    マシンリーダブルになっても伝わりにくい

    View Slide

  37. 書籍のご案内
    • デザイニングWebアクセシビリティ
    アクセシブルな設計やコンテンツのための実践Q&A
    http://www.amazon.co.jp/dp/4862671756
    • 鋭意執筆中!予約受付中!

    View Slide

  38. もうひとつの課題

    View Slide

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

    View Slide

  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 プログラムが解釈可能な識別名・役割
    及び設定可能な値
    – 設計と実装もそうだが、チェックにもコストが掛かる
    – ブラックボックスなフレームワークを使った開発

    View Slide

  41. 壁への対抗
    • 制作フローに織り込めるものは、
    ただ普通にちゃんとやればよい
    • 「コストが掛かるならやらなくていい」
    という「壁」が問題
    • この状況の打破するためには、
    アクセシビリティの機運を
    もっと高めることが必要

    View Slide

  42. たとえば
    • 費用対効果ではなく
    投資対効果のロジックを考える
    – future-proof:将来も使い続けられる
    • マルチデバイス、ウェアラブル、スクリーンの消滅、いろんな利用
    状況、一時的な障害、法律、オリンピック、少子高齢化…
    – コンテンツの切片化と流通
    • ソーシャルメディアやアプリによって「一部が切り取られて出回
    る」という状況への準備
    • 部分的に対応しながらROIを算定する

    View Slide

  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

    View Slide

  44. たとえば
    • 「Webアクセシビリティ」だけで考えない
    • 近しい方向を見ている人同士の
    協調・乗り入れを生む
    – ユニバーサルデザイン(プロダクト)方面
    – Linked Open Data (LOD)方面
    – UX/HCD方面
    – Makers/IoT方面

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  48. アクセシビリティやるぞ!

    View Slide