前へ

スクリーンリーダー対応アプリ作成のために

PC-Talker試用記

まとめ

ネタもつきてきたのでそろそろまとめに入る。
私の立ち位置は、「視覚障害者向けのソフトを作る」ではなく、「晴眼者向けに普通に作ったソフトを視覚障害者にも対応させる」というものなので、PC-TalkerのAPIを呼び出すというのは最後の手段と考えている。
Windowsの標準的なGUI部品を使っている限り、たいていの物は読むことがわかったと思う。
逆に読まないのはGDI関数群。なので、可能なかぎりスタティックコントロール等を使い、GDI関数を使わないようにすれば良い。
（あと、標準GUI部品に似て異なるものを自分で作ろうとしないこと。どっからどう見てもメニューバーなのだがPC-Talkerが読まないというアプリがある。標準GUI部品の挙動が気に入らないならサブクラス化による機能拡張という方法もある）

以降では、アプリケーションの種類別にちょっと考察してみる。

音を扱うアプリケーション

音を扱うアプリは、当然ながら音を出力するルーチンを自前で持っているはずである。
また、音を扱うアプリを使用する時はスクリーンリーダーをオフにすることがある。
（単に「邪魔になるから」だけではない。そもそも複数のソフトがPCのサウンド機能を同時に使えない場合もあるのだ）
よって、たとえば「レベルオーバー警告」のような固定メッセージは独自に出した方が良い。（on/offをつけること）
その場合、古い環境では、waveOutOpen()をしているときにMessageBeep()やsndPlaySound()はできなかったりするので、自前でミキシングして出す必要があるだろう。
周波数やレベルの数字を読み上げたいといった可変メッセージの場合は、ステータスバーに表示もしくはクリップボートにコピーあたりが妥当な線だろうか。

リアルタイムアプリケーション（ゲーム等）

固定メッセージの場合で、WAVEファイルを同梱することが許されるなら、Windows APIのsndPlaySound()を使うのが簡単。
可変メッセージならやはりクリップボードだろうか？
もっと積極的に特定のスクリーンリーダーに対応したいなら，95readerやPC-TalkerのAPIを呼び出すという方法もある。（あとで説明するが、文字列を読ませるだけなら意外と簡単である）

画像を扱うアプリケーション

視覚障害者が画像を扱うって？　扱うのだ。ＯＣＲのために。
先入観を排除して、キーボードだけで最低限の操作はできるようにしておくこと。

それ以外の通常のアプリケーション（テキストエディタ、ビュアー、メールソフト等）

・可能な限りGDI関数よりもスタティックコントロールかエディットコントロールを使う
・状態通知はステータスバー
・クリップボードに全文コピーを標準的な操作で簡単にできるようにしておく
などが考えられる。
ただ、エディットコントロールを使うと、メモ帳に毛が生えた程度のものしかできなくなるという難点がある。これはテキスト処理をやりたいアプリにとっては大きな難点である。
たとえば私は、テキスト関係のツールには行ピッチ変更機能が必須だと思っているが、こういったことが実現できない。色をつけたりもできない。（またWindows95や98やMeで使うことも考えると、扱えるテキストサイズが小さいという問題もある）
これらの難点の一部は、リッチテキストコントロールを使うことで解決可能だろう。（ただし、私もまだ使ったことがないので解説できない）

ということで、次回は「最後の手段」PC-TalkerのAPIを呼び出す方法について書く予定。
次ページ

コメント、トラックバックはココログへ