スクリーン・リーダーでNoteを試す：閲覧編
先日の投稿でスクリーン・リーダー・ユーザーが投稿するのはちょっと大変という話を紹介したNote、今回は閲覧する場合についての感想を紹介する。
結論から言うと、画像がない記事を読むだけならまあ良いかもしれないけど、Note特有の機能の使い勝手には難あり、といった感じだ。
テキストのみの記事
テキストのみの記事を読む分には、致命的な問題はない。 とはいえ、Noteは書き手がいくらちゃんとしたHTMLにしたいと思っても、表現できる文書構造の種類が多くないので、結果として読みづらいテキストになってしまうという可能性は充分にありうる。
これまで気づいた範囲で、少し詳しく記す。
見出しの種類が1種類
文書中に見出しを入れたいという場合、利用できる見出しは1種類だけだ。 なので、この直前の見出しは本来2階層目の見出しにするべきだが、Note掲載版ではその前の見出しと同じ階層のものとしてしか表現できない。
そして、なぜかその見出しがh3になる。
記事タイトルはh1で表記されるので、本来はh2であるべきだ。
ちなみに、目次がある記事の「目次」という見出しはh4になっている。
見出しレベルが全く成っていない。
箇条書きができない
もちろん見た目を箇条書きっぽくすることは可能だと思う。
が、出力されるページで、ulやolとliを使った箇条書きになるような書き方は、僕が知る限りできない。
表も書けない
僕が知る限り、table要素を必要とするような表現もできない。
もしそういう視覚的表現が必要な場合は、おそらくは画像を張ることになるのだろう。
文書構造はそんなに重要なのか
上で示したような見出しレベルや箇条書きなどを適切にマークアップできることの重要性というのが、スクリーン・リーダーを普段使わない人にはピンとこないかもしれない。
もしかするとスクリーン・リーダー・ユーザーの中にもあまり重要性を感じていない人が少なからずいるかもしれない。
多くのスクリーン・リーダーには、Webコンテンツの閲覧の際に、こういったマークアップに基づいてコンテンツ内を移動する機能がある。
そのような機能の中で僕自身がもっとも頻繁に利用しているのが、前後の見出しに移動する機能だ。 NVDAの場合は、Hキーで次の見出し、Shift+Hキーで前の見出しに移動できる。
さらに、特定のレベルの見出しへの移動機能もある。
1キーとShift+1キーなら、次/前のh1に、2キーとShift+2キーなら次/前のh2に移動できるといった具合だ。（これもNVDAの場合）
この機能を使えば、例えばこの文章なら、「テキストのみの文書」から一気に「文書構造はそんなに重要なのか」へ移動することができる。
箇条書きに関しても、前後の箇条書きへの移動、箇条書き内部で前後の箇条書き項目（li）に移動といったことができる。
また、今読んでいる箇条書きの末尾に移動、つまりその箇条書き部分をまとめて読み飛ばすといったことができる。
このように、いわば斜め読みするような感じで、自分が必要としている情報に容易にたどり着くことができるわけだ。
文章だとよく分からないかもしれないので、以下にこの記事を使って簡単なデモの様子を張り付けておく。
画像を含む記事
つぎに、画像を含む記事についてだ。
より正確には、画像の代替テキスト（alt属性値）についてだ。
以前のNoteでは、画像に代替テキストを指定することはできなかった。
今は多少状況は改善されていて、その画像のファイル名が自動的に代替テキストとして記述されるような仕様になっているらしい。
もちろん全くなにも指定できないよりはかなりましだろう。
でも、空のaltを指定するのが妥当な場合はどうするのか。
そして、もし記事公開後に代替テキストを変更した方が良いという判断に至った場合はどうするのか。
ファイル名を変更してアップロードし直せば良いのだろうけど、それはちょっと記事製作者の負担が大きすぎるだろう。
ブログにしてもNoteにしても、僕自身が記事中に画像を張り付けることはまずない。 しかし、多くの人は何かしら写真とかイラストとかを含む記事を書くことが多いだろうし、僕たちがそういう記事を読むことも当然多い。
さらに、上述のようにもし表を使いたい場合などに、本来はテキストで記述できるものであっても画像を使わざるを得ない場合というのもありそうだ。
そう考えると、一般的なブログなどに比較して、内容が理解できないと困る画像が出現する可能性は高いのではないかと推測する。
スクリーン・リーダー・ユーザーにも同様に情報を伝えたいという人にとっては負担が大きい仕組みだ。
無論そもそもそんなことを意識していない人にとってはどうでも良いことだろうけど。
スクリーン・リーダーで閲覧している場合、代替テキストがある画像であっても、もしかすると製作者の意図していない内容であるかもしれないということを意識しながら読むのが安全ということになりそうだ。
Note特有の機能
Noteには、特有の機能がいくつかある。 閲覧者の視点では、クリエイターのサポートや有料記事の購入あたりを使いたくなることが時にはあるだろう。
こういった機能を使おうとすると、いわゆるモーダル・ダイアログが表示されることがしばしばある。 （経験的にモーダル・ダイアログだと僕は認識しているけど、実は違うかもしれない。）
今見ているページを覆い隠すようにして表示される（らしい）モーダル・ダイアログは、視覚的には目だつし、そのダイアログの中で可能な操作しかできない状態になる（ことになっているらしい）ので、画面が見えている人にとっては分かりやすいインターフェースなのだと思う。 しかし、これは適切に実装しないとスクリーン・リーダー・ユーザーには非常に分かりづらいものになってしまう。
最近は増えてきた印象はあるが、適切に実装されているモーダル・ダイアログはすごく少ない。
Noteのモーダル・ダイアログの実装も、スクリーン・リーダーのユーザーの視点から見ると、適切なものではない。
少々技術的な話になるが、モーダル・ダイアログが表示されると、その実体はDOMツリーの末尾に挿入される。
この手法自体は本当によく見かけるものだ。
なので、慣れている人だと何か表示されるはずの操作をしてもなにも見当たらないときは、とりあえずページの最後を確認してみることが多いと思う。（実際僕もそうした。）
しかし、すべてのスクリーン・リーダー・ユーザーがそのように操作することを期待するのは無茶というものだろう。
モーダル・ダイアログを含む要素以外の要素をスクリーン・リーダーから隠蔽する（aria-hidden="true"を指定する）というのが理想的な実装だが、これは最初から意識して作っていない限り、ちょっと実装するのが大変だと思う。
それができなくても、最低限適切にフォーカスを制御して、モーダル・ダイアログにフォーカスが移るようにしてあれば良いのだが、そういうことはされていない。
少なくないスクリーン・リーダー・ユーザーが、モーダル・ダイアログを見つけられずにあきらめてしまうということが考えられる。
これも文章だけでは分かりづらいと思うので、簡単なデモの様子を以下に張り付けておく。
結論
まとめると
- スクリーン・リーダーで長文を読むのには向いていない
- スクリーン・リーダーのユーザーは、掲載されている情報が不完全である可能性を意識して読む必要がある
- Note特有の機能を使えないスクリーン・リーダー・ユーザーが少なからず存在しそう
- アクセシビリティー関連の情報を発信する媒体としては不適切
ではなぜおまえはNoteにアクセシビリティー関連の記事を掲載しているのか、と思う方もいらっしゃるだろう。
僕はこういった現状を踏まえて、あくまでもメインは自分のブログで、Noteはその転載先という位置づけで当面使ってみることにした。
不完全であっても、火取りでも多くの人に届くかもしれない手段は活用した方が良いだろうという判断だ。
※この記事はNoteにも掲載しています。