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

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

　

※2018/08/11　追記

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

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

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

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

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

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

　Website Usability Infoでブロックスキップに関するエントリが３月に公開されています。また、それに対して、@kazuhitoさんも返信エントリを公開されています。

• ブロックスキップを考える — Website Usability Info
• Re: ブロックスキップを考える | 覚え書き | @kazuhito

　Website Usability Infoの公開から2ヶ月が経過がしてしまい、タイミングを逸してしまった感もありますが、ブロックスキップについては、いろいろと考えさせることも多いので、少し自分の考えをまとめておきたいと思います。

そもそもブロックスキップがなぜ必要なのか

　スクリーンリーダーユーザーであるか否かに関わらず、そのページのメインコンテンツにたどり着くコストが少なければ少ないほど、そのページは使いやすい、というのがブロックスキップを考える上での大前提です。
　視覚機能に問題がなく、マウス等のポインティングデバイスを利用できる人であれば、視覚的にメインコンテンツを認識して、マウスでフォーカスをメインコンテンツに移動させることも容易ですが、スクリーンリーダーユーザーのように、ウェブページ中を１つずつ順番に移動するユーザーにとっては、画面表示時のフォーカスの開始点とメインコンテンツの距離が離れていればいるほど、使いづらくなります。そのようなユーザーにとっって、メインコンテンツに辿り着くコストが高くなる場合は、ブロックスキップのメカニズムを用意する必要があります。
　ブロックスキップの実装方法として、WACG達成方法集では、①スキップリンクの設置（G1: メインコンテンツエリアへ直接移動するリンクを各ページの先頭に追加する）、②見出し要素やARIAランドマーク等による適切にマークアップによる構造化（H69: コンテンツの各セクションの開始位置に見出し要素を提供する、ARIA11: ページの領域を特定するために ARIA ランドマークを使用する）が紹介されていますが、どちらも一長一短で、必ずしも全てのスクリーンユーザーが使いこなせるものではないと感じています。　
　

スキップリンクの有効性

　スキップリンクは、ユーザー側からみても、支援技術からみても、ただのページ内リンクにすぎません。同じページ内に大量にリンクが埋め込まれている中では、スキップリンクを機械的に判別する方法はありませんので、リンクテキストの内容から判断するしかありません。スクリーンリーダーユーザーは、Tabキーを連打して、リンクテキストからリンクテキストへとフォーカスを高速で移動することが多いので、そのような操作の中で、大量のリンクに紛れるスキップリンクをリンクテキストの内容からユーザーに判別できるかどうか、です。

スキップリンクのラベルをどう表記するか？誰でも理解できる平易な言語表現が可能か？
ブロックスキップを考える — Website Usability Info

リンクラベルにまつわる課題は大きいと思いますね。リンクラベルはユーザーにとってわかりやすい、遷移先をイメージしやすいものにする必要があるわけですけど、スキップリンクでは特にユーザーに学習コストを強要する結果に陥りがちというか、ユーザーの側からすると、同じサイト内にある複数のページを閲覧した結果としてようやくページ間にある構造上の共通点を学習でき、そこで初めてラベルの意味するところが実用性を伴って伝わるのではないかと思っていて。
Re: ブロックスキップを考える | 覚え書き | @kazuhito

　上でお二人が述べられているように、ナビゲーションとしての使用に耐えうる短い言葉で、リンク先を誰でもイメージできる言葉は、なかなか難しいと、個人的にも感じているところです。@kazuhito さんが上で書かれているように、何度か使用してサイトの構造を学習した上でないと、リンクテキストの意味を理解することが難しいことが多いのではないかと思います。
　また、スキップリンクは、当然ですが、そのリンクテキストにフォーカスが当たらないと使用できません。スキップリンクの存在に気がつかず、スキップリンクを通過していまうと、当然、そのスキップリンクは活用できません。そこにあると知っていれば、フォーカスをうまく当てる事もできると思いますが、ユーザーは、最初にそのページを開いた時にはそのページの情報を全く持っていませんので、スキップリンクがどこに埋め込まれているかもわからない、そもそもあるかどうかもわからないという状態で、大量のリンクテキストを高速にフォーカスを移動しながら読み上げるわけですので、リンクテキストの内容を判断して、ピタッとフォーカスを当てて、利用するというのは、なかなか大変ではないかと思います。Tabキーを連打して、フォーカスを高速で、しかし、1つずつ順番に移動する場合に、スキップリンクの存在を気がつかずに通過してしまっているケース、多いかもしれません。
　ただし、スキップリンクが無用というわけではありません。スクリーンリーダーユーザーのICTスキルにもばらつきはあり、後述する見出し要素間の移動などができない人もいると思います。Tabキーによるフォーカスの移動やリンクテキストにフォーカスをあてた上でリンク先に移動することは、見出しジャンプよりは利用できる方がずっと多いと思いますので、スキップリンクを不要であるとは言い切れない。ユーザーが何度も繰り返し利用するようなウェブサイトでは、自然のページの構造は把握できるでしょうし、スキップリンクの存在も把握するようになりますので、スキップリンクの存在は、ユーザービリティを高める一定の効果はあると思います。
　今回は言及しきれませんが、Website Usability Infoでも言及されているように、スクリーンリーダーユーザー以外にも、マウスが使用できず、キーボードだけで操作を完結させたい（あるいはさせる必要がある）ユーザーや、キーボードも使用困難でスイッチ等でウェブを利用するユーザーが存在します。一般のウェブブラウザでは、後述する見出しジャンプ等はできませんので、スキップリンクが視覚的に認知しやすい設計であれば、これらのユーザーにとって、サイトの利便性を大幅に向上させるものになると思います。

見出し要素やARIAランドマーク等による適切にマークアップによる構造化

　Website Usability Infoで書かれているように、確認する限り、PC-Talker、NVDA、ナレーター、JAWS、VoiceOverなど、主要なスクリーンリーダーは全て見出し要素間の移動をサポートしています（WAI-ARIA ランドマークのサポートは知りませんでした　汗）。
　見出し要素間移動やランドマークの移動は、操作に必要なキーを押せば、フォーカスがどこにあっても使用することができます。スキップリンクのように特定のリンクテキストにフォーカスを当てる必要をユーザーに強いることはありません。スキップリンクなどの特定のサイトの使用に習熟するよりは、支援技術の操作方法というより汎用性の高い手段に習熟したほうがユーザー側にとってメリットが大きいと思います。
　と、思うのですが・・・
　上で述べたように、スクリーンリーダーユーザーのICTスキルもかなりばらつきがあり、見出し要素間の移動などを使いこなすことができないユーザーも多いと感じています。あくまで私個人が感じた中での話ですが、このあたりは、私が接する機会の多いユーザーが、Webをがんがん利用する方というよりは、DAISYを利用したいために、Web（もっと具体的にはサピエ図書館など）を利用するという方が多く、傾向として高齢の方が多いということがあるかもしれません。スクリーンリーダーを使用するのは、視覚障害者に限りませんが、視覚障害者に限定するなら、視覚障害者の高齢化を非常に進んでいます（参考: 日本の視覚障害者の人口-日本眼科医会の調査より）。ユーザーのICTスキルにかなりばらつきがあることは留意する必要があるのではないかと感じています。

やはり優先すべきは、そもそもソースレベルでのページ設計から

　スキップリンクも適切なマークアップによる構造化も全ての人のとっての解決策にはならないように感じます。考えると、やはり考えるべきはページ設計の段階でメインコンテンツへ到達するコストを可能な限り減らすことを検討するべきだと思います。これはスクリーンリーダーユーザーに限定されず、あらゆる、控えめに言っても一般ユーザーを含む幅広いユーザーにとって、ユーザビリティを高めるものと信じます。そう考える私ですので、

コストをかけてスキップリンクを「正しく」設計することに腐心する代わりに、そもそものウェブページ設計において、メインコンテンツ手前のブロック (ナビゲーションメニュー) をコンパクトにすることを検討する、というのも合理的な解決なのかなと考えます。
ブロックスキップを考える — Website Usability Info

　@kazuhito さんも「200%同意します」とおっしゃっていますが、私もWebsite Usability Infoのこの意見に完全に同意します。
　スキップリンクも適切なマークアップもメインコンテンツへのアクセスを改善しうる方法ではありますが、十分ではないということからもまずは、上の先に考え、追加でスキップの設置を考えるべきなのだろうと思います（適切なマークアップは、ブロックスキップ云々を考える以前に対応すべきということで）。
①　メインコンテンツに辿り着くコストをソースレベルで減らすことをまずは考えるべき
②　適切なマークアップによる構造化
それをフォローする形で
③　必要に応じてスキップリンクを埋め込む
という形が現時点では必要ではないかと考えています。
①が十分であれば、③は不要になりますが、②と③だけでは、上で述べたように①で生じる問題は十分に解決できない、と思う。

スキップリンクを設けなくても、さほどストレスなくメインコンテンツ内をフォーカスできるようになるのではないでしょうか。たとえば 5～7つくらいのメニュー項目で、メインコンテンツにたどり着くまでの [Tab] キーの押下回数が10程度であれば、(サイト独自のスキップリンクの使いかたを学習して操作することと比較しても) そう悪くない気がします。ブロックスキップを考える — Website Usability Info

　こちらもほぼ同意で、個人的にも以下のように感じています。もう少しこれは、いろいろな人の意見を聞いてみたいところ。

• Tabキーの押下回数が10程度であれば、つかいやすい。スキップリンクを設けることで、むしろTabキーを押す回数が増えてしまうので、設置の要否そのものを検討するべきレベル
• 20程度でも、ちょっと使いづらいかもしれないけど、スキップリンクの使い方を学習しなくてもTabキーのみで使えるレベル（許容範囲）、ただし、スキップリンクの設置は必要

　5以下になると、スクリーンリーダーユーザーにとっては、「超絶使いやすい」といレベルと思いますが、視覚障害者等の利用に特価したサピエ図書館でも一部でしか実現できていません。グローバルナビゲーションをそのものをバッサリ切ってしまうなどしないとなかなか実現できない領域で、そこでまやるとなると、@kazuhito さんの別のエントリの言葉を借りれば、「音声でコンテンツを読み上げさせる、というコンテキストに目一杯寄せた（そういう目的に特化した）デザインは、全体最適化ではなく部分最適化を目指したもの」になるかもしれません。スクリーンリーダーユーザーの利用に特化したサイトであれば、それでも良いと思いますが、幅広いユーザーが利用することを想定するサイトであれば、Website Usability Infoでエントリの最後に以下のように締められているように、サイト全体のコンテンツのあり方を含めて、まずはサイトの構成をシンプルにする方向で検討し、必要な情報をウェブページにシンプルな構造で埋め込めるよう、デザインに落とし込めるとよいのかなと考えています。その方向を追及できるとよいのですが。
　

メニューの項目数を絞ることはユーザーの認知負荷軽減 (選択のしやすさ) という点でも意義があります。また、メインコンテンツの手前をコンパクトにすることはスモールスクリーン (スマートフォン) でのウェブコンテンツ利用という文脈にもマッチします。対処療法的にスキップリンクに頼らざるを得ないケースもあるかもしれませんが、せっかくならユーザビリティの向上も見据えつつウェブページ設計を最適化することも含めて、考えたいなと思います。
ブロックスキップを考える — Website Usability Info