アクセシビリティキャンプ東京#2
2012年8月3日(金曜日)
アクセシビリティキャンプ東京#2
公開: 2012年9月4日23時20分頃
アクセシビリティキャンプ東京#2 (www.facebook.com)が開催されました。
なぜかまた二日前にモデレーターを依頼されて、「アクセシビリティに関する自動テスト・CI」を担当することになりました。
以下、当日に映しながら議論していたメモ。長いうえにまとまっていませんが、そのまま掲載しておきます。
アクセシビリティに関する自動テスト・CI
- 自動テストって何、CIって何。
- 自動テストでどこまでできるのか?
自動テスト
- どれくらいできるのか?
- お金になる仕事ではやっていない。
- ワールドスペースを買ってくれたお客様にはやっている。
- 実際、全部はできない
- 複数ページ一括でできるものは少ない。
- 売り物でも意外に少ない。
- miChecker
使ってみてどうか
富士通 WebInspector
- http://jp.fujitsu.com/about/design/ud/assistance/webinspector/ (jp.fujitsu.com)
- 2006年版 ガイドラインと同じタイミングで作られた?
- 結局、自動化できているところは○か×か
- 結果、ほぼ目視になる
- altが適切かどうかまでは見てくれない
- あればあっただけ確かに楽
- どこまで見てくれるのがベストなのか
HAREL
- http://harel.nttdata.co.jp/wact/inputProc/inputUrlBL.do (harel.nttdata.co.jp)
- 同じ問題
- 要件を満たすことができなかった
- 言葉の問題、「子供」→「子ども」などをチェックしたい、というニーズが満たせなかった
Dreamweaver拡張のチェッカー
- 分かりづらかった
Worldspace
- http://www.mitsue.co.jp/release/20101214.html (www.mitsue.co.jp)
Add-on / アクセシビリティツールバー
- http://www.infoaxia.com/tools/wat/index.html (www.infoaxia.com)
- https://chrome.google.com/webstore/search/accessibility#detail/fpkknkljclfencbdbgkenhalefipecmb (chrome.google.com)
- https://addons.mozilla.org/en-US/firefox/addon/wave-toolbar/ (addons.mozilla.org)
miChecker
- altの重複、冗長なaltは警告してくれる
- altを判断するための支援機能
- altを表示させる
- これ一つあれば全てまかなえる、というものはない?
- ツールによって機能が違う
テストに関して
- みんなどういう風にテストをしているのか
- ページごとにチェックするのか、全体をチェックするのか
- どのタイミングでチェックするのか
- つぶせるところはページを作っているときに単体でテストしてつぶす必要があるのでは
- 制作の人が作ったものがQAに
- 要件、仕様としてアクセシブルでないものが作られてしまう場合がある
- 最初からやる、あらゆる段階でやるのが望ましい
CI / Continuous Integration
- ユニットテスト、ソフトウェア全体のテストを自動で行う
- 仕様を満たしていないと絶対にリリースできない
- 最初にテストを作る、テストドリブンを前提にした手法
- 「このウェブサイトはこのアクセシビリティ基準を満たす必要がある」という定義 → テスト
- この画像のaltはこれ、という定義があればアラートを出せる
- 人間がチェックするのではCIにはならない
- 画面提示までは自動化できるのでは
- ページが変わるたびにチェック → 人間がチェックしてください、という項目が多量 → チェックのスピードが鍛えられる
- 変更された部分が微少なのに全て警告を出すのが問題なのではないか。
- worldspaceには、一度見た部分はスキップできる機能がある。
- 「アクセシビリティに問題が生じる可能性がある部分」を全部挙げられる
- 文法エラー→×
- 動画→点滅しないか、etc.
- 知識がないと目視でのジャッジができない
- ソーシャルボタンをつけたら文法エラー
- Dreamweaverで書いた瞬間にエラーが出る、とか
- ツールを信用しすぎて漏れてしまうという問題もあるのではないか
- 自動テストを使いこなすスキル?
- 完全な自動化のためには、最初からこの画像にはこのalt、など、コンテンツ全てが決まっている必要がある
- 現実問題として難しいのではないか
- 自動化できるところは自動化して、無理なところはあきらめる
- lang属性などはチェックできるはず?
- アラビア語のサイト、韓国語のサイト→全く分からない、altが適切であるかどうかといわれても……。
- 設計がある前提で、ツールチェックできるものをチェック
- 人間が判断する必要がある部分を理解しておく
- モジュールレベルで担保する
- モジュール化はアクセシビリティにも貢献
意味のある順序
- 見出しの前に関連画像がある、というマークアップはNG
- そうでないようにモジュールを作成する必要がある
意味のある順序
- 前景色と背景色
- →画像上の色のチェックは可能?
- 富士通のツールで行える
- 文字の有無の判定すら難しいので、完全自動化は難しい
- 機能豊富なツールでAAまでチェックすると大変なことになる
- デザイナーにも意識が必要
- デザイナーが色依存のグラフを作る
- マークアップレイヤーではなく、デザイナー、ディレクターにも知っておいてもらう必要がある
- どこでアラートが出せるのか?
- どこで気づくポイントがあるのか
- できあがったものに対するチェックだけでなく、作っている途中のチェックが必要なのではないか
- 文法エラーのついでに……?
- Photoshopには色覚障害のエミュレートモードがある
- 日立のやつ http://www.hitachi.co.jp/universaldesign/products/business/assistance_for_color_generation/index.html (www.hitachi.co.jp)
- 個々のツールの中にチェック機能が入っているのがベストなのではないか
- 全てWebで使うわけではない、Web専用のツールではないから難しいかも
- 影をつけて視認性を上げるなど、デザインの工夫でクリアできる場合も多い
何を目的にしているのか
- JISに準拠するための試験のコストを下げたいのか?
- 制作の環境作りをしたいのか?
- 自動化は無理という空気
- どこをどうすれば何を改善できるのか
- プロセスを変えることで、ある程度自動化できる可能性があるのではないか
- HTML5: 登場する場所でマークアップが変化?
- ひどいサイトをチェックするときはツールも役に立つ
- チェックするまでもない
- レガシー: テストコードがない
- テストコードがあるサイトはアクセシブルである
- モジュール設計がきちんとしていて、モジュールのアクセシビリティが保証されている、ということがテストへの第一歩
- テスト可能である、ということが重要
- どんなちゃんとしたサイトでも図のaltは難しい。
- テキストの中のスペースが何を意味しているのか判断するのも難しい
- どうしても自動的に見られないものは多い
- Word文書でも同じことが言える
- 先は長い
- PowerPointの画像がどう読み上げられるか
- 動的なページの自動テストは難しい
- JavaScriptが使われているコンテンツ
- ソフトウェアCIでは、ブラウザエンジンでレンダリングした結果をテストする手法もある
- テストがナンセンスなJSも
何というか、あんまりうまくモデレートできた気がせず、申し訳ないです。もう少し論点を整理しておくなど、もう少し準備ができれば良かったのかもしれません。
- 「アクセシビリティキャンプ東京#2」にコメントを書く
- 前(古い): JavaScript勉強会 五回目
- 次(新しい): ドラゴンクエスト10 オンラインプレイ