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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

ements/translations
/elements_jp.pdf

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

方針の立て方

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

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

View Slide

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

View Slide

View Slide

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

View Slide

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

View Slide

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

View Slide

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

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

View Slide

踏み出したあとは

View Slide

ements/translations
/elements_jp.pdf

View Slide

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

View Slide

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

View Slide

もうひとつの課題

View Slide

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

View Slide

「今は」別コストが発生しそうなもの
• リッチ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

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

View Slide

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

View Slide

たとえば
• 白日の下に晒す
– 例：自治体サイトアクセシビリティ調査
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

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

View Slide

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

View Slide

アクセシビリティやるぞ！

View Slide

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

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

Rikiya Ihara

More Decks by Rikiya Ihara

Featured

Transcript