10章「アクセシブルなJavaScript」
- 1 JavaScriptの歴史
- 2 なぜJavaScriptは悪評を立てられてしまったのか
- 3 JavaScriptについて考慮すべきこと
- 3-1 ユーザーは何を必要としているか
- 3-2 動的なJavaScriptのためのガイドライン
- 4 控えめなJavaScript
- 4-1 ふるまいのレイヤーとしてのJavaScript
- 4-2 インタラクティブ性
- 4-3 ルック・アンド・フィール
- 4-4 新しいウインドウ
- 4-5 要素の可視性
- 4-6 時代遅れのテクニックと代替方法
- 5 アクセシブルなフォームとJavaScript
- 6 まとめ
JavaScriptのアクセシビリティ問題
- ユーザビリティを阻害（3節）
-
- 前のページに戻れない
- ステータスバー乗っ取り
- 右クリック禁止！
- 勝手にポップアップ・ウィンドウ
- スクロールバーがない
- JavaScriptが使えなければ利用できない
-
- 基本操作部分（ナビゲーションメニュー，ボタン）をJavaScriptで作成
- Ajax：マウス操作に依存，音声で利用できる？
- 後で紹介：Googleアプリケーションのアクセシビリティ問題
著者の主張
出しゃばらない（控えめな）JavaScript
－JavaScriptを利用できる時はユーザの利用体験を向上させる－
- ユーザがJavaScriptを利用できる・有効にしていることを仮定できない
- ユーザ環境（ブラウザ，画面サイズ）を仮定できない
- よいコード例を示す
- DOMの利用方法（4-1項）
- 正しいコーディング作法(10章全体)
- 適切な，ポップアップウィンドウの作り方（4-4項）
- 適切な，要素の隠し方（4-5項）
- アクセシブルなフォームの作り方（5節）
3-2項 動的なJavaScriptのためのガイドライン
- ブラウザではなく，標準に従う
- 基本的なマークアップはJavaScriptに依存すべきではない
- HTMLを生成するときは，HTMLを書くときと同じルールに従う
- ユーザとユーザーエージェントの制限に注意する
- やりすぎない方がいいこともある
- あまり多くの決まりごとを無視しない
- アクセスするものすべてをテストする
- すべてを分離しておく
4-1項 構造，表現，ふるまいの分離
p346 「図10-3 Web製作の3つのレベル」
- HTML：構造
- CSS：表現
- JavaScript：ふるまい
DOMを使えば，JavaScriptとHTMLやCSSを分離できる．
- プログラミングが可能
- インタラクティブ性の強化（5節）
- HTMLもCSSも制御可能
- 適切なポップアップ・ウィンドウを生成可能（4-4項）
さて，
次スライドをご覧ください
ARIA
この本を離れて，JavaScript，特に動的なWebサイト(RIA)のアクセシビリティを見てみたい．
ARIA: Accessible Rich Internet Applications
- 技術仕様と支援技術の対応状況
- Google RIAのケーススタディ
Google RIAのケーススタディ
渡辺研究室の2007年度卒業研究「JavaScriptを利用した動的なWebのアクセシビリティ」（松田理沙）から，GoogleのRIAのアクセシビリティ問題のケーススタディを紹介．（12月6日のWIT研究会＠お台場で発表予定）
- 調査対象：iGoogle と Googleドキュメント
- 支援技術：IBM ホームページ・リーダー 3.04 と Internet Explorer
- 調査方法：WCAG 2.0 ワーキングドラフトのチェックポイントを念頭に，情報提示，理解，操作の観点から問題点をピックアップ
- 観察した問題点を大きく3つに整理
Google RIAの問題点1a：基本操作
（HPRを使う場合）キーボードでは操作できないボタン
- iGoogle：タブの横にあるボタン
- マウス：クリックすると「タブの編集、共有、削除」のメニューが表示
- キーボード：タブでもカーソルキーでもフォーカスを当てることができない
- iGoogle：ガジェットのボタン3つ
- マウス：クリックしてメニュー（設定を編集、共有）、縮小化、削除
- キーボード：タブでもカーソルキーでもフォーカスを当てることができない
- Googleドキュメント：トップページのフォルダーツリー
- マウス：「＋（－）」をクリックするとツリーが開く（閉じる）
- キーボード：タブでもカーソルキーでもフォーカスを当てることができない
部品の実態は、「空の要素＋背景画像」。読み上げる対象すらない。
Google RIAの問題点1a：基本操作
（HPRを使う場合）キーボードでは操作できないメニュー
- Googleドキュメント：トップページのメニュー
- マウス：クリックするとメニュー（文書、表計算などの新規作成）が開く
- キーボード：カーソルキーで移動し「新規作成」と読むが、Enterキーを押しても「リンクではありません」。
ソースに「新規作成」という文字はあるが、divやspanで作った部品であり、リンク要素やフォームコントロールを用いていない。
Google RIAの問題点1b：文字入力
（HPRなどの）支援技術では文字を入力できない
- キー入力の取り合い：
- RIA：文字入力をJavaScriptが処理して、ショートカットキーとして処理、HTMLを書き換えて文字を入力
- スクリーンリーダ：ユーザのキー操作をフックしてショートカットとして処理
- 例：Google文書の作成場面
- H：HPRの見出しジャンプとして処理されるので、Hを入力できない
- Enter、Backspace、Deleteも駄目
- Ctrl+S：Google文書の「保存」機能ではなく、HPRの「ページの保存」が実行される
RIAでは、インターラクティブな操作性を実現するために、キー入力を処理する必要がある。リッチな画面出力のためには、HTMLを書き換える必要がある。でも、支援技術もキー入力を処理する必要がある。
Google RIAの問題点2：ソースの追加と削除
ドロップダウンメニューの表示・非表示に伴うソースの処理が不適切なので、音声で利用するユーザが混乱
- Google文書：「スタイル」メニューを選択
- 画面表示：「スタイル」メニューの直下に隣接してメニュー項目が表示
- ソース上：HTMLソースの最後に追加。音声ユーザは気がつかない
- メニュー項目を閉じる
- 画面表示：画面から消える（display:none など）
- ソース上：残る。音声ユーザには読み上げられるので、混乱する
画面表示と音声表示（ソースの上から順）のずれ
動的なページ書き換えの問題（次ページ参照）
Google RIAの問題点3：動的なWeb
RIAの動的なWebページ（の一部）書き換えを音声ユーザに伝える方法？
- メニューの表示・非表示
- iGoogle：ガジェットの配置を変更
- HPRは配置変更に気付かず、元のソースの順番で読み上げる
- HPRが配置変更に気付いて、ソースの先頭から読み上げ直す
Ajax：ユーザの操作に応じて、あるいは任意のタイミングで、動的にページの一部が変更される。
WAI-ARIAのlive属性は、この問題の解決策。but 有効かどうかわからない。
おわりに
- 研究：何が問題で、どう解決すればよいのか（人間の認知）
- Web標準（3層の分離）：HTML、CSS、JavaScript
- コンテンツの制作者：アクセシブルなライブラリ、ガイドライン、コーディングのGood Practice
- 技術仕様：WAI-ARIA、IAccessible2
- 支援技術：IE、FF、...、スクリーンリーダ、音声ブラウザ
- ユーザ：RIAの理解、支援技術操作のスキル
Ajaxを初めとするRIAのアクセシビリティへの取り組みは始まったばかり。
日本の支援技術の向上が急務。
このスライドの公開URL： http://www.comm.twcu.ac.jp/~nabe/UAI/20071109/nabe/
『Webアクセシビリティ』
- I. Webアクセシビリティの影響
- II. アクセシブルなWebサイト実装
- 技術の概要，支援技術
- コンテンツ，ナビゲーション，データ入力，CSS，JavaScript，Flash，PDF
- アクセシビリティ・テスト，WCAG 2.0，ケーススタディ
- III. 法律と政策
- 付録
- 用語集，リハ法508条，PAS78，日本のスクリーンリーダー，日本の最新動向
|
|
