前へ
スクリーンリーダー対応アプリ作成のために
PC-Talker試用記
こういうことやられるとPC-Talkerは対応できない
ていうか他のスクリーンリーダーでも無理だと思うぞ。
オーナードローのボタン（代替テキスト無し）
例：サウンドレコーダーのボタンは、全部「プッシュボタン」としか読まない。
代替テキストがあれば大丈夫。（CreateWindowの第二引数）
リストボックスにオーナードローでチェックボックスをつける
例：コントロールパネルの「アプリケーションの追加と削除」の「Windowsコンポーネントの追加と削除」。内容の文字列は読むが、チェックがついてるかどうか判別できない。
リストビューのチェックボックスは読むのでこちらを使うべき。ただしCOMCTL32.DLLのバージョンが4.70以降であることをDllGetVersion()で確認すること。
ツールバー
そもそも読むか読まないか以前に、キーボード操作不能なら対応不可能。
ツールバーへのフォーカス移動は、Excelの場合、F10でメニューをアクティブにした後、Ctrl＋Tabキーで移動できるらしい。（私はExcelを持ってないので未確認）
手元のアプリで試したところ、Adobe Readerが同じ動作をした。
しかし、エクスプローラ、Internet Explorer、ワードパッド等、Microsoftの標準ツールが全滅。
また、自作アプリに同じキー操作を組み込もうにも、どうやればいいのか不明。
（おそらくツールバー側じゃなくてメニューバー側の動作をカスタマイズする必要があるのだと思うが……）
ならば、ツールバーコントロールじゃなくてメインウインドウに直接ボタンを並べたほうがいいのでは？
まあ、ツールバーのボタンはあくまでマウスでのショートカット用ということで、同じ機能が全てメニューバーから実行可能なら問題はおこらない。しかし、ツールバーにある機能は重複してメニューバーには置かないようなアプリでは問題が生じる。メニューバーが存在しないとか、初期状態で隠れているとかだとどうしようもない。（Vistaの馬鹿野郎！）、
メニューにビットマップ
めったに見ないとはいえ、Petzold本にも載っている有名なモノなので一応言及。
この場合、代替テキストを指定する方法すら無いようだ。
JavaのSwingで作ったアプリ
プッシュボタンすら読まないようだ。一方、AWTなら読む。．Netアプリも読む。
その他
情報募集中
PC-Talkerの妙な動作
メインウインドウに複数のボタンやスタティックコントロールがある状態で、全ボタンをDisableにすると、キー操作もしてないのにいきなりウインドウ全文読みを始める。
スタティックコントロールが20個もある状態でこれをやられると、一体何がおこったんだ？？？状態になる。
いやー。気がついて良かった。
解決方法
つねに最低二個のボタンがEnableな状態にすること。（一個だとダメっぽい）
それが無理なら、読まれて困るコントロール類をShowWindow(SW_HIDE)する。
ステータスバーとメニューバーとの関係
自作アプリ「SPEANA:リアルタイムスペクトルアナライザ」に、ステータスバーにピーク周波数を表示する機能をつけてみた。
SPEANAは、どう見ても晴眼者前提のツールだが、こうすることで「ステータスバー読み」機能を使って最低限ピーク周波数だけでもわかれば視覚障害者にも使い道がありそうだ。
（現実に、私が使うときでも、チューニングメーターがわりに使うときにはピーク周波数しか見ていないし）
さて、実際にやってみると、メニューを開いたとき、ステータスバーの内容を延々と読み上げ始めた。
PC-Talkerには、「音声ガイドの設定」に「メニューの説明文をガイドする」という項目があり、これがOnだとそういう動作になるようだ。（デフォルトでOnである。）
まあ、一般的なアプリでメニューの詳細説明をステータスバーに表示するアプリが多いようなので、そういう設定項目になるのは仕方ないのかもしれない。
（しかしそれにしても，メニューの選択位置を動かさなくともステータスバーの内容が変わるたびに読み上げるので、いつまでたっても読み上げが止まらないっていうのはどうなのよ？）
逆に言えば、メニューが開かれた時は、ステータスバーにメニューとは関係ない情報を表示してはいけないということだ。これを実現するには、メニューが開かれたタイミング、閉じられたタイミングを把握する必要がある。開かれたタイミングはWM_MENUSELECTメッセージ、閉じられたタイミングはWM_EXITMENULOOPメッセージで判るようだ。
参考：猫でもわかるプログラミング
次ページ
コメント、トラックバックはココログへ