Bilingual Emacspeakと
視覚障害者のLinuxアクセシビリティ向上

Linux Conference 2000 Fall (2000年 11月30日、京都国際会舘)

発表者名と所属
渡辺隆行 湘南工科大学 情報工学科、
ARGV(Accessibility Research Group for the Visually-Impaired)
井上浩一 ARGV
坂本貢; ARGV
切明 政憲; ARGV
白藤 秀樹;  
本多博彦; 湘南工科大学
西本 卓也 京都工芸繊維大学 電子情報工学科
釜江常好; Stanford Linear Accelerator Center

概要

パソコンを使って文字を読み書きすれば、視覚障害者も晴眼者と同じ文字情報を共有できる。しかし、パソコン登場時からDOSを利用してきた視覚障害者の中には、GUIベースのWindowsはイメージがつかみにくくてなじめない、まどろっこしいと感じる人もいる。GNU/Linuxシステムはキャラクタベースの操作を基本としているので、このような人にもなじみやすいOSとなりうる。しかし、現実にはLinux用の日本語スクリーンリーダは存在しないので音声化されたDOS端末からログインするしかなく、LinuxノートPCを持ち歩くといった使い方はできない。このような状況を打開するために、Emacsが好きな晴眼者と視覚障害者のオープンな共同プロジェクトとして、音声化システムBilingual Emacspeakを開発している。これはLinux用及びWindows用の2種類の日米2カ国語対応スピーチサーバを作って、Raman博士が開発した英語音声化システムEmacspeakをバイリンガルに拡張しようというプロジェクトである。本システムはOSを音声化する既存のスクリーンリーダとは異なり、Emacs自身がスピーチサーバを制御して聴覚に最適化した形で情報を提示する。本発表では、開発中のBilingual Emacspeakの構成、特徴、機能、現状などをLinux版のデモを交えて紹介する。さらに誰もが使いやすいようにLinuxを初期段階からデザインすることの重要性を述べる。


目次


1. はじめに

初期のパソコンは、コマンドを文字でDOSのシェルに与え、DOSは文字で結果を出力していた。パソコンの音声化システム、いわゆるスクリーンリーダは、テキスト画面をスキャンして必要な情報を音声化し、それによって視覚障害者は効率よくDOSパソコンを利用できた。実際、パソコンが登場してまもなく、視覚障害者自身が開発したVDM[Saito95]やグラスルーツなどのスクリーンリーダが登場し、パソコン通信や日本語ワープロなどが利用された[Kurihara90]。つまりDOSはCUI (Character User Interface)を用いた小さなOSであったので、スクリーンリーダが音声化しやすいOSであった1

1990年代に入るとGUIを持ったWindowsが登場し、ハードウェアが低価格で入手できたこともあって社会にパソコンが普及した。そして電子メールやWebブラウザなどのインターネットアプリケーションの普及とともに、パソコンが情報提供及び情報取得の強力な手段として注目されるようになった。欧米ではWindows用のスクリーンリーダも早期から開発された[Ishikawa95]。日本ではWindows 95の登場以後にいくつかのスクリーンリーダが実用化され、利用されている2。Windowsは最新の技術がいち早く導入される反面、ウインドウ・アイコン・メニュー・ポインタなどのGUI部品による操作を前提にしている場合が多いので、Windows標準の部品を使ったりスクリーンリーダに配慮して作成したりしないと視覚障害者が使えないアプリケーションになってしまう。また、これまではDOSの80 x 25のマトリックス画面の情報をすべて把握できていたのに対してWindowsスクリーンリーダから取得できる情報が少ないので、Windowsはなじみにくいと感じたり、操作にまどろっこしさを感じる人も少なくない。このためいまでも、Windowsを使わなければならない状況以外ではDOSのスクリーンリーダを常用している視覚障害者も多い。しかしDOSでは最新の技術やデバイスを使用しにくく、個人用OSとして世の主流となっているWindowsに簡単に移行できなければ、新たなデジタルデバイドを生み出すことになる。

Windows以外の高機能なOSとして、LinuxなどのUNIX系OSが注目を集めている。UNIXはもともとテキストコンソールから操作するOSであり、今でもテキストベースで動作するアプリケーションがたくさん開発されており、文字情報だけでOSを管理できる。X-Windowはテキストの世界の上に別のレイヤとして存在しているだけで、ユーザは好みに応じてテキストツールでもGUIツールでもUNIXを利用できる。したがって、UNIXもDOSと同じように音声利用できてDOSユーザが移行しやすいOSであるはずであるが、ユーザが少ないこともあってUNIX用のスクリーンリーダは数少なく、日本語スクリーンリーダで実用化されているものはまだ一つもない。そのため仕事などでUNIX を利用する視覚障害者は、スクリーンリーダと端末ソフトが動作する他のDOSパソコンなどからUNIXの動作するパソコンにログインして利用せざるをえない。そのため、(1)余分なコストがかかる、(2)モバイル用途に利用できない、(3) 提示する情報の細かなチューニングが難しい、などの問題がある。(3)はエディタのように普段から多用するプログラムの使い勝手を大きく左右する。最近になってUNIX用英語スクリーンリーダが登場し、日本でもASUKA3が開発中であるが、これらのスクリーンリーダによる(3)への対処には限界がある。

つまり、視覚障害者にとってDOSはOSとしての機能が低く新たに習得しても報われない、WindowsのGUIは音声化システムに適していない、UNIXには音声化システムがないといった状態になっており、WindowsとUNIX用の使いやすい日本語音声化システムが待望されている。

目次に戻る


2. Bilingual Emacspeak Project (BEP)

2.1 BEPの概要

BEP[Watanabe2ndWIT, WatanabeIEICE2000, WatanabeIPSJ2000]はその名が示すように、Raman博士が開発したEmacspeakという音声化システムを日米2カ国語に拡張しようというプロジェクトである。詳細は次節で述べるが、EmacspeakはEmacsエディタがスピーチサーバを制御して、Emacsが扱う情報を聴覚にわかりやすいように音声化するシステムである。つまり既存のスクリーンリーダがOSが処理した情報を音声化しているのに対しEmacs自身が喋る音声化システムであり、スクリーンリーダにない情報処理能力を備えている。BEPはこのEmacspeakを拡張して、日本の視覚障害者の知的生産活動を支援することを目的としている。本プロジェクトはEmacsが好きな人間(視覚障害者と晴眼者)が集まり、Emacspeakの2カ国語化とWindows及びLinux用のバイリンガルスピーチサーバの開発にオープンに取り組んでいる4。2種類のOSをターゲットにしているのは、個人レベルではWindowsが最も普及していて、仕事ではUNIXを使っている視覚障害者がおり、また後述するようにGNU/Linuxが障害者にやさしいOSになる可能性があるからである。また本システムを使えば、外付けの音声合成装置なしのノートPCだけで、いつでもどこでもWindowsでもLinuxでも、ほとんど同じ操作でEmacsを利用できる。

本システムは、Emacs上で動作するEmacs Lispプログラムのライブラリ(2ヶ国語対応のEmacspeak)と、受け取ったテキストを音声化してからサウンドデバイスに出力するソフトウェアスピーチサーバからなる。このスピーチサーバは、日本語及び英語の音声合成エンジンとそれを制御するプログラムからなる。

目次に戻る

2.2 Emacspeak

GNU EmacsはUNIXを利用する研究者や技術者の間で広く利用され標準となっているエディタで、UNIXやWindowsをはじめとする多くのOSで動作する。EmacsはEmacs Lisp (elisp)という強力なプログラミング言語を持ち、elispで書かれたライブラリを使えば、テキスト編集以外にも、ファイラ、shell、Webブラウズ、電子メール、ftp、telnet、辞書検索、仮想端末、PIM、カレンダ、日記、プログラム開発(デバッグなど)などのいろいろな機能をエディタ内から実行できる。さらに欧米語、アジア言語などのほとんどの文字コード体系をサポートしている。

Emacspeakの主要部はelispで書かれており、hookやadvice機能を用いてEmacsの動作に割り込み、Emacsの動作を邪魔することなくEmacsが取り扱う情報を取得して、音声化した時に分かりやすいように加工してから、インテキストコマンドの形でスピーチサーバへの命令を埋め込んで、スピーチサーバ5に文字列を送り出す。Emacsはテキストエディタとして設計されており、elispで情報を自由に加工できる。また高度なカスタマイズも容易である。さらにエディタそのものが音声出力を制御しているので、十分な応答性の確保と、提示情報の詳細なチューニングが可能である。したがってEmacspeakによって、研究・開発・教育等に必要なほとんどの作業が可能となる。なおEmacspeakの詳細な説明は、ユーザマニュアル6に書かれている。

EmacspeakがAUIとGUIとに独立して情報を提供している図

図1: Emacspeakは、2次元の画面に情報を表示するGUIとは独立したAUIが、1次元のシークエンシャルな音声ストリーム専用に情報を処理してユーザに提供する。

図1に示すように、EmacspeakはAuditory User Interface (AUI)[RamanPhD, RamanAUI]を使ってEmacsを音声化する。音声表示用のAUIは画面表示用のGUIとは独立に情報の論理構造にアクセスして必要な情報を取り出し、聴覚に適した形で音声化する。Emacspeakはbufferのmodeに応じた最適なAUIをelispで実装しており、calendar-modeではカレンダに適した機能を供給でき、W3-modeではCSS2 (Cascading Style Sheets, level 2)7の音声スタイルシートに対応したWebブラウザとなる。

GUI画面に表示される文字には複数のフォントがあり、さらに太字やイタリックなどの修飾をしたり大きさを変えたりできる。音声においても、ピッチなどの声の個性を変えたり、男女を変えたり、年齢を変えたり、ボリュームを変えたりすることで、テキストの読み上げに対して多様な修飾ができる。Emacspeakにはaudio formattingやvoice-lockという機能があり、プログラムソースを編集するときはコメント、キーワード、関数名、文字列、などの構成要素ごとに異なった声を割り当てたり、大文字の場合は短いビープ音を鳴らして大文字であることを示したり、声の調子を変えることで、どこが大文字か耳で聞いただけでわかるようになっている。

このようにEmacspeakは、全盲の大学院生であったRaman氏が自分のためにいろいろな人の協力を得て開発したので、本当に必要な機能が実装されている極めて高機能な音声化システムである。しかしながら、Emacsを知らなければ使えない、UNIX以外のOSを考慮していない、英語以外の言語を全く考慮していない、スピーチサーバに対するコマンドがDECtalkという特定の音声合成装置を想定している、などの理由で、米国においても一般ユーザには普及していない。

目次に戻る

2.3 日本語の音声表現に必要な機能

Emacspeakを日本語に拡張するためには、elisp部(オリジナルのEmacspeakそのもの)、スピーチサーバ部ともに多言語化(multilingualization, m17n)しなければならない8

日本語の音声出力に適した表現方法には、以下の2種類がある。

説明読み;
漢字は表意文字なので複数の同音異義語があり耳で聞いただけでは漢字を同定できないので、既存の日本のスクリーンリーダは注釈をつけて漢字を説明する詳細読み機能を備えている。本システムは、かな漢字変換時の注釈として、だれが聞いても漢字を同定できる分かりやすい説明と、慣れた人ならすぐに同定できる短い説明を切り替えられるようにする。またカーソル移動に伴う文字読み上げ時は音や訓などの短い言葉で読み上げないと時間がかかってわずらわしい。これらのかな漢字変換時の短い説明とカーソル移動での一文字読み上げに使う辞書は、静岡県立大学の石川教授が開発したグラスルーツの辞書をもとにしている。文節単位で読み上げるときは文字の種類ごとに切り分け、同じ文字種の集まりごとに文字の種類を表す注釈をつけて読み上げることもできる9。文より大きな単位の読み上げに関しては、場合に応じて一部の記号を置き換える。他は日本語音声化エンジンにまかせる。

日本語にはひらがなの他にカタカナと半角カタカナがあるが、読み上げるとこれらはすべて同じ音になる。音声で文字の種類を区別する方法のひとつは「カタカナの あ」というふうに注釈をつけることであるが、読み上げに時間がかかる。全角と半角の英数字を区別すべき場合もある。また、日本語だけの問題ではないが、記号などを読み上げる際は何の記号であるかという説明をつけて読み上げた方が良い場合と、無視して音声化しない方が良い場合がある。アルファベットの大文字と小文字の区別が必要になる場合もある。

以上からわかるように、日本語を音声化するときは操作の状況とユーザの要求にしたがって読み上げ方を使い分ける必要がある。そこで本システムではひとつの日本語文字に対して3種類の読み方(カーソル読み、短い詳細読み、わかりやすい詳細読み)を用意し、状況によって使い分けるように実装中である10

音声フォント、audio queue;
耳で聞いただけではわからない文字種を音で識別するには、文字種の注釈をつける読み方の他に、声を使い分けたり短い音(audio queue)で合図したりする方法がある。ひらがなとカタカナ、大文字と小文字などを識別する際に、文字の種類に応じて声のピッチや種類などの声の性質を使い分ければ注釈をつけなくても文字の種類を識別できる。同じことは全角と半角の英数字にも言えるが、半角の英数字は英語のエンジン、全角の場合は日本語のエンジンが読み上げれば簡単に識別できる。なおEmacspeakでは大文字と小文字のアルファベットを識別するために、大文字の所だけアクセントをつける方法、大文字の前に短い音を鳴らして識別する方法、注釈をつける方法などを、場合に応じて使い分けている。日本語においてもカタカナの前に特有の短い音を鳴らしてカタカナであることをユーザに示す機能も取り入れる予定である。こうした機能は既存の日本のスクリーンリーダでも一部使われているが、本システムでは系統的に取り入れる。

また本システムは、Emacspeakが備えているコンテキストに応じた声の使い分け機能を日本語でも使用できる。たとえばプログラムソースでは、コメント文、クォート文字列、キーワード、関数などに応じて声を使い分けることで、データの構造をわかりやすく音声表現できる。

目次に戻る

2.4 Emacspeakの多言語化

Emacspeakは英語しか考慮しておらず、トラブルを防ぐためにUNIBYTEモードにしてマルチバイト文字を解釈しないようにしているので、まずこの制限をはずした。またEmacs 19のバージョンは多言語対応になっておらずEmacs Lispの仕様も若干異なるので、Emacs 20を対象にした。Linuxにおける日本語入力も考慮して、Bilingual Emacspeak ProjectがサポートするEmacsのバージョンはEmacs 20.4以降である11

言語の判断はelispのレベルで行い12、読み上げ単位やユーザの希望に応じて言語を切り替え、切り替え用のインテキストコマンドを読み上げ文字に付加してからスピーチサーバに渡す。

またEmacspeakはpunctuation modeによって音声化する文字の範囲を変えることができる。punctuation modeがallの場合は、句読点などの記号もすべて読み上げる。all以外のモードで読み上げて良い文字としてEmacspeakはASCII英数字しか考慮していないので、このままではマルチバイト文字を読み上げることができない。こういった関数も多言語に対応するように拡張する13

Emacsは多様な文字コードを扱えるので、生の情報の文字コードの判断はEmacsにまかせている。elispからスピーチサーバに送り出す文字列の文字コードはWindows、LinuxともにシフトJISにしている14。LinuxもシフトJISなのは、現在使用しているLinux用の日本語エンジンがシフトJISしか扱えないのと、両バージョンの共通化をはかるためである。

目次に戻る

2.5 バイリンガルスピーチサーバへの要求

日本語と英語(米語)では音素がまったく異なるので、ひとつの音声合成(TTS, text-to-speech)エンジンで日米2カ国語を読み上げることはできない。したがって、それぞれ複数の声を持つ日米2種類の音声合成エンジンのインスタンスを用意して、Bilingual Emacspeak本体からの指示に応じてそれを使い分けるスピーチサーバを作らなければならない。以下に示すように米語と日本語の音声合成エンジンの差が大きいので、スピーチサーバはエンジンのこの差を吸収しなければならない。

言語によって音声合成エンジンが備えるべき仕様は異なるが、現存の音声合成のインターフェースは英語を基準に考えられた仕様が多い。例えば、表音文字の基本セットが言語によって全く異なる。また日本語には表音要素を表す標準がないので、各社によって規格がそろっていない。速度はwpmで表すが日本語における定義が明確でない。また鼻濁音など日本語にしかない特性もある。WindowsにはSAPIという音声合成エンジンの統一インターフェースがあるので、統一したインターフェースで多言語エンジンを操作できる。しかしLinuxにはまだ統一インターフェースがなく、日本語の標準的なエンジンもないので、一から作り上げる必要がある。

目次に戻る

2.6 Linux版スピーチサーバ

Linux版スピーチサーバは標準入力からコマンドを受け取って解釈し、音声の合成、停止、声質の変更などを行うプログラムである。最終的にはWindowsと同様に日本語と米語を発声できる形に拡張するが、現在は日本語のみを発声できるスピーチサーバが動作している。

開発言語;
オリジナルのEmacspeakでは音声合成ハードウェアやソフトウェア音声合成エンジンをTclXプログラムでラップする形で書かれており、音の出力はそれぞれのエンジンにまかされている。しかしBilingual Emacspeakでは複数の言語に対応したそれぞれの音声合成エンジンの出力を同期させなければならないため、波形レベルでの操作も行えるC/C++を利用する。
英語音声エンジン;
Linuxで動作する英語音声合成ソフトウェアとしてはIBMのViaVoice Outloudがあり、本家Emacspeakもサポートしている。Cから利用できる独自のECIインターフェースを持ち、いくつかの声質が定義されており、インテキストコマンドで制御できる。

また、エジンバラ大学で開発されたFestivalは英語・スペイン語などの複数の言語に対応しており、フリーで提供されている。エンジンの制御はSchemeのインタプリタを通して行い、そのインタプリタを利用するためのC/C++, Java及びクライアント・サーバ形式のAPIを持つ。語彙辞書や音声波形を切り替えることで多種の声質と言語に対応する。いずれのエンジンもC/C++から波形を受け取って出力したり加工したりすることもでき、BEP のスピーチサーバでこのFestivalの英語エンジンを利用することも計画している。

日本語音声エンジン;
Linuxで動作するフリーまたは無償の日本語音声合成エンジンは存在しない。商用のものとしてもクリエートシステム開発(株)のSDKのみである。BEPではこのエンジンを使用している。SDKは入力文字列を言語処理して表音文字列を出力する言語処理部とその表音文字列から音声波形を合成する波形合成部からなる。表音文字列にインテキストコマンドを前置するか独自のAPI関数を呼ぶことで速度や音程、性別などを変更できる。
esoundの利用;
BEPのLinuxスピーチサーバでは音声出力先としてesound (Enlightened Sound Daemon)を利用できる。esoundではサーバとなるデーモンがクライアントからの接続を受け付け、送られたサウンドデータをまとめてサウンドデバイスに出力する。このため、一つのプログラムの出力しか受け付けないサウンドデバイスに対しても、音声とauditory-iconなど複数の音を同時にならすことができる。また、TCP/IP経由でリモートのマシンに音声を出力できるため、離れた場所で動いているEmacspeakの音声フィードバックを手元のマシンで聞くことも可能である。
音声の即時停止;
快適な操作性を実現するためには迅速な音声発声とともに停止要求に即座に反応することも必要である。esoundを利用する場合、停止要求を受けた時点ではすでに何秒分かのデータがサーバに送られており、これをキャンセルするAPIは用意されていない。そのため、現在出力中のチャネルの音量を0にする要求をesoundサーバに送信することで即時停止を実現している。

Linux版スピーチサーバは、(1)コマンドを受け付けて解釈し、キューイング、音声出力、スレッドへの停止要求を行うメインのスレッドと、(2)音声出力すべき文字列を受け取って言語解析と波形処理を行い、サウンドデバイスに順次出力するスレッドから構成される。現在は日本語の合成のみを行い、英語はカタカナ英語に変換して出力する。今後は内容によって、またはEmacspeak側の指定によって英語と日本語のエンジンを使い分けて2カ国語で話すスピーチサーバをめざす。本スピーチサーバは標準入力から任意のタイミングで制御文字列を受け取るだけのインターフェースであり、将来的にEmacspeak以外のアプリケーションからの音声出力を処理するために用いることも考えられる。現在は日本語の音声エンジンがLinux版のものしか存在しないため、Linuxまたはそのバイナリが動く環境でのみ動作するが、音声エンジンが準備できるUNIX系環境一般で利用できるようにポータビリティを維持する。

目次に戻る

2.7 BEPの試用

Bilingual EmacspeakはまだWindows版、Linux版とも開発中で一般公開していない。しかし両者とも視覚障害者が試用できるレベルになっており、BEP MLの参加者には公開してフィードバックを募っている15。Windows版は日米2カ国語を自動的に切り替えて喋ることができ、WindowsでもMewを使いたかったメンバーが日常生活で使用している。電子メールに限らず、Emacsだけでコンピュータを必要とする作業のほとんどを行えるので、使い慣れたエディタでデータを相互利用しながら作業ができるメリットは計り知れない。また日本語も英語もnativeが喋る音声化システムは今まで事実上存在しなかったので、本システムのWindows版によって初めて、文単位以上の長さを持つ英語を自然に聞けるようになった。ただし本システムはEmacsの内部しか音声化しないので、Windowsを使うためにはWindows用スクリーンリーダとの併用が必要である。Linux版スピーチサーバはまだ日本語しか喋らないが、シリアル端末を用いなくてもEmacs を音声利用できるようになっている。Bilingual Emacspeakを使った人は、コンテキストに応じて多彩な声で喋りあげるところに興味を持つようである。特にEmacs用WWWブラウザであるW3はaural style sheetsに対応しているので、Bilingual Emacspeakが完成すればHTMLの要素ごとに声を指定して読み上げることができるはずである。

現在のBEPは、開発者でもあるARGVのメンバーが使いやすい音声システムにすることを目指している。いいかえれば、Emacsが好きでWindowsでもLinuxでもEmacsを使いたい視覚障害者をユーザ像として想定しており、効率よく小気味よく使えるように不要な情報を音声化しないように努力している。このように開発者とユーザが一体化してユーザが必要とする機能を実装していく体制が、本システムの使いやすさを保証すると考えている16

これは同時に、ARGVのメンバーと違うニーズや背景をもつ視覚障害者には使いにくくなる危険性もはらんでいる。しかしEmacsはelispを用いてフルカスタマイズができるエディタであり、Bilingual Emacspeakもその特徴を受け継ぐように作っている。したがって、いくつかのモードを用意しておいて、各ユーザが自分の好みに合わせてモードを使い分けたりカスタマイズしたりすることもできる。

本システムはユーザがEmacsを知っていることを仮定している。Emacsを知らないけれども本システムに興味を持っているユーザ、特にコンピュータの詳細には関心がなくてとにかく使いやすければよいといったユーザに対するインターフェースやrpmなどのインストールパッケージを用意する必要もある。BEPに興味を持った人が簡単に使用できるようにする準備も早急に進めなければならない。

一般公開をするためには、未実装の重要な機能を使えるようにする、ドキュメントやインストーラを作る、いろいろな環境でテストする、有償でしか入手できない日本語音声合成エンジンの取り扱い方を考える、オープンソースとして公開できるように整理する、などの作業が必要である。本プロジェクトはだれでも自由に参加できる。また本システムの一般公開時には、オープンソースとして配布する。この論文を読まれた方で本プロジェクトに興味をもたれた方は是非BEP MLに参加してBEPの開発に力を貸していただきたい17

目次に戻る

2.8 BEPの予定

早く一般公開できるレベルにまでもっていくのが当面の目標である。Emacspeakの2カ国語化、Windows版、Linux版それぞれで動作する安定した2カ国語スピーチサーバの実現などまだまだ課題は山積みである。

Emacspeakは音声出力に主眼をおいており、音声出力だけでプログラミング作業ができる工夫がなされている。しかし音声だけではプログラムや文書の2次元配置を理解しにくいため、点字ディスプレイに出力する仕組みも組み込んでユーザの選択肢を広げたい。

Emacsは多言語に対応した入出力機能を持っているので、Bilingual Emacspeakをさらに多言語環境に国際化し各言語に対応した音声エンジンをインストールすれば、真のマルチリンガルな音声化システムになる。本システムを多言語に拡張する際にRamanと相談して、Emacspeak自身を多言語に拡張してもらうことも計画している。同じマルチバイト文字文化圏である韓国にはWindows用のスクリーンリーダさえ満足にないと聞くので、こういった国で使ってもらえるようにしたいと思っている。

本システムは情報の出力のみに音声を使っており、入力にはキーボードを想定している。これは、Emacsを使おうというようなユーザならばキーボードに慣れており、タッチタイプをするのに視力の有無は関係ないと考えたからである。しかし、データやコマンドの音声入力を本システムと併用することも可能であり、簡単なテストも実施している。音声入出力を活用した場合、視覚障害者だけではなく肢体障害者やモバイルコンピューティングやテレフォニなどの分野に応用することもできる。

目次に戻る


3. コンピュータのアクセシビリティ

3.1 アクセシビリティ向上の要件

Windowsの音声化が難しかった理由の一つは、Windowsのユーザインターフェースが基本的にGUIしかなく、GUIが出力した画面又は出力する少し前の段階でしかスクリーンリーダがOSから情報を取得できなかったことにあった18。逆に言うと、視覚が使えない人や運転中の人、聴覚を使えない人やうるさい工事現場にいる人、高齢者や子供や初心者や四肢不自由者など手で細かい操作ができない人、文字を読み書きできない人、小さな画面しか使えないモバイル機器、キーボード入力ができない状態、などのいろいろな状況に応じてアクセスしやすい情報機器を作るためには、ユーザの状況やニーズに適合したユーザインターフェースを提供することが大事である。そのためにはユーザインターフェースをOSから分離しておかなければならない。Windowsはこれができないが、UNIXなら可能である。UNIXはテキストコンソールで管理や操作ができるし、ウインドウマネージャを交換して自分が使いやすいGUIを選ぶこともできる。

また、初期段階からアクセシビリティを考慮して設計する必要がある。できあがったもの に追加しようとするとWindowsと同じ苦労を味わうことになる。

音声化と相性のよいユーザインターフェースは何かと考えると、画面表示を目的としたGUIが適さず、聴覚に表示することを目的としたAUIが最適であることは自明である。しかし本格的なAUIは存在せず、また例えUNIXであってもAUIをスクラッチから作ることは難しいし、AUIを作ってもそれを晴眼者と共有することも難しいと思われる。その点、キーボードから入力や操作が行えて、文字として情報が出力される世界、つまりテキストコンソールやEmacsの世界ならば、出力された情報をアレンジしなおして聴覚に最適化して出力することが可能であるし、晴眼者と同じインターフェースを共有できる。Bilingual Emacspeakの元となっているEmacspeakの優れた点は、Emacs Lispというプログラム言語を用いてこの再アレンジを実現している点にあると思う。

目次に戻る

3.2 Linuxのアクセシビリティ

Linuxが注目されるにつれ、Windowsと同じようにGUIだけでLinuxをインストール・管理・使用できるようになってきた。この状態を放置するとLinuxがGUI中心の世界になってしまい、GUIが苦手な人たちが置き去りにされる恐れがある。オープンソースのGNU/Linuxは志のあるユーザが積極的に参加して改良できるシステムであるので、Linux が急成長しているこの時期にLinuxを誰でもが使いやすいように設計することの重要性を訴えておきたい。誰にでも使いやすいというのは、その人の置かれた状況や能力に応じた使い方を許容するということである。たとえばX-Windowを使用しなくてもコンソールアプリケーションだけでシステムを管理できる、マウスを用いなくても主なウインドウ操作ができる、文字の大きさや配色をユーザの好みに応じて変更できる、などの配慮が必要である。また、インストーラが何をしているかなどの詳細をユーザが把握できることも必要である。Windowsのようにインストーラが何でもやってくれてユーザはなにも考えなくてもよいシステムも大切であるが、何をしているか知りたいユーザや自分で作業したいユーザにそれを許すことも重要である。

GNOME Foundationの一員であるSun Micrsosystemsは、GNOMEにGNOME Accessibility Interfaceを追加してアクセシブルなGTK Widgetsを作ろうとしている。またLinuxのカーネルにはハードウェア音声合成装置DoubleTalk(ただし英語)にメッセージを出力するためのドライバーもオプションとして用意されている。Emacspeakパッケージを含むディストリビューションも多い。このようにLinuxはWindowsに代わるアクセシブルな高機能OSとなる可能性を秘めているのでこの可能性を現実のものにしたいと願っている。

このような配慮は障害者のためだけにするのではなく、健常者も含んだすべてのユーザを対象にすることが重要である。設計の初期段階から幅広いユーザ像を考慮して、実際にユーザの意見を取り入れながらシステムを作っていく必要がある。

目次に戻る

3.3 晴眼者と視覚障害者の音声利用

同じ音声出力でも視覚障害者用の音声出力と一般ユーザ用の音声出力は異なる点が多いことに注意すべきである。音声出力は眺望感のないシークエンシャルな1次元のストリームであり、斜め読みやブラウジングが困難である。したがって不要な情報まで音声化してしまうと、必要な情報にたどり着くまでに時間がかかってしまう。目が文字を追う速度より文字を話す方が時間がかかるので、視覚障害者は倍速程度の早口での音声化を必要としている。音声化しなくても考えればわかる情報や意味のない音を再生するのは邪魔になるだけである。彼らにとって音声は一種の文字コードであり、短時間になるべく多くの情報を伝達できる音声合成が必要である。

一般ユーザが音声出力を利用するときはこれとは全く異なる。倍速で音声合成すると慣れていない耳にはほとんど聞き取れないし、単調な符合調で喋るとすぐに飽きてしまう。本当は不要な情報でも確認のために音声化してフィードバックを与えてあげないと不安になってしまう。又晴眼者は目が使えるので、補助的な情報だけでも視覚に提示してカンニングできればかなりの情報量を補える。

目次に戻る


4. まとめ

コンピュータは視覚障害者などの障害者の支援技術になる。しかしGUIでしかフル機能を使えないWindowsは音声化に適していない。UNIXはWindowsに代わる高機能なOSであるが日本語スクリーンリーダがないために音声化されたシリアル端末からログインするしかなかった。

このような状態を打開するために、Emacsが好きな晴眼者と視覚障害者が集まってBilingual Emacspeak Project (BEP)を立ち上げた。本プロジェクトはRaman博士のEmacspeakを日米2カ国語を扱えるように拡張し、Windows用及びLinux用のバイリンガルソフトウェアスピーチサーバを開発して、仕事や研究でEmacsを使う日本の視覚障害者の知的生産活動を支援しようというオープンなプロジェクトであり、BEP ML参加者で構成されている。本システムは日米2カ国語が混じった情報を正確に発音し、またコンテキストに応じて複数の声を使い分けることができる初のシステムである。本システムはEmacsの内部だけを音声化しているので、OSを外部から音声化するスクリーンリーダとは相補的な関係にある。本システムはEmacspeakの優れた機能をそのまま引き継ぎ、さらに日本のスクリーンリーダが築き上げた日本語音声化の工夫も取り入れるように実装する。本システムを使えばWindowsでもLinuxでも、LinuxのテキストコンソールでもXの上でも、同じ操作で音声Emacsを使うことができる。本システムはまだ開発中であるが基本部分は完成し、すでにBEP MLユーザによるテストも実施している。現段階のLinux版Bilingual EmacspeakでもノートPCだけを持ち歩いてLinuxを使用できる。本システムが完成したら、自主開発部分はオープンソースで公開する。本プロジェクトは誰でも参加できるので、皆さんの積極的な寄与を期待している。

本論文の元となった論文及び発表スライドはWebで公開する。

目次に戻る


謝辞

GNUやオープンソースという言葉によって代表される知的財産の共有文化に感謝する。クリエートシステム開発の小出社長には日本語音声合成エンジンに関する様々な助言や援助を得た。VDMの作者であるアクセス・テクノロジーの斎藤社長やグラスルーツの作者である静岡県立大学の石川教授からは、詳細読み辞書を使わせていただく許可を得た。両氏の活動を尊敬すると共に辞書の提供を感謝する。統合システム研究所の藤沼氏からは、詳細読み辞書が備えるべき機能を助言していただいた。

本プロジェクトは、ITRC (日本学術振興会産学協力会163委員会;インターネット技術研究委員会)の「視聴覚障害者のインターネット利用分科会」のメンバーと、視覚障害者のコンピュータ利用について広く議論しUNIXサーバを立ち上げて活動しているARGVのメンバの出会いから本格的なスタートを切った。両組織のメンバの様々な協力に感謝する。

目次に戻る


参考文献

[Saito95]
斎藤正夫: "視覚障害者支援ソフトウェアの製作", 情報処理, Vol. 36, No. 12, (1995) pp. 1116 〜 1121.
[Kurihara90]
栗原 亨: "視覚障害者用音声端末の現状と将来 - 人工視力に向けて -", 東京大学大型計算機センター, CCUT-TR-89-01, (1990).
[Ishikawa95]
石川 准: "GUI用スクリーンリーダの現状と課題 - 北米と欧州の取り組みを中心に -", 情報処理, Vol. 36, No. 12, (1995) pp. 1133 〜 1139.
[Watanabe2ndWIT]
渡辺隆行、井上浩一、鳥原信一、飛岡正人、坂本貢、釜江常好: "Bilingual Emacspeak Project - Windows及びLinux用の日英2ヶ国語対応Emacspeakの開発 -", 電子情報通信学会技術研究報告 WIT99 −1 22 [福祉情報工学], (2000) pp. 71 〜 76.
[WatanabeIEICE2000]
渡辺隆行、井上浩一、坂本貢、本多博彦、釜江常好: "Bilingual Emacspeak for Windows; 日米2ヶ国語の豊かな音声表現力を持つEmacs", 電子情報通信学会 音声研究会 信学技報、 Vol.100 No.256, (2000) pp.29 〜 36.
[WatanabeIPSJ2000]
渡辺隆行、井上浩一、坂本貢、本多博彦、釜江常好:"Bilingual Emacspeak - A universal speech interface with GNU Emacs -", 情報処理学会ヒューマンインターフェース研究会 情処技報、 Vol.2000 No.81, (2000) pp.39 〜 44.
[RamanPhD]
T.V. Raman: "Audio System for Technical Readings", Ph. D thesis, Cornell University (1994).
[RamanAUI]
T.V. Raman: "Auditory User Interfaces -Toward the Speaking Computer-", Kluwer Academic Publishers (1997).

目次に戻る


リンク集

BEP関連
Emacspeak関連 (英語)
スクリーンリーダ
その他 アクセシビリティ関連

目次に戻る


注釈

DOSはスクリーンリーダが音声化しやすいOS1
DOSが音声化しやすいといっても、日本語音声化システムがほとんどなかった時代にスクリーンリーダを視覚障害者が1人で作るのが大変であったこと、彼らの努力がなければ日本語DOSを音声利用できなかったことは間違いない。表意文字が多い日本語を音声化する工夫は、このDOS時代のスクリーンリーダが築き上げたものである。
日本語Windows用のスクリーンリーダ2
日本語Windows用の音声化システムとしては、95Reader ((株)システムソリューションセンターとちぎ)、VDM100W-PC-Talker ((株)高知システム開発、(株)アクセス・テクノロジー)、outSPOKEN for Windows JPN ((株)富士通中部システムズ)などがある。
UNIX用日本語スクリーンリーダ ASUKA3
ゼータビッツ(株) (旧 (株)ネットワーク応用通信研究所)
Bilingual Emacspeak4
Windows版のBilingual EmacspeakはWindows用Emacsの名をとってVoice Meadowとも呼ばれる。Linux版の愛称は募集中。
Emacspeakのスピーチサーバ5
スピーチサーバは、音声合成ハードウェアか、Emacsとは非同期に動作する別プロセスのソフトウェアである。
Emacspeakのユーザマニュアル6
EmacspeakのマニュアルとしてTexinfo形式のドキュメントがある。
CSS27
CSS2では、画面、音声出力装置、プリンタ、点字出力装置などの異なった出力装置ごとにスタイルシートを指定できる。
Emacspeakの多言語化8
現在は日本語しか取り扱えないが、将来は多言語に拡張する予定。
文字の種類を表す注釈をつけて読み上げる9
たとえば、「前のユーザに、」を"マエノ カタカナ ユーザ ニ"と読み上げる。
状況による詳細辞書の使い分け10
例えば"案"という文字に対してカーソル読みは"アン"、短い詳細読みは"アンナイノ アン"と読み上げる。"A"だったら、カーソル読みは"エー"、短い詳細読みは"アルファ"と読む。
Emacs 20.4以降をサポート11
Linux版ではeggのレベルで日本語入力を音声化しているので、egg 4に対応したEmacsが必要。
言語の判断はelispのレベルで行う12
現バージョンは簡易のためスピーチサーバで判断してエンジンを切り替える仕様になっている。
Emacspeakの多言語化13
例えば、punctuationがall以外の時の読み上げ対象を「語構成文字」というEmacsの文字シンタックスを利用して識別するように変更して、言語に依存しないように拡張した。
スピーチサーバが扱う文字コードはシフトJIS14
2カ国語から多言語に拡張するときはUnicodeで取り扱うべきかもしれない。
BEP MLでフィードバックを募っている15
試用に必要なモジュールの情報は、BEPのWebサイトで公開している。
ユーザビリティ16
どんなシステムにも言えることであるが特に障害者用の福祉機器を開発するときに、ユーザである障害者のニーズを健常者が想像して作ったシステムは使いにくいことが多い。設計の初期段階からユーザのニーズを正確に把握してシステムに反映させることが重要である。ユーザ=開発者はその理想的な形態のひとつであると思う。
BEPの開発に参加する方法17
BEP MLの参加方法は、BEPのWebサイト参照。
Windowsの困難18
Microsoftはアクセシビリティ向上に熱心な会社であるが、すでに完成して世界中に普及しているOSに後からアクセシビリティ機能を追加したので、十分な機能を提供できなかった。米国でADA (Americans with Disabilities Act)が成立したのは1990年になってからであり、それまでは誰もが使いやすいようにする(accessible)ことには誰も注意を払っていなかった。Windowsがアクセシビリティ機能を含有するように設計されなかったのは無理のないことであり、DOSにしろUNIXにしろアクセシビリティ機能を基本構造として持っているOSはない。OSではないが、1990年代に登場したJavaにはアクセシビリティ機能が最初から入っている。

目次に戻る


watanabe
2000/11/24 10:06:06