Windows 7 のアクセシビリティ (ユーザー補助)

この投稿は、アクセシビリティに対して重点的に取り組んでいるユーザー インターフェイス プラットフォームチームの開発長である Michael Bernstein によるものです。私たちにとってアクセシビリティという用語は、できるだけ多くの人々にとって Windows が使いやすくなるための機能や API のことを意味します。つまり、身体能力や認識能力に関係なく、誰もが Windows の機能にアクセスする力を持てるわけです。これを可能にするために、Windows には、あらかじめ組み込まれたアクセシビリティのユーティリティと API の両方が含まれています。API は特に、他社製の支援技術や、自分のソフトウェアがアクセスしやすいようにしようと考えているアプリケーション開発者によって使用されています。今回のトピックはマイクロソフトにとって大変重要であり、Windows 7 のエンジニアリングの基本理念のひとつでもあります。また、マイクロソフトには、 PC が見やすく、聞こえやすく、使いやすいことを確実にするために尽力している全社的なグループがあります。マイクロソフトのアクセシビリティに対するイニシアチブについては、 https://www.microsoft.com/enable/ で詳しくご覧いただけます。 --Steven

こんにちは。私は Windows 7 のアクセシビリティと音声認識のエクスペリエンスの開発長をしています。私たちが Windows 7 におけるアクセシビリティに関してどのように考えたかについて書きたいと思います。

私たちは Windows 7 をこれまでマイクロソフトが製作してきたオペレーティングシステムの中でもっともアクセスしやすいものにしようと思いました。今回のリリースを計画するにつれて明らかになってきましたが、アクセシビリティという概念は見た目ほど単純ではありません。アクセシビリティはセキュリティのように考えたくなります。どちらも既知の不具合がある一方で、システムは安全/アクセス可能だと信じられています。しかしながら、この定義は限定的だとわかります。視覚障害を持つユーザーのニーズは、聴覚障害を持つユーザーのニーズとはまったく異なるという事実に対して、どのように対処すればよいでしょう? 全盲の人のニーズと弱視の人のニーズですら異なります。たとえば、拡大ツールは全盲の方々にとっては役に立ちませんが、弱視の方々にとっては極めて重要です。さらには、理論的にはアクセス可能でも、実質的にはイライラするような (たとえば、実行するのに 36回キーを押さないといけないシナリオなど) ケースはどうでしょうか? 明らかに、アクセシビリティは単純な「はい」「いいえ」で答えられるような質問にはなりません。どちらかというと特別なユーザビリティであり、しかもそれぞれ個別のニーズを持った特殊なユーザー群のためのユーザビリティです。

質問が複雑なので、その答えも複雑になってしまいました。私たちは、Windows 7 においてアクセシビリティを向上させるため、4つのパーツから成る方策を選びました。

I. UI オートメーションでしっかりとした基礎を築く

Windows Vista で、マイクロソフトは「UI オートメーション」というアクセシビリティ用の新しいコアコンポーネントを導入しました。UI オートメーションは、ユーザーの支援技術 (Assistive Technology = AT) がアプリケーションの UI をプログラムで駆動するのを可能にし、アクセシビリティ機能を以前のバージョンの Windows と比べてより豊かな方法で表現できるようにします。UI の要素について細かく確認でき、その上もっと豊かな方法でUI を操作できます。UI オートメーションは「コントロール パターン」という考え方も導入しました。コントロールパターンとは、UI のいずれの要素も、どのようにコントロールされるべきか決定できるというものです。たとえば、ボタンには Invoke パターンがありますが、これは押せるということを示すものです。同様にコンボ ボックスには、開いたり閉じたりできることを示す ExpandCollapse パターンがあります。すべてのコントロールを同じ型にはめようとするのではなく、それぞれのコントロールは違うようにしています。これらは Windows Vista から登場し、今もなお採用され続けています。

Windows 7 では、UI オートメーション システムのパフォーマンス向上に力を注ぎ、支援技術を使ったさまざまなソフトウェアで効果的に使用されるよう UI オートメーション用の API を新しく一から作成しました。今では C++ で書かれたアプリケーションも .NET フレームワークを使って書かれたアプリケーションも、UI オートメーションを活用することができます。

私たちはまた、UI オートメーション システムがレガシーである Microsoft Active Accessibility (MSAA) とより密接に統合されるようかなりの作業を行い、新旧テクノロジーのよいところを橋渡しするための新しい技術を開発しました。UI オートメーションのクライアントは MSAA アプリケーションからアクセシビリティ情報を読み出すことができますし、逆もまた同様ですが、これはアプリケーションがもともとどちらの API を使用していたかにかかわらず、最大限のアクセシビリティを確かなものとするためです。UI オートメーション システムと MSAA システムはさまざまなシナリオで緊密に協力し合っているので、これら 2つの組み合わせを「Windows Automation API」と呼ぶことにしました。このアーキテクチャーは、その他のアクセシビリティに対する取り組みの基礎となるもので、このアクセシビリティの基礎が Windows 7 にも入っていることを喜ばしく思います。

II. Windows に入っているアクセシビリティのユーティリティを改良する

Windows に最初から入っているアクセシビリティのユーティリティも改良しました。マイクロソフトは、Windows が障害のある方にとってよりアクセスしやすいものとするために、数多くの AT ソフトウェア会社と密接に協力していますが、他のソフトウェアをインストールする前の初期のエクスペリエンスもアクセスしやすいものとするために、Windows には一連のユーティリティが含まれています。Windows 7 では、これらのユーティリティのうち 2つを強化することにしました。スクリーン キーボードと拡大鏡です。

スクリーン キーボードの最も顕著な変化は改良された外観や操作性ですが、ほかにも微妙な拡張があります。このユーティリティの外観は Windows XP から変わっておらず、お客様からサイズ変更ができるようにとの要望をいただいていました。私たちはこの両方についてタブレットの開発者とともに取り組み、タブレットソフト キーボードとスクリーン キーボードで共通のコード ベースを共有しました。今ではどちらのキーボードも Windows 7 と調和した魅力的な外観となり、サイズ変更が可能になりました。しかしながら、キーボードは異なったままです。というのは、それぞれ異なった使い方をされるからです。タブレットのユーザーは、手書きとタイプ入力をダイナミックに切り替えたいと思うでしょう。一方、スクリーンキーボードのユーザーは、クリックするのが困難な障害がある場合、キーの上をさまよったりスキャンできるようなモードが必要でしょう。この線に沿って、障害のある方が文字をより速く入力できるようにするため、基本的な予測入力機能を追加しました。これまでにスクリーンキーボードでタイプ入力を試みたことがあるなら、予測入力がいかにテキストの入力スピードを向上させるか、そのよさをお分かりいただけるでしょう。

拡大鏡は徹底的に見直されました。Windows Vista や Windows XP での拡大鏡は、直感的なエクスペリエンスではありませんでした。たとえば、画面の一部をポイントすると、拡大された内容は、(通常、画面の上方にドッキングされた) 別のウィンドウに表示されました。つまり、ある一点をポイントしながら、別の場所を見なければなりませんでした。この問題に対して、私たちは 2つの基本的なソリューションを考えました。画面全体をズームできるようにすることと、ポインターの動きにあわせて領域を拡大して残りの部分はそのままにすることです。この「全画面モード」と「レンズモード」が、Windows 7 の拡大鏡の 2つの主要なモードとなりました。

全画面モードは、画面上にあるすべてのもののサイズを一度に大きくしたい場合に有効です。マウスやキーボードのフォーカスを画面の中央あたりで動かしても、ビューはじっとしたままです。画面の端に向かって動かすと、拡大鏡は追いかけるようにビューをスクロールします。このモードのマイナス面は、状況がわからなくなりがちなことです。このユーザビリティの問題に対処するため、画面全体に対して今見ている領域がどこなのかを表すためにズームアウトし、その後再びズームインするような、状況を示すアニメーションを追加しました。

一方、レンズ モードは、ある特定のものだけをズームインしたい場合に便利です。このモードでは、レンズはマウスポインターを中心とするので、虫眼鏡を使っているような感じです。レンズは広くも狭くも幅広くサイズ調整が可能なので、文書を 1 行ずつ拡大して読みたい場合に便利です。このデザインは、好評を博している Microsoft IntelliPoint の拡大鏡に基づいていますが、これからはどのマウスでも使うことができます。

拡大鏡のウィンドウが画面上でスペースをとり過ぎる、というユーザーからのフィードバックに対しても対応しました。もっともよく使われているズームイン/ズームアウトといったコントロールを小さなツールバーに移動させました。このツールバーは、未使用時には半透明の透かしのような感じにフェードアウトします。その他のオプションは必要なときに [オプション] ダイアログで設定できます。そして最後に、ほとんどすべての機能に対してキーボードショートカットをつけました。したがって、UI を見たくなければ、使わなくてもすみます。Windows 7 では、[Win] + [+] キーを押せばいつでもズームインできます。

これらのツールは、低視力や手先の細かい作業が困難なお客様のアクセシビリティを直接向上させます。当たり前のことですが、PC を見たり情報のやり取りを行ったりするのを容易にすることは、すべての人にとってプラスになることであり、これらの 2つの例は AT ツールを幅広い層に対してアピールしました。PDC ではスクリーン キーボードと拡大鏡の両方をお見せしましたが、能力に関係なくすべての人が、これらのツールが自分のためになると思ってくださったと見てもよいと思います。

III. アクセシビリティ ソフトウェアの作成を容易にする

Windows の API だけで、アクセシビリティのすべてを提供できるわけではありません。Windows ベースのアプリケーションが、AT プログラムが使用するアクセシビリティのデータを正しく渡すことが不可欠です。たとえば、文字読み上げソフトはうまく音声を出せるにもかかわらず、気に入っている Web ブラウザで読み上げられないとしたら、それは何の意味があるのでしょう? 文字読み上げソフトや拡大鏡といった支援ツールは、アクセシビリティシステムの「クライアント」です。一方、Web ブラウザやワープロなどのアプリケーションは「プロバイダー」です。エクスペリエンス全体がアクセス可能なものとなるには、両方必須なのです－ つまり、高品質なクライアントとしっかりしたプロバイダーの両方が、すぐれたアクセシビリティ エクスペリエンスを得るために必要です。ソフトウェア エコシステムでは、数多くのプロバイダーがあります。そのため、それぞれのプロバイダーについて正しくコードが書かれているか一つ一つチェックするのは大変なことです。

この難問に対処するため、私たちのチームは「UI Accessibility Checker (略して AccChecker)」と UI Automation Verify (UIA Verify) という、アプリケーション (実際にはプロバイダー) をスキャンして一般的なアクセシビリティ問題について報告するユーティリティを開発しました。ソフトウェア開発者の方は、お客様が実際に使用する前に、AccChecker や UIA Verify を使ってプロバイダー コードの問題を検出することができます。また、品質保証エンジニアの方は、会社の仕事の品質を検証するのにこれらのユーティリティを使用できます。私たちは、AccChecker や UIA Verify をオープンソースのソフトウェアとして公開し、できる限り多くの関係者に使っていただけるようにしたことは、極めて重要だと考えています。プログラマーでない方は、直接使用することはないかもしれませんが、これらのユーティリティが遭遇していたかもしれないバグの除去に役立ったであろうことを考えると、やはり恩恵を受けていることになります。

IV. 1 日目からのアクセシビリティの計画

Windowsの機能そのものがすぐれたプロバイダーであることを確かなものとするために、ソフトウェア開発ライフサイクルのリスク評価からお知恵を拝借しました。コードを書く前に、それぞれの計画された Windows 7 の機能について、アクセシビリティの危険度を評価するのです。基本的な既成のコモン コントロールを使用している機能は通常、よりアクセシビリティに対応しています。なぜなら、Windows は既成のコンポーネントに対して内蔵されたプロバイダーを提供するからです。凝ったことやカスタム描画をするような機能は、対応させるためにいろいろな作業を行う必要があります。この計画プロセスにより、それぞれの開発チームはどの程度アクセシビリティの危険度があるか知ることができ、その結果、的確に計画を立てることができました。いったん機能が正しく評価されたら、私たちのチームは危険度によって機能表を並び替え、危険度の高い機能を担当しているチームに接触し、その機能がアクセシビリティ対応となるために必要なリソースやツールが足りているかを確認しました。また、より実践的なテストや検証が確実になされるようにもしました。その結果、Windows の機能のほとんどは、以前のバージョンに含まれていたものと比較して、よりアクセス可能となっており、総合的なユーザーエクスペリエンスが向上しています。

最後にまとめると、私たちは Windows 7 の開発において、アクセシビリティを重視しました。アクセシビリティ用のコア構造の改良や、スクリーンキーボードや拡大鏡など Windows に含まれるツールの強化で、順調な進展がありました。AccChecker および UIA Verify ツールにより、アプリケーションが既存の支援ツールや Windows Automation API をベースとした将来のツールに対して互換性があるか検証するのがずっと簡単になりました。Windows の機能やプロバイダーのアクセシビリティに対する私たちの取り組みは、社内の何百人ものエンジニアの懸命な働きのおかげで、さらに徹底して、一貫性があり、統合されたものとなりました。Windows 7 で成し遂げたことに対して私たちは誇りに思います。そして、障害のあるユーザーの方が自らの全潜在能力を発揮し、Windows でより楽しいエクスペリエンスを実現する手助けとなれば幸いです。

--Michael