a11y界隈では珍しくトゲのある議論を見かけたのでちょっと追いかけたら面白い課題に出くわしたという話です。
最初に見たのがこちら
電子書籍の読み上げで「IT」が「イット」と読み上げられてしまうのを避けるために「I T」のように空白を入れるというバッドノウハウを自慢気に語る人たちがいて嘆かわしいという話。そんな非生産的で副作用の大きいクソみたいな単純作業をするくらいなら、読み上げソフトに機械学習を導入して根本的に誤読を減らす方がエンジニアリング的に正しい道だと思います。
http://sho.tdiary.net/20170201.html
まあEPUBを「E PUB」と書いている時点で読者を馬鹿しているのかな、という感想です。
http://momdo.hatenablog.jp/entry/20170202/1486036120
ハンドアックスがぶん投げられてるのを見るのは久しぶりだなーとか変な感想を持ちつつ、a11y周りではこういう"けちょん♪"という感じの議論は珍しいなと思った次第。
こういう流れだったっぽい
議論をたどっていった結果、以下のようなことがあった模様。
- 1月30日に東洋大学で「『電子書籍アクセシビリティの研究』公刊記念シンポジウム」が開催された。
- 当該書籍では音声読み上げで誤読を0にした
- 誤読0にするための著者側でのテクニックが紹介されていた
- そのテクニックの一部はよくないとWeb系のa11y関係者は感じた
- また読み手の視覚障害者からも「誤読はこっちで脳内修正するからあまり気にすんな」との声も出ていた。
- その後の飲み会でヒャッハーした
- これはバッドノウハウだろうとの記事がいくつか上がった
ってな状況のようで。
昔のはてな界隈でよく見たサツバツ感が足りませんが、けちょん、って空気が出てきたのはこの界隈にとってはあまりよくない気がします。「善意が空回り」ってのをdisってもねぇ、と。やっちまった著者陣は赤っ恥でしょうが後に続くおいらたちにとっては貴重な事例なわけでありまして。おかげでa11yの知識も増えましたし。
論点整理
- 音声読み上げソフトの「誤読」はかなりの頻度で発生する。
- 現状では読み手の視覚障害者たちが誤読として理解し処理している。
- 著者側で取りうる誤読対策として、頭字語の文字間にスペースを入れる、書き方を変える、読みを補足するの3点があげられる。
- このうち読み補足以外の手法には異論がある。
前提知識として、
頭字語とは
イニシャリズム (initialism)：頭文字を一字ずつアルファベットの名のままで読むもの。例： FBI（エフ・ビー・アイ）、OECD（オー・イー・シー・ディー）、WHO（ダブリュー・エイチ・オー）など。
https://ja.wikipedia.org/wiki/%E9%A0%AD%E5%AD%97%E8%AA%9E
アクロニム (acronym)：連なったアルファベットを通常の単語と同じように発音して読むもの。例： AIDS（エイズ）、OPEC（オペック）、NATO（ナトー）など。
ウェブアクセシビリティ上の扱い（WCAG2.0）ではイニシャリズム（頭文字語と訳している）への空白文字の挿入は不適合とは断じていない。
「空白文字」については、
F32の解説でいうところの空白文字、原文では"white space characters, such as space, tab, line break, or carriage return"というのがどのような集合を指すのかがあやふやなのが気になるところ。
http://momdo.hatenablog.jp/entry/20170202/1486036120
これたぶん、文字をdivとかで囲んでdisplay:inline-block;で並べた時に正体不明の余白を生じさせるあれ（普通じゃ見えない文字）じゃないですかね。
考察
基本的に音声読み上げソフトはまだ発展途上にあって、誤読問題を抱えていると。
それを現状で何とかしようとした結果が今回の問題であって、これとどう向き合っていき、どうしていけばいいかを俺たちゃ考えなきゃいけないわけです。
現状のまま読み手側が勝手に修正解釈するのに甘えるってのは書き手・編集・エンジニアのコケンに関わるので無しって方向で。
今回著者側からの提案
http://kidachi.kazuhi.to/blog/archives/039318.html
- 用字変更・その他（例：IT → I T）
- 表現変更（例：3/4 → 4分の3）
- 読み補足（例：AA → AA（ダブルエー））
があって、少なくとも1つ目のスペース入れるのは読み上げソフト特化型のハックであり、マシンリーダブルとは言えない（検索性が著しく劣化する、また機械翻訳がまともに機能しなくなる恐れも）、晴眼者向けにも違和感を生じさせるため、むしろアクセシブルとは言い難いのではないかと思います。
表現変更については、書き手の表現の幅を狭めるので編集側のコケンにかかわるだろうと。
本手法に対しては、「ワープロのルビ機能も使えず、プレーンテキストしか書けない人が全部引き受けようとして無理をしている対策」という印象を受けます。
ここはエンジニア・コーダー側の出番ではないかと。
案1 rubyタグで処理
HTMLコーダーの目からすると、「これら全部ruby要素とかで処理できないか？」って思うんですがどうなんでしょう。
まだ試してないんですが、cssのメディアクエリのspeechとか使ってごにょごにょしたら通常の読み上げでは振り仮名を、単字送りでは漢字の方を読み上げさせることできないかなー、というのを以前から考えていて、それで読みの補足と表現変更分はカバーできるんじゃないかというのが私の考え。
で、頭字語についても、rubyかabbrタグでどうにかできないかなと。
この案の欠点は、単にスペース入れるだけよりはるかに膨大な手間がかかるってところでしょうか。
電子書籍化する段階で置換すれば手間が省けますが、今度は誤置換を防ぐノウハウが必要になります。原稿の段階では単語の前後にアンダースコアを入れるとか、置換時に単純検索ではなく正規表現を駆使して誤置換を防ぐとかいう形になるのではないかと思います。
案2 規格を変えてしまえ
最初は<initialism>タグができるといいんじゃね？、とか書くつもりだったのだけれど、ググってみたらなんかあったわw。
提案中なのか却下されたのかよく分かりません。
案3 書籍ごとに辞書付けたら？
HTMLのメタタグみたいなもので、単語と読み方の指示を先に書いておく。
リーダー側でそれを読み込んで、正しく読み上げる、という仕組み。リーダー側の対応が必要である課題は残るものの、書き手側の負担は最小限に抑えられ、表現の幅も確保できるはず。ヘッダーとかに分離しておけるのでこの技術が不要になっても悪い影響は残らない。
将来は機械学習に置き換わるにしても、その学習データとして有効に活用できるのではないかと思います。
案4 JavaScriptでどうにかできないか
案1、4を現状で実現するのに、JavaScriptを使って検索・置換して対応する。
一体どういうコードになるのかなんてのは分からんわけですが、著者・編集側の負荷をほとんど増やさずにできるのではないかなと。
