カテゴリー: Web

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

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解説を参照してください。
　

参考

　

さいごに

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

関連エントリ

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

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

「Web情報を保存するとは何か」の続き-Web情報の保存についての個人的で簡潔な妄想-

kzakza

　以前、以下のようなエントリを書きました。

　要点をまとめると
　Webにおけるユーザーの行動の結果として、Webを構成するリソース、またはその断片的な一部は、ユーザーにより断片化され、大量に複製される形で残っていくのではないか。
ということでした。言い換えると、画像の転載やテキストの一部のコピペなどより（しかも、それが転載と複製を繰り返されることで）、一部とはいえ、Web上にあった情報は残っていくものもあるんじゃないかということでした（複製にまさる保存手段なしということで）。オリジナルが失われても、転載されたものが一部残っていたおかげで辛うじて当時のオリジナルの情報を部分的にでも再現できるなんてあたりは、紙の史資料と同じですね。
　そして、結果としてそういう形でしか残らなかった情報を将来の人間は活用するしかない場面が出てくるのはないか。ならば、自然に情報が残っていくにまかせるのではなく、少しでもよい方向にもっていくことはできないだろうかと、一応業界人なので考えたりします。
　　
　いろいろとあるのでしょうね。少しでも残りやすくするとか、なるべく理想に近い残り方をするようにするとか。
　　
　Internet Archiveなどが取り組んでいるようなウェブアーカイビングプロジェクト（参照:Wikipedia）で保存されているような理想的な形ではないとしても、結果として断片的な形で情報が残ることも折り込んで、どうすれば少しでも真正性を担保できるのか、将来の歴史家の負担を軽減できるのかということは図書館がいつか考えなければならないのでないかという気がしてきました。
　具体的に何をすればよいのでしょう。
　すぐに思いつくのが、将来にわたって真正性を担保できるようなメタ情報を少しでもリソースに残すことに貢献することでしょうか。
　リソースにメタデータが新規に付与され、それにメタ情報が追加・修正されるタイミングはざっと以下の２つあるかと思いますが、

  1. リソースが作成されたタイミングで埋め込まれるメタデータ（例としは、Exifなど）
  2. リソースが転載されたタイミングで新たなメタデータが埋め込まれる。

　１は例にもあげたようなExifなど、すでに結構あるかと思います。必要ならその仕様の改訂に意見して必要なメタ情報が残るようにする、ないフォーマットにはメタｰデータが付与されるように意見を出すとか。
　2はどれくらいあるのでしょうか。そもそもどうすればできるのかも分かりませんが、OSに依存することが結構多そうですね。しかし、どのような経路をたどって、そのリソースがその時代に残ったのかという情報が記録される仕組みが1ファイルレベルで欲しいところです。コピペされたテキストは1ファイルどころではないですが、今の時代に残ったテキストがどういう経路でコピペされ、どのように改変されていったかその差分情報がWikiのように残れば理想的です。そういう仕組みってどうすればできるんでしょうか。
　ところで、今回、真正性、真正性という言葉を多用してしまいましたが、この使い方でよいのかしら・・