アクセシブルな flash デザインの...

アクセシブルな Flash デザインの

ベストプラクティス

Macromedia, Inc.シニアプロダクトマネージャー

ボブリーガン

2003 年 10 月

本ホワイトペーパーは、『Best Practices for Accessible Flash Design』Bob Regan 著の翻訳です。スクリーンリーダーでのテストは、英語環境のみで行われています。

Copyright © 2002 Macromedia, Inc. All rights reserved.

The information contained in this document represents the current view of Macromedia on the issue discussed as of the date of publication. Because Macromedia must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Macromedia, and Macromedia cannot guarantee the accuracy of any information presented after the date of publication.

This white paper is for information purposes only. MACROMEDIA MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Macromedia may have patents, patent applications, trademark, copyright or other intellectual property rights covering the subject matter of this document. Except as expressly provided in any written license agreement from Macromedia, the furnishing of this document does not give you any license to these patents, trademarks, copyrights or other intellectual property.

{INSERT OUR MARKS IN THE DOCUMENT} are either trademarks or registered trademarks of Macromedia, Inc. in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Macromedia, Inc. 600 Townsend Street San Francisco, CA 94103 415–252–2000

目次

はじめに ............................................................................................................................ 1

1. Flash におけるアクセシビリティの理解 ..................................................................... 2 1-1. ユーザーの要件を定義する .........................................................................................................3

2. アクセシビリティのベスト・プラクティス ................................................................ 5 2-1. テキスト情報を提供する............................................................................................................5

2-2. アニメーションを制御する .......................................................................................................9

2-3. サイト構造に関する情報を提供する ....................................................................................... 11

2-4. キーボードのみでの操作を保証する ...................................................................................... 12

2-5. 音声読み上げ順序を制御する ................................................................................................. 14

2-6. コンポーネントのアクセシビリティを有効にする ................................................................ 17

2-7. キャプションを提供する ......................................................................................................... 19

2-8. 色を思慮深く使用する ...........................................................................................................20

3. 参考資料......................................................................................................................21

Page iii

アクセシブルな Flash デザインのベストプラクティス

はじめに

このドキュメントは、Macromedia Flash におけるアクセシブルなデザインの基礎を確立するためのものです。Flash では数え切れないほどの様々なコントロール、オブジェクト、そしてアプリケーションが提供されるため、アクセシブルなデザインのためにこれだけ守ればいいというようなルールをガイドラインのようにまとめるのは困難です。ゆえに、アクセシブルなデザインのよりどころとなるのは、検証に検証を重ねる以外にありません。このことはアクセシブルなデザインを実践する上でも骨の折れる作業であるともいえます。アクセシブルな Flash コンテンツを制作するためには、デザイナーは少なくともスクリーンリーダーおよびその他の支援技術について一定の理解を要求されます。

このドキュメントは、以下の章から構成されています。

Flash におけるアクセシビリティの理解

Flash アクセシビリティのベスト・プラクティス

参考となるリソース

初の章では、ユーザーの要件を定義することでいくつかの利用事例を示します。利用事例は、それぞれの事例における問題点、テクニックそしてツールの説明とともに、デザインのプロセスにおけるペルソナとして紹介されている場合があります。

この初の章では、Flash におけるアクセシビリティを理解しながら、Flash アクセシビリティの概要とそれに伴うチャレンジについて、Flash におけるアクセシブルなデザイン手法と同様に説明します。

2 つめの章では、Flash におけるアクセシブルなデザインテクニックとして推奨するベスト･プラクティスをご紹介します。

テキスト情報を提供する

アニメーションを制御する

サイト構造に関する情報を提供する

キーボードのみでの操作を保証する

音声読み上げ順序を制御する

コンポーネントのアクセシビリティを有効にする

キャプションを提供する

色を思慮深く使用する

3 つめの後となる章では、アクセシブルなデザインの参考資料を紹介します。

Page 1


1. Flash におけるアクセシビリティの理解

Macromedia Flash MX と Flash Player 6 のリリースにより、Macromedia Flash はアクセシブルな Flash プラットフォームの実現に向けての第一歩を踏み出しました。現時点では、Freedom Scientific 社の JAWS（バージョン 4.5 以上）と GW Micro 社の Window Eyes（バージョン4.2 以上）、そして Dolphin 社の HAL が Flash をサポートしています。それまで Flash は認知障害を持つ方々に対してコンテンツをより理解しやすくするものでしたが、このリリースによって視覚障害を持つ方々も Flash コンテンツを利用できるようになったのです。

Flash は、Flash ムービーの情報をスクリーンリーダーやその他の支援技術に伝達するのにマイクロソフト・アクティブ・アクセシビリティ（MSAA）を使います。MSAA は、Flash Player とスクリーンリーダーとの間で情報の橋渡しをする役割を果たしています。Macromedia Flash Player は、スクリーン上のオブジェクトのリストを作成して、それを MSAA の“データ・ツリー”に記録します。そして、スクリーンリーダーは、Flash コンテンツを読み上げるときにはこのリストを読み上げます。スクリーン上に変化があると、MSAA のデータ・ツリーは更新されます。ムービーが動きを伴って変化すると、スクリーンリーダーはそのムービーの先頭部分に戻って、またそのリストを上から順に読み上げてしまいます。

デフォルトでは、Flash ムービーのテキスト・オブジェクトはスクリーンリーダーで読み上げられます。スクリーンリーダーは、スクリプトによってボタンおよびムービー・クリップを識別することもできます。スクリーンリーダーは、スクリーン上のグラフィック要素を発見して、その意味を伝達するのです。Flash ムービーのグラフィック要素あるいはアニメーション要素にテキスト情報を付加するかどうかはデザイナー次第です。テキスト情報は、Flash のアクセシビリティ・パネルあるいは ActionScript によって付加できます。アクセシビリティ・パネルの“子オブジェクトをアクセス可能にする”というオプションあるいは“.forcesimple”のようなプロパティは、HTML にはないものです。デザイナーは、このドキュメントやマクロメディアの Web サイトにあるアクセシビリティ関連情報などを参照して、こういったプロパティや関連するテクニックについて学ぶ必要があるでしょう。

スクリーンリーダーと MSAA は、目の見えるデザイナーには全く馴染みのない方法で、視覚障害を持つユーザーに Flash コンテンツを提供します。スクリーンリーダーは常にムービーの先頭から読み上げを開始したり、一度に一つのことしか読み上げることができなかったりするので、Flash コンテンツの構造によってはどうしてもアクセシブルに出来ない場合があります。例えば、複数のオブジェクトが同時に様々な変化を起こすことがよくあります。ユーザーは、そういった複数の要素に基づいた意思決定を要求され、素早く反応しなくてはなりません。全盲の人にとってこういったことはリアルな世界では容易なことでもスクリーンリーダーを使っているときには極めて困難なものです。

Page 2


1-1. ユーザーの要件を定義する

アクセシビリティは、しばしば 2 つの異なる基準を用いて定義されます。それは、規格への準拠と障害者ユーザーにとってのユーザビリティです。前者の基準は、後者と比べると容易に定量化できます。規格の内容を読んでからコンテンツを点検して、その規格に適合しているかどうかを判断すればよいのです。全てのチェックポイントをクリアしていれば、そのコンテンツはアクセシブルであると判断できます。ところが、アクセシビリティというのは実際にはもっと複雑なものです。も一般的なアクセシビリティ・ガイドラインである、米国リハビリテーション法 508条スタンダードと W3C のウェブ・コンテンツ・アクセシビリティ・ガイドラインは、HTML コンテンツのアクセシビリティを主眼に書かれています。部分的に共通点はあるものの、HTML におけるアクセシビリティの問題点と Flash におけるそれは基本的に異なるのです。幾つかのガイドラインで要求していることに対処するテクニックも Flash においては全く違います。同時に、Macromedia Flash のコンテンツに関する問題点の中には、HTML には全く存在しないものがあるのです。

こうしたことから、Flash コンテンツを既存のガイドラインに準拠するということ以上の方法で検証することが非常に重要です。Flash コンテンツをアクセシブルだと判断するためには、障害者ユーザーも含めたユーザーの利用特性に照らし合わせて検証しなくてはなりません。デザイナーは、しばしば様々なブラウザや OS の組み合わせでコンテンツをチェックするのと同じように、そういった利用特性をふまえた検証を行うことを習慣づけることが重要です。多くのデザイナーにとって、これが Flash のアクセシブルなデザインにおけるも大変な作業となります。特に、目の見えるユーザーだけを対象にしがちなデザイナーにとっては、スクリーンリーダーに慣れ親しむまでが一つの大きな壁になることでしょう。

この章は、デザイナーの皆さんにとても基本的な利用特性を理解してもらうためのものです。以下のリストを、コンテンツにおける対処法を検討して障害者ユーザーが使用しているツールを理解するのに役立ててください。このリストで言及していることが全てではありませんが、低限知っておくべきことをまとめてあります。

全盲のユーザー：

操作や入力にはキーボードのみを使う

マウスは使わない

ムービーの情報をスクリーンリーダーの音声読み上げで取得する

ムービーに関する情報をその他の音声情報で取得する

画面拡大ツールは使わない

スクリーンリーダーが提供する音声情報を耳で聞くよりも点字ピンディスプレイを好んで使うこともある

弱視のユーザー：

操作や入力のほとんどをキーボードで行う

軽度の弱視の場合は、マウスを使っていることもある

ムービーに関する情報を取得するのに画面拡大ツールを使うことが多い

ムービーに関する情報を取得するのにスクリーンリーダーを使うことも多い

Page 3


ムービーに関する情報を取得するのにスクリーンリーダーと画面拡大ツールの両方を使うこともある

スクリーンリーダーを使っている場合は、スクリーンリーダーが提供する音声情報を耳で聞くよりも点字ピンディスプレイを好んで使うこともある

色覚に特性のあるユーザー：

操作や入力にはマウスやキーボードを使う

スクリーンリーダーや画面拡大ツールは使わない

特定の色だけで表現していない視覚的な情報を必要とする

運動障害のユーザー（主に、腕や指先が不自由なユーザー）：

マウスを使うことが出来ない場合がある

操作や入力の多くをキーボードで行う

全ての操作や入力をキーボードで行うこともある

ムービーに関する情報は視覚で取得できる

聴覚障害のユーザー：

キーボードとマウスの両方を使う

ムービーの情報を視覚のみで取得する

Page 4


2. アクセシビリティのベスト・プラクティス

アクセシブルなデザインのベスト・プラクティスをご紹介します。ただし、これらが全てではありませんし、まだ改善の余地があるものも含まれます。個々のアプリケーションについて先に述べた利用特性をふまえたものになっているかどうかは、デザイナーの皆さんが各自で判断してください。

2-1. テキスト情報を提供する

スクリーンリーダーは、ステージ上のグラフィック要素やアニメーション要素の内容を理解することはできません。そのため、デザイナーはグラフィック要素を説明する簡潔なテキスト情報を提供する必要があります。テキスト情報は、ムービー全体あるいはムービーの中の一つのオブジェクトやムービー内のオブジェクトのグループのいずれかに対して提供できます。

ムービー全体にテキスト情報を提供する

ムービー全体を同等の代替テキストで表現できる場合には、そのムービー全体に対するテキスト情報を提供しなくてはなりません。例えば、シンプルなアニメーション、バナー広告、あるいはそれ以外にアクセシブルにする方法がないような複雑なムービーがこれに該当します。

テキスト情報は、アクセシビリティ・パネルの自動ラベルにある“名前”フィールドに記述します。一般的に“名前”フィールドに記述するテキスト情報は、できるだけ簡潔にそのムービーの機能について説明するのがよいとされています。テキスト情報が長くなる場合には、“説明”フィールドに記述します。しかしながら、IBM の JAWS for Windows と GW Micro, Inc. の Window Eyesといったスクリーンリーダーはデフォルトではその内容も読み上げてしまいます。結果として、“説明”フィールドに記述された長いテキスト情報は、そのアプリケーションやページをユーザーにとって長ったらしくてうんざりするものになってしまいます。

ムービー全体に対してテキスト情報が提供されている場合には、そのムービーの子オブジェクトはアクセス不可能にしなくてはなりません。そうすることで、ムービー内のアニメーションがスクリーンリーダーの音声読み上げの更新を引き起こすことを未然に防ぐことができます。また、コンテンツのアクセシビリティについての自動的なテストもしやすくなります。

テキスト情報は、アクセシビリティ・パネルを使って提供することが出来ます。下にあるスクリーンショットでは、テキスト情報が”名前”フィールドに「惑星の周囲を軌道を描きながら回る月のアニメーション」というように記述されています。

Page 5


ActionScript を用いてテキスト情報を提供するには、オブジェクトにアクセシビリティ情報を付加する必要があります。name の値が割り当てられたら、アクセシビリティ・オブジェクトは更新されなければなりません。これは変化があるときに全てのオブジェクトに対して一度だけ実行されればよいのです。オブジェクトの各インスタンスを更新する必要はありません。以下のサンプルコードに、そのムービー全体に新しいオブジェクトを作る 1 行があることに着目してください。次に、.name プロパティに値が割り当てられ、そして子オブジェクトが.forcesimple プロパティでアクセス不可能にされています。ActionScript プロパティを、対応するアクセシビリティ・パネルのフィールドとともに以下の一覧表で示しています。

_root._accProps = new Object(); _root._accProps.name = "Moon orbiting planet"; _root._accProps.forcesimple = true; Accessibility.updateProperties();

以下の一覧表は、ActionScript におけるアクセシビリティ・プロパティです。

表 1： ActionScript のアクセシビリティ／プロパティ

プロパティタイプアクセシビリティ・パネルで該当する機能対象

.silent boolean ムービーをアクセス可能にする Make Movie Accessible/ オブジェクトをアクセス可能にする Make Object Accessible (逆のロジック inverse logic)

ムービー全体

ボタン

ムービークリップ

動的なテキスト

入力テキスト whole movies buttons movie clips dynamic text input text

.forceSimple boolean 子オブジェクトをアクセス可能にする Make Child Objects Accessible (逆のロジック inverse logic)

ムービー全体

ムービークリップwhole movies movie clips

Page 6


プロパティタイプアクセシビリティ・パネルで該当する機能対象

.name string 名前 Name ムービー全体

ボタン

ムービークリップ入

力テキスト whole movies buttons movie clips input text

.description string 説明 Description ムービー全体

ボタン

ムービークリップ

動的なテキスト

入力テキスト whole movies buttons movie clips dynamic text input text

ムービークリップにテキスト情報を提供する

HTML とは異なり、Flash においては全てのムービークリップあるいはボタンにテキスト情報を提供する必要はありません。ここで想定しておくべき事例が少なくとも 3 つあります。

事例 1：ムービークリップを silent に設定する

まず、単に装飾だけを目的にしていたり、繰り返していたり、あるいは何も情報を伝達していない場合があります。そういったムービークリップは、アクセス不可能にしなくてはなりません。アクセシビリティ・パネルで“ムービーをアクセス可能にする”というオプションを非選択にします。

Page 7


これと同じことを ActionScript を使って設定することも出来ます。以下のサンプルコードは.silent プロパティを用いてアクセス不可能にしているオブジェクトの例です。

_root.logo_mc._accProps = new Object(); _root.logo_mc._accProps.silent = true; Accessibility.updateProperties();

事例 2：ボタンおよびコントロールのラベル

Flash には、“自動ラベル”というオプションがあります。テキスト・オブジェクトがボタン内で使われていたり、ムービークリップがボタンとして使われていたりすると、Flash Player はそのテキスト・オブジェクトがそのボタンのテキスト情報であると解釈します。こういった場合には、ムービークリップの子オブジェクトがアクセス可能であることが重要です。ただ一つのテキスト・オブジェクトのみがラベルとして使われることが可能で、そのテキスト・オブジェクトはボタンのヒットエリア内に完全におさまっていなくてはならない、ということを念頭においておくことが重要なポイントです。

自動ラベルは、ムービーで使用されるラジオボタンおよびリスト・ボックスのようなコンポーネントにも適用されます。Flash Player は、コントロールの上あるいは左に位置するテキスト・オブジェクトがラベルであると解釈します。繰り返しますが、ただ一つのテキスト・オブジェクトのみがラベルとして用いられます。

もし、テキスト情報がアクセシビリティ・パネルか ActionScript のどちらかで name プロパティにより設定されている場合は、その値が自動ラベルより優先され、自動ラベルを無効にはしません。自動ラベルはアクセシビリティ・パネル上でのみ無効にすることが可能で、一度設定されると変更することはできません。

以下のスクリーンショットは、自動ラベルのオプションが有効になっている例です。

Page 8


事例 3：ムービークリップあるいはボタンのテキスト情報

テキスト情報をムービー内のある一つのオブジェクトに割り当てるには、アクセシビリティ・パネルを使うしか方法はありません。そのテキスト情報は、単なる説明というよりは、そのオブジェクトの機能を説明したもので、かつできるかぎり簡潔なものである必要があります。そうすることで、そのムービーがユーザーにとって言葉数の多いものやうんざりするものになってしまうことを避けることができます。

“説明”フィールドは、長い説明を記述するために使います。しかしながら、JAWS と Window Eyes は両方ともデフォルトでこの内容を読み上げてしまいます。つまり、この事例のような場合には、あまり使うメリットがありません。

2-2. アニメーションを制御する

Flash はもはやアニメーションツールという域を超えていますが、それでもさまざまな目的のためにアニメーションを制作するのによく使われています。Flash ムービーでアニメーションを使うときに考慮すべき 3 つのポイントがあります。

子オブジェクトを隠す

先にも述べたように、画面上での変化が繰り返されるとスクリーンリーダーの読み上げを繰り返し更新させてしまうことになります。ユーザーがコンテンツを後まで読み上げさせようとしても、スクリーンリーダーの読み上げが何度も途中でムービーの先頭に戻ってしまうので、スクリーンリーダーのユーザーは後まで読み上げさせるのをあきらめてしまいます。

スクリーンリーダーが読み上げを更新するのを避けるために、アニメーションを含むムービークリップの子オブジェクトを隠してください。アクセシビリティ・パネルの“子オブジェクトをアクセス可能にする”を非選択にすると隠すことができます。ActionScript を使用している場合は.forcesimple プロパティを true に設定してください。

動きを止める

ユーザーに画面上のテキストを読んでもらいたいときは、画面上で何かが絶え間なく繰り返し動かないようにしてください。学習障害や認知障害を持ったユーザーは、画面上で何かが動いているとコンテンツへの集中力が散漫になってしまいます。テキストと同じ画面で何らかの動きを使うことは許容範囲ですが、しばらくしたら画面上の動きは止めなくてはいけません。

点滅を避ける

Page 9


Flash ムービーを画面の大部分で 1 秒以上点滅することを避けるのはとても重要なことです。ユーザーが画面に接近して見ているときに、特定の周波数で点滅すると感光性のてんかんの発作を引き起こす恐れがあるからです。ユーザーが使用しているマシンのスペックに依存しているので、明滅の危険な周波数を正確に算出することはできません。そのため、画面を明滅させないことはとても重要です。

Page 10


2-3. サイト構造に関する情報を提供する

スクリーンリーダーは、Flash ムービーのレイアウトや構造を理解する手がかりをユーザーに提供することはできません。そのため、複雑な構造のムービーはその構造をユーザーに説明し、コントロールが複数の状態（例：チェックあり/なし）を持っている場合にはそれをユーザーに知らせることが重要です。ただし、そのムービーが説明を要するほど複雑かどうかや、そのコントロールが何らかの手がかりとなる情報を要するかどうか、といったことについての明確な判断基準というものは存在しません。こういった判断はそれを制作しているデザイナーに委ねられることになります。

説明を提供する

ムービーに幾つかの操作部分がある場合には、ムービーの概要、ムービー内にある操作部分、そしてキーボード・ショートカットについての説明を提供することが重要です。さらに、それ以上の情報がどこで得られるのか、あるいはカスタマーサポートに連絡するにはどうしたらよいか、といった情報も提供するとよいでしょう。

具体的な実装方法はいろいろ考えられます。まず、Flash ムービーの別スクリーンや HTML ページの別ページでこういった情報を提供することができるでしょう。その場合には、そのページへのリンクを“サイト情報”といったラベルのボタンにして各ページの先頭あたりに置くことをお奨めします。このように簡潔なラベルにすることで、そのアプリケーションを必要以上にくどいものにしないですみます。このボタンは必要であれば画面上には見えないように隠すこともできるでしょう。ただし、目の見えるユーザーもその情報にアクセスできるように、同じ情報への 2つ目のリンクをスクリーンのどこか（例えば、下のほう）に配置するようにしてください。

状態を明らかにする

Flash を使うことでデザイナーは数えきれないほど多種多様なユーザーインターフェースをデザインすることができます。ムービー内で操作部分やスクリーンの状態を視覚的な合図や表現で示すような場合には、その情報を画面の変化とともに更新される動的なテキストでも提供する必要があります。

以下の例で説明しましょう。このムービーでは、タブが下に下りてくることで現在どのスクリーンがアクティブな状態なのかを示しています。ただし、これは視覚的には有効な表現なのですが、このような視覚的な表現をスクリーンリーダーのユーザーに伝えることはできません。

Page 11


スクリーンリーダーのユーザーにも同じように情報を提供するために、サイト ID の下に画面のタイトルを示す隠しテキストを配置します。これはスクリーンリーダーのユーザーに情報を提供するためのものなので、目に見える必要はありません。画面が切り替わったら、このテキストもそれに応じて更新されるようにします。

2-4. キーボードのみでの操作を保証する

マウスで操作可能な全ての操作部分を、キーボードでも同じように操作可能にすることが重要です。これは、マウスを操作できないスクリーンリーダーのユーザーだけでなく、腕や指先が不自由な運動障害を持ったユーザーにとってもアクセシブルにするためです。Flash Player はマウスに依存したイベントを自動的にキーボードでもアクセシブルにすることで、キーボードのみでの操作を容易にします。しかし、Flash デザイナーがよく使うテクニックの中に使うべきではないものが 2 つあります。そして、デザイナーはキーボードのみでの操作が容易になるようにキーボード・ショートカットを付加すべきです。さらに、HTML に Flash ムービーを埋め込んだウェブページにおいて、バージョン 6 以前の Flash Player が引き起こす問題についても認識しておかなくてはなりません。

on (click) { getURL(index.html); }

例えば、上記のスクリプトはウェブページを開くために使われることがあります。ボタンとして用いられているムービークリップのインスタンスに直接関連付けられています。そうではなくて、このスクリプトはムービーのフレーム、それも初のフレームにあるべきです。スクリプトを修正すると以下のようになります。

_root.home_mc.onRelease = function () { getURL(index.html); }

Page 12


「ヒット」状態だけのボタンを作らない

ボタンシンボルのタイムラインに含まれる「ヒット」状態で形を定義した空のボタンクリップのことを”ヒットエリア”といいます。デザイナーは、それをテキスト・オブジェクトの上に重ねて配置し、スクリプトだけを変更することで、一つのライブラリ・オブジェクトを繰り返して利用している場合があります。このテクニックの問題は、ボタンクリップの「アップ」状態が空だと、スクリーンリーダーがそれをボタンとして認識できないことです。

この問題を解決するのは至って簡単です。「アップ」状態に透明のムービークリップを置くことで、スクリーンリーダーはそのボタンを認識できるようになり、ユーザーはそのボタンを使えるようになります。

基本的な操作部分にキーボード・ショートカットを割り当てる

多数の操作部分を持つ複雑なアプリケーションでは、キーボード・ショートカットを用いてアプリケーションを操作できるようにすることでユーザーの使い勝手が飛躍的に向上します。運動障害を持つ多くのユーザーにとっては、キーを押すことはとても困難な場合があるのです。キーボード・ショートカットを用いることで、ユーザーが目的を達成するのに必要なキー操作の数を減らすことができます。

アクセシビリティ・パネルのショートカット設定または ActionScript の.shortcut プロパティを使うだけでは十分ではありません。キーボード・ショートカットを作成するには、listner イベントの定義と、その listener に関連付けられたスクリプトが必要です。MSAA はショートカット設定の値を単に読み上げるだけで、listner が自動的に生成されるわけではありません。さらに、このドキュメントを書いている時点では、MSAA のこの機能をサポートしているスクリーンリーダーはありません。

HTML との混合ページでフォーカスを閉じ込めてしまう ActiveX の問題

バージョン 6 以下の Macromedia Flash Player を使っていると、Flash ムービーの中に入ったフォーカスがそのムービーの外にある HTML のコンテンツに移動できなくなります。これはActiveX コントロールの全てに共通する問題です。も簡単な解決方法は、Flash Player をバージョン７以上にアップデートすることです。

バージョン 6 以前の Player におけるこの問題を解決するために、HTML と Flash コンテンツを修正するテクニックがあります。詳細は以下の URL を参照してください。

http://www.sonokids.com/tabnew.html

Page 13

http://www.sonokids.com/tabnew.html


2-5. 音声読み上げ順序を制御する

Flash ムービーの音声読み上げ順序を制御することは、おそらくアクセシブルな Flash デザインにおいても重要かつ難しいポイントです。Flash ムービーのデフォルトの音声読み上げ順序は左から右に、上から下にという予測の付く順序にはなりません。そのため、スクリーンリーダーでは Flash ムービーのコンテンツを理解しづらいことがあります。以下の例で説明しましょう。3行に並んだアルファベット文字は、音声読み上げでもアルファベット順に読み上げられると考えるのが自然です。

しかし、実際の読み上げ順序は行を行ったり来たりして、以下のようになります。

A, B, C, D, E, F, I, G, J, H, K, L, M, N, O, R, P, S, Q, T, U, V, W, X, Y, Z

音声読み上げ順序を制御するには、3 つ方法があります。もシンプルな方法は、ムービーの物理的なサイズをできるだけ小さくすることです。２つめは、ActionScript を使用して音声読み上げ順序を制御する方法です。そして、３つめは全く同じコンテンツを 1 行に並べてオフステージに置くというものです。

ムービーの読み上げ順序は開発プロセスの初期段階からスクリーンリーダーを使ってテストすることがとても重要です。Flash ムービーが完成してからその音声読み上げ順序を制御するのは大変な作業になります。ムービーの制作過程でスクリーンリーダーを使いながら音声読み上げ順序を検証していくことで、どのようなときに問題が発生して、どのようにそれを修正すればよいか、ということを理解できるようになります。

ステージのサイズを制限する

幅が 300 ピクセル以下で、かつオブジェクトが 1 行あるいは 1 列に並んでいる、小さな Flash ムービーは、特に音声読み上げ順序を制御する必要はありません。ポップアップする別ウィンドウの小さなアニメーションやアプリケーション、1 行に並んでいるナビゲーション・バーや 1 列に並んでいるアプリケーションなどが、これに該当します。

Page 14


ActionScript を使って音声読み上げ順序を制御する

ActionScript を使うのが、音声読み上げ順序をも正確に制御する方法です。デザイナーはActionScript の.tabindex プロパティを使って音声読み上げ順序を正確に制御することができます。ActionScript においては、音声読み上げ順序と Tab キーによる移動順序は全く同じです。しかし、ActionScript を Flash ムービーの音声読み上げ順序を制御するのに使うときは、ムービー内のテキストや装飾のための要素を含む全てのインスタンスに.tabindex プロパティを割り当てる必要があります。

ムービーで使用している全てのインスタンスにインスタンス名が必要

音声読み上げ順序を制御する際には、ステージ上のどのインスタンスにもインスタンス名がついていることを確認することが重要です。具体的には、ムービーで使用している全てのコンポーネントをはじめ、全てのテキスト、ムービークリップ、そしてボタンなどです。

スタティックなテキストを使用しない

スタティックなテキスト・オブジェクトにはインスタンス名をつけることができないため、スタティックなテキストだけのインスタンスがあると全ての音声読み上げ順序をデフォルトに戻してしまいます。ActionScript で音声読み上げ順序を制御するには、ダイナミックなテキストを用いる必要があります。これはアプリケーションで使用されているフォントに影響を及ぼし、全体のファイルサイズにも影響を与えることがあります。Flash でのフォントの取り扱いについては、以下の URL を参照してください。

http://www.macromedia.com/support/flash/ts/documents/flashfonts.htm

オフステージや読み上げられない要素を含める

.tabindex の値はムービー全体の全てのインスタンスに割り当てられる必要があります。全てのインスタンスというのは、目に見えない要素やオフステージにあるもの、他のインスタンスの背面に隠れているものも含みます。重要なのは、これらの要素がスクリーンリーダーのユーザーには読み上げられない場合は._visible プロパティが false に設定されているか、.silent プロパティが true に設定されているべきだということです。これは、ムービーの初には目に見えなくて後で目に見えるようになる要素にも.tabindex の値が割り当てられていなければならないということでもあります。

Page 15

http://www.macromedia.com/support/flash/ts/documents/flashfonts.htm


連続して swf ファイルがロードされるときの音声読み上げ順序の制御

複数の子 swf ファイルが連続して親ムービーにロードされるような場合には.tabindex 値のリストは子ムービークリップの中にリストされなくてはなりません。しかし、重要なのはそれぞれの.tabindex 値リストはユニークである必要があることです。例えば、親ムービーにロードされる 2 つの子ムービーにそれぞれ”1”、”2”、”3”という.tabindex 値を持った3 つの要素があるとします。スクリーンリーダーは、初にロードされたムービーの”1”の値の部分を読み上げて、それからもう一つのムービーの”1”の値を読み上げます。次に、スクリーンリーダーは初のムービーの”2”の値の部分を読み上げて、2 つめのムービーの”2”の値の部分を読み上げる、といった順序になるのです。初のムービーのコンテンツを読み上げてから 2 つめのムービーのコンテンツを読み上げるようにするためには、初のムービーの.tabindex 値のリストには”1”、”2”、”3”を割り当てて、2 つめのムービーの.tabindex 値のリストには”4”、”5”、”6”を割り当てなくてはなりません。これらの値は連続している必要はありませんが、ユニークでなければなりません。

サードパーティの修正＆チェックツールを使用する

このドキュメントを書いている時点では、Flash コンテンツの読み上げ順序設定をサポートするツールが Hi Software 社から提供されています（ただし、日本語版はありません）。ACCRepairというこのツールは、Flash のエクステンションとして販売されています。インスタンス名のないものを探し出し、スタティックなテキストをダイナミックなテキストに変換して、読み上げ順序を設定することが可能です。このツールは、ステージ上に多数のインスタンスがあるような場合にとても役立ちます。ACCRepair に関する詳細は以下の URL を参照してください。

http://www.macromedia.com/software/flash/extensions/accrepair/

オフステージ・コンテンツを使って読み上げ順序を制御する

アプリケーションのほとんどがダイナミックに生成されるコンテンツの場合は、事前に音声読み上げ順序を指定することは困難です。そのようなアプリケーションの場合には、コンテンツのコピーをオフステージに 1 行に並べておくことで音声読み上げ順序を制御できます。オンステージのコンテンツはスクリーンリーダーに読み上げられないように全てアクセシブルでない状態でレンダリングさせます。オフステージに置くコンテンツを 1 行に並べておくことで、音声読み上げ順序を制御できます。

ただし、この方法には 2 つの欠点があります。1 つめは、ムービー内のオブジェクトの数が増えて、ファイルサイズとムービーのパフォーマンスに影響を及ぼすことです。2 つめは、画面拡大ツールを使っているユーザーがオフステージのコンテンツがオンステージの目に見えているコンテンツとかち合っているのに気づくかもしれないという点です。画面拡大ツールはステージ上の要素のサイズを拡大するだけでなく、中央に移動させます。オンステージのコンテンツがアクセシブルでないと、画面拡大ツールのフォーカスがオフステージのコンテンツにあたってしまい、ユーザーは訳が分からなくなってしまいます。この方法はスクリーンリーダー検出と一緒に使われますが、ユーザーはスクリーンリーダーと画面拡大ツールの両方を同時に使用しているケースもあることを考慮に入れることが重要です。

Page 16



スクリーンリーダー検出

これはスクリーンリーダーのユーザーだけにメリットがあるので、しばしばスクリーンリーダー検出と一緒に用いられます。Flash は MSAA をスクリーンリーダーの存在を検出するのに使えるという点で JavaScript より優れています。スクリーンリーダーが起動していてフォーカスがFlash コンテンツにあると、Accessibility.isActive() メソッドは true の値を返してきます。重要なのは、このメソッドを呼ぶには少しの時間待つ必要があり、待たなければ正しくない結果を引き起こす可能性があるという点です。ムービーの初のフレームでこのメソッドを呼ぶのではなく、このメソッドをムービーの初のボタンに適用してください。

オフステージのコンテンツを作る

Accessibility.isActive() メソッドが true の値を返してくると、スクリーン上のコンテンツはアクセシブルではなくなります。おそらくも容易な方法は、オンステージのコンテンツの全てを一つのムービークリップに置いて、そのムービークリップの.silent プロパティを trueに設定することです。スクリーンリーダーのユーザーは、オンステージのコンテンツを目で見ているユーザーと一緒にそのコンテンツを利用しているかもしれないので、ムービークリップの見た目を変えるよりも.silent プロパティを使うことのほうが望ましいでしょう。

次に、オフステージのコンテンツは 1 列にロードされます。この列はムービーの高さと一致している必要はありません。オンステージのコンテンツに変化があると同時にオフステージのコンテンツも更新されることが重要です。

2-6. コンポーネントのアクセシビリティを有効にする

Macromedia Flash MX 2004 から、以下のアクセシブルなコンポーネントが提供されています。

シンプルなボタン

チェックボックス

ラジオボタン

ラベル

テキストフィールド

テキストエリア

コンボボックス

リストボックス

ウィンドウ

アラート

データ・グリッド

Page 17


各コンポーネントに対して、デザイナーや開発者は enableAccessibility()コマンドを使ってアクセシビリティ・オブジェクトを有効にするだけでよいのです。そうすることで、ムービーがコンパイルされる際に、コンポーネントにアクセシビリティ・オブジェクトが追加されるようになります。コンポーネントにオブジェクトが追加されるとそれを簡単には削除できないので、これらのオプションはデフォルトではオフになっています。そのため、デザイナーや開発者が各コンポーネントのアクセシビリティを有効にすることがとても重要なのです。これは各コンポーネントに対して 1 回だけ行えばよくて、コンポーネントの各インスタンスごとに行う必要はありません。ラベルのコンポーネントに追加されたサンプルの例を以下に示します。

import mx.accessibility.LabelAccImpl; LabelAccImpl.enableAccessibility();

繰り返しますが、このコードは各コンポーネントにつき 1 回だけ追加してください。ムービーの初のフレームにこのスクリプトを記述するのがベストです。それぞれのコンポーネントに必要

なコードは以下の通りです。

シンプルなボタン import mx.accessibility.ButtonAccImpl; ButtonAccImpl.enableAccessibility();

チェックボックス import mx.accessibility.CheckBoxAccImpl; CheckBoxAccImpl.enableAccessibility();

ラジオボタン import mx.accessibility.RadioButtonAccImpl; RadioButtonAccImpl.enableAccessibility();

ラベル import mx.accessibility.LabelAccImpl; LabelAccImpl.enableAccessibility();

コンボボックス import mx.accessibility.ComboBoxAccImpl; ComboBoxAccImpl.enableAccessibility();

リストボックス import mx.accessibility.ListAccImpl; ListAccImpl.enableAccessibility();

ウィンドウ import mx.accessibility.WindowAccImpl; WindowAccImpl.enableAccessibility();

アラート import mx.accessibility.AlertAccImpl; AlertAccImpl.enableAccessibility();

データ・グリッド import mx.accessibility.DataGridAccImpl; DataGridAccImpl.enableAccessibility();

Page 18


テキストフィールドとテキストエリアのコンポーネントにはコードを追加する必要はありません。これらのコンポーネントのアクセシビリティは Flash Player によって自動的に実装されます。

2-7. キャプションを提供する

Flash はオーディオやビデオコンテンツを提供するためによく使われます。あらゆる音声情報には、同等の役割を果たすテキスト情報をキャプションとして提供するべきです。キャプションを提供するには主に 3 つの方法があります。キャプションは、すでにキャプションが付いているオーディオコンテンツをインポートするか、ステージ上にテキストオブジェクトを直接置くか、または XML でキャプションデータをストリーミングする、といった方法で提供可能です。

すでにキャプションのついたオーディオコンテンツをインポートする

Flash にキャプションを付けるのにシンプルなのは、すでにキャプションが付けられているコンテンツをインポートすることです。この方法には、デザインの自由度やアプリケーションのフレキシビリティが制限されるというデメリットがあります。Flash に直接キャプションを付けるのであれば、デザイナーはフォーマットやユーザーインターフェースをより自由に考えることができます。

テキストをステージ上に直接置く

Flash コンテンツにキャプションを提供する 2 つめの方法は、テキスト・オブジェクトをステージに直接置くことです。この方法は、デザイナーに要求される作業としてはも退屈なものですが、オーディオコンテンツとキャプションをも正確に同期させることが可能です。この方法が特に優れているのは、キャプションの体裁や動きを微調整できたり、複数の話者のキャプションの位置を変えたりして提供できるという点です。

Hi Software 社のツールを使うと、テキスト・オブジェクトをステージ上に直接置く方法でキャプションを容易に提供することができます。キャプションを提供する上で、唯一大変なのは、音声情報をテキストに書き起こす作業です。音声認識ソフトウェアの進歩にはめざましいものがありますが、音声情報を問題なく自動的にテキスト化できるレベルには至っていません。音声情報をテキスト化したものをキャプションにするのによく使われるツールが 2 つあります。Hi Software 社の Hi Caption SE と、NCAM（National Center for Accessible Media）の MAGpieです（ただし、現時点ではまだ日本語には対応していません）。これらのツールは、キャプション用のテキストを各スクリーンごとに分割して、各スクリーンごとのタイミングを設定することができます。

Hi Caption SE には、この情報をタイムライン上のテキスト・オブジェクトに直接変換できるという利点があります。Macromedia Breeze のプレゼンテーションのように、XML を使用することで sandbox violation を引き起こすような状況のときに特に有効です。

Page 19


XML キャプションデータをストリーミングする

Flash ムービーにキャプションデータを提供するもフレキシブルで容易な方法は、リアルタイムでのキャプションデータのストリーミングです。これは、Hi Software 社の Hi Caption SE および NCAM（National Center for Accessible Media）の MAGpie の両方で可能です（ただし、現時点ではまだ日本語には対応していません）。どちらも Flash のためのキャプションデータを専用の XML ファイルで生成します。このファイルは、Flash Player のパフォーマンスを向上るために、SAMI や SAPI といったキャプションの規格の XML データを適化したものです。

HiCaption SE には、この XML ファイルをインポートしてクローズドキャプション・インターフェースで提供するコンポーネントがあります。デザイナーはキャプションとして表示されるテキストやアイコンのルック＆フィールを変更することが可能です。

Hi Caption SE に関する詳細情報（英語）：

http://www.macromedia.com/software/flash/extensions/hicaption/

MAGpie に関する詳細情報（英語）：

http://ncam.wgbh.org/webaccess/magpie/

2-8. 色を思慮深く使用する

Flash デザイナーが使用できる色は数えきれないほどありますが、Flash コンテンツで使用する色を選定する際に重要なのは、色覚に特性のあるユーザーや弱視のユーザーへの配慮を十分行うことです。つまり、色だけで情報を伝達しないようにするということです。例えば、“次へ進むには赤いボタンを、前に戻るには緑のボタンをクリックしてください”というのは典型的な例です。色の違いで情報を表現するのはよいのですが、同時にそれ以外の手段でもその違いを示さなくてはなりません。同じ例でも、“次へ進むには右側にある赤いボタンを、前に戻るには左側にある緑のボタンをクリックしてください”というように、色だけではなく位置に関する情報も加えてあれば問題はありません。

色に関するもう一つのポイントは、読みやすさを確保するために文字色と背景色のコントラストが十分かどうかを確認するということです。方法の一つとして、そのアプリケーションが白黒で表示されたときに、色の違いが識別できるかどうかを考えてみるとよいでしょう。コントラストが不十分な色の組み合わせは、そのページ上の要素を読み取るのをものすごく困難にします。

Page 20


http://ncam.wgbh.org/webaccess/magpie/


Page 21

3. 参考資料

Macromedia Accessibility Resource Center

http://www.macromedia.com/accessibility/

Rich Media Accessibility Center http://ncam.wgbh.org/richmedia/mediatypes/FL.php

Bob Regan Accessibility Blog

http://www.macromedia.com/go/bobregan/

Flash Accessibility Working Group

http://groups.yahoo.com/group/accessflash/

HiCaption SE


ACC Repair


http://www.macromedia.com/accessibility

http://www.macromedia.com/accessibility/

http://ncam.wgbh.org/richmedia/mediatypes/FL.php

http://www.macromedia.com/go/bobregan

http://www.macromedia.com/go/bobregan/





アクセシブルな flash デザインの...

Documents