水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 2012年のえび日記 > 2012年8月 > 2012年8月3日(金曜日)

2012年8月3日(金曜日)

アクセシビリティキャンプ東京#2

公開: 2012年9月4日23時20分頃

アクセシビリティキャンプ東京#2 (www.facebook.com)が開催されました。

なぜかまた二日前にモデレーターを依頼されて、「アクセシビリティに関する自動テスト・CI」を担当することになりました。

以下、当日に映しながら議論していたメモ。長いうえにまとまっていませんが、そのまま掲載しておきます。

アクセシビリティに関する自動テスト・CI

  • 自動テストって何、CIって何。
  • 自動テストでどこまでできるのか?
自動テスト
  • どれくらいできるのか?
  • お金になる仕事ではやっていない。
  • ワールドスペースを買ってくれたお客様にはやっている。
  • 実際、全部はできない
  • 複数ページ一括でできるものは少ない。
  • 売り物でも意外に少ない。
  • miChecker
使ってみてどうか
富士通 WebInspector
  • 2006年版 ガイドラインと同じタイミングで作られた?
  • 結局、自動化できているところは○か×か
  • 結果、ほぼ目視になる
  • altが適切かどうかまでは見てくれない
  • あればあっただけ確かに楽
  • どこまで見てくれるのがベストなのか
HAREL
  • 同じ問題
  • 要件を満たすことができなかった
  • 言葉の問題、「子供」→「子ども」などをチェックしたい、というニーズが満たせなかった
Dreamweaver拡張のチェッカー
  • 分かりづらかった
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も

何というか、あんまりうまくモデレートできた気がせず、申し訳ないです。もう少し論点を整理しておくなど、もう少し準備ができれば良かったのかもしれません。

関連する話題: Web / アクセシビリティ

JavaScript勉強会 五回目

公開: 2012年8月26日13時50分頃

「ツッコミながらスクラムで学ぶ JavaScript勉強会」、第五回目。

今回の範囲は「よくわかるJavaScriptの教科書 (www.amazon.co.jp)」のLecture1-9~Lecture1-10 (テキストの74ページ~79ページ)。第五回目の課題を見ながらの進行です。

課題 5-1: 前回の振り返りと感想 (基本課題)

前回の感想や疑問など。

インクリメント演算子には前置 (++i) と後置 (i++) がありますが、実際にはどんなときにどちらが使用されるのか、という質問が出ました。……答えとして出たのは、「そもそもインクリメントは使わない」。

また、前回出たswitchの特殊な使い方について少し。

課題 5-2: 前回の応用 (チャレンジ課題)

掛け算の「九九」の表を出力するという課題。

多くの人がfor文の入れ子普通に実装する中、処理をいくつもの関数に分けたり、MultiplicationTableBuilderなるオブジェクトを設計して処理させる人がいたり。

仕様でまったく言及されていない表のスタイルについて工夫を凝らした解答もあり、なかなか楽しめました。

課題 5-3: Lecture1-9~Lecture1-10を読んで (基本課題)

テキストの74ページ~79ページを読んでの疑問や感想。

複数の方から、配列リテラルについての質問が出ました。var foo={a:1,b:2} のようなオブジェクトリテラルの書き方は説明されているのですが、var foo=[1,2,3] のような配列リテラルの書き方は説明されていないという。

あとは for in について、順序は決められていないという話とか。たいていのブラウザは格納された順に返す実装になっているようですが、そうでない挙動をしたとしても文句は言えません。メニューを表示するサンプルが出ていますが、仕様的には順序が不定なため、場合によってメニューの並び順が異なるということが起こりえるという話になります。

課題 5-4: 今回の範囲の練習 (基本課題)

都道府県を表示するという問題。

配列を使うよ派、連想配列使うよ派などいろいろ。並び順を考慮するかどうか、都道府県以外の選択肢 (「その他」「海外」など) にも対応できるようにするかなど、拡張をどこまで想定するかで結構分かれたりしました。

Lecture1-9~Lecture1-10はどうなの? (チャレンジ課題)

いわゆるツッコミですが、一部を紹介。

  • for inの説明が軽すぎるのではないか。順序が保持されない点、ライブラリ等でつけられたメソッドまで列挙してしまう点など、注意点が多数あるはず。
  • 配列の説明で背番号を持ち出すのは適切で無いのではないか。順序を持つ、というのが配列の重要な特徴だが、背番号には欠番もあり、順序を表すわけではない。

関連する話題: Web / JavaScript / / ツッコミながらスクラムで学ぶ JavaScript勉強会

最近の日記

関わった本など