月: 2013年2月

アクセシビリティに配慮したリンクのはり方とは（その1）–リンクテキストとリンクの配置–

kzakza

　ウェブページを作成していると、リンクをはるという行為から逃れることはできませんが、それだけにアクセシビリティに配慮したリンクのはり方について迷う場面によく遭遇します。そこで、何回かに分けてアクセシビリティに配慮したリンクのはり方について考えてみたいと思います。

WCAG2.0（JIS X8341-3:2010）での要件

　　W3CのウェブアクセシビリティガイドラインであるWCAG2.0では、以下の2.4.4、2.4.9がリンクのはり方に係る主たる要件になります。

2.4.4 文脈におけるリンクの目的: （JIS X8341-3:2010では7.2.4.4）

それぞれのリンクの目的が、リンクのテキストだけから、又はプログラムが解釈可能なリンクの文脈をリンクのテキストとあわせたものから解釈できる。ただし、リンクの目的が一般的にみて利用者にとって曖昧な場合は除く。 (レベルA)

参考: 達成基準 2.4.4 を理解する | WCAG 2.0解説書

2.4.9 リンクの目的: （JIS X8341-3:2010では7.2.4.9）

それぞれのリンクの目的がリンクのテキストだけから特定できるメカニズムが利用可能である。ただし、リンクの目的が一般的にみて利用者にとって曖昧な場合は除く。 (レベルAAA)

参考: 達成基準 2.4.9 を理解する | WCAG 2.0解説書　
　　スクリーンリーダーなどの支援技術は、そのウェブページにあるリンクの一覧したり、フォーカスを移動してリンクテキストだけを読み上げる機能をもっていますので、前後の文脈に依存せずにリンクテキストだけでリンクの目的が判断できるようにすることが求められています。
　2.4.9の要件では、全てのリンクを前後の文脈に関係なくリンクテキストだけでユーザーがリンクの目的を完全に理解できるようにすることが求められています。全てのリンクをリンクテキストだけで理解できるようにすると、逆に分かりづらいものになってしまう場合もあり、なかなか難易度が高い要件であるため、達成基準AAAになっています。
　2.4.4 の要件では、リンクテキストに加えて、プログラムが解釈可能なリンクの文脈を組み合わせてリンクの目的を判断させることを認めています。この2.4.4 の要件は最低限満たすべき要件（達成等級A　⇒参考 WCAG 2.0への適合を理解する）です。

リンクテキスト

　リンクテキストとは、アンカーテキストとも呼ばれますが、a要素でタグ付けされるテキストを指しています。

<a　href=”ample.html”‘>リンクテキスト</a’>’
リンクテキスト

　リンクテキストはリンクの目的を説明し、同じページにある他のリンクと区別でき、リンク先に遷移するべきかどうかを判断できるものでなくてはなりません。
　以下のように「PDF版」に対してだけ、リンクをはってしまうと、スクリーンリーダーなどでリンクテキストだけを読み上げる、もしくはリンクテキストを一覧した場合にリンクの目的が判断できません。


<ul>
<li>平成24年版障害者白書　<a href="h24hakusyo.pdf">PDF版</a></li>
<li>平成23年版障害者白書　<a href="h23hakusyo.pdf">PDF版</a></li>
</ul>

　　
　PDF版を説明するテキストをあわせてリンクテキストとして提供することで、リンクの目的をユーザーに説明することができます。


<ul>
<li><a href="h24hakusyo.pdf">平成24年版障害者白書　PDF版</a></li>
<li><a href="h23hakusyo.pdf">平成23年版障害者白書　PDF版</a></li>
</ul>

　
　上で例にあげた『障害者白書』がPDF版だけではなく、EPUB版を提供していた場合、以下のようにリンクをはりたいところです。しかし、この場合、リンクテキストだけではリンクの目的を説明することができません。


<ul>
<li>平成24年版障害者白書　<a href="h24hakusyo.pdf">PDF版</a> <a href="h24hakusyo.epub">EPUB版</a></li>
<li>平成23年版障害者白書　<a href="h23hakusyo.pdf">PDF版</a> <a href="h23hakusyo.epub">EPUB版</a></li>
</ul>

　　　
　リンクテキストだけでリンクの目的を説明しようとすると、PDF版とEPUB版のリンクそれぞれに書名のテキストを加えてやる必要があります。


<ul>
<li><a href="h24hakusyo.pdf">平成24年版障害者白書 PDF版</a> <a href="h24hakusyo.epub">平成24年版障害者白書 EPUB版</a></li>
<li><a href="h23hakusyo.pdf">平成23年版障害者白書  PDF版</a> <a href="h23hakusyo.epub">平成23年版障害者白書 EPUB版</a></li>
</ul>

　WCAG2.0の2.4.9「リンクの目的」（達成基準AAAの要件）はそれを求めていますが、フォーマットごとに同じ書名が読み上げられることは、スクリーンリーダーのユーザーにとって使いやすいものとは限りません。2.4.4「文脈におけるリンクの目的」（達成基準Aの要件）では、リンクテキストに加えて、リンクのおかれている文脈からリンクの目的を特定させてもよいとしています。

参考

リンクの文脈

　可能な限り、リンクテキストだけでリンクの目的を伝えることが理想的ですが、それが難しい場合でもリンクを含む文章からリンクの目的がユーザーに伝わるようにしなければなりません
　リンクの文脈はどのようにあるべきかは、WCAG 2.0解説書の以下の文章が簡潔にしてわかりやすいと思われますので、そのまま転載します。

　ある状況においては、コンテンツ制作者は、リンクの説明の一部を、そのリンクの文脈を提供する論理的に関係のあるテキストで提供したいことがある。この場合、利用者がリンクからフォーカスを移動させずに、そのリンクの目的を確認できなければならない。言い換えれば、利用者があるリンクにやってきて、その位置にいたままで、リンクに関するより多くの情報を探し出すことができる必要がある。これは、同じ文、段落、リスト項目、そのリンクの直前にある見出し、リンクであるテーブルのセル、又はデータテーブル内にあるリンクの見出しセルに、リンクの説明を置くことで可能である。なぜなら、それらはリンク自体と直接関連付けられているからである。
　こういった文脈は、リンクの前にあると、最も使いやすいだろう（例えば、曖昧なリンクテキストを使わなければならない場合、その曖昧な語句をリンクの行き先を説明する文章の初めに置くよりも、リンクの行き先を説明する文章の最後に置いたほうが分かりやすい）。リンクの後に説明がきてしまうと、ウェブページを（先頭から最後まで）順に読んでいるスクリーンリーダーの利用者が、困惑したり、理解しづらかったりする可能性がある。
from 達成基準 2.4.4 を理解する | WCAG 2.0解説書

　
　　つまり、2.4.4「文脈におけるリンクの目的」であれば、以下のように提供してもよいということになります。


<ul>
<li>平成24年版障害者白書　<a href="h24hakusyo.pdf">PDF版</a> <a href="h24hakusyo.epub">EPUB版</a></li>
<li>平成23年版障害者白書　<a href="h23hakusyo.pdf">PDF版</a> <a href="h23hakusyo.epub">EPUB版</a></li>
</ul>

　同じ文、段落、リスト、見出しなど様々なものをリンクの説明に活用することができますが、順に読み上げているユーザーのことを考慮し、リンクに到達する前に必要な情報をユーザーが取得できているようにリンクの前にリンクの説明をおくことが望ましいです。
　ここまで人間が理解できるリンクの文脈の話でしたが、WCAG2.0では、さらにリンクの文脈をプログラムが解釈可能であることも求めています。
　

参考

プログラムが解釈可能なリンクの文脈

　「プログラムが解釈可能」と言っても、人間のようにリンクの文脈を意味としてプログラムが解釈できることを求めているわけではありません（無理・・・）。ここで求められているのは、リンクの目的を説明する文脈をプログラムからでも特定できるようにすることです。
　以下のように「続きを読む」のリンク部分のパラグラフが前のパラブラフから独立していると、「続きを読む」のリンクがどこの文章と関係しているのかが特定できず、ユーザーに混乱を与えてしまいます。

間もなくあなたの近くの町に行きます……。
全米民族音楽祭にラインナップしている最終15組です。

<a href="final15.html">続きを読む</a>

　
　以下のように一つのパラグラフにまとめることで、「続きを読む」のリンクがどこのテキストをと関係しているのかをプログラムでも理解できるようにしておく必要があります。

間もなくあなたの近くの町に行きます……。
全米民族音楽祭にラインナップしている最終15組です。
<a href="final15.html">続きを読む</a>

　
　つまり、コンテンツをタグ付けしてきちんと構造化しましょうという話になります。スクリーンリーダーなどはセンテンス、パラグラフ、見出しなどの単位でフォーカスを移動させる機能を備えているため、きちんと構造化することで必要な説明にすばやく到達させることが可能になります。
　例えば、リンクをul要素とli要素でグループ化することで、これらのリンクが１つのグループであることと、リンク同士が並列関係にあることをプログラムに理解させ、ユーザーに伝えることができます。

<a name="categories" id="categories"></a>

<h2>商品カテゴリー</h2>

<ul class="navigation">
    <li><a href="kitchen.html">キッチン</a></p></li>
    <li><p><a href="bedbath.html">ベッドとバス</a></p></li>
    <li><p><a href="dining.html">ダイニング</a></p></li>
    <li><p><a href="lighting.html">照明</a></p></li>
    <li><p><a href="storage.html">収納</a><li><p>
</ul>

<p>

　
　
　パラグラフ、テーブル、リストのケースは以下のWCAG 2.0 実装方法集で詳しく紹介されています。

参考

代替手段を用意する（2.4.9の要件）

　2.4.9「リンクの目的」（達成基準AAAの要件）では、リンクテキストだけでリンクの目的が特定できることを求めています。しかし、部分的にならともなく、ウェブサイト全体に対してこの要件を満たそうとすると、リンクテキストが冗長になるため、サイトの使い勝手が悪くなるとユーザーに感じさせる箇所も出てくるはずです。
　
　そこで、2.4.9の要件を満たした別バージョンのコンテンツを提供する、もしくは説明の表示・非表示を切り替えできる機能を提供するなどの手法を以下の文書で案内しています。

参考

　

関連エントリ

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

視覚情報を触覚情報に変換する視覚障害者用の支援機器、オーデコ（AuxDeco）

kzakza

　これは面白いなぁと思った視覚障害者のための歩行補助具オーデコ（AuxDeco）を紹介します。東京大学とアイプラスプラスが共同開発したもので、カメラで眼前の視覚情報を電子情報として取得し、その輪郭を電子刺激（触覚情報）に変換して額に伝える機器です。
オーデコ（AuxDeco）
http://www.eyeplus2.com/
　まずは以下の（おそらく）公式の紹介動画をご覧ください。

　
　視覚情報を触覚情報に変換する流れは以下の通りです。

①小型カメラで、前方を撮影する
内蔵された小型カメラで、前方を撮影します。前方とはカメラの向いている方向、つまり使用者の顔の向きです。使用者は「見たい」方向に顔を向けることで、撮影する方向を定めます。
②撮影した映像を電気刺激に変換する
撮影した映像は小型コンピューター（以下「本体」）に送られます。本体ではまず、送られてきた映像の輪郭線を抽出します。そして、抽出した輪郭線を電気刺激に変換します。
③額（おでこ）で刺激を感じとる
電気刺激に変換された輪郭線は、使用者の額部分に装着された512個の電極から出力します。使用者は、出力される輪郭線刺激を額の触覚で感じとります。
④白杖の先の前方をイメージする
使用者は、額で感じとった刺激の位置・動き・形から、前方の空間をイメージします。白杖を使って歩きながら、白杖の届かない範囲の情報を額から得られると、より安心して、そして楽しく歩行できるようになります
「仕組み」より

　
　カメラで取得された情報は以下のような形で512の電磁版により触覚情報に変換されるそうです。　　

オーデコの視覚情報を触覚情報に変換される画像(「トレーニング」より）
　白い杖では、杖の届く範囲の周辺情報しかを取得することができませんが、この支援機器なら杖の届かない遠方の障害物の存在を把握することができます。
　オーデコのような歩行補助具以外にも、視覚情報を触覚情報に変換する機器はいろいろな用途でありえそうです。この分野、もっと拡がるといいですね。

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

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

参考

　

さいごに

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

関連エントリ

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