水無月ばけらのえび日記

富士通 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は警告してくれる

CI / Continuous Integration

• ユニットテスト、ソフトウェア全体のテストを自動で行う
• 仕様を満たしていないと絶対にリリースできない
• 最初にテストを作る、テストドリブンを前提にした手法

• 「このウェブサイトはこのアクセシビリティ基準を満たす必要がある」という定義 → テスト
• この画像のaltはこれ、という定義があればアラートを出せる
• 人間がチェックするのではCIにはならない

• 画面提示までは自動化できるのでは
• ページが変わるたびにチェック → 人間がチェックしてください、という項目が多量 → チェックのスピードが鍛えられる
• 変更された部分が微少なのに全て警告を出すのが問題なのではないか。
• worldspaceには、一度見た部分はスキップできる機能がある。
• 「アクセシビリティに問題が生じる可能性がある部分」を全部挙げられる

• 文法エラー→×
• 動画→点滅しないか、etc.
• 知識がないと目視でのジャッジができない

• ソーシャルボタンをつけたら文法エラー
• Dreamweaverで書いた瞬間にエラーが出る、とか
• ツールを信用しすぎて漏れてしまうという問題もあるのではないか

• 自動テストを使いこなすスキル?
• 完全な自動化のためには、最初からこの画像にはこのalt、など、コンテンツ全てが決まっている必要がある
• 現実問題として難しいのではないか
• 自動化できるところは自動化して、無理なところはあきらめる
• lang属性などはチェックできるはず?
• アラビア語のサイト、韓国語のサイト→全く分からない、altが適切であるかどうかといわれても……。
• 設計がある前提で、ツールチェックできるものをチェック
• 人間が判断する必要がある部分を理解しておく
• モジュールレベルで担保する
• モジュール化はアクセシビリティにも貢献

意味のある順序

• 見出しの前に関連画像がある、というマークアップはNG
• そうでないようにモジュールを作成する必要がある

意味のある順序

• 前景色と背景色
• →画像上の色のチェックは可能?
• 富士通のツールで行える
• 文字の有無の判定すら難しいので、完全自動化は難しい
• 機能豊富なツールでAAまでチェックすると大変なことになる

何を目的にしているのか

• JISに準拠するための試験のコストを下げたいのか?
• 制作の環境作りをしたいのか?

• 自動化は無理という空気
• どこをどうすれば何を改善できるのか
• プロセスを変えることで、ある程度自動化できる可能性があるのではないか