投稿者: kzakza

リンク先を別ウィンドウ（タブ）で表示させることはアクセシビリティ上どうなのか。

kzakza

　ということが、ちょっと前に私の周りで議論になりました。
　なんとなくよくなさそうな気がしますが、実際のところどうなの？というあたり、それを説明できる文書や説明を当時はうまく見つけることができませんでした。しかし、改めて時間をおいて調べてみると、（意外とあっさりと・・）いろいろと出てきましたので今回は、
リンクを別ウィンドウ（タブ）で開くことをユーザーに強いることはアクセシビリティ上どうなのか。
について考えてみたいと思います。いつものようにW3CのWCAG2.0関連文書を参照しました。

結論からを申せば

　
　ユーザーが想定していない形でリンク先を別ウィンドウ（タブ）で表示させることは、基本的にアクセシビリティ上望ましくはないようです。リンク先をどのように表示させるかはユーザーの選択に委ねるべきということです。

リンクを別ウィンドウ（タブ）で開くことについて、デメリットを考えたことはあるでしょうか？別ウィンドウで開く一番のリスクは、キーボードで「前のページに戻る」動作ができなくなることです。他にもパソコン初心者の方も、別ウィンドウで開いたということが認識しにくいようです。
from 「Webアクセシビリティは、誰がどう必要としているのか？ | Webクリエイターボックス」

参考

　

しかし、絶対ダメというわけではない

・・・ようです。target=”_blank”を用いる場合と、JavaScriptを用いる場合について、W3Cが以下のようなドキュメントを公開しています。

target=”_blank”を用いて別ウィンドウ（タブ）を開く

　「target=”_blank”」はマシーンリーダブルですので、読み上げソフトなどの支援機器がそれを理解することが可能です。つまり、支援機器は別ウィンドウ（タブ）が立ち上がることをあらかじめユーザーに知らせることができますので、それを望まないユーザーは、別ウィンドウ（タブ）を開かない設定に事前に変更することが可能です。
　なお、支援技術を利用していないユーザーのことも考えて、リンクテキストからも別ウィンドウ（タブ）が開くという情報が得られるようにしておく必要があります。
　というわけで、 target=”_blank”を用いて別ウィンドウ（タブ）を開くならば、以下のようにリンクをはるべきです。

<a href=”contactme.html” target=”_blank”>お問い合わせ (新しいウィンドウが開きます)</a>

参考

　

JavaScriptを用いて別ウィンドウ（タブ）を開く

　JavaScriptを用いて別ウィンドウ（タブ）を開く手法はダメのか、といいますとそうでもないようでして、ユーザーに事前に別ウィンドウ（タブ）が開くという情報を伝えておくようにしておけばよいようです。

参考

　

WCAG2.0（JIS X8341-3:2010）上では？

　W3CのウェブアクセシビリティガイドラインであるWCAG2.0では、以下の「3.2.5 利用者の要求による状況の変化」がリンクを別ウィンドウ（タブ）に係る要件になります（JIS X8341-3:2010では、7.3.2.5）。

3.2.5 利用者の要求による状況の変化（JIS X8341-3:2010では、7.3.2.5）

状況の変化は利用者の要求によってだけ生じるか、又は、そのような変化を止めるメカニズムが利用可能である。　 (レベルAAA)

　リンクを別ウィンドウ（タブ）が開くなどの予期しない状況の変化によって混乱が引き起こされる可能性を取り除き、状況の変化をユーザーが完全に制御できることを求めています。この要件は達成基準がAAAですので、ウェブサイト全体に対してこの要件を満たすことはなかなか難易度は高いとみなされてるようですが、別ウィンドウ（タブ）だけに限れば、個人的にはさほど高い難易度でもないように思えます。
　この要件の詳細は以下のWCAG 2.0解説を参照してください。
　

参考

　

さいごに

　ここまで書いたように、リンク先を別ウィンドウ（タブ）で開いて表示させることは、事前にユーザーにその情報が伝わる限りにおいてアクセシビリティを担保できるようです。
　
　しかし、あくまでユーザーに混乱を与えない必要最低限のアクセシビリティを担保するものであり、事前であれ、事後であれ、ユーザーに別ウィンドウ(タブ)の対応を強いることには変わりありません。リンク先をどのように表示させるかはユーザーの選択に委ねるべきであり、どうしても別ウィンドウ（タブ）でなければならない場合を除き、リンク先を別ウィンドウ（タブ）で開いて表示させる手法はなるべく用いないほうがよいと思われます。別ウィンドウ（タブ）で開いて表示させる場合でも、ユーザー側から一を見て十が知れるような、つまり、ここが別ウィンドウ（タブ）で立ち上がるならここもそうかなと推測が容易にできるような、はっきりとした使われ方が望ましいと思います。
　

関連エントリ

ウェブアクセシビリティガイドラインについて
代替テキスト
リンクのはり方

「触覚フィードバック機能付きタッチスクリーン」のiPhoneってまだですか・・・

kzakza

　以下のニュースを見て以来、期待してます。ずっと待っています。触覚フィードバック機能付きタッチスクリーンのiPhoneやiPadってまだ出ないのでしょうか。

　上のニュースによると、2009年当時は振動を返すだけのものだったようですが、2012年のニュースによると、スクリーンが立体的に浮かび上がりボタンや地図などを表現できる技術に進化している（らしい）。これはすごい！

　　　2010年のゲーム機関係のニュースになりますが、ソニーとマイクロソフトも似たような技術の特許を出願しているようです。

　例えば、iOS機にはVoice Overのような支援機能が搭載されているとはいえ、タッチスクリーンは平面的で視覚障害者の方にとって使いやすいものではありません。とはいえ、タッチスクリーンは必要な時に必要なボタンだけ表示できるUIが可能ですので、触覚がより活用できるタッチスクリーンが登場すれば、必要な時に必要な物理的ボタンだけを備えたUIを実現できる。結構理想的かもしれません。アクセシビリティが大きく向上すると思われます。タッチスクリーンの次は触覚の時代です。
　電子書籍の普及で「書籍」がよりアクセシブルになることが期待されたわけですが、ほとんどの端末がタッチスクリーンだけのものになってしまい、ボタンがあったとしてもほとんど脇に追いやられてしまっています。非常に残念ですが、触覚技術の進化とその普及がその状況が逆転されるかもしれません。
　将来的に点字を浮かび上がらせるところまでできれば本当に理想的です。

Internet Archiveのブリュースター・ケール氏が問うSiteless Websiteの可能性

kzakza

　Web情報を収集し、保存して後世に残すことを目的としたウェブアーカイブ（参照:Wikipedia）というプロジェクトがあります。日本では国立国会図書館（プロジェクト名:WARP）が進めていますが、もっとも歴史が古く、有名なのは米国のInternet Archiveでしょう。1996年から開始してすでに2600億件のURLを集めたそうです※1。
　そのInternet Archiveを設立したブリュースター・ケール氏(参照:Wikipdia)が2012年10月にInternet Archiveのブログで「Siteless Websiteは可能か」というエントリを投稿しています。

　私自身、クライアントサイドでウェブアーカイブはできないのいかと考えることもあり、ケール氏のこの話は個人的に非常に興味の深いところです。本エントリでは「ブリュースター・ケール氏が問うSiteless Websiteの可能性」と題しまして、サーバーレスウェブサイトの話を紹介します。また、それによってウェブがアーカイブされるかもしれない話も少々触れることになります。
　

1.ケール氏がP2Pのファイル配布について意見募集（人材も？）

　まずはケール氏があのエントリでSiteless Websiteについて触れる前段の話から。ケール氏は2012年2月に以下のエントリをInternet Archiveのブログに投稿しました。
　

内容は・・

Internet Archiveには毎日200万人のユーザーがアクセスして大変（しかも、エジプト人と日本人のユーザーが多い）。しかも、同じファイルを何度も何度もInternet Archiveのサーバーからダウンロードするんだぜ。コストもかかるし、帯域くってしょうがない。
　　　↓
最初のユーザーがファイルをInternet Archiveのサーバーからダウンロードしたら、次のユーザーはInternet Archiveのサーバーではなく、最初のユーザーがダウンロードしたファイルをP2Pで融通してくれれすればいいじゃない。意見くれ！

というものでした（超意訳）。
　コメントにはP2Pに関するいろいろなコメントが寄せられています（これ理解できたら楽しそう・・・）。個人的にはコメントで言及されているコンテンツ主体のネットワークというContent-centric_networking（Named data networking 参照:Wikipedia）が気になります。　
　

2.Internet ArchiveのBitTorrentを活用したコンテンツ配布の開始

　そして、あのエントリが投稿されて半年後の2012年8月、Internet Archiveは、BitTorrent（参照: Wikipedia）によるP2Pのデータの配布を開始しました（早い・・・）。配布対象のコンテンツは音声ファイル、映像ファイル、電子書籍ファイルです。つまり、ファイル１つで成り立つコンテンツが対象で、複数のファイルが組み合わされて構成されるアーカイブドウェブサイトは対象外のようです。

　コンテンツをP2Pで配信するBitTorrentの仕組みは、BitTorrentの公開する以下の動画が比較的概要をイメージしやすいと思います。　
　
　

　
　厳密にいえば、上のBitTorrentの映像の説明と少し異なるところもありますが、図でまとめると以下のような感じでしょうか。クライアント同士でコンテンツをP2Pで融通しあうわけです。
ある1台の端末がサーバーからダウンロードしたコンテンツAを複数のクライアント同士でP2Pで共有している
図1 Internet ArchiveのBitTorrentを活用したP2Pによるコンテンツの配布のイメージ
　ここまでは、Internet Archiveにくる大量のアクセスをP2Pを使って分散させるというお話でしたが、ケール氏はTorrentFreakのインタビューに答える形で、次は「分散型コンテンツ保存システム(distributed preservation system for content)」を構築したいと述べています。それがSiteless Websiteの話につながります（たぶん）。
　

3.ケール氏、Siteless Websiteの可能性を問う

　ケール氏は2012年10月に以下のエントリ（冒頭にあげたものの再掲）を投稿し、次はSiteless Websiteの可能性を問いかけています。

　Bittorrentがサーバーなしで分散型ファイルサーバーを実現しているように、特定の１つの置き場所を持たないウェブサイトはありえないのか。Siteless Website、おそらくクライアントだけで実現されるサーバーレスウェブサイトと置き換えてもよいのでしょうか。
　ケール氏はSiteless Websiteを以下のように定義しています。

  • Siteless Websiteのホームコンピュータは１つだけではない。
  • Siteless Websiteは時間の経過とともに多くの人間によってサポートされるようになる。

　
　あのエントリでは、詳しくは語られていませんが、先の「分散型コンテンツ保存システム(distributed preservation system for content)」と組み合せて考えるとSiteless Websiteについて、いろいろと想像（妄想）できるところもあります。
　

4.Siteless Websiteとは

　ケール氏の言うSiteless Websiteを少し私の想像で肉付けしてみたいと思います。あくまで私の想像ですので、ご注意ください。
　現在のWebはクライアントサーバモデル（参照: Wikipedia）を基本としてます。コンテンツを配布するサーバーと受け取るクライアントの役割が明確に分かれています。クライアント同士が通信したり、コンテンツをやり取りする場合もその間にサーバーを介することになります（以下の図のB）。
クライアントサーバモデルのイメージ図。1台のサーバーに複数のクライントがリクエストをだして同じリソースを取得している図。
図2 クライアントサーバモデルのイメージ
　同じリソースに対して異なるクライアントからリクエストされてもそれぞれに同じように返すので、その分重複して帯域を食います。これでは負荷がかかる。ということで、Internet Archiveが2012年8月に始めたのが先の項で紹介したBitTorrentを活用したP2Pによるコンテンツの配布でした。
　そして、ケール氏の目指す、「分散型コンテンツ保存システム(distributed preservation system for content)」を実現する”Siteless Website”です。ケール氏の挙げる条件をまとめると以下のようなイメージにあるのではないかと思います。
　

図3 Siteless Websiteのイメージ図 その１（あくまで私の想像です）
　サーバー・クライアント型のウェブサイトが完全に排除されることもないだろうと一応サーバーを残してありますが、Seedたるクライアントからもコンテンツの提供がスタートしています。その後は各端末でどんどん複製され、いわば、各クライアントがホストとなり、クライアント同士でコンテンツをやり取りしていくようになります。
　コンテンツのやりとりの結果として、図4のように各クライアントにコンテンツの複製物がおかれるようになります。
Siteless Websiteのイメージ図その１。次のパラグラフで解説
図4 Siteless Websiteのイメージ図 その2　コンテンツの複製物がクライアント側に蓄積されるイメージ（あくまで私の想像です）
　以上、私が想像しうるSiteless Websiteでした。クライアントサーバーモデルとP2Pが融合するようなWebといえるのでしょうか。利点として以下が挙げられます。

  • クライアント側にコンテンツのアーカイブの役割を担わせることで、ほぼ無限ともいえる大容量のストレージを確保することができる。
  • ウェブサイトのホストであるサーバーやSeedたるクライアントが落ちたとしても、またはコンテンツが削除されたとしても、クライアント側に大量にある複製されたコンテンツによってアクセスを担保することができる。
  • アクセスされればされるほど、クライアント側に大量の複製が作成され、アクセスも分散されていくので、クライアントサーバモデルのように特定のサーバーにアクセスが過度に集中する事態をさけることもできる。

　しかし、P2Pのセキュリティ上の問題や著作権の問題を置いておくとしても課題は多そうです。たとえば、以下の3点が気になります。

  1. ウェブサイトのホストが唯一ではない場合のURIのあり方
  2. 真正性の担保
  3. サーバーやSeedにおかれているウェブサイトが更新したら、クライアントに大量に複製された過去の情報はどうするのか。

　1のURIの問題。クライアントサーバーモデルでは、Webのホストは１つであるため、場所を示すURLが識別子として機能しています。しかし、全く同じコンテンツが複数のコンピュータに大量にあるシステムの場合、URLのような場所を一意に指し示す識別子では、同じコンテンツに対して複数の識別子が振られることになります。コンテンツ主体で考えると。コンテンツ主体の識別子、つまり、どこにあるかは問題にせずに「コンテンツa」と指定できる識別子が必要になるような気がします。　
　2の真正性の担保の問題。間に複数のクライアントが入る可能性がある以上、中継した悪意のある第三者による改変のリスクも無視できません。手元に届いたコンテンツが改変されていないことが分かる仕組み、改変をされたら、されたことが分かる仕組みが必要でしょう。先のエントリ（「「Web情報を保存するとは何か」の続き-」）で述べたような、リソースが転載されたタイミングで付与されるメタデータが重要になってくるのだと思います。
　問題は３の更新の問題ですね。DNSの設定変更のようにWeb中に更新情報を行き渡らせる必要があるのでしょうか。うーん、よくわかりません。しかし、せっかくアーカイブされたウェブサイトですから、そのまま新しいバージョンに上書き更新されるのではなく、（特に公開者が拒まなければ）古いバージョンも保存される仕組みが取り入れられると、Web情報の保存の観点から理想的です。
　課題は多いとは思いますが、W3Cに”Unhosted Web Community Group“というCommunity Group（参照: Web標準Blog）も立ち上げられており、ケール氏以外にもSiteless WebsiteのようなWebを考えている人は結構いるようです。10年、15年後のWebは、今我々が知っているWebと全く異なるものになっているのかもしれません。
　
※1 https://twitter.com/internetarchive/status/298925082103930881