ウェブブラウザの「リーダー」モードの実装状況

ウェブブラウザでメインコンテンツ部分に集中にして閲覧することができるモードがあります。以下のようにメインコンテンツ部分のみを表示し、フォントサイズや配色等を変更できる機能です。Safariが「リーダー」モードを実装したことが端を発していますが、最近では、Safari以外でのいろいろなブラウザがそれに相当する機能を備える様になっています

アドレスバーの横のリーダーモードボタンを押すとリーダーモードが表示され、文字サイズや配色、フォントが変更できる
Safariのリーダーモード

 「アクセシビリティの観点からWebブラウザで標準で取り入れて欲しいUI」というエントリでも書いたことがありますが、閲覧環境を柔軟に変更できる機能は、OSでもなく、支援技術でもなく、そして、ウェブサイト側でもなく、本当はウェブブラウザ側で実装する必要があるのではないかと感じていますが、このリーダーモードはそれに近い機能と言えます。
ブラウザの「リーダー」モードの実装状況とそのモードが備えている機能を少しまとめてみました。

「リーダー」モードの実装状況とその機能
ブラウザ名 標準実装 モード名称 文字の拡大縮小 背景色と文字色の変更 フォント変更
(フォントの種類)
文字間隔調整 行間調整 縦書・横書の変更 合成音声による
読み上げの呼び出し
その他
Chrome(Mac OS)
68.0.3440.84
無し
Fiirefox(Windows 10 / Mac OS)
61.0.1
有り リーダービュー 有り 有り 有り
(2種類)
有り 有り 無し 有り
Microsoft Edge
42.1734.1.0
有り 読み取りビュー 有り 有り 無し 有り 無し 無し 有り
Safari(Mac OS)
11.1.2
有り リーダー 有り 有り 有り
(4種)
無し 無し 無し 無し
Moblie Safari (iOS) 有り リーダー 有り 有り 有り
(4種)
無し 無し 無し 無し
Vivaldi (Windows 10 / Mac OS)
1.15.1147.55
有り リーダービュー 有り 有り 有り
(2種類)
無し 有り 有り 無し 幅調整有り
Internet Explore 11 無し
NetReaderⅡ 無し

 

※2018/08/11 追記

 kazuhito さんより本エントリについて、Re: ウェブブラウザの「リーダー」モードの実装状況 というリプライエントリをいただきました(ありがとうございます)。
 本エントリの以下の言葉について

閲覧環境を柔軟に変更できる機能は、OSでもなく、支援技術でもなく、そして、ウェブサイト側でもなく、本当はウェブブラウザ側で実装する必要があるのではないかと感じています

 上について、以下のようなコメントをいただいていますので、少しだけ補足を。

kzakzaさんは優先順位を説いていらっしゃるようなのですが、そこは自分は異なる意見を持っています。ユーザーニーズに寄り添うための機能は、コンテンツの側とそれを表示する側の両方に必要だし(表示がコンテンツそのものからある程度分離されていないと「リーダー」モードだってうまく機能しないはず)、両方が相応の機能を備えてはじめてユーザーニーズを満たし得ると思います。そして表示する側に位置付けられるブラウザ(というかUA)、支援技術、OSはそれぞれに異なるレイヤーにあって、異なる価値なり機能提供が可能であるからして、やはりそれら全てがいい塩梅に連携・協調してこそ……と思います。
Re: ウェブブラウザの「リーダー」モードの実装状況

 私の理解に相違なければ、kazuhito さんの上のコメントに全く異論はありません(むしろ強く同意します)。追記冒頭で書いた本エントリの言葉は、ウェブの閲覧環境を柔軟に変更できる機能を標準で搭載するべきはブラウザではないか、ぐらいの意味で書いたもので、それは排他的な役割分担を意図したものではなく、支援技術やコンテンツ側にそれを実装すること自体を否定するつもりはありません。
 
 kazuhito さんが「それぞれに異なるレイヤーにあって、異なる価値なり機能提供が可能」と書かれているように、それぞれのレイヤーがそれぞれの守備範囲と目的やベクトルを持っています(端的に言って、ウェブを利用するだけでは収まらない人はOSなり、支援技術の利用は欠かせないでしょうし、適した閲覧環境も人によってかなり異なるはずなので、支援技術のフォローが必要な人も)。それらが協調したり、場合によって異なるベクトルから重複した役割を担うことで、100人のユーザーがそれぞれ自分の使いやすい100通りの環境を選択できることが望ましいのだろうと考えています。
 ただ、それを前提として、「アクセシビリティの観点からWebブラウザで標準で取り入れて欲しいUI」で書いたことがありますが、OS、支援技術やコンテンツ側でフォローできないところがあると感じていて、ウェブの閲覧環境については、他のレイヤーよりももっと負うべきものがブラウザ(UA)にはあるのではないか、というものがこの追記冒頭で再掲した本エントリの一文の趣旨でした。ただ、改めて読むと、「OSでもなく、支援技術でもなく、そして、ウェブサイト側でもなく、本当はウェブブラウザ側で」という書きぶりが、読む方に排他的な機能の棲み分けを想起させてしまいますね。今頃気がつきました(すいません 汗)。

bes形式の点字データをユニコード点字のテキストデータに変換するスクリプト

 @brlat さんが BES形式の点字データをユニコード点字のテキストデータやマークダウン記法のテキストデータに変換するスクリプトを公開しています。

 IBM由来のBES形式はこれまたIBMのてんやく広場由来のサピエ図書館で採用されているため、日本の点字データとしては幅広く使用されている形式ですが、点字はすでにUnicodeで登録されており(参考 :Unicode点字と点字フォーマットPEF(Portable Embosser Format))、Unicode点字も様々な環境でもすで対応はしているようです。ユニコード点字が活用されば、BES形式の点字データ以上に非常に幅広い環境で利用できるようになると思いますので、BES形式からユニコード点字に橋渡しするスクリプトの存在はとても貴重なのではないかと思います。

ためしてみた

 ためしに国立国会図書館が公開している「国立国会図書館の障害者図書館協力」パンフレットのBES形式版(以下)でユニコード点字のプレーンテキストに変換するスクリプトを試してみました。マークダウン記法のスクリプトも今度試してみたいですね。

元データ

[点字版]「国立国会図書館の障害者図書館協力サービス」パンフレット(BES: 14KB)

アウトプット(一部のみ抜粋)

 全文掲載すると長くなりますので、一部のみ抜粋した形で掲載します。なお、Unicode点字はUnicode点字変換などでひらがな文字に変換することもできます。

⠪⠩⠓⠝ ⠪⠂⠡⠃ ⠞⠈⠺⠡⠴⠎
⠈⠺⠒⠐⠡⠃⠈⠱ ⠞⠈⠺⠡⠴ ⠈⠪⠒⠈⠚⠩
⠶⠟⠴⠐⠳⠐⠥⠴⠶
⠼⠃⠚⠁⠓⠏⠴ ⠼⠋⠐⠡⠝
⠪⠩⠓⠝ ⠪⠂⠡⠃ ⠞⠈⠺⠡⠴
⠾⠩⠐⠳ ⠼⠁
⠾⠩⠐⠳
⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒
⠈⠺⠒⠐⠡⠃⠈⠱⠽⠫ ⠳⠈⠚⠒⠎ ⠞⠒⠐⠪⠒
⠫⠴⠱⠩ ⠱⠒⠐⠧⠹ ⠤⠪⠩⠓⠝ ⠪⠂⠡⠃
⠞⠈⠺⠡⠴ ⠱⠒⠗ ⠰⠤⠈⠺⠒⠐⠡⠃⠈⠱⠽⠫
⠳⠈⠚⠒ ⠫⠴⠱⠩⠤⠆⠤ ⠂⠂⠂⠂⠂⠂⠂⠂⠂ ⠼⠁
⠳⠡⠩ ⠈⠺⠒⠐⠡⠃⠈⠱ ⠞⠒⠜⠒ ⠐⠟⠒⠕⠎
⠈⠹⠒⠈⠹⠒ ⠊⠜⠐⠧ ⠺⠒⠳⠴ ⠱⠒⠐⠧⠹ ⠼⠉
⠈⠺⠒⠐⠡⠃⠈⠱⠽⠫ ⠳⠈⠚⠒⠎ ⠈⠺⠳⠐
⠈⠺⠐⠺⠒ ⠘⠺⠒⠮⠒⠎ ⠈⠹⠒⠈⠹⠒ ⠊⠜⠐⠧
⠟⠃⠈⠪⠒⠶⠟⠴⠐⠳ ⠞⠈⠺⠐ ⠚⠩⠊⠴ ⠞⠈⠺
⠐⠻⠴⠪⠩ ⠺⠒⠐⠪⠒ ⠾⠩⠚⠩⠶ ⠂⠂⠂⠂ ⠼⠊
⠐⠡⠩⠘⠹⠝ ⠐⠭⠴⠫⠴ ⠚⠩⠊⠴ ⠞⠈⠺⠎
⠻⠃⠱⠩ ⠊⠜⠐⠧ ⠡⠳⠐⠕⠳⠶⠻⠴⠾⠴⠻⠃⠎
⠕⠡⠃ ⠐⠡⠩⠘⠹⠝ ⠐⠭⠴⠫⠴⠔ ⠚⠩⠊⠴
⠞⠈⠺⠞ ⠳⠟ ⠓⠜⠒ ⠐⠟⠣⠙⠶ ⠂⠂⠂⠂ ⠼⠁⠙
⠺⠎⠕ ⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂ ⠼⠃⠚
⠾⠩⠐⠳ ⠼⠃
⠪⠩⠓⠝ ⠪⠂⠡⠃ ⠞⠈⠺⠡⠴ ⠮⠒⠽ ⠠⠯⠒⠐⠳⠎
⠐⠪⠁⠴⠅⠃ ⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂ ⠼⠃⠉
⠪⠩⠓⠝ ⠪⠂⠡⠃ ⠞⠈⠺⠡⠴⠎ ⠈⠺⠒⠐⠡⠃⠈⠱
⠞⠈⠺⠡⠴ ⠈⠪⠒⠈⠚⠩ ⠐⠳⠘⠪⠒⠎ ⠁⠬⠷
⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂ ⠼⠃⠑
⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒
⠖⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠲
⠪⠩⠓⠝ ⠪⠂⠡⠃ ⠞⠈⠺⠡⠴⠄⠰ ⠈⠺⠒⠐⠡⠃⠈⠱
⠱⠒⠐⠧⠹⠔ ⠐⠳⠂⠳ ⠳⠟ ⠃⠙ ⠡⠩⠈⠹ ⠞⠈⠺⠡⠴⠇
⠕⠃⠳⠟⠰ ⠱⠵⠐⠱⠵⠅ ⠳⠋⠴⠐ ⠈⠪⠒⠈⠚⠩ ⠘⠪⠒⠽⠔
⠊⠪⠅⠂⠟ ⠃⠵⠹⠲
⠓⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠚
⠼⠁

関連エントリ

アクセシビリティの祭典 2018 個人的なふりかえり

 アクセシビリティの祭典2018に参加したので、ふりかえる。当日の様子は、公開されているアーカイブ動画やこのイベントのツィート( アクセシビリティの祭典 2018 #accfes – Togetter )をみれば、よくわかると思うので、省略。
 本当は全日参加する予定だったけど、当日、別の用事が入ってしまったので最後のほうの3時間強だけの参加になってしまった。それでも、非常に濃厚だったので、この3時間だけでもかなり充足感はあった。会場について早々にイスカンダルからの通信がはじまったので、会場の雰囲気にまだ慣れていない私は、度肝を抜かれた、というか、とんでもないところにきてしまった、感があった。会場に向かいながら、流れてくる #accfes のツィートを確認していたけどと、会場に着く前には、視覚障害、肢体不自由、聴覚障害のある方がいろいろな方法や方式で情報を入手し、発信される現況のセッションなどあったりして、直接、その場でその話を見ていれば、かなりの衝撃を受けたのあろうなと思う。そういう機会を逃してしまったことが本当に悔やまれる。全日参加していたら、刺激受けすぎてヘロヘロになってしまっただろうか。
 私は、どちらかというと、アクセシビリティをやらなければならないという雰囲気の環境にいる(私自身の想いはともかく)。しかし、この祭典では、技術者が中心になっているイベントだから、ということもあるかと思うけど、技術的にいろいろとアクセシビリティ上の課題を解決できるようになった未来を、もっとこっちに引き寄せようとしている明るさを感じられて、そういう空気にいるだけでも元気をもらったような気持ちになった。前者と後者では、問題の捉え方も深さの点からも自ずと変わってくるはずだと思うし、その日もどう感じた。当日は間に合わなかったけど、@caztcha さんのお話(参考:発表の概要)を聞くことができていたら、その点、もっと痛感したのだろうか。
 会いたいと思っていた方の何人かには、辛うじて挨拶することができたけど、ほとんどの方には遠くから「おおぉ、あの方があの方か」と認識できるに留まってしまった。時間がなかったという言い訳もあるけど、人見知りなので気後れしてしまった、というか、それを振り払う小さな勇気を振り絞る時間がなかったというのが正直なところ。うーん、書いていて、これが一番残念であったかもしれない。
 私は、基本的に「図書館の障害者サービス」の人間ですが、セッションの話や会場の雰囲気を感じつつ、ここで語られているアクセシビリティ、ウェブアクセシビリティについて、どのように受け止めるべきかもいろいろと考えていたりした。 
 
 私は「図書館の障害者サービス」以外に他にもいろいろなコンテキストに関わるようになっている(ような気がする)。
・点字図書館のサービス(視覚障害者への福祉としての情報提供サービス)
・大学の障害学生支援
・アクセシビリティ
・ウェブアクセシビリティ、
・インクルーシブ・・・(は、今のところない「かもしれない」けど、視野に入りつつ「あるかもしれない」)
 他の人に説明しても、「これ、一緒でしょ」と言われて、なかなか理解されなくて、確かに本質的には同じはずだし、目指すところも同じはず。実際にいろいろ重なる。しかし、重ないところもある、ような気がする(人の交流も)。先のエントリで書いた大学図書館の障害者サービスの話は、そんな例の1つ。 複数のコンテキストに関われている自分は、多分、幸せなことなのだろうとし、嬉しい悩みなのかもしれない。でも、感じるだけではだめで、それぞれのコンテキストの違いを意識して、重なるところを軸に他のコンテキストを考えないと、一方の視点から一方のコンテキストを評価するだけになってしまうので、ごにょごにょごにょ(結論が出ていない)。
 
 話が逸れてしまったけど、この祭典で感じたある種の「敗北感」は癖になりそう。来年こそは全日参加したい。
 参加できなかったセッションは、あとで観よう。