(57)【要約】      （修正有）【課題】コンテンツの読み上げ順序を視覚化するための技術を提供する。【解決手段】読み上げ順序を視覚化するための視覚化装置は、読み上げ対象となる文字列を有する複数の要素の各々について、文字列の書字方向に基づいて、文字列が画面に表示される領域である要素領域を表示位置とし、かつ書字方向を示す有向線分を生成する有向線分生成部と、読み上げの順序で、生成した各要素の有向線分を記憶する記憶手段と、読み上げの順序に従って、各要素に対し生成された有向線分を連結し、画面に表示されている構造化文書に重ねて表示するオーバレイ描画部とを含む。【選択図】図２
2011034204.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサと記憶手段とを備えたコンピュータ・システムにおいて実行される、画面読み上げアプリケーションによる前記コンピュータ・システムの画面に表示された構造化文書内の要素の読み上げの順序を視覚化するための視覚化プログラムであって、前記視覚化プログラムは、前記コンピュータ・システムに、
前記プロセッサが、前記アプリケーションによる読み上げの対象となる文字列を有する複数の前記要素の各々について、前記要素の前記文字列の書字方向に基づいて、前記要素の前記文字列が前記画面に表示される領域である要素領域を表示位置とし、かつ前記書字方向を示す有向線分を生成するステップと、
前記プロセッサが、前記アプリケーションによる前記要素の読み上げの順序で、生成した各要素の有向線分を前記記憶手段に格納するステップと、
前記プロセッサが、前記アプリケーションによる前記要素の読み上げの順序に従って、前記記憶手段から前記各要素に対応する前記有向線分を読み出して連結し、前記画面に表示されている前記構造化文書に重ねて表示するステップと
を実行させる視覚化プログラム。
【請求項２】
前記要素の前記文字列の書字方向は、前記構造化文書内において指定された言語設定に関する言語情報及び書字方向を示す書字方向情報の少なくとも一方に基づいて決定される、請求項１に記載の視覚化プログラム。
【請求項３】
前記要素領域が矩形の形状を有しかつ前記書字方向が横書きの場合は、前記要素領域が一定以上の高さを有することを条件に、または前記要素領域が矩形の形状を有しかつ前記書字方向が縦書きの場合は、前記要素領域が一定以上の幅を有することを条件に、前記要素に対応する前記有向線分は、前記書字方向を示しかつ前記要素領域の対角方向に延びる線分として生成される、請求項１に記載の視覚化プログラム。
【請求項４】
前記書字方向が横書きかつ前記要素領域が矩形の形状を有することを条件として、前記要素領域が一定未満の高さを有する場合は、前記要素に対応する前記有向線分は、前記書字方向を示しかつ前記要素領域の水平方向に延びる線分として生成され、及び前記書字方向が横書きかつ前記要素領域が矩形の形状を有することを条件として、前記要素領域が一定以上の高さを有する場合は、前記要素に対応する前記有向線分は、前記書字方向を示しかつ前記要素領域の対角方向に延びる線分として生成される、請求項１に記載の視覚化プログラム。
【請求項５】
前記視覚化プログラムは、前記コンピュータ・システムに、前記プロセッサが、前記コンピュータ・システムの入力手段を介してユーザから、前記有向線分の表示の抽象度を示す抽象化パラメータを取得するステップと、前記プロセッサが、前記記憶手段に格納される前記有向線分の数が前記抽象化パラメータにより示される抽象度に相当する数になるまで又は前記記憶手段に合成可能な前記有向線分が存在しなくなるまで、前記要素の読み上げの順序において隣り合う２つの要素の組に対応する２つの前記有向線分の組を前記記憶手段から読み出して合成するステップと、前記プロセッサが、前記記憶手段に格納される前記有向線分を、前記合成の結果で更新するステップとを更に実行させる、請求項１に記載の視覚化プログラム。
【請求項６】
前記２つの有向線分の組の合成は、対応する２つの前記要素領域を包含する最小の領域に対して前記有向線分を生成することによりなされる、請求項５に記載の視覚化プログラム。
【請求項７】
前記２つの有向線分の組の合成は、対応する２つの前記要素領域を包含する最小の領域が、前記対応する２つの要素領域の和集合により近い前記２つの有向線分の組を優先して行われる、請求項６に記載の視覚化プログラム。
【請求項８】
前記２つの有向線分の組の合成は、前記有向線分の向き及び大きさが類似する前記２つの有向線分の組を優先して行われる、請求項５に記載の視覚化プログラム。
【請求項９】
前記２つの有向線分の組の合成は、対応する２つの前記要素領域の和集合がより小さい前記２つの有向線分の組を優先して行われる、請求項５に記載の視覚化プログラム。
【請求項１０】
前記２つの有向線分の組の合成は、対応する２つの前記要素領域が水平方向又は垂直方向に整列している前記２つの有向線分の組を優先して行われる、請求項５に記載の視覚化プログラム。
【請求項１１】
前記合成するステップは、前記プロセッサが、前記要素の読み上げの順序において隣り合う前記２つの要素の組であって、各要素の前記書字方向の水平成分が左から右へ向かう場合において、読み上げ順番が後の前記要素の前記要素領域が、読み上げの順番が先の前記要素の前記要素領域の左側または上側に位置する前記２つの要素の組、または各要素の前記書字方向の水平成分が右から左へ向かう場合において、読み上げ順番が後の前記要素の前記要素領域が、読み上げの順番が先の前記要素の前記要素領域の右側または上側に位置する前記２つの要素の組について、該２つの要素の組に対応する２つの前記有向線分の組の合成を禁止するステップを含む、請求項５に記載の視覚化プログラム。
【請求項１２】
前記合成するステップは、前記プロセッサが、前記要素の読み上げの順序において隣り合う前記２つの要素の組であって、読み上げの順番が先の前記要素の表示位置と、読み上げ順番が後の前記要素の表示位置とが一定の距離以上離れている前記要素の組について、該２つの要素の組に対応する２つの前記有向線分の組の合成を禁止するステップを含む、請求項５に記載の視覚化プログラム。
【請求項１３】
合成を禁止された前記２つの有向線分の組は、前記構造化文書に重ねて表示される際に、合成を禁止されなかった他の前記有向線分と区別がつくような態様で表示される、請求項１１又は１２に記載の視覚化プログラム。
【請求項１４】
前記有向線分の連結は、ベジエ曲線を利用して行われる、請求項１に記載の視覚化プログラム。
【請求項１５】
プロセッサと記憶手段とを備えたコンピュータ・システムにおいて実行される、画面読み上げアプリケーションによる前記コンピュータ・システムの画面に表示された構造化文書内の要素の読み上げの順序を視覚化するための視覚化方法であって、
前記プロセッサが、前記アプリケーションによる読み上げの対象となる文字列を有する複数の前記要素の各々について、前記要素の前記文字列の書字方向に基づいて、前記要素の前記文字列が前記画面に表示される領域である要素領域を表示位置とし、かつ前記書字方向を示す有向線分を生成するステップと、
前記プロセッサが、前記アプリケーションによる前記要素の読み上げの順序で、生成した各要素の有向線分を前記記憶手段に格納するステップと、
前記プロセッサが、前記アプリケーションによる前記各要素の読み上げの順序に従って、前記各要素に対し生成された前記有向線分を前記記憶手段から読み出して連結し、前記画面に表示されている前記構造化文書に重ねて表示するステップと
を含む視覚化方法。
【請求項１６】
画面読み上げアプリケーションによるコンピュータ・システムの画面に表示された構造化文書内の要素の読み上げの順序を視覚化するための視覚装置であって、
前記アプリケーションによる読み上げの対象となる文字列を有する複数の前記要素の各々について、前記要素の前記文字列の書字方向に基づいて、前記要素の前記文字列が前記画面に表示される領域である要素領域を表示位置とし、かつ前記書字方向を示す有向線分を生成する有向線分生成部と、
前記アプリケーションによる前記要素の読み上げの順序で、生成した各要素の有向線分を記憶する記憶手段と、
前記アプリケーションによる前記各要素の読み上げの順序に従って、前記各要素に対し生成された前記有向線分を前記記憶手段から読み出して連結し、前記画面に表示されている前記構造化文書に重ねて表示するオーバレイ描画部と
を含む視覚化装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＨＴＭＬ文書等の構造化文書に含まれるコンテンツの読み上げ順序を視覚化するための技術に関し、特に、読み上げ順序の確認を容易にする技術に関する。
【背景技術】
【０００２】
スクリーンリーダや音声ブラウザ等の音声読み上げアプリケーションは、ＨＴＭＬ文書等の構造化文書に含まれるコンテンツを、ＤＯＭ（Ｄｏｃｕｍｅｎｔ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）ツリーの順に読み上げる。そのため、コンテンツの読み上げを分り易くするには、意味のある順序でコンテンツを記述する必要がある。かかる要求は、Ｗ３Ｃ（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ  Ｃｏｎｓｏｒｔｉｕｍ）が勧告として公開するＷｅｂ  Ｃｏｎｔｅｎｔｓ  Ａｃｃｅｓｓｉｂｌｉｌｉｔｙ  Ｇｕｉｄｅｌｉｎｅｓ  １．０のＣｈｅｃｌｋ  Ｐｏｉｎｔ  ６．１にも記載されている。詳しくは、http://www.w3.org/TR/WAI-WEBCONTENT/を参照されたい。  
【０００３】
意味のある順序でコンテンツが記述されていることを検査するために、従来より、スクリーンリーダ等の音声読み上げアプリケーションによるコンテンツ読み上げ順序を確認することが行われている。
【０００４】
そのような確認方法の１つとして、テキスト化による確認方法がある。これは、ＨＴＭＬ文書のソースコードの表示、スタイルシートによるレイアウトをオフにした状態でのＨＴＭＬ文書の表示、また、スクリーンリーダの読み上げをシミュレーションするツールの出力結果の表示等、コンテンツのテキスト化による確認方法である。
【０００５】
また他の確認方法として、番号表示による方法がある。これは、レイアウトはオンにしたままで、読み上げ順序の番号をＨＴＭＬ文書の上に重ねて表示する方法である（例えば、非特許文献１参照。）。
【０００６】
更にまた、ウェブページ全体における読み上げ位置を確認するための技術も存在する。例えば、特許文献１は、タグを利用して、範囲指定された部分を視覚的に表現するための情報を指定する技術を開示する。当該技術によれば、読み上げ指定された範囲の背景色や、文字の色や大きさなどを変えたり、網掛けをして表示させる等の設定をすることができる。また特許文献２は、読み上げ位置を、音声の高低や、長さ、強さ等の音の属性に置き換えて提示する技術を開示する。当該技術によれば、読み上げ位置が進む毎に、音の属性を変化させることができる。
【０００７】
更にまた、特許文献３は、ウェブページのユーザへの情報伝達機能の強化を目的として、タグを用いて、ウェブページに読み上げ対象テキストを指定する記述、および対象テキストの読み上げ順序を指定する記述をする技術を開示する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００１−１０９６１２号公報
【特許文献２】特開２００６−１７１５４４号公報
【特許文献３】特開２００５−１０９９２号公報
【非特許文献】
【０００９】
【非特許文献１】Kasday, L.R.,”A Tool to Evaluate Universal WebAccessibility”, Proc. the 2000 conference on Universal Usability (ACM), pp.161-162, 2000.
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながらテキスト化による確認方法では、テキスト化されたコンテンツとスタイルシートによってレイアウトされたコンテンツとの対応関係を把握するのが難しい。そのため、テキスト化による確認方法には、確認に時間がかかるという問題や、直感的ではないため、初心者には使いこなせないという問題がある。
【００１１】
一方、番号表示による確認方法では、読み上げ順序の正確な把握が可能となる。しかしながら、番号表示による確認方法では、コンテンツ読み上げ順序の流れを把握するために、１つ１つ数字を追いかけなくてはならず、局所的な順番の入替えや、全体的なコンテンツ読み上げ順序の流れを把握するには、やはり時間がかかってしまう。
【００１２】
また特許文献１や２の技術は、現在の読み上げ位置を確認することを可能とする。しかしこれら技術では、１つ前の読み上げ位置や１つ先の読み上げ位置等、前後の読み上げ位置を確認できない。そのため、特許文献１や２の技術においても、全体的なコンテンツ読み上げ順序の流れや、局所的な順番の入替えを把握することができないという問題がある。
【００１３】
更に特許文献３の技術は、意味のある順序でコンテンツが記述されていなくても、コンテンツ読み上げを意味のある順序で行うことを可能とする。しかしながらかかる方法は、予めタグを用いて構造化文書に読み上げ順序を指定する記述をすることを必要とするので、手間がかかる。また、読み上げ順序の指定にはミスが起こりえることから、特許文献３の技術によっても、読み上げ順序の指定が正しくなされていることを確認する必要は依然として残る。
【００１４】
この発明は、上記の問題点を解決するためになされたものであって、構造化文書に含まれるコンテンツの読み上げ順序の確認を容易にする技術を提供することを目的とする。また本発明は、構造化文書内のコンテンツの読み上げ順序の局所的な入れ替わりや、全体的なコンテンツ読み上げ順序の流れを容易に把握することを可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するために、本発明では、構造化文書を描画したその上に、構造化文書内の要素の読み上げ順序を表示し、読み上げ順序の流れを視覚的に提示することとした。即ち、上記目的を達成する本発明は、次のような、プロセッサと記憶手段とを備えたコンピュータ・システムにおいて実行される、画面読み上げアプリケーションによるコンピュータ・システムの画面に表示された構造化文書内の要素の読み上げの順序を視覚化するための視覚化プログラムによって実現される。
【００１６】
上記視覚化プログラムは、前記コンピュータ・システムに、前記プロセッサが、前記アプリケーションによる読み上げの対象となる文字列を有する複数の要素の各々について、前記要素の前記文字列の書字方向に基づいて、前記要素の前記文字列が前記画面に表示される領域である要素領域を表示位置とし、かつ前記書字方向を示す有向線分を生成するステップと、前記プロセッサが、前記アプリケーションによる前記要素の読み上げの順序で、生成した各要素の有向線分を前記記憶手段に格納するステップと、前記プロセッサが、前記アプリケーションによる前記各要素の読み上げの順序に従って、前記記憶手段から前記各要素に対応する前記有向線分を読み出して連結し、前記画面に表示されている前記構造化文書に重ねて表示するステップとを実行させる。
【００１７】
ここで有向線分生成処理の単位となる構造化文書内の要素は、１文字、１行、１画像、１コントロール（ボタンやコンボボックステキスト入力等、フォームのための部品をいう）、１ノード（ＤＯＭツリーにおけるノードをいう）、１エレメント（ＤＯＭツリーにおけるエレメントをいう）等、構造化文書の任意の部分であってよい。ただし、いずれの要素を処理単位とするかは予め決定される。また要素に対して生成される有向線分は、直線に限らず曲線であってもよい。
【００１８】
好ましくは、前記要素の前記文字列の書字方向は、前記構造化文書内において指定された言語設定に関する言語情報及び書字方向を示す書字方向情報の少なくとも一方に基づいて決定される。
【００１９】
また好ましくは、前記要素領域が矩形の形状を有しかつ前記書字方向が横書きの場合は、前記要素領域が一定以上の高さを有することを条件に、前記要素に対応する前記有向線分は、前記書字方向を示しかつ前記要素領域の対角方向に延びる線分として生成される。また、前記要素領域が矩形の形状を有しかつ前記書字方向が縦書きの場合は、前記要素領域が一定以上の幅を有することを条件に、前記要素に対応する前記有向線分は、前記書字方向を示しかつ前記矩要素領域の対角方向に延びる線分として生成される。
【００２０】
また好ましくは、前記書字方向が横書きかつ前記要素領域が矩形の形状を有することを条件として、前記要素領域が一定未満の高さを有する場合は、前記要素に対応する前記有向線分は、前記書字方向を示しかつ前記要素領域の水平方向に延びる線分として生成される。また、前記書字方向が横書きかつ前記要素領域が矩形の形状を有することを条件として、前記要素領域が一定以上の高さを有する場合は、前記要素に対応する前記有向線分は、前記書字方向を示しかつ前記要素領域の対角方向に延びる線分として生成される。
【００２１】
また好ましくは、前記視覚化プログラムは、前記コンピュータ・システムに、前記プロセッサが、前記コンピュータ・システムの入力手段を介してユーザから、前記有向線分の表示の抽象度を示す抽象化パラメータを取得するステップと、前記プロセッサが、前記記憶手段に格納される前記有向線分の数が前記抽象化パラメータにより示される抽象度に相当する数になるまで又は前記記憶手段に合成可能な前記有向線分が存在しなくなるまで、前記要素の読み上げの順序において隣り合う２つの要素の組に対応する２つの前記有向線分の組を前記記憶手段から読み出して合成するステップと、前記プロセッサが、前記記憶手段に格納される前記２つの有向線分の組を、前記合成した有効線分で更新するステップとを更に実行させる。
【００２２】
より好ましくは、前記２つの有向線分の組の合成は、対応する２つの前記要素領域を包含する最小の領域に対する前記有向線分を生成することによりなされる。
【００２３】
更に好ましくは、前記２つの有向線分の組の合成は、対応する２つの前記要素領域を包含する最小の領域が、前記対応する２つの要素領域の和集合により近い前記２つの有向線分の組を優先して行われる。
【００２４】
また好ましくは、前記２つの有向線分の組の合成は、前記有向線分の向き及び大きさが類似する前記２つの有向線分の組を優先して行われる。
【００２５】
また好ましくは、  前記２つの有向線分の組の合成は、対応する２つの前記要素領域の和集合がより小さい前記２つの有向線分の組を優先して行われる。
【００２６】
また好ましくは、前記２つの有向線分の組の合成は、対応する２つの前記要素領域が水平方向又は垂直方向に整列している前記２つの有向線分の組を優先して行われる。
【００２７】
また好ましくは、前記合成するステップは、前記プロセッサが、前記要素の読み上げの順序において隣り合う前記２つの要素の組であって、各要素の前記書字方向の水平成分が左から右へ向かう場合において、読み上げ順番が後の前記要素の前記要素領域が、読み上げの順番が先の前記要素の前記要素領域の左側または上側に位置する前記２つの要素の組、または各要素の前記書字方向の水平成分が右から左へ向かう場合において、読み上げ順番が後の前記要素の前記要素領域が、読み上げの順番が先の前記要素の前記要素領域の右側または上側に位置する前記２つの要素の組について、該２つの要素の組に対応する２つの前記有向線分の組の合成を禁止するステップを含む。
【００２８】
また好ましくは、前記合成するステップは、前記プロセッサが、前記要素の読み上げの順序において隣り合う２つの前記要素の組であって、読み上げの順番が先の前記要素の表示位置と、読み上げ順番が後の前記要素の表示位置とが一定の距離以上離れている前記要素の組について、該２つの要素の組に対応する２つの前記有向線分の組の合成を禁止するステップを含む。
【００２９】
より好ましくは、合成を禁止された前記２つの有向線分の組は、前記構造化文書に重ねて表示される際に、合成を禁止されなかった他の前記有向線分と区別がつくような態様で表示される。
【００３０】
また好ましくは、前記有向線分の連結は、ベジエ曲線を利用して行われる。
【００３１】
以上、画面読み上げアプリケーションによるコンピュータ・システムの画面に表示された構造化文書内の要素の読み上げの順序を視覚化するための視覚化プログラムとして本発明を説明した。しかし、本発明は、構造化文書内の要素の読み上げの順序を視覚化するための上記視覚化プログラムを記録した記録媒体、視覚化プログラムをコンピュータ・システムにインストールすることにより実現される、構造化文書内の要素の読み上げの順序を視覚化するための視覚化装置、またそのような視覚化装置により実行される、構造化文書内の要素の読み上げの順序を視覚化するための視覚化方法として把握することもできる。
【発明の効果】
【００３２】
本発明によれば、構造化文書を描画したその上に、構造化文書内の要素の読み上げ順序を表示し、読み上げ順序の流れが視覚的に示されるので、構造化文書に含まれるコンテンツの読み上げ順序の確認が容易になり、構造化文書内のコンテンツの読み上げ順序の局所的な入れ替わりや、全体的なコンテンツ読み上げ順序の流れも把握することが可能となった。本発明のその他の効果については、各実施の形態の記載から理解される。
【図面の簡単な説明】
【００３３】
【図１】図１は、本発明の実施形態に係るコンピュータ・システム５０のハードウェア構成の一例を示す。
【図２】図２は、本実施形態に係る視覚化装置２００の機能構成の一例を示す。
【図３】図３は、表示属性の一例を示す。
【図４】図４（ａ）は、有向線分の一例を示す。図５（ｂ）は、有向線分の他の一例を示す。図５（ｃ）は、有向線分の更に他の一例を示す。図５（ｄ）は、有向線分の更に他の一例を示す。
【図５】図５は、連結された有向線分の一例を示す。
【図６】図６（ａ）は、合成処理前の連結した有向線分の一例を示す。図６（ｂ）は、合成処理後の連結した有向線分の一例を示す。図６（ｃ）は、合成処理後の連結した有向線分の他の一例を示す。
【図７】図７（ａ）は、合成処理前の２つの有向線分の一例を示す。図７（ｂ）は、合成処理後の有向線分の一例を示す。
【図８】図８（ａ）は、合成が禁止される第１のケースの一例を示す。図８（ｂ）は、図８（ａ）に示す第１のケースにおいて、合成を行った後の有向線分の一例を示す。
【図９】図９（ａ）は、合成が禁止される第２のケースの一例を示す。図９（ｂ）は、図９（ａ）に示す第２のケースにおいて、合成を行った後の有向線分の一例を示す。
【図１０】図１０（ａ）は、合成が禁止される第３のケースの一例を示す。図１０（ｂ）は、図１０（ａ）に示す第３のケースにおいて、合成を行った後の有向線分の一例を示す。
【図１１】図１１は、本実施形態に係る画面に表示された構造化文書内の要素の読み上げの順序を視覚化するための処理の流れの一例を示すフローチャートを示す。
【図１２】図１２は、図１１に示すフローチャートのステップ１１００の前処理の流れの一例を示すフローチャートを示す。
【図１３】図１３は、図１１に示すフローチャートのステップ１１１５の有向線分の合成処理の流れの一例を示すフローチャートを示す。
【図１４】図１４（ａ）は、本発明を適用した、読み上げ順番を入れ替えるプログラムのユーザインタフェースの一例を示す。図１４（ｂ）は、図１４（ａ）に示すユーザインタフェースを利用して順番を入れ替える途中の様子を示す画面の一例を示す。図１４（ｃ）は、図１４（ｂ）に示す入替えが完了した後の画面の一例を示す。図１４（ｄ）は、図１４（ｂ）と同様の処理を繰り返して全部の順番を入替えた後の画面の一例を示す。
【発明を実施するための形態】
【００３４】
以下、本発明を実施するための最良の形態を図面に基づいて詳細に説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。なお、実施の形態の説明の全体を通じて同じ要素には同じ番号を付している。
【００３５】
図１は、本発明の実施の形態に係る視覚化装置を実現するのに好適なコンピュータ・システム５０のハードウェア構成の一例を示した図である。コンピュータ・システム５０は、バス２に接続されたメインＣＰＵ（中央処理装置）１とメインメモリ４を含んでいる。ハードディスク装置１３、３０、およびＣＤ−ＲＯＭ装置２６、２９、フレキシブル・ディスク装置２０、ＭＯ装置２８、ＤＶＤ装置３１のようなリムーバブル・ストレージ（記録メディアを交換可能な外部記憶システム）がフレキシブル・ディスクコントローラ１９、ＩＤＥコントローラ２５、ＳＣＳＩコントローラ２７などを経由してバス２へ接続されている。
【００３６】
フレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭのような記憶メディアが、リムーバブル・ストレージに挿入される。これらの記憶メディアやハードディスク装置１３、３０、ＲＯＭ１４には、オペレーティング・システムと協働してＣＰＵ等に命令を与え、本発明を実施するためのコンピュータ・プログラムのコードを記録することができる。即ち、視覚化装置としてのコンピュータ・システム５０の上記説明した数々の記憶装置には、コンピュータ・システム５０の画面に構造化文書を表示するアプリケーションや画面に表示された構造化文書内の要素の読み上げの順序を視覚化するための視覚化プログラムを格納できる。そしてこれら複数のコンピュータ・プログラムはメインメモリ４にロードされることによってＣＰＵ１により実行される。コンピュータ・プログラムは圧縮し、また複数に分割して複数の媒体に記録することもできる。
【００３７】
コンピュータ・システム５０は、キーボード／マウス・コントローラ５を経由して、キーボード６やマウス７のような入力デバイスからの入力を受ける。コンピュータ・システム５０は、オーディオコントローラ２１を経由して、マイク２４からの入力を受け、またスピーカー２３から音声を出力する。コンピュータ・システム５０は、視覚データをユーザに提示するための表示装置１１に、グラフィックスコントローラ１０を経由して接続される。コンピュータ・システム５０は、ネットワーク・アダプタ１８（イーサネット（Ｒ）・カードやトークンリング・カード）等を介してネットワークに接続し、他のコンピュータ等と通信を行うことが可能である。
【００３８】
以上の説明により、本発明の実施の形態に係る視覚化装置を実現するのに好適なコンピュータ・システム５０は、通常のパーソナルコンピュータ、ワークステーション、メインフレームなどの情報処理装置、または、これらの組み合わせによって実現されることが容易に理解されるであろう。なお、上記説明した構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。
【００３９】
次に、このような本実施形態に係る視覚化装置２００の具体的な構成について説明する。図２は、画面に表示された構造化文書内の要素の読み上げの順序を視覚化するための視覚装置２００の機能構成の一例を示す図である。本発明の実施形態に係る視覚装置２００は、シミュレーション部２０２と、シミュレーション結果格納部２０３と、文字列抽出部２０５と、表示属性算出部２１０と、書字方向決定部２１５と、有向線分生成部２２０と、メモリ２２５と、オーバーレイ描画部２３０と、抽象化パラメータ取得部２３５と、合成部２４０とを備える。なお、図２には、コンピュータ・システム５０の画面に構造化文書を表示するアプリケーション２５０も合わせて図示する。  
【００４０】
アプリケーション２５０は、描画データ生成部２５５と描画部２６０とを含み、構造化文書を読み込んで表示装置１１の画面に表示する任意のアプリケーションである。描画データ生成部２５５は読み込んだ構造文書を解析して描画データを生成し、生成した描画データをアプリケーション２５０内部の図示しないメモリに一旦格納する。描画部２６０は該メモリに格納される描画データを参照して、構造化文書に含まれるテキストデータや画像データを表示装置１１の画面に表示する。
【００４１】
このようなアプリケーション２５０は、ブラウザや、アクセシビリティ・チェッカー等のブラウザの描画エンジンの機能を有するアプリケーションであってよい。本実施例では、アプリケーション２５０はブラウザであるとして説明する。この場合、描画データ生成部２５５は、構造化文書を解析して構造化文書の構造に対応したＤＯＭを生成し、該ＤＯＭを、オブジェクト間の入れ子関係を表現するツリー構造としてメモリに保持する。なお、メモリに格納されるデータは、描画部２６０のみならず、視覚装置２００、具体的には、後述するシミュレーション部２０２、文字列抽出部２０５、表示属性算出部２１０及び書字方向決定部２１５によっても参照される。
【００４２】
シミュレーション部２０２は、アプリケーション２５０内部の上記メモリを参照して、スクリーンリーダや音声ブラウザ等の画面読み上げアプリケーションによる画面の読み上げをシミュレーションする。即ち、シミュレーション部２０３は、画面に表示されている内容がスクリーンリーダ等の画面読み上げアプリケーションによりどのように読み上げられるかを推測し、読み上げ対象となる要素を、推測した読み上げの順序に並べて、後述するシミュレーション結果格納部２０３へ格納する。
【００４３】
本実施例では、シミュレーション部２０２は、ユーザによる読み上げ位置のコントロールがなされない場合の画面読み上げアプリケーションによる画面読み上げをシミュレーションし、構造化文書中に現れる順番で読み上げ対象となる要素の文字列を並べて、後述するシミュレーション結果格納部２０３へ格納する。なお、読み上げ対象となる要素であるか否かの判断は、単純に文字列を有する要素であるか否かにより判断するのではなく、好ましくは以下のように行う。
【００４４】
例えば、シミュレーション部２０２は、スタイルによりdisplay:noneと指定されて画面上に表示されない要素は、たとえ文字列が含まれていても読み上げ対象となる要素ではないと判断する。また、ＩＭＧやＡＲＥＡといった要素の場合、シミュレーション部２０２は、該要素に対し、ａｌｔ属性に指定された文字列を抽出し読み上げ対象の要素とする。更にａｌｔ属性が指定されていない画像のみを含むリンクがあった場合には、スクリーンリーダ等の画面読み上げアプリケーションは重要であると判断しＵＲＬの一部を読み上げ文字列として採用するので、シミュレーション部２０２も同様にＵＲＬの一部を抽出して読み上げ対象となる要素とする。
【００４５】
シミュレーション結果格納部２０３は、シミュレーション部２０２による画面読み上げのシミュレーション結果を格納する。シミュレーション結果格納部２０３に格納されるシミュレーション結果は、後述する文字列抽出部２０５により利用される。
【００４６】
文字列抽出部２０５は、アプリケーション２５０内部の上記メモリと、シミュレーション結果格納部２０３に格納されるシミュレーション結果とを参照して、アプリケーション２５０により読み込まれ表示部１１に表示された構造化文書内の複数の要素のうち、スクリーンリーダや音声ブラウザ等の画面読み上げアプリケーションによる読み上げの対象となる文字列を有する要素を全て抽出する。抽出された各要素と対応する文字列の情報は、シミュレーション部２０２が推測した画面読み上げアプリケーションによる読み上げの順に並べて後述する表示属性算出部２１０、書字方向決定部２１５及び有向線分生成部２２０へ渡される。なお、以下ではシミュレーション部２０２が推測した画面読み上げアプリケーションによる読み上げの順序を、画面読み上げアプリケーションによる読み上げの順序、又は単に読み上げの順序と記載する。
【００４７】
なお、文字列抽出部２０５がその処理単位とする構造化文書内の要素は、上述したように、１文字、１行、１画像、１コントロール、１ノード、１エレメント等構造化文書の任意の部分であってよい。文字列抽出部２０５の処理の単位となる構造化文書内の要素は、後述する有向線分生成処理の単位ともなるため、読み上げ順序の流れを正確に表現する観点から小さいほど好ましい。しかし１文字がどの矩形領域に描画されているか取得することは難しく、従って実際は、処理単位とする構造化文書内の要素は、実装時に実装上の都合や効率的な計算処理の観点から決定される。本実施例では、処理単位とする構造化文書内の要素は１ノードとする。なお以下では、処理単位とする構造化文書内の要素を、単に、構造化文書内の要素と記載する。
【００４８】
表示属性算出部２１０は、文字列抽出部２０５から受け取った読み上げ対象となる各要素について、アプリケーション２５０内部の上記メモリを参照して、該要素の表示属性を算出する。ここで要素の表示属性とは、要素の位置と大きさをいう。このような要素の位置や大きさは、アプリケーション２５０のウィンドウサイズによって変化するため、表示属性算出部２１０は、アプリケーション２５０による構造化文書の読み込み及び描画を待って、描画データ生成部２５５が生成した描画データを参照して表示属性を算出する。算出された各要素の表示属性の情報は、後述する有向線分生成部２２０へ渡される。
【００４９】
なお、本実施例のように第１のアプリケーション２５０がブラウザである場合、表示属性は、Ｗ３Ｃが定める標準のインタフェースを使用して算出することができる。Ｗ３Ｃでは、構造化文書内の各要素は、親要素の表示位置に対する相対位置の属性（offsetLeft, offsetTop)をスタイル情報に持つよう定められている。従って例えばＪａｖａｓｃｒｉｐを使用する場合、相対位置の属性はelement.style.offsetLeftと指定して参照することができる。なお、取得できるのは相対位置であるため、絶対位置を計算するには親要素を順に辿って絶対位置を計算する必要がある。
【００５０】
図３に、文字列「あああああああ」を有する要素を例として、表示属性算出部２１０が算出する要素の位置と大きさを示す。この場合算出される要素の位置は(left, top)、(left, top + height) 、(left + width, top)、(left + widht, top + height)である。また算出される要素の大きさはwidth x heightである。
【００５１】
書字方向決定部２１５は、アプリケーション２５０内部の上記メモリを参照して、構造化文書内において指定された言語設定に関する言語情報及び書字方向を示す書字方向情報の少なくとも一方に基づき、要素の文字列の書字方向を決定する。決定された各要素の書字方向の情報は、後述する有向線分生成部２２０へ渡される。
【００５２】
例えばＨＴＭＬでは、lang属性によって使用言語を、またdir属性によって書字方向が指定される。具体的には、lag=”ja”の場合、使用言語は日本語である。またdir属性にはltrとrtlのいずれか一方を設定でき、dir=”ltr”の場合、書字方向は左から右(left-to-right)であり、dir=”rtr”の場合、書字方向は右から左(right-to-left)である。なお、これら２つの属性はほとんど全ての要素に指定でき、指定がない場合は親要素から継承される。
【００５３】
また縦書きの表示設定は、縦書きを希望する要素にスタイル属性を持たせ、その属性値としてwriting-mode:tb-rlを指定することによりなされる。ここでtb-rlは、要素内で文字が上から下、右から左へ(top〜bottom-right〜left)流れることを示す。なお、デフォルトではwriting-mode:lr-tb属性となっており、これは要素内で文字が左から右、上から下へ(left〜right -top〜bottom)流れることを示す。  
【００５４】
そこで書字方向決定部２１５は、書字方向情報を取得できる場合は、該書字方向情報に基づいて、要素の文字列の書字方向を決定する。また、言語情報のみしか取得できない場合は、書字方向決定部２１５は、該言語情報に基づいて書字方向を決定する。例えば言語情報が日本語や英語であることを示す場合、書字方向決定部２１５は、書字方向を左横書きと決定する。また言語情報がアラビア語であることを示す場合、書字方向決定部２１５は、書字方向を右横書きと決定する。
【００５５】
有向線分生成部２２０は、文字列抽出部２０５から受け取った、画面読み上げアプリケーションによる読み上げの対象となる文字列を有する複数の要素の各々について、表示属性算出部２１０から受け取った各要素の表示属性の情報と、書字方向決定部２１５から受け取った要素の文字列の書字方向に基づいて、要素の文字列が画面に表示される領域である要素領域を表示位置とし、かつ書字方向を示す有向線分を生成する。生成された有向線分は、画面読み上げアプリケーションによる要素の読み上げの順序に並べてメモリ２２５に記憶される。
【００５６】
一例として、有向線分生成部２２０は、書字方向が横書きかつ要素領域が矩形の形状を有することを条件として、矩形の要素領域が一定未満の高さを有する場合は、要素に対応する有向線分を、書字方向を示しかつ矩形の要素領域の水平方向に延びる線分として生成する（図４（ａ）参照）。同様に、有向線分生成部２２０は、書字方向が横書きかつ要素領域が矩形の形状を有することを条件として、矩形の要素領域が一定以上の高さを有する場合は、要素に対応する有向線分を、書字方向を示しかつ矩形の要素領域の対角方向に延びる線分として生成する（図４（ｂ）参照）。
【００５７】
また一例として、有向線分生成部２２０は、要素領域が矩形の形状を有しかつ書字方向が横書きの場合は、矩形の要素領域が一定以上の高さを有することを条件に、要素に対応する有向線分を、書字方向を示しかつ矩形の要素領域の対角方向に延びる線分として生成する。同様に、有向線分生成部２２０は、要素領域が矩形の形状を有しかつ書字方向が縦書きの場合は、矩形の要素領域が一定以上の幅を有することを条件に、要素に対応する有向線分を、書字方向を示しかつ矩形の要素領域の対角方向に延びる線分として生成する。
【００５８】
なお有向線分は、対応する要素の文字列の流れを表現することを目的として生成するものである。従って有向線分は、対応する要素の文字列の流れを適切に表現するものであれば、直線だけでなく曲線であってもよく、または一部を曲線とする線分であってもよい。例えばdivなどのブロック要素に文字列がある場合、これら文字列は折り返されて複数行に亘って表示される。本実施例によれば１ノードであるブロック要素の複数行に亘る領域全体が１つの要素領域となるが、このようなケースでは、１つの要素内で複数回左から右へ向かうような線分を有向線分として生成してもよい（図４（ｃ）参照）。
【００５９】
また、ブロック要素のブロック中にfloatで指定された画像が存在する場合、テキストが画像に沿ったＬ字型の領域に表示されることもある。このようなケースでは、Ｌ字型に曲がった線分を有向線分として生成してもよい（図４（ｄ）参照）。
【００６０】
オーバーレイ描画部２３０は、画面読み上げアプリケーションによる各要素の読み上げの順序に従って、メモリ２２５から各要素に対応する有向線分を読み出して順次連結し、表示装置１１の画面に表示されている構造化文書に重ねて表示する。オーバレイ描画部２２３０による各有向線分の連結は、各有向線分を順次直線で結ぶことにより行ってよいが、２次や３次のベジエ曲線を利用して一筆書きの雰囲気を出すように行ってもよい（図５参照）。
【００６１】
例えば２つの有向線分Ａ及びＢが読み上げ順において隣り合っていると仮定して、有向線分Ａ及びＢを３次のベジエ曲線により連結することを考える。一例として、有向線分Ａの中間点と、有向線分Ａの終点と、有向線分Ａの終点と、有向線分Ａの終点と有向線分Ｂの始点との中間点とを制御点とするベジエ曲線と、有向線分Ａの終点と有向線分Ｂの始点との中間点と、有向線分Ｂの始点と、有向線分Ｂの始点と、有向線分Ｂの中間点とを制御点とするベジエ曲線により、有向線分Ａの中間点から有向線分Ｂの中間点までの曲線を表現できる。
【００６２】
上述したように、各要素の有向線分は、該要素の文字列の読み上げ順の流れを表現するものであるが、オーバーレイ描画部２３０により有向線分を連結することによって、更に、要素間の読み上げ順序の流れが表現される。なお、読み上げ順序の流れの方向を強調するために、有向線分にその向きを示す矢印を追加してもよく、また２つの有向線分を連結する連結部分の線分に、要素間の読み上げ順序を示す矢印を追加してもよい（図５参照）。
【００６３】
抽象化パラメータ取得部２３５は、キーボード６やマウス７等の入力手段を介して、ユーザから有向線分の表示の抽象度を示す抽象化パラメータを取得する。例えば、画面に一度に表示される要素の数が多いと、要素の文字列の上に重ねて表示される有向線分の数もそれに応じて多くなり、画面が非常に見にくくなってしまう。そこで本実施例では、有向線分を重ねて表示することにより画面が見にくくなる場合に、ユーザにより指定された抽象度に基づいて２つの有向線分を１つにまとめて抽象化する。
【００６４】
有向線分の抽象化の程度は、ユーザから取得した抽象化パラメータの値により決定される。即ち、抽象化パラメータ取得部２３５は、抽象化パラメータの値を用いて、有向線分の抽象化後の目標数を算出する。一例として、抽象化パラメータの取得は、有向線分の抽象度を調整するためのスクロールバースライダを画面に表示し、ユーザにスライダの位置を指定させることにより行ってもよい。例えば１０段階のスライダを用意したとすると、スライダの位置に応じて有向線分の抽象化後の目標数を、要素数の１００％、９０％、８０％、…というように決定してよい。
【００６５】
図６は、抽象化処理前と抽象化処理後の連結した有向線分の一例を示す。図６（ａ）は、抽象化処理前の連結した有向線分の一例を示す。図６（ｂ）は、中程度の抽象化処理後の連結した有向線分の一例を示す。図６（ｃ）は、抽象度のより高い抽象化処理後の連結した有向線分の一例を示す。図６を見ると分るように、抽象度が高いほど画面が見やすくなり、一方、抽象度が低いほど読み上げ順の流れが画面上に詳細に示される。
【００６６】
また、画面に一度に表示される要素の数が少ない場合を考慮して、抽象化パラメータ取得部２３５は、予めその内部に有向線分の最低数を用意しておいてもよい。例えば画面に一度に表示される要素の数が１０００ある場合は、スライダで最高の抽象化度を指定し、有向線分の抽象化後の目標数を要素数の１０％としても、有向線分はまだ１００ある。しかし、画面に一度に表示される要素の数が５０しかない場合は、最高の抽象化度を指定して有向線分の抽象化後の目標数を要素数の１０％とすると、有向線分は５になってしまう。そこで例えば有向線分の最低数を予め２０と設定しておくことにより、有向線分の抽象化後の数が２０以下にならないように調整できる。なお、抽象化パラメータ取得部２３５により算出された有向線分の抽象化後の目標数と、有向線分の最低数は、後述する合成部２４０へ渡される。
【００６７】
合成部２４０は、メモリ２２５に格納される有向線分の数が抽象化パラメータにより示される抽象度に相当する数になるまで又はメモリ２２５に合成可能な有向線分が存在しなくなるまで、要素の文字列の読み上げの順序において隣り合う２つの要素の組に対応する２つの有向線分の組をメモリ２２５から読み出して合成する。そして、合成部２４０は、メモリ２２５に格納される有向線分を、合成の結果で更新する。該更新に応答して、オーバーレイ描画部２３０は、再び画面読み上げアプリケーションによる各要素の読み上げの順序に従って、メモリ２２５から各要素に対応する有向線分を読み出して連結し、表示装置１１の画面に表示されている構造化文書に重ねて表示する。
【００６８】
ここで、好ましくは２つの有向線分の組の合成は、対応する２つの要素領域を包含する最小の領域に対して有向線分を生成することによりなされる。これを、図７を参照して説明する。まず、図７（ａ）に示すような、読み上げの順序において隣り合う２つの要素７００及び７１０の組に対応する、２つの有向線分７０５及び７１５の組があったとする。なお図７では、図４（ａ）及び（ｂ）を参照して説明した方法により有向線分を生成するものとする。すると合成は、対応する２つの要素領域７００と７１０とを包含する最小の領域７２０に対して有向線分を生成することによりなされるので、合成後の有向線分は、上から下へ向かう、最小の矩形領域７２０の対角線７２５となる。
【００６９】
なお、２つの有向線分の組の中には、合成後も対応する要素の文字列の流れを適切に表現することができるものもあれば、合成することによって、対応する要素の文字列の流れを適切に表現することができなくなるものもある。そこで、本実施例では、そのように合成後も対応する要素の文字列の流れを適切に表現することができる２つの有向線分の組を優先して合成処理することとした。また本実施例では、合成することによって、対応する要素の文字列の流れを適切に表現できなくなってしまうような２つの有向線分の組を合成処理の対象から除外することとした。
【００７０】
合成を禁止する２つの有向線分の組の識別は、具体的には次のようにして行う。即ち、本実施例では、読み上げの順序において隣り合う２つの有向線分a及びbの組ごとに、次の（Ａ１）及び（Ａ２）にそれぞれ定める位置関係が、２つの有向線分a及びbの間に成り立つか否かを判断する。（Ａ１）または（Ａ２）のいずれか一方でもその位置関係が成り立つと判断された有向線分の組は、合成処理の対象から除外する。なお以下では、読み上げの順序は有向線分aに対応する文字列が先であるとする。
【００７１】
（Ａ１）書字方向の水平成分が左から右へ向かう場合は、有向線分bの要素領域が、有向線分aの要素領域の左側または上側に位置する。書字方向の水平成分が右から左へ向かう場合は、有向線分bの要素領域が、有向線分aの要素領域の右側または上側に位置する。
（Ａ２）有向線分aの要素領域と有向線分bの要素領域とが一定の距離以上離れている。
【００７２】
図８は、隣り合う２つの有向線分a及びbの組が、（Ａ１）に定める「書字方向の水平成分が左から右へ向かう場合において、有向線分bの要素領域が、有向線分aの要素領域の左側に位置する」という位置関係を満たす一例を示す図である。
【００７３】
図８（ａ）において、番号がついた各矩形領域は、各要素の要素領域を示し、要素領域内の線分は対応する有向線分を示す。また番号は、要素間の読み上げ順序を示す。図８（ａ）では、番号３の要素領域に対応する有向線分と番号４の要素領域に対応する有向線分との組が、上記位置関係を満たす。これら有向線分の組を合成した後の有向線分を図８（ｂ）に示す。図８（ｂ）を見ると分るように、合成後の有向線分は、番号４の要素領域から番号３の要素領域を指し、合成前の要素間の読み上げ順序を適切に表現しないものとなっている。
【００７４】
図９は、隣り合う２つの有向線分a及びbの組が、（Ａ１）に定める「書字方向の水平成分が左から右へ向かう場合において、有向線分bの要素領域が、有向線分aの要素領域の上側に位置する」という位置関係を満たす一例を示す図である。
【００７５】
図９（ａ）において、番号がついた各矩形領域は、各要素の要素領域を示し、要素領域内の線分は対応する有向線分を示す。また番号は、要素間の読み上げ順序を示す。図９（ａ）では、番号２の要素領域に対応する有向線分と番号３の要素領域に対応する有向線分との組が、上記位置関係を満たす。これら有向線分の組を合成した後の有向線分を図９（ｂ）に示す。図９（ｂ）を見ると分るように、合成後の有向線分は、番号３の要素領域から番号２の要素領域を指し、合成前の要素間の読み上げ順序を適切に表現しないものとなっている。
【００７６】
図１０は、隣り合う２つの有向線分a及びbの組が、（Ａ２）に定める「有向線分aの要素領域と有向線分bの要素領域とが一定の距離以上離れている。」という位置関係を満たす一例を示す図である。
【００７７】
図１０（ａ）において、番号がついた各矩形領域は、各要素の要素領域を示し、要素領域内の線分は対応する有向線分を示す。また番号は、要素間の読み上げ順序を示す。図１０（ａ）では、番号１の要素領域に対応する有向線分と番号２の要素領域に対応する有向線分との組が、上記位置関係を満たす。これら有向線分の組を合成した後の有向線分を図１０（ｂ）に示す。図１０（ｂ）を見ると分るように、合成後の有向線分は、番号１の要素領域と番号２の要素領域の間に位置する番号３の要素領域に対応する有向線分と交わり、読み上げ順の流れを混乱させるものとなっている。
【００７８】
また、優先して合成処理を行う２つの有向線分の組の識別は、具体的には次のようにして行う。なお、該識別は、合成を禁止する有向線分の組の識別に平行して、または、合成を禁止すべき不適切な組を除外した後に行う。本実施例では、読み上げの順序において隣り合う２つの有向線分の組ごとに、次の（Ｂ１）〜（Ｂ４）の判断基準に基づいてそれぞれ重みW1〜W4を計算する。そして各判断基準に対して計算した重みW1〜W4の合計を求め、合計が最も小さい組について合成処理を行う。
【００７９】
なお、本実施例では任意の有向線分Ｘに対応する要素の要素領域は全て矩形とする。またここでも、判断対象となる２つの有向線分の組を有向線分a及びbとし、任意の有向線分Xについて、その要素領域の幅をX.width、要素領域の高さをX.height、また要素領域の画面向かって左上の座標を（X.left、X.top）と表す。更に、dw = a.width - b.width、dh = a.height&#8211; b.height、dl = a.left- b.left、dt = a.top&#8211; b.top、X.area = X.width x X.heightとする。
【００８０】
（Ｂ１）有向線分の向き及び大きさが類似する２つの有向線分の組を優先して合成する。
W1 = dw２ + dh２
（Ｂ２）対応する２つの要素領域が水平方向又は垂直方向に整列している２つの有向線分の組を優先して合成する。この際Ｋｖ＞Ｋｈとして、水平方向に連続している要素を優先する。
W2 = Kｖx dl + Kｈ x dt
【００８１】
（Ｂ３）対応する２つの要素領域を包含する最小の領域が、対応する２つの要素領域の和集合により近い２つの有向線分の組を優先して合成する。
W3 = ｃ.area &#8211; (a.area + b.area)
（Ｂ４）対応する２つの要素領域の和集合がより小さい２つの有向線分の組を優先して合成する。
W4 = a.aera + b.area  
【００８２】
なお一度合成処理を行うと、合成後の有向線分とペアになる組について重みの値が変化するので、次の合成処理を行う前に、重みの値が変化する前後２つの組について、再度重みを計算しなおす。そして再び重みの合計が最小となる組を探し、該組について合成処理を行う。合成部２４０は、上記処理を、メモリ２２５に格納される有向線分の数が抽象化パラメータにより示される抽象度に相当する数になるまで又はメモリ２２５に合成可能な有向線分が存在しなくなるまで繰り返す。
【００８３】
合成部２４０はまた、抽象化パラメータ取得部２３５から新たな有向線分の抽象化後の目標数を受け取ると、新たな有向線分の抽象化後の目標数を基に再度合成処理をやり直す。
【００８４】
次に図１１乃至図１３を参照して、構造化文書内の要素の読み上げの順序を視覚化するための視覚装置２００の動作を説明する。なお、視覚装置２００の動作は、アプリケーション２５０が構造化文書を読み込んで表示装置１１の画面に描画した後に開始する。ここで構造化文書は、ネットワーク・アダプタ１８等を介してネットワーク上の他のコンピュータから受信したものでもよく、またはハードディスク装置１３、３０等のストレージに記憶されたものでもよい。
【００８５】
図１１において処理はステップ１１００から開始し、アプリケーション２５０による構造化文書の描画に応答して、視覚化装置２００は読み上げ順序の視覚化のための前処理を行う。なお前処理の詳細は図１２を参照して後述する。次に視覚化装置２００の有向線分生成部２２０は、画面読み上げアプリケーションによる読み上げの対象となる文字列を有する複数の要素の各々について、該要素の文字列の書字方向に基づいて、要素の要素領域を表示位置とし、かつ書字方向を示す有向線分を生成する（ステップ１１０５）。生成された複数の有向線分は、有向線分生成部２２０により画面読み上げアプリケーションによる読み上げの順序でメモリ２２５に格納される。
【００８６】
次にステップ１１１０において、視覚化装置２００の抽象化パラメータ取得部２３５は、マウス７等の入力装置を介してユーザから抽象化パラメータの値を取得し、該抽象化パラメータの値に基づいて抽象化後の有向線分の目標数を算出する。算出された抽象化後の有向線分の目標数は、抽象化後の有向線分の最低数とともに、抽象化パラメータ取得部２３５から視覚化装置２００の合成部２４０へ渡される。
【００８７】
続いて処理はステップ１１１５へ進み、合成部２４０は、メモリ２２５に格納される有向線分の数が抽象化パラメータにより示される抽象度に相当する数になるまで又はメモリ２２５に合成可能な有向線分が存在しなくなるまで、要素の読み上げの順序において隣り合う２つの要素の組に対応する２つの有向線分の組をメモリ２２５から読み出して合成する。そして合成部２４０は、メモリ２２５に格納される有向線分の情報を、合成した有向線分の情報で更新する。なお合成処理の詳細は図１３を参照して後述する。
【００８８】
次に視覚化装置２００のオーバーレイ描画部２３０は、画面読み上げアプリケーションによる要素の文字列の読み上げの順序に従って、メモリ２２５から各要素に対応する有向線分を読み出して連結し、表示装置１１の画面に表示されている構造化文書のデータに重ねて表示する（ステップ１１２０）。そして抽象化パラメータ取得部２３５は、ユーザにより新たに抽象化パラメータの値が入力されたか否か判定する（ステップ１１２５）。ユーザにより新たな抽象度が指定された場合（ステップ１１２５：ＹＥＳ）処理はステップ１１１０へ戻る。一方ユーザにより新たな抽象度が指定されなかった場合（ステップ１１２５：ＮＯ）処理は終了する。
【００８９】
図１２は、図１１に示すフローチャートのステップ１１００の前処理の流れの一例を示す。処理はステップ１２００から開始し、視覚化装置２００の文字列抽出部２０５は、構造化文書の各要素から、第２アプリケーションによる読み上げの対象となる文字列を抽出する。続いて視覚化装置２００の表示属性算出部２１０は、文字列抽出部２０５から受け取った読み上げ対象となる各要素について、該要素の位置、大きさといった表示属性を算出する（ステップ１２０５）。算出された各要素の表示属性は、表示属性算出部２１０から有向線分生成部２２０へ渡される。
【００９０】
続いて処理はステップ１２１０へ進み、視覚化装置２００の書字方向決定部２１５は、構造化文書内において指定された言語設定に関する言語情報及び書字方向を示す書字方向情報の少なくとも一方に基づいて、読み上げ対象となる要素の文字列の書字方向を決定する。決定された文字列の書字方向は、有向線分生成部２２０へ渡される。そして処理は終了する。
【００９１】
図１３は、図１１に示すフローチャートのステップ１１１５の合成処理の流れの一例を示す。処理はステップ１３００から開始し、視覚化装置２００の合成部２４０は、メモリ２２５に格納される有向線分の数が抽象化パラメータにより示される抽象度に相当する数に到達したか否か、又はメモリ２２５に合成可能な有向線分が存在しないか否か判定する。メモリ２２５に格納される有向線分の数が抽象化パラメータにより示される抽象度に相当する数に到達した場合、またはメモリ２２５に合成可能な有向線分が存在しない場合（ステップ１３００：ＹＥＳ）、処理は終了する。
【００９２】
一方ステップ１３００においてＮＯの場合、処理はステップ１３０５へ進み、合成部２４０は、メモリ２２５に格納される複数の有向線分について、画面読み上げアプリケーションによる要素の文字列の読み上げ順序において隣り合う２つの有向線分の組ごとに、合成禁止の組に該当するか否か、即ち、対応する２つの要素の要素領域の組が、上述した（Ａ１）及び（Ａ２）のいずれかの位置関係を満たすか否かを判断し、満たすと判断した場合はその組を合成候補から除外する。
【００９３】
次に合成部２４０は、ステップ１３０５において合成候補から除外された組を除く、読み上げ順序において隣り合う２つの有向線分の組ごとに、上述した合成の判断基準となる重みＷ１〜Ｗ４を計算し、その合計を一時的に格納する（ステップ１３１０）。そして合成部２４０は、重みＷ１〜Ｗ４の合計が最も小さい２つの有向線分の組について、合成処理を実行する（ステップ１３１５）。そして処理はステップ１３００へ戻る。なお、２回目以降のステップ１３０５及びステップ１３１０の処理は、その前のステップ１３１５において合成した有向線分と、読み上げ順において合成した有向線分の前後に並ぶ有向線分との組について行えばよい。
【００９４】
次に図１４を参照して、本発明を、構造化文書内の要素の文字列の読み上げ順序を変更するためのプログラムのユーザインタフェースに適用した例を示す。図１４（ａ）は、読み上げ順序を変更する前の本来の読み上げ順序の流れを示す、連結した有向線分を示す。なお図１４（ａ）乃至（ｄ）は全て同じ構造化文書を表示した画面を示し、各図において、番号がついた各矩形領域は、各要素の要素領域を示し、番号は、要素間の読み上げ順序を示す。また図１４において要素領域内の黒丸はノブを示す。ここで要素領域３の読み上げ順序を、３番目から２番目に変更することを考える。
【００９５】
この場合、要素領域１から要素領域２へ向かう連結された有向線分を、要素領域１から要素領域３へ向かう連結された有向線分に変更するため、要素領域１のノブを、マウス６等の入力装置により要素領域３のノブへドラッグする。このときの画面の様子を図１４（ｂ）に示す。ドラッグ中は、読み上げ順序は未確定となるので、ドラッグしている箇所以外の有向線分は未表示とする。また読み上げ順序を変更中であることを明示するために、各要素領域のノブを白丸表示する。
【００９６】
図１４（ｃ）は、ドラッグ操作が終わった後の画面の様子を示す。ドラッグ操作が終わると、読み上げ順序が確定するので、確定後の読み上げ順序を示す連結された有向線分を再び画面に表示する。なお、本実施例では、読み上げ順序の変更によりスキップされる要素領域の読み上げ順序は、一番最後に繰り下がるものとした。同様に、元の読み上げ順序において、読み上げ順序が変更される要素領域よりも後に読み上げられる要素領域の新たな読み上げ順序は、変更される要素領域の読み上げ順序に応じて順次繰り下がるものとした。
【００９７】
このように読み上げ順序が変更された場合、オーバーレイ描画部２３０は、元の読み上げ順序で格納されているメモリ２２５内の有向線分を、新たな読み上げ順序に並び替える。そのためにオーバーレイ描画部２３０は、ノブの識別子に関連付けて読み上げ順序を内部のメモリに維持し、ユーザの操作に応じて、上述したように各ノブに対応する読み上げ順序を変更する。そしてオーバーレイ描画部２３０は、新たな読み上げ順序に従って、メモリ２２５から各要素に対応する有向線分を読み出して連結し、画面に表示されている構造化文書に重ねて表示する。そして、同様の処理を繰り返して全ての読み上げ順番を入れ替えると最終的に図１４（ｄ）に示すような画面が表示される。
【００９８】
以上、実施形態を用いて本発明の説明をしたが、本発明の技術範囲は上記実施形態に記載の範囲には限定されない。上記の実施形態に、種々の変更または改良を加えることが可能であることが当業者に明らかである。従って、そのような変更または改良を加えた形態も当然に本発明の技術的範囲に含まれる。
【００９９】
特許請求の範囲、明細書、および図面中において示した装置、システム、プログラム、および方法における動作、手順、ステップ、および段階等の各処理の実行順序は、特段「より前に」、「先立って」等と明示しておらず、また、前の処理の出力を後の処理で用いるのでない限り、任意の順序で実現しうることに留意すべきである。特許請求の範囲、明細書、および図面中の動作フローに関して、便宜上「まず、」、「次に、」等を用いて説明したとしても、この順で実施することが必須であることを意味するものではない。
【図１】
2011034204.tif 000003
【図２】
2011034204.tif 000004
【図３】
2011034204.tif 000005
【図４】
2011034204.tif 000006
【図５】
2011034204.tif 000007
【図６】
2011034204.tif 000008
【図７】
2011034204.tif 000009
【図８】
2011034204.tif 000010
【図９】
2011034204.tif 000011
【図１０】
2011034204.tif 000012
【図１１】
2011034204.tif 000013
【図１２】
2011034204.tif 000014
【図１３】
2011034204.tif 000015
【図１４】
2011034204.tif 000016