NVDAからWindows10のOCR機能を呼び出して、NDLデジタルコレクションを読み上げて使ってみる

 以下のJEPAセミナーで、中根雅文(@ma10)さんが、スクリーンリーダーのNVDAからWindows10のOCR機能を呼び出して、アマゾンの画像ベースの固定レイアウトのKindleストアのコンテンツを文字認識させて読み上げさせるというハックを紹介されていました。

なるほど、そんな方法が!と思ったので、国立国会図書館デジタルコレクション(以下、NDLデジコレ)で試してみました。

NVDAの画像認識機能

 NVDAのこの機能は、現行の最新版である2017.3版から実装された機能です。詳しい解説はNVDA 2017.3jp ユーザーガイドにありますので、その抜粋を以下に掲載します。

9. 画像認識
 コンテンツの制作者がスクリーンリーダー利用者に対して十分な情報を提供していない場合には、画像認識が利用できます。 NVDA は Windows 10 に内蔵された文字認識エンジン(OCR)に対応しています。 そのほかの画像認識エンジンは NVDA アドオンとしての提供が可能です。
 画像認識コマンドを実行すると、NVDA は現在のナビゲーターオブジェクトの画像からその内容を認識します。 既定の設定では、ナビゲーターオブジェクトはシステムフォーカスまたはブラウズモードのカーソルに追従するので、まず認識したい場所にシステムフォーカスまたはブラウズモードのカーソルを移動します。 例えば、ブラウズモードカーソルで画像に移動して認識を実行すれば、その画像が認識されます。 しかし、オブジェクトナビゲーションで認識対象を選ぶこともできます。例えば、アプリのウィンドウ全体を認識の対象にしたい場合などです。
 認識が完了すると、認識結果がブラウズモードのドキュメントとして同じ場所に置かれます。その内容は矢印キーなどを使って読み取ることができます。 Enter キーまたはスペースキーを押すと、カーソル位置のテキストで既定のアクションが実行されます。これは通常のマウスクリックに相当する操作です。 Esc キーを押すと認識結果のドキュメントは消去されます。
9.1. Windows 10 文字認識
Windows 10 は多くの言語に対応した文字認識エンジンを内蔵しています。 NVDA はこのエンジンを使って画像やアクセシブルでないアプリに含まれるテキストを認識できます。
Windows 10 文字認識 の設定ダイアログで、文字認識に使う言語を選ぶことができます。 追加の言語をインストールするには Windows のスタートウィンドウから「設定」「時刻と言語」「地域と言語」を選び、「言語を追加する」を実行します。
Windows 10 文字認識で現在のナビゲーターオブジェクトの画像を認識するには NVDA+R を押します。

NDLデジコレのコンテンツで文字認識して読み上げる

 結論から言うと、NDLデジコレのコンテンツを文字認識して読み上げることができました。
 コンテンツ閲覧画面の標準表示(書誌情報エリアとコンテンツ表示エリアが表示されているもの)、フルスクリーンモードで試しました。
 私がNVDAの操作に不慣れで、デジコレの標準表示画面上でNVDAのフォーカス(ナビゲーターオブジェクト)をうまく当てることができず、文字認識させることが私はできなったのですが、お手伝いいただいた中根さんはデジコレの標準表示画面上で文字認識させることができたようです(ありがとうございます)。
 
 デジコレのフルスクリーンモードは私のほうでも、文字認識させて読み上げさせることができました。こちらは簡単。
 もしNVDAの文字認識機能を使用して、NDLデジコレを使う場合は、フルスクリーンモードで使用することがおすすめです。標準表示と比べて、画像が拡大されるので、認識率が向上するということ(フルサイズモードで認識率が良くない場合は表示を拡大するとよくなる可能性あり)と、UIがシンプルになるので、目的の画像にフォーカスまたはナビゲーションオブジェクトを選択しやすいからです(画面の表示した段階で基本的にフォーカスが当たっている)。
コマの移動も左右の矢印キーで行えるので、コマ移動も容易です。このエントリの最後に今回の使用で利用しそうなNDLデジコレのショートカットを掲載しておきます。
利用の流れとしては、以下の流れになるでしょうか。

  1. NDLデジコレで目的の資料の閲覧画面に入る
  2. Fキーでフルスクリーンモードに切り替え
  3. 表示したいコマをを選択して表示
  4. NVDAキー+Rキーで文字認識
  5. 読み上げ
  6. 左右の矢印キーでコマの移動

 この機能、面白いですね。他のものでも試してみたいと思います。

参考 NDLデジコレのショートカット

  • フルスクリーンモードのオンオフの切り替え: Fキー
  • 前のコマに戻る: 左矢印キー
  • 次のコマに移動する: 右矢印キー

W3C Publishing Working Groupで軽量SMIL(次世代SMIL?)について議論始まる

 W3CのPublishing Working Group の2017年9月18日の電話会議で、SMIL lite(軽量のSMIL)が(おそらく)始めて議論されています。先のエントリで紹介したWeb Pulications
での利用が想定されています。Web Pulications はEPUBと統合されて、EPUB4的な立ち位置になる可能性も示唆されているので、次世代SMILといえる立ち位置になりうるのかもしれません。まだ、議論は始まったばかりのようで、どこに向かうのかはわかりませんが。

 要件リストは、Essential Requirements(不可欠な要件)とAdvanced Requirements(高度な要件)にわけて整理されています。Essential Requirements はざっと見た感じ、現行のEPUB3ですでに実現できていることが並んでいるようですが、Advanced Requirements では、現行のEPUBでは実現できていない手話動画とテキストの同期も想定した動画のサポートや、音声解説を付けた動画のサポートが挙げられています。
 議事録を読むと、SMIL lite は XMLではなく、JSON で行く可能性が今のところ高そうですね。 
 なお、SMIL (Synchronized Multimedia Integration Language) は、DAISY や EPUB 3 では、テキストと音声の同期あるいは音声(録音音声またはTTSによる読み上げ)の再生の制御のために使用されています。現行の EPUB 3 におけるSMILのサポートは音声に限定されていますが、聴覚障害者のために手話動画とテキストを同期させたEPUBを作るため、動画のサポートが EPUB 3 仕様策定の段階から要望としてあがっていたようです。そういう経緯があったためか、EPUB Media Overlays 3.0の仕様では、動画をサポートしないことがわざわざ言及されています(最新の EPUB 3.1 でも同じです)。今回の SMIL lite の議論もこの経緯を受けてということだと思われます。

Although future versions of this specification might incorporate support for video media (e.g., synchronized text/sign-language books), this version supports only synchronizing audio media with the EPUB Content Document.

 
 最後に議事録からSMIL lite に関係するところを転載します(ここでも河村宏さんの名前が…)。

1. Requirement for SMIL Lite
Garth Conboy: “SMIL lite” == “grin”
Tzviya Siegman: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia
Marisa DeMeglio: link in GotoChat
… we’ve been looking at design reqs for syncronized multimedia
Rachel Comerford: https://github.com/w3c/publ-wg/wiki/Requirements-and-design-options-for-synchronized-multimedia
Marisa DeMeglio: allowing talking books to talk
Tzviya Siegman: can you give a quick overview?
Marisa DeMeglio: EPUB3 didn’t have a lot of problems with media overlays
… we can look at something lighter than SMIL
… we used a slim subset in EPUB3
… but SMIL adoption in the world at large hasn’t been huge
… so we can look at other formats
… we do need to link chunks of text with chunks of audio
… you still need structural semantics for navigation etc
… making video + text transcripts more accessible is a requirement
… and there are some things not included in media overlays
… I’ve been emailing with dweck
… like having multiple granularities of navigation–from para by para to word by word
… text + sign language
… video + descriptive audio
… all those are not covered by media overlays
… our next step is deciding what format to do
Garth Conboy: That multi-resolution MO approach was discussed some years ago, and I think prototyped in Readium, I think. It’s a cool idea.
Marisa DeMeglio: first question is about formats–XML or not XML
Dave Cramer: what’s the status of audio sync on the web at large?
Marisa DeMeglio: I don’t know of anything
Ivan Herman: I don’t know much more
… I love your understatement… SMIL adoption is terrible
… we will have to define a SMIL-lite which has any hope for implementation
Bill Kasdorf: is there an active SMIL WG?
Ivan Herman: we will also have to ensure there will be several implementations on top of browsers
Laurent Le Meur: I agree with Ivan when he says we’ll have to create polyfills
… if this is the case, if JS is the language that will use SMIL, then XML is not the best structure for that
… JSON has the lead, a structure JS loves
… SMIL is so complex, there are too many features
… we can track as JSON structure
Garth Conboy: Marisa is also correct, when saying MO/SMIL(lite) adoption in EPUB Reading Systems is pretty good.
Laurent Le Meur: as for the requirements, we should make sure the structure we define doesn’t prevent us from adding advanced features later
Ric Wright: one other area is where there is a SMIL implemenation is for animation of SVG
… this has been implemented by browsers
Avneesh Singh: the main objective of this work was lack of support of SMIL on the web
… and then additional things came up
… that were not covered in EPUB3 MO
… media fragments is the one thing in the web which is used
… if we can find out groups in web who are trying to solve similar problems
… we can try to do it together
Charles LaPierre: ETS and Mark Hakkinen has done lots of work with SMIL
… they might have some insight
… they use this for assessments
Tzviya Siegman: the larger group should comment about requirements
… this is not part of our charter… so what should we do with these requirements? What are next steps?
Ivan Herman: as usual, this was the topic I wanted to put on the queue
… that’s an admin problem
… this whole issue of SMIL lite is not in our charter, but is a necessary thing
… this would be rec-track work
… the traditional way to do something like this would be to form a separate CG
… that would look at an initial spec plus one or two polyfills, showing it is possible
… once the CG says we have this, it solves these requirements, it’s polyfilled, it has users
… the most obvious way would be to then form a new WG
Garth Conboy: From charter: “This specification should generally be a functional superset of EPUB 3.1. Functional round-tripping to/from EPUB 3.1 considered highly desirable.” So, would could argue it’s kinda in our charter, as it’s in EPUB 3.1.
Ivan Herman: I still believe something like SMIL is still necessary for the web, and not only for WP
… even if WP is driving this here
… the web in general would benefit
… we then could get experts from other places for a CG
… I have some colleagues in Amsterdam who worked on original SMIL
… some of them are still around; I can approach them
… but a WG would be too much for them
Tzviya Siegman: the next steps are to clean up requirements and share them
… we should pass this on to APA, and share with Janina
Ivan Herman: there are some other media-related groups, like a video group
… they might have feedback
… and outside w3c there are other groups
Marisa DeMeglio: to comment on SMIL
… DAISY was in smil WG
… we used SMIL more than anyone else, but used less of it
… our use case was really different from everyone else’s
… they used it for short presos, annotations, etc.
… we used for entire books
… I’m not sure that reawakening the SMIL group would be good
… we might look elsewhere for overlap
Ivan Herman: it’s going to be very light, very concentrated
Tzviya Siegman: it might come down to how you position it
… I can help with that
Avneesh Singh: that’s a valid point from marisa_demeglio
… we need more strength to make it an implementable standard
… we need to strike a balance for something useful for our requirements as well as for others
… that IPTV was looking for something like SMIL
… Hiroshi can be a liason
… and Mark H can also help
Tzviya Siegman: we have people volunteering to be liasons
… joanie might know who to talk about at the browsers
Avneesh Singh: I will contact Mark Hakkinen and Hiroshi Kawamura
Bill Kasdorf: I was going to ask Marisa if there is a link she can share that documents the subset of SMIL that is actually used by DAISY
Marisa DeMeglio: bill_kasdorf: http://www.idpf.org/epub/31/spec/epub-mediaoverlays.html#sec-overlays-def
Bill Kasdorf: marisa: thanks, I didn’t realize that the MO spec in EPUB 3.1 was the subset you were talking about. That’s great to know because that is what folks are actually using in the publishing world.

アクセシビリティの観点からWebブラウザで標準で取り入れて欲しいUI

6年ほど前に以下のエントリで電子書籍のUIでWebブラウザのUIをまねて欲しいところを書いたことがありますが(6年前かぁ・・・)、今回は逆の話で、WebブラウザのUIで電子書籍のUI(機能というべきかもしれない)を取り入れて欲しいという話。

 ウェブサイトに自治体や公的機関のサイトで、文字の拡大縮小や白黒反転機能などを備えているものものあります。これの要否については、OSやブラウザの標準の機能で備えているので、それを阻害しないようなウェブサイト作りをするべきで、まずはそれにリソースを割くべきという考えがおそらく主流なのだと思います。私も基本的にはこれに同意しますが、一方で、OSやウェブブラウザの機能がどこまで使いやすいかということもやや疑問がなくはありません。
 例えば、OSで白黒反転表示することは可能ですが、これはPC上で行う全ての作業が白黒反転されてしまうので、これに切り替えて使うには、かなりの覚悟がいるというか、白黒反転でなければもう使えないという方に限られてしまうのではないかと思ったりする。
 私も子どもが寝かしつけで抱っこしている際は、部屋を真っ暗にして、iPhoneで電子書籍などを読んでいたこともありましたが(片手で指挟んででも読めるし、暗いところでも読めるので重宝した→当時のエントリ)、そういう場合は、普通の画面ではまぶしすぎるので、白黒反転表示で環境によって読んでいましたが、環境によって、表示を切り替えたいというニーズもあるのではないか。
 
 いわゆる「健常者」と、いわゆる「障害者」の間にはとても大きな層があって、例えば、高齢者の方などはだんだんWebブラウザが使いづらくなっていくことに気がつかないまま、使わなくなるか、遠ざかってしまうという人もいるのではないか。
 Webブラウザで文字の拡大縮小はだいたいついていますし、ボタンで変更できるUIを備えたブラウザもある。しかし、それ以外は、ユーザー側で表示を切り替えるのはかなりハードルが高い。ウェブサイトごとに表示を切り替えたい気もするし、環境に応じて切り替えたい。
 電子書籍だと、文字拡大や、フォント変更、行間変更、配色変更などはほぼ標準的についていますが、Webブラウザでもそういう機能とそれを気軽に使えるUIを備えてもらえないかなと思ったりする。拡張機能で追加できるかもしれないけど、標準で備えてもらってこそ多くの人の手の届くと思うので。