ソフトウェア > Lotus > Lotus Developer Domain >

Iris Today Archives

アクセシブルなノーツ・アプリケーションの設計

by Shannon Rapuano
レベル：すべて
対象：すべて
原文の掲載：2000年11月1日

Iris Today Archivesの原文（US）

インデックス

	アクセシビリティーと R5 アプリケーション
	視覚障害者のノーツ・アプリケーションの使用例
	R5 アプリケーションにおけるアクセシビリティーのチェックリスト
	フォームにおけるポイント
	グラフィックにおけるポイント
	ボタンにおけるポイント
	ナビゲーションにおけるポイント
	埋め込みコントロールについてのポイント
	まとめ

利用しているアプリケーションは見た目と同じくらい音にこだわっているでしょうか？アプリケーションはそうであるべきです。

アプリケーションの設計で重要な部分として、使いやすいユーザー・インターフェースが挙げられます。しかしながら、設計者はアプリケーションの利用者に身体障害者がいるという可能性を見落としがちです。

すべてのユーザーが利用できるようなアプリケーションの設計には、アクセシビリティー (可触性、接近性、利用のしやすさ) についての基本的な知識とその問題を解決する知識が要求されます。幸いにも、晴眼のユーザーにとっては見やすく、盲目のユーザーには聞きやすく、万人に使いやすいアプリケーションを設計することはそれほど難しいことではありません。

アメリカ合衆国やその他の国の新しい法律により、連邦議会や州議会は、情報技術に対するアクセシビリティーを求めています。アメリカ合衆国では 508部門は、連邦局に対し、情報技術を体に障害のあるすべての従業員と顧客が利用できるように要求しています。2001年から、連邦局が購入するすべての新しい情報技術の設備やサービスはアクセシブルでなければなりません。少なくとも13 の州では同様の法律を適用しています。もしあなたがアプリケーションの設計者ならば、アクセシビリティーの標準を満たすような設計方法やテスト方法を知っているかということが非常に重要になってきます。

この記事では、体に障害のある人々が R5 のアプリケーションを利用しているときに遭遇する一般的な事柄について議論し、アクセシビリティーのガイドラインに適合するようにアプリケーションを開発、テストする方法を学びます。

アクセシビリティーと R5 アプリケーション

アクセシビリティーとは、障害者のために製品を使いやすくするものです。障害者は、情報技術にアクセスするための補助技術を利用するでしょう。補助技術には、ハードウェアもソフトウェアも含まれています。たとえば、盲目の人は点字ディスプレイや、画面上の情報を読み上げてくれるスクリーン・リーダーといったものを利用するでしょう。音声認識のような代わりの入力装置や、キーボードの代わりとなるようなものを障害者は利用するでしょう。アプリケーションがアクセシビリティーの要求を満たしていなければ、補助技術をアプリケーションで用いることはできません。

R5 では新しいアクセシビリティーの機能を提供しています(詳しくは、Iris Today の Notes R5:Accessibility をご覧下さい)しかしながら、アプリケーションの設計者は、これらの機能をアプリケーションと一体化させなければなりません。次に、障害者がノーツやドミノのアプリケーションを利用するときに遭遇する最も一般的な問題について述べます。

視覚障害のあるユーザー
視覚障害のあるユーザーは次のような部分で問題に遭遇します。

キーボード・ナビゲーション
視覚障害のあるユーザーは、マウスを使えないのでキーボードでアプリケーションを操作します。アプリケーションが、キーボードでは難しい操作やキーボードではできない操作を利用している場合、そのアプリケーションはアクセシブルではありません。
フィールド・ヘルプ
スクリーン・リーダーは、入力フィールドに関係のあるテキスト・ラベルを正確に特定することができないので、フィールド・ヘルプを用いてユーザーに情報を提供します。ユーザーがある入力フィールドを選ぶと、スクリーン・リーダーはテキスト・ラベルではなくそのフィールドのフィールド・ヘルプを読み上げます。フィールド・ヘルプが存在しせず、ユーザーが入力フィールドを選択した場合、スクリーン・リーダーはただ「編集」とだけ言います。
グラフィック（画像）
アプリケーションが画像を使っていたとしても、アクセシブルであり続けることは可能です。補助技術を用いてテキストやテキスト・ラベルの代わりに画像についての情報を提供します。代替テキストを用いると、スクリーン・リーダーは画像の代替テキストを読み上げ、視覚障害のある人でも、健常者と同様の情報を得ることができます。代替テキストが無ければ、スクリーン・リーダーは「画像」と言うだけなので、情報を得ることができません。
Web ナビゲーション
視覚障害者は、順番に Web サイトを移動しなければなりません。ページに「ナビゲーションをスキップする」というリンクが無ければ繰り返しの多いリンクをスキップするのは容易ではありません。設計上、Web ページの各フレームに意味のあるタイトルがつけられていれば、移動しやすくなります。これらの項目が無ければ、ページの上部や下部にあるナビゲーションバーを読むためにユーザーがページ上のコンテンツを聞くまでに時間がかかってしまいます。
アクセスできないコントロール
いくつかの機能 (たとえば、ナビゲーター、テキスト・ポップアップ、Java アプレット) は補助技術からアクセスできません。アプリケーションにこのようなコントロールが含まれており、情報を得る代替方法が提供されていなければ、アプリケーションはアクセシブルではありません。

動作困難なユーザー
動作困難なユーザーは次のような問題に遭遇します。

キーボード・ナビゲーション
動作困難なユーザーは移動のためにマウスを使うことができないので、キーボードを用いた移動が必要となります。

聴覚障害のあるユーザー
聴覚障害のあるユーザーは以下のような問題に遭遇します。

音声情報の視覚的表現
たいていの R5 アプリケーションは聴覚障害のあるユーザーにアクセシブルです。しかしながら、アプリケーションが音声を用いていれば、その情報が視覚的に表現されなければ、その情報を得ることはできません。

上に戻る

視覚障害者のノーツ・アプリケーションの使用例

アクセシビリティーの要求の重要性をより理解するためには、視覚障害者がどのようにアプリケーションを利用するのかについて理解することは非常に意義のあることです。R5 のメール・テンプレートはアクセシブルなアプリケーションのよい例です。スクリーン・リーダーがどのように動作するのか実演してみてください。

ブックマークバー
晴眼のユーザーはブックマーク・バーをじっくり見ることができ、マウスで望みのブックマークをクリックできます。キーボードを使用しなければならないユーザーは、Alt-B で各ブックマークを表す英数字を表示させることで簡単にアクセスできるようになります。そして、Alt-B を押した後、ブックマークに対応した英数字をタイプすることでそのブックマークを開くことができます。

スクリーン・リーダーを用いると、順番に情報を読み上げていくために、その過程は多少複雑になります。Alt-B を押すと、スクリーン・リーダーはブックマークを英数字で、「1はメールです。2はカレンダーです。3はアドレス帳です。」というように読み上げていきます。ブックマークのリストを走り読みすることはできないので、望みのブックマークが読み上げられるまで待って、その英数字を覚えておく必要があります。ブックマークの長いリストを順番に聞くのは煩わしいので、NOTES.INI ファイルに変更を加えることで、Alt-B を押して、方向キーを使うと各ブックマークを1つずつ読み上げることができます。

タスクボタン
ウィンドウを開くためのタスク・ボタンも同様にしてアクセスできます。Alt-W を押すと、各ウィンドウタスクに対応するボタンに対応する英数字が現れます。そして、スクリーン・リーダーは各アイテムを読み上げていきます。たとえば、「1は Welcome です。2はワークスペースです。3はシャノン・ラピュアーノの受信ボックスです。」というようになります。また、Ctrl-Tab を押すことで、タスク間の切り替えができます。

開発者がフォームにタイトルを指定しなかった場合、無題のウィンドウが作成されます。晴眼のユーザーなら、そのアイテムをクリックしフォーカスを移動させると直ちに見ることができ、望みの文書かどうかを判断できます。スクリーン・リーダーを用いているとこのように簡単にはいきません。Alt-W を押すことで、「無題」のウィンドウの番号を得ることができます。たとえば、４であれば、Alt-W を押した後、キーボードの 4 を押します。そうすると、望みの文書かどうか判断できる情報を聞き取れるまで、スクリーン・リーダーは、順番に文書を読み上げていきます。ウィンドウのタイトルは簡単に設計に取り込め、補助技術の利用者にとっては大きな改善になります。

メール・ファイル
スクリーン・リーダーをメール・ファイル関係に用いた場合について見てみましょう。
Alt-B+1 でメールの受信ボックスを開くことができます。そして、アプリケーションのウィンドウ・タイトルが読み上げられ、受信ボックス中でハイライトされた文書についての情報が読み上げられます。たとえば、「シャノン・ラピュアーノの受信ボックス。クレイグ・ローダン 2000 年8月31日、午前 9:00 のメッセージが未読です。タイトルはIris Today の記事を入稿してください。」といった感じになります。R5 では、オブジェクトの情報を見るために Microsoft Active Accessibility (MSAA) を用いており、スクリーン・リーダーは未読の文書を特定します。上下の方向キーを用いて、受信ボックスのアイテムを読んだり、Tab キーを用いて次の未読文書に移動できます。

F6 を押すと、次のフレームに移動でき、「メール」という言葉に続いて、そのタイトルを聞くことができます。これは、タイトルページがフレームに「メール」という言葉があることを表しています。再び F6 を押すと次のフレームに移り、「受信ボックスのツリー・ビュー」と読み上げられます。そして、それがビューであり、受信ボックスが選択されているということが分かります。方向キーでビュー内を移動するたびに、その項目が読み上げられ、Enter を押すと選択したビューやフォルダーが開きます。

F6 を押していくとすべてのフレームに移動でき、「カレンダー・フレームセットを開きます」と読み上げられることになるでしょう。グラフィックには代替テキストが設定されていて、スクリーン・リーダーが読み上げます。スペース・キーを押せばカレンダーを起動できます。

上に戻る

R5 アプリケーションにおけるアクセシビリティーのチェックリスト

IBM のアクセシビリティー・センターは、ソフトウェアや、Java、Web のコンテンツ、ハードウェアのみならず、R5 と R4 のためのアクセシビリティーのチェックリストを作成しました。各チェックリストでは、詳細な根本的理由や、開発技術、テスト戦略が提供されており、製品にアクセシビリティーを実装し、それを実証することができます。

以下のセクションでは、R5 のアプリケーションのさまざまな部分で重要となるアクセシビリティーの要求について議論します。また、アクセシビリティー・センターの完全なチェックリスト (R5 Application Accessibility Checklist) をご覧になれます。

上に戻る

フォームにおけるポイント

アクション・ボタンやフォームを適切なメニューに取り入れる
Alt キーを押しながらアクションに対応する数字キーを押すことで、キーボードからアクション・バーにアクセスすることができます。Alt キーを押すと、アクション・ボタン上に数字が現れ、スクリーン・リーダーはその数字とボタンのラベルを読み上げます。たとえば、受信ボックスのビューで Alt キーを押すと、スクリーン・リーダーは「1は新しいメールです。2は返答です。3は転送です。」と読み上げることでしょう。ボタンにアクセスするために、この方法を用いると手間がかかります。また、ユーザーは読み上げられた各ボタンの番号を覚えておかなければなりません。〔アクション(A)〕メニューにボタンを含めることでマウスを使えないユーザーや、スクリーン・リーダーに頼らなければならないユーザーは簡単にアクセスできるようになります。

次にアクション・ボタンやフォームを扱うためのテクニックを紹介します。

〔アクション(A)〕メニューにすべてのアクション・ボタンを含める。これは R5 ではデフォルトの設定になります。
ユーザーが文書を作成するためにフォームが必要であれば、〔作成(C)〕メニューや〔アクション(A)〕メニューにフォームを含める。
アクションに対して意味のあるキーボードのショートカットを割り当てる。これにより、ユーザーはリストを方向キーで移動する代わりに、ショートカット (たとえば、Ctrl-O で開くなど) をタイプするだけで済みます。

アクション・バーのすべてのアクションがアクション・メニューにあるアクションと等しいかを確認して、アクション・ボタンやフォームへのキーボードでのアクセス方法についてテストしてください。キーボードだけを使い、Alt-A を押して〔アクション(A)〕メニューが開いて、アクション・ボタンが一覧表示されることを確認してください。〔アクション(A)〕メニューにアクションが一覧表示されなければ、〔作成(C)〕メニューに一覧表示されるかもしれません。〔作成(C)〕メニューにキーボードからアクセスするには、Alt-C を押して、方向キーで選択肢を選びます。

すべての編集可能フィールドに簡潔なフィールド・ヘルプを与える
ユーザーはフィールド・ヘルプから、文書を書きこむ際の補助的な情報を得ることができます。フィールド・ヘルプは万人にとって有用なものですが、スクリーン・リーダーの利用者にとっては非常に重要なものです。晴眼のユーザーはフィールドの一般的な目的を理解するためにフィールドのラベルを読み、補助的な情報を得るためにフィールド・ヘルプを見ます。しかしながら、視覚障害者はいつもフィールド・ラベルにアクセスできるとは限りません。

スクリーン・リーダーの利用者が入力フィールドを選択したとき、スクリーン・リーダーはフィールド・ヘルプの内容、コントロールの種類、そしてフィールドが空でなければ、フィールドの値を読み上げます。ノーツは自動的に入力フィールドとラベルを関連づけてくれないので、スクリーン・リーダーからはラベルが見えず、ラベルを読み上げてくれないかもしれません。スクリーン・リーダーが編集可能フィールドの内容を読み上げるにはフィールド・ヘルプに頼ることになります。

次にフィールド・ヘルプについてのテクニックを紹介します。

すべての編集可能フィールドに簡潔なフィールド・ヘルプを与える。
可能であれば、フィールド・ヘルプの長さは5単語から8単語を越えない長さにする。ユーザーがフィールドを選択すると、スクリーン・リーダーはヘルプメッセージ全部を読み上げます。ヘルプが長過ぎると、文書の残りの部分を読み上げる妨げとなります。
フォームに同じ様なフィールドがある場合、各フィールドに重複しないフィールド・ヘルプを指定します。たとえば、もしフォームにホーム・アドレスとビジネス・アドレスという編集可能フィールドがあれば、「アドレスを入力してください」というような一般的過ぎるヘルプは使用せず、各アイテムに異なるフィールド・ヘルプを指定してください。

各編集可能フィールドを選択し、フィールド・ヘルプのテキストがスクリーン下部のステータスバー付近に現れることを確認することで、簡単にフィールド・ヘルプのテストができます。

上に戻る

グラフィックにおけるポイント

重要なグラフィック、イメージ・マップ、イメージ・マップのホットスポットには代替テキストを指定する
グラフィックにテキストの記述を与えることで、視覚障害のあるユーザーはグラフィックを思い浮かべることができます。スクリーン・リーダーは、ユーザーにグラフィックだと分かるように (グラフィックの代替テキストとして入力された) テキストを利用します。グラフィックがリンクされていなかったり、重要でなく冗長なものである場合は、代替テキストを指定しないでください。その文書を見ることができるユーザーはグラフィックを無視できたとしても、その文書を聞いて理解しなければならないユーザーは、そのテキストを無視できないかもしれないからです。

Alternate text for a graphic

次にグラフィックに関するテクニックを紹介します。

重要なグラフィックには〔図形〕プロパティー・ボックス内の〔代替テキスト・フィールド〕を用いて代替テキストを指定します。イメージがオブジェクトの図形であれば、代替テキストとしてはオブジェクト名が適切です。たとえば、赤い風船の図形の代替テキストは「赤い風船の図形」とすればよいでしょう。
イメージ・マップに対しても〔図形〕プロパティー・ボックス内の〔代替テキスト・フィールド〕を用いて代替テキストを指定します。
イメージ・マップのホットスポットに対しても〔図形〕プロパティー・ボックス内の〔代替テキストフィールド〕を用いて代替テキストを指定します。

代替テキストのテストにはいくつかの方法があります。

ブラウザーでアプリケーションを実行し、カーソルをページ上のグラフィックの上に移動します。すると代替テキストがテキスト・ポップアップとして現れます。重要なイメージでテキスト・ポップアップが現れなければ、代替テキストを指定し忘れていることになります。
ブラウザーのイメージの表示をオフにします。各イメージが表示される代わりに、その部分に代替テキストが表示されます。
Center for Applied Special Technology (CAST:応用特殊技術センター) より提供されているフリーの HTML アナライザー・ツールである Bobby を用いてサイトをテストします。

上に戻る

ボタンにおけるポイント

ボタンにテキスト・ラベルを指定する
スクリーン・リーダーはボタン上のテキスト・ラベルをボタンの使用目的を述べるために用います。もしボタンのラベルが空だったり、ラベルがグラフィックやアイコンであれば、スクリーン・リーダーはただ「ボタン」と言うだけで、ユーザーはそのボタンの目的を知ることができません。アクション・ボタンがプリンターのアイコンで、ユーザーが晴眼であれば、そのボタンは印刷をするためのものだと理解できます。スクリーン・リーダーはそのアイコンに関する情報を持っていないため、ただ「ボタン」と読むしかないのです。

次にボタンの使用に関するテクニックを紹介します。

すべてのホットスポット・ボタンに名前 (テキスト・ラベル) を指定する。
すべてのアクション・ボタンに名前 (テキスト・ラベル) を指定する。アイコンを含める場合、〔ボタンバーにアイコンを含む〕を選択しないでください。
レイアウト領域やナビゲーターではグラフィック・ボタンを使用しないでください。というのも、グラフィックでは代替テキストを利用できないからです。

すべてのボタンにテキスト・ラベルがあるかどうかを視覚的に照合してボタンのテキスト・ラベルを確認してください。

上に戻る

ナビゲーションにおけるポイント

各フレームにタイトルを指定する
晴眼のユーザーは、望みのページにある情報を見つけるために Web ページを走り見することができます。それに対し、盲目のユーザーは、Web ページを順番に移動しなければなりません。もしページがフレームセットなら、フレームごとにページを移動しなければなりません。フレームに意味のある名前がついていれば、ユーザーは望みのフレームを選択でき、冗長で関係の無い情報を飛ばすことができます。

次にフレームの使用に関するテクニックを紹介します。

〔フレーム〕プロパティー・ボックスで、フレームセット中の各フレームに対して、意味を持つ重複しない名前を指定します。
「バナー・フレーム」、「ナビゲーション・フレーム」、「メインフレーム」(主なコンテンツのためのフレーム) といった名前は非常に良い例でしょう。というのもフレームの主な役割が理解できるからです。逆に「上部」、「左側」、「赤」といったフレームの名前はページ移動の際のヒントにならないでしょう。
フレームの名前では略語の使用を最小限に抑えます。「navfr」(おそらく NAVigate FRame の略。フレーム間の移動という意味) といった名前では、スクリーン・リーダーが名前を読み上げても意味が理解できないことでしょう。

フレームの名前の確認には補助技術の使用が不可欠です。IBM アクセシビリティー・センター(US)の Web サイトでは試用版も含む補助技術製品の紹介をしています。補助技術製品の1つをインストールすれば、フレームセット内のフレームを一覧表示するリストフレームオプションが利用できるようになります。フレームの一覧からページを移動する際の有用な情報が得られること確かめてみてください。

Web ページのメインのコンテンツを得るためにナビゲーション・リンクをスキップする方法
ナビゲーション・バーはページの上部や左側の下部に配置されていることがありますが、ユーザーが晴眼なら、そのリンクを無視して直接メインのコンテンツに行くことができます。スクリーン・リーダーでページを読んでいるユーザーは、メインのコンテンツにたどり着くまで上部や左下部にあるリンクが読み上げられていくのを聞いておかなければなりません。サイトに首尾一貫したレイアウトが用いられていると、サイトの各ページを訪れるたびにこのようなことが起こります。しかしながら、晴眼のユーザーならリンクを無視して直接メインのコンテンツにたどり着けます。このチェック項目の目的は盲目のユーザーがナビゲーション・リンクを飛ばして素早くメインのコンテンツにアクセスできるようにすることです。

次にナビゲーション・リンクを飛ばすためのテクニックを紹介します。

ページのトップにリンクを貼った重要でない画像を配置する。このイメージのリンク先をページのメインのコンテンツの開始部分とする。このテクニックは IBM のアクセシビリティー・センターのサイトで用いられているものです。このようにすると、スクリーン・リーダーの利用者はリンクを選択すると直ちにページのメインコンテンツに移動できます。イメージの代替テキストは、「メインコンテンツに移動する」といったものにします。晴眼のユーザーは、マウスでカーソルをイメージの上に移動させるとリンクを確認することができます。
メインコンテンツに移動できるようにページのトップにテキストのリンクを配置する。テキストのナビゲーション・リンクは晴眼のユーザーもスクリーン・リーダーの利用者にも確認することができます。

ページにはスキップ・ナビゲーションのためのテキスト・リンクあるいは、リンク先がメインコンテンツであるイメージがページの上部に配置されていて、「メインコンテンツに移動する」という代替テキストを持っているということを確認することができます。スキップ・ナビゲーションのリンクを見るためには、マウス・カーソルをイメージの上に移動させます。そうすると代替テキストがポップアップ表示されます。

上に戻る

埋め込みコントロールについてのポイント

できるだけ1つのページに複数の埋め込みオブジェクトを配置しないでください
アプリケーションに対話式のコントロールを加えるために、埋め込み設計要素 (ビュー、フォルダー、アウトライン、ナビゲーター、カレンダー) をページやフォーム、サブフォーム、文書に配置できます。1つ以上の埋め込み設計要素をもつページは、そのページにフレームセットがある場合、キーボードでの移動が非常に困難になります。ユーザーはキーボードで移動するためにページのレイアウトについて常に知っておかなければならなくなります。

次に埋め込み設計要素の扱いについてのテクニックを紹介します。

ユーザーが F6 キーを使って要素間を簡単に移動できるように、各要素を1つのページに配置してください。複数の要素を1つのページに配置するとページの見た目が複雑になります。
埋め込み設計要素を表に配置しないでください。
1つのページに複数の埋め込み設計要素を配置しなければならない場合は、2つ以上のコントロールを持たないようにし、埋め込み設計要素の位置はアプリケーション内で首尾一貫してください。これによりユーザーはアプリケーションの新しいフレームセットを移動するときに、同じ操作をすればよいことになります。

視覚的には、アプリケーションが1つのページに複数の埋め込み設計要素を持つかどうかを確認することはできないかもしれませんが、キーボードを使ってアプリケーション内を移動すると簡単に分かります。

F6 を押すと最初のフレームに移動します。そして方向キーや Tab キーでフレーム内を移動できます。方向キーや Tab キーを使ってフレーム内の全てのアイテムにアクセスできなければ、フレームには複数の埋め込み設計要素が存在することになります。
F6 を押して次のフレームに移動し、同様の操作を繰り返します。

上に戻る

まとめ

これまで見てきたように、アクセシブルな R5 アプリケーションの設計のためにアプリケーションの外観を妥協する必要はありませんが、アクセシビリティーについて理解しておく必要があります。フィールド・ヘルプやボタンのラベルといった、多くのアクセシビリティーの要求に応えることは、すべてのユーザーのためになります。そのほかに、代替テキストやフレームのタイトルといったものは、アクセシビリティーにとって非常に重要なものであり、晴眼のユーザーからは気づかないものです。設計にアクセシビリティーを盛り込むことは難しいことではなく、顧客が要求するかもしれないアクセシビリティーの標準を満たす準備がアプリケーションに整っているということになります。さらに詳しい情報については、IBM のアクセシビリティー・センターの Web サイトをご覧ください。

著者について
シャノン・ラピュアーノはテキサスのオースティンにある IBM のアクセシビリティー・センターのメンバーです。シャノンは2年間 Accessiblitity Center に勤めており、ノーツの開発者として5年の経験があります。仕事以外では、彼女はトライアスロンや、夫とカリブ海に旅行に行ったりして楽しんでいます。

上に戻る