Flashのアクセシビリティチェックも可能なアクセシビリティチェックツールとして、オープンソースで提供されている「ACTF aDesigner」(エーデザイナー)を紹介します。
aDesignerのインストールから基本的な使用方法を紹介した後、Flash用のチェック項目をどのようにこのツールで確認するのか紹介します。準備としてサンプルファイルをダウンロードしてください。
インストール
EclipseのaDesiner配布サイトからダウンロードしたZIPファイルを解凍するだけで使用できます。
使用方法
aDesigner.exeを起動します。
このツールでは「HTML」「OpenDcument」「GUI」「Flash」という4つがチェック可能です。アプリケーションを起動すると4つのチェック対象ごとにモードが分かれておりどれを使用するのか尋ねられます。
このモードの違いは表示するレポート情報の組み合わせが異なるだけですので、FlashアクセシビリティモードとHTMLアクセシビリティモードを行き来してテストするなど可能です。
今回はWebに埋め込まれたFlashをチェックするために「Flashアクセシビリティ」を選択します。
Flashアクセシビリティモードでは、Adobeが提唱しているFlashアクセシビリティで気をつけるべき項目すべてを確認できるようになっています(ただし色に関してはHTMLアクセシビリティモードを利用します)。
モードを選択するとワークスペースになります。この中には、小さなウィンドウがたくさんあり、それらをビューと呼んでいます。ビューは、独立させたり別のビューとドッキングしたり自由にレイアウトできます。
Flashを開く
サンプルのcheck_noaccessibility.htmlとcheck_accessibility.htmlを開いてみましょう。ここに使用されているSWFはAS3、FlashPlayer9用です(ソースのflaファイルはCS4用です)。
このムービーには、アクセシビリティ設定を施したオブジェクトが並べてあります。
その内容は「名無しムービークリップ」「名無しボタン」「名ありムービークリップ(イトウ ムービークリップ)」「名ありボタン(ノリ ボタン)」「名ありUIコンポーネント(名前の最初にUIと付けた)」です。
aDesignerを起動したら、モード選択ダイアログでFlashアクセシビリティモードにします。モード選択ダイアログが出てこないときは[ファイル]→[モード選択]で同じダイアログを開くことができます。
解析を開始するためにデスクトップにある対象のHTMLファイルをビューにドラッグします。
Flashをチェックするために注目するビューは「GUIレポート」「GUIアウトライン」「GUIサマリー」「GUIイベント」「GUIプロパティ」です(残念ながら「Flashアウトライン」は正しく動作しないようです(筆者調べ)。結果的にGUIアクセシビリティモードでも必要な情報は見れます)。
GUIレポート
GUIレポートビューではアクセシビリティの問題点を一覧表示します。ここで問題がないこと=完全なFlashコンテンツではありませんが、最初のハードルを超えているのは間違いないでしょう。問題点が認められたらクリックしてブラウザビューでどのオブジェクトなのかを確認できます。
GUIアウトライン
GUIアウトラインビューでは設定されている内容をMSAAオブジェクトのツリー構造で確認できます。つまり、設定した値が正しくMSAAに引き継がれているかどうかを知ることができます。
もし、Flash以外の要素が並んでいるWebをチェックしているなら、Flashだけの情報にするために「Flash項目のみ表示する」を選択します。
GUIサマリー
GUIサマリービューではアプリケーションに含まれるテキスト情報の一覧を表示します。これはスクリーンリーダーが読み上げる直接の情報をテキストにしています。たとえば、●●という名称のボタンオブジェクトであれば「●●ボタン」となります。
Flash項目だけに出力結果を絞っていないとき、Flashコンテンツに該当する部分は「フラッシュ開始」~「フラッシュ終了」までとなります。
GUIイベント
GUIイベントビューはFlashが発生するMSAAイベントを表示します。実際にユーザが操作して別のボタンにフォーカスがあたると、その読み上げる内容が表示されます。ここに表示される経過秒数は、読み上げが始まってから、次の操作に移るまでの秒数です。
GUIプロパティ
GUIアウトラインで選択しているオブジェクトの詳細を表示します。具体的にどのプロパティにどのような値が設定されているのか、スクリーンリーダーが読み上げない情報も知ることができます。
いずれかのビューでオブジェクトをクリックすると、ブラウザビューでは該当するボタンにキーボードを使用してフォーカスしたのと同じ状態(focusRectプロパティをfalseにしていなければ黄色い四角が出ます)になります。また、GUIイベント以外のビューはリンクしており該当するオブジェクトに関する情報が表示されるようになります.
Adobeのチェックポイントに沿って確認
次に示したのはAdobeが提唱しているFlashアクセシビリティのチェックポイント(Adobe - Flash Accessibility Design Guidelines)です。
抜き出すと、次のようになります(筆者訳)。
- テキスト情報を付加―Assign text equivalents
- アニメーションは制御可能に―Animation
- コンポーネントはアクセシビリティをオンに―Use accessible components
- 読み上げ順序は正しく―Enable control over reading order
- キーボードだけで操作可能に―Facilitate keyboard access to all controls
- 字幕をつけよう―Provide captions
- 映像の制御手段を提供―Provide accessible video controls
- サウンドの制御手段を提供―Enable control over audio playback
- 構造を明確に―Expose structure
- 操作の状況を明示的に―Expose state of controls
- 色情報だけに頼らないデザイン―Use color wisely
- ガイドラインだけでなく実地テストを―Validate for accessibility
基本的には「GUIレポートビューのエラーに対処しチェックする」し、目視やサウンドのチェックは動作確認となります。また、11番目の色に関するチェックはHTMLアクセシビリティモードでロービジョンにて確認できます。
色を確認するーHTMLアクセシビリティのロービジョン
モード切替ダイアログから、HTMLアクセシビリティを選択します。
次に、メガネアイコンをクリックしてロービジョン描画を実行します。弱視や色覚異常の場合、どのように見えるかがロービジョンタブにシミュレーションされますので、目視で確認します。
最後に
Adobeが提唱している12番目のチェックポイントでは、どんなツールで自動化が進んでも念のためにユーザと同じスクリーンリーダー(PC-TALKERやJAWS、Focus Talkなど)でのチェックを忘れないように、と言っています。
もっと言うなら、これらの項目すべてをクリアしたからと言えども謙虚にユーザの声に耳を傾けていくことを提案します。
Flashなどの技術的なことに限らずアクセシビリティの考え方そのものも日々進化していっています。極端な話、1年前には無理だったことが1年後には当然になることもあります。しかし、そこで落胆していては前に進めません。
私は常に現在の手法がベストか疑い率先して開拓するつもりでアクセシビリティに挑んでいく気持ちが大切だと考えています。