耳で読む人に「前回のあらすじ」を — arasuji.js を作った

はじめに

ディスレクシアを持つ知人が、「読書を楽しめない」と話していた。

文字を目で追うこと自体に、強い疲れを感じるのだという。だからその人は、スクリーンリーダーなどの音声読み上げで文章を読んでいる。

前回の記事の最後に、本を読むのではなく聴く、という道について書いた。その道が用意されていて、本人が選べることが大切だと。 けれど、音声で読む道が「ある」ことと、その道が歩きやすいことは別の話だと思う。

今回は、耳で読むときに生まれる引っかかりを一つ取り上げて、それを小さくするためのライブラリ arasuji.js(新しいタブで開く) を作ってみた。デモは https://arasuji.takosu.me/(新しいタブで開く) に置いてある。

目で読むことと、耳で読むこと

目で読むのと耳で読むのとでは、情報へのたどり着き方がそもそも違うのではないか。それが出発点だった。

目で読むとき、私たちはページ全体をほぼ一度に見渡している。見出しの並びや段落の長さ、太字の位置が、読む前からなんとなく目に入る。気になったところへはすぐに戻れるし、飛ばしたいところは飛ばせる。

耳で読むときは、そうはいかない。音は一つずつ、時間の順にしか届かない。頭から順に再生していくのが基本で、全体を見渡すことは難しい。

前回の記事でいう「時間の主導権」の話にも近いけれど、今回気になったのはもう少し具体的な場面だった。

中断したあとの「再開の壁」

長い文章を、一度で読み切れるとは限らない。途中で用事が入ったり、疲れて休んだりする。問題は、そのあと戻ってきたときだと思う。

読むのを再開するには、「どこまで読んだか」と「何が書かれていたか」を、自分で覚えておく必要がある。

目で読む人なら、見出しや太字をざっと流し見るだけで、文脈はすぐに戻ってくる。本人はたぶん、思い出す作業をしている自覚すらないと思う。

耳で読む人には、この流し見ができない。最初から聞き直すか、あいまいな記憶を手探りでたどるしかない。文章が長いほど、この負担は重くなる。

「読書を楽しめない」の理由はきっと一つではない。ただ、その一部はこの「再開の壁」にあるのではないか、と考えた。

アニメの「前回のあらすじ」

ヒントにしたのは、アニメの冒頭に流れる「前回のあらすじ」だった。一週間空いても話に戻れるのは、あれがあるからだと思う。

arasuji.js は、ページを開いたときに、前回どこまで読んだか、続きはどこからか、ここまでの要点、残りの節の数を読み上げる。たとえば、こんな文になる。

前回は3日前、「関数の定義」の節まで進みました。続きは「引数と戻り値」からです。自分で関数を作ることを「定義する」といいます。残り2節です。

聞き終わったら「続きから読む」を押すと、続きの節の見出しにフォーカスが移る。あらすじを聞いて、そのまま読み始められるようにした。もう一つ「全体像を聞く」では、ページ全体の節の並びと、どこまで読んだかを読み上げる。目で読む人が見出しを流し見るのと同じことを、耳でできるようにしたかった。

既存のページに 2 行足すだけ

作るときに決めていたのは、既存のページに手を入れずに使えるようにすることだった。HTML にクラスや属性を足す必要はなく、ページの末尾に script を 2 行足せば動く。

<script src="./arasuji-data.js" defer></script>
<script src="/arasuji.js" defer data-container="main" data-heading="h2"></script>

どこが本文で、どれが節の見出しかを指定するだけだ。読み上げには aria-live を使っていて、表示する UI は自分で作ったものに差し替えることもできる。

「ここまでの要点」の要約は、AI で事前に作っておく。そのまま使うのではなく、人が中身を確かめてから配信する前提にした。読んでいる最中にページの本文を外部へ送ることはしないし、どこまで読んだかの記録も、ブラウザの localStorage の中にしか残さない。要約がなくても動き、その場合は要点を省いたあらすじになる。

特定のサイト専用にしたくなかったので、ライブラリの形にした。サイトを作る側が組み込むだけでなく、読む人が自分で差し込めるように、ブックマークレットと Chrome 拡張機能も用意している。サイトが対応してくれるのを待たなくても、自分で道を作れるようにしたかった。

実在の教材サービスでも試してみた。そこでは本文が iframe の 2 段下にあり、拡張機能から本文の入った iframe を選んで差し込めるようにした。ただ、こうしたサイトはそれぞれに個別の設定が必要になる。

このブログにも入れた

このブログにも arasuji.js を入れた。節のある記事では、ヘッダーの「ダークモード」の隣に「『前回のあらすじ』を使う」というボタンが出る。

ただし、最初はオフにしてある。ボタンを押してオンにした人にだけ動き、もう一度押せばオフに戻せる。

あらすじに助けられる人もいれば、ページを開くたびに読み上げが始まるのを煩わしく感じる人もいると思う。目で読む人にとっては、なくても困らないものかもしれない。だから、全員に同じものを押し付けるのではなく、使うかどうかを読む人が選べるようにした。

前回の記事で、道が用意されていて本人が選べることが大切だと書いた。新しい道を一本足すことと、その道を通らなくてもいいことは、どちらも選択肢を増やすことだと思う。

まだわかっていないこと

一番大事なことを書いておくと、当事者による検証はまだできていない。

今回作ったのは、仮説を確かめるための道具だ。「再開の壁」が本当に壁になっているのか、あらすじを聞くことで本当に楽になるのかは、実際に使ってもらわないとわからない。もしかすると、私が想像したのとはまったく違う場所でつまずいているのかもしれない。

ほかにも、わかっている制約がいくつかある。読んだ位置は端末ごとに記録しているので、別の端末には引き継げない。要約は事前に作っておく必要があり、要約のないページでは要点が読み上げられない。また、画面遷移で中身が入れ替わる SPA のようなページには、まだ対応できていない。

おわりに

「読書を楽しめない」

この言葉に対して、ライブラリ一つでできることはほんの少しだと思う。楽しめない理由のすべてを解決できるわけではないし、そもそも私の仮説が外れている可能性もある。

それでも、途中でやめても、耳で続きから読める。それが当たり前になれば、音声で読むという道は、少しだけ歩きやすくなるのではないかと思う。

次は、当事者に実際に使ってもらって、この仮説が合っているのかを確かめたい。

記事一覧に戻る