2月 27

Personal Web Archivingでソーシャルメディアのウェブアーカイブを試みるMat Kelly氏

 Mat Kelly氏。通常のウェブアーカイブの方法ではなかなか技術的にアーカイブの難しいSNSなどをPersonal Web Archivingで収集できるようにしてしまおうとしている人みたいです。WARCファイルを作成するChormeプラグインのWARCreateやウェブアーカイブ版XAMMPともいうべきWeb Archiving Integration Layer (WAIL) を公開しています。

Mat Kellyのウェブサイト
http://matkelly.com/

Mat Kelly氏の意図するところは以下の図がわかりやすいです。
次のパラグラフデ解説あり。
from WARCreate and Future Stewardship: An interview with Mat Kelly | The Signal: Digital Preservation
 
 これはWARCreateについての解説ですが、基本的には方向性はこの図にあるのだろうと思われます。Heritrxのようなクローラーでは収集することができないが、WARCで保存することは技術的に可能なfacebook等のウェブサイト、これをPersonal Web Archivingという手法で保存できるようにしたいのかなと。そして、 Mementoとでつなぐと。スライドや資料を全部みたわけではないので憶測もまじりますが、そのように思えます。なかなかおもろいことをするなぁ。

 自分用にとりあえずまとめてみましたが、Mat Kelly氏のスライドもSlideshareでいくつか公開されています。ここで Mementoとかぁと軽く個人的には驚きました。


Making Enterprise-Level Archive Tools Accessible for Personal Web Archiving from matkelly01


An Extensible Framework for Creating Personal Web Archives of Content Behind Authentication from matkelly01
 


The Revolution Will Not Be Archived from matkelly01
 


WARCreate – Create Wayback-Consumable WARC Files from Any Webpage from matkelly01

 


NDIIPP/NDSA 2011 – YouTube Link Restoration from matkelly01
 


NDIIPP/NDSA 2011 – Archive Facebook from matkelly01

2月 26

『アクセシビリティハンドブック』(O'Reilly Japan)

 以下の本を一読したので、感想などをメモ程度に。


『アクセシビリティハンドブック』(O’Reilly Japan)

 ウェブアクセシビリティについていろいろと調べていくと、これはこうだからダメ、あれはああなのでそうしたほうがいいということがある程度わかってきますが、調べれば調べるほど表層的な部分に触れる程度の理解でしかないことを痛感します。

 それでこの書籍です。目次をみて、障害者がどのような困難に遭遇しているかを障害別に詳しく書いてあるのかと期待してすぐに読んでみました。しかし、内容は障害別にウェブアクセシビリティを配慮したコンテンツの作成の方法をまとめたもので、そう言う意味では少し期待を裏切られました。

 とはいえです。他の本のようにJavaScript、フォーム、テーブルといった開発者視点の分類でのウェブアクセシビリティ解説より、なぜ対応しなければならないかという理由とその対応方法がセットになっているこの本のほうが初めてウェブアクセシビリティについて触れる人には理解しやすいかもしれません。ページ数も10.5インチのiPadで読めば、だいたい100頁強ですので、数時間で通読できるものだと思います。巻末に障害別にツール類を紹介したまとめが掲載している点もポイントが高い。

 なお、ですが、この本を手にとったそもそもの動機を満足させるためには、個々に書籍にあたっていくしかないようです(し、実際にいろいろと読んでもいる)。しかし、障害者の抱える困難については、国立国会図書館が公開する以下の研修資料がよくまとまっています。

2月 21

アクセシブルに「強調」-strong要素、em要素、b要素、mark要素 –

 なんとなく強調するために使われているっぽいstrong要素、em要素、b要素、mark要素の使い分けについて整理し、アクセシビリティ的にどうなのかというところを簡単にまとめてみました。なお、HTML5になってこれらの要素の定義が変更されたようですので、今回はHTML5の仕様に基づいてまとめます。

テキストに対する意味付けをする要素

 HTML5タグリファレンスを参照して整理しますと以下の通りになります。 

strong要素

 重要性を表します。

em要素

 強調を表します。重要性を伝える意味はありません。

b要素

 他のテキストと視覚的に区別させたいときに使用します。重要性や強調は意味しません。太字で表示されることが多いですが、太字で表示されるとは限りません。

mark要素(HTML5の新要素)

 特定の範囲をハイライトします。他の箇所である箇所を言及した場合にそのある箇所を目立たせる場合に使用されます。重要性や強調は意味しません

strong要素とem要素の違い

 strong要素が意味するところの重要性とem要素が意味するところの強調の違いが分かりづらいですね。以下のHTML5.JPで公開されているhtml5doctorの翻訳でその違いが詳しく紹介されていますが、アクセントを置くのはそこが重要だからではないかという気もしまして、個人的にはその使い分けが完全にはよくわかっていません。重要だからアクセントを置くならばstrong要素を、重要ではないがアクセントを置くならem要素をとなるのでしょうか。ケースバイケースで判断するところもあるのだと思います。

参考

支援技術でのサポート

 strong要素とem要素はテキストにそれぞれ重要性と強調の意味を持たせることができますので、支援技術が対応していれば、プログラムがその意味を理解し、ユーザーに伝えることができます。
 
 残念ながら現時点でこの両要素に対応するものはほとんど存在しないようですが、重要性や強調を表現する場合は、将来の支援技術の対応に備えるために、また、テキストにセマンティクスを与えるためにもstrong要素やem要素を使用するべきです。

参考

WCAG2.0(JIS X8341-3:2010)上では?

 W3CのウェブアクセシビリティガイドラインであるWCAG2.0では、「1.3.1 情報及び関係性」が今回のエントリに係る要件になります(JIS X8341-3:2010では、7.1.3.1)。

1.3.1 情報及び関係性

表現を通じて伝達されている情報、 構造、及び関係性は、プログラムが解釈可能である。プログラムが解釈可能にすることができないウェブコンテンツ技術を用いる場合は、それらがテキストで提供されている。 (レベルA)

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

 

関連エントリ

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

国際電子出版EXPO2011におけるBRC松井 進氏の講演「視覚障がい者とインターネット」の講演動画

  一昨年の国際電子出版EXPO2011で行われたバリアフリー資料リソースセンター松井 進氏の「視覚障がい者とインターネット」の動画が公開されていました。UStreamでまだアーカイブもされているのですが、こちらのほうが画質もよさそうなので、こちらを紹介。1/4〜4/4あわせて45分です。


視覚障がい者とインターネット【国際電子出版EXPO2011】
※上の埋め込み動画は1/4から4/4が連続再生されますので、個々に視聴したい場合は上のリンクにあるYoutubeからどうぞ。

バリアフリー資料リソースセンター(BRC)副理事長 松井 進氏
2011年7月9日(土) 11:30~12:20
国際電子出版EXPO2011 ボイジャー・セルシス合同ブース内 Voyager Speaking Sessions

発表資料も公開されています。
[PDF]発表資料

 「視覚障がい者とインターネット」とありますが、内容的には視覚障害者がどのように「読書」を行うのか、支援機器のデモを交えての紹介と視覚障害者にとってのアクセシブルな電子書籍とは何かというお話でした。プレクストークリンクポケットを使った音声のみによるサピエ図書館の利用デモを観ることができたのが、個人的に非常に良かったです。
 
 プレクストークがサピエ図書のウェブサイトを音声で読み上げて利用させているのかは分かりませんが、他のウェブサイトも同様のことが本当はできなくてはいけない。GUIで利用できるだけではなく。プレクストークのような機器で音声だけでも利用することができるアクセシブルなデザインが求められているのだろうと感じました。もしかすると、これがマルチモーダルというのでしょうか。

 松井氏は講演の中で、後付けのアクセシビリティではなく、アクセシビリティを最初から盛り込んだ電子書籍をとおっしゃっていましたが、これは電子書籍に限らずの話だと思います。ウェブデザインもアクセシビリティをあらかじめ盛り込んだ「アクセシビリティファースト」な考えが普及して欲しいと願うところです。

 

紹介されたソフトウェア、支援機器など
2月 20

アクセシビリティに配慮したリンクのはり方とは(その3)- 画像を用いたリンク –

 前々回前回のエントリに引き続き、アクセシビリティに配慮したリンクのはり方を取り上げます。
 
今回は、アクセシビリティに配慮した画像を用いたリンクのはり方です。

 画像といえば代替テキストですが、アクセシブルな代替テキストの提供方法はすでに以下のエントリで紹介したことがあります。

 上をベースにしつつ、今回は改めてリンクのはり方に焦点をあてたいと思います。

リンクテキストとしての代替テキスト

 たとえば、以下のように画像がリンクの唯一のコンテンツである場合は、画像の代替テキストがそのリンクテキストの役目を果たす事になります。

<a href="toppage.html"><img src="toppage.jpg" alt="トップページへ"></a>

 この場合はリンクの目的を伝えるテキストを画像の代替テキストとして提供します。

 以下のように画像そのものを説明するテキストを代替テキストとして提供すると、スクリーンリーダーなどの支援技術のユーザーにはこのリンクの目的が伝わりません。

#不適合事例
<a href="toppage.html"><img src="toppage.jpg" alt="トップページのスナップショット></a>

  

 以下のように検索ボタンとして虫眼鏡の画像を使用するケースです。

 

  検索ボタンとして使用されるので「検索」といれるほうが適切です。

<input type="image" src="image.png" alt =検索"/>

 

 検索ボタンとして使用される虫眼鏡画像の代替テキストに「虫眼鏡」といれてはなりません。

#不適合事例
<input type="image" src="image.png" alt =虫眼鏡"/>

 

参考

 
 

画像とリンクテキストの組み合わせ

 以下のように画像を用いてリンク先をビジュアル的にイメージしやすくする手法がよく使われています。

Yahoo! Japan
  Yahoo! Japan

  この場合、以下のように画像とテキストそれぞれに対してリンクをはり、かつ代替テキストとリンクテキストが同一だと、スクリーンリーダーでは全く同じテキストが重複して2度読まれることになります。

#不適合事例
<a href="http://www.yahoo.co.jp/"><img src="yahoo_cap.gif" alt="Yahoo! Japan" /></a>
<p><a href="http://www.yahoo.co.jp/">Yahoo! Japan</a></p>

 

 上のような場合は、リンクはテキスト及びアイコンを含み、alt属性を以下のように空にするか、

<a href="http://www.yahoo.co.jp/"><img src="yahoo_cap.gif" alt="" /></a>
<p><a href="http://www.yahoo.co.jp/">Yahoo! Japan</a></p>

 
 もしくはalt属性には画像を説明するテキストを代替テキストとして提供します。

<a href="http://www.yahoo.co.jp/"><img src="yahoo_cap.gif" alt="Yahoo! Japanのトップページのスナップショット" /></a>
<p><a href="http://www.yahoo.co.jp/">Yahoo! Japan</a></p>

  なお、alt属性を空にして提供する場合もalt属性を省略してはいけません。
 
 a要素でp要素をラップすることに違和感を感じる方もいるかもしれませんが、HTML5からa要素はp要素やdiv要素のようなブロック要素に対しても用いることができるようになりました。

参考

 

WCAG2.0(JIS X8341-3:2010)上では?

 W3CのウェブアクセシビリティガイドラインであるWCAG2.0では、「1.1.1 (非テキストコンテンツ)」、「2.4.4 (文脈におけるリンクの目的)」、「2.4.9 (リンクの目的)」が画像を用いたリンクに係る要件になります(JIS X8341-3:2010では、7.1.1.1、7.2.4.4、7.2.4.9)。

1.1.1 非テキストコンテンツ: (JIS X8341-3:2010では7.1.1.1)

利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たす代替テキストを提供する。ただし、次の場合は除く: (レベルA) “>1.1.1 非テキストコンテンツ: 利用者に提示されるすべての非テキストコンテンツには、同等の目的を果たす代替テキストを提供する。ただし、次の場合は除く: (レベルA)

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

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月 19

アクセシビリティに配慮したリンクのはり方とは(その2)- リンクのみせ方 –

 前回のエントリに引き続き、今回もアクセシビリティに配慮したリンクのはり方を取り上げます。

 今回は、特にリンクのみせ方についてです。ユーザーにリンクの存在を視覚的に伝えるにはどのようにリンクテキストを表現するべきなのかについて考えます。
 

全てのユーザーがリンクテキストであることを認識できるように

 視覚障害者というと全く目が見えない人を想像する人もいるかと思いますが、視覚障害者と呼ばれる人のうち、6割強がロービジョンと呼ばれる方だと言われています。ロービジョンと一言で言っても見え方は人によって様々で、Webの利用方法もその人の見え方に左右されますが、全てのユーザーがリンクテキストであることを認識できるように視覚的に表現することが求められます。これはリンクテキストの表示方法に限りませんが、今回はリンクテキストの表示方法に焦点をあててみたいと思います。

参考

下線は必要か

 ヘッダーやナビゲーション部分、メニュー部分などページのデザインや文脈から明らかにそこはリンクだとわかる部分もありますが、文中のテキストにはられたリンクを色の違いだけで表現すると、色覚異常の方は識別することができない場合があります。色の違いだけに頼らず、その他の表現方法で視覚的にリンクの存在がわかる手がかりを用意するべきです。

 何がなんでも下線でなくてはならないということではありませんが、リンクを表現する方法として下線は非常に一番なじみのある表現方法ですので、特に理由のない場合はリンクの表現には下線を用いるほうがよいのではないかと思います(逆に言えば、リンクがはられていないテキストに下線は用いるべきではありません)。

 なお、リンクをマウスオーバーした時などフォーカスがあてられた時だけ下線が表示されるウェブサイトもありますが、フォーカスをあてない限り、リンクの存在を色の違いだけで表現していることに変わりありません。参考にもあげているWCAG 2.0 実装方法集 G183では、リンクテキストとその周辺のテキストとのコントラスト比を 3:1 以上する方法を紹介していますが、同文書でも「この達成基準を満たすために十分であるが、リンクテキストを区別するには、好ましい実装方法ではない」としており、あまり望ましいものではありません。

参考

リンクテキストの適切な色は?

 
 リンクテキストの色とその他の周辺のテキストの色の違いを識別できるようにすることは当然ですが、それぞれの色が背景色との違いを識別できるようにする必要がありますので、以下のコントラスト比を考慮して色を選択する必要があります。

  1. リンクテキストの色背景色のコントラスト比
  2. リンクテキスト周辺のテキストの色背景色のコントラスト比
  3. リンクテキストの色その周辺のテキストの色のコントラスト比

 
 1と2は、WCAG2.0の以下の要件が参考になります(達成基準AA以上の準拠を目指すなら参照しなくてはならない)。

 日本語で太字ではない22ポイント未満のテキストであれば、1.4.3の要件に従うなら4.5:1以上のコントラスト比、1.4.6の要件に従うなら7:1以上のコントラスト比が必要です。

 3のリンクテキストとその他のテキストの色のコントラスト比は、WCAG2.0の中で特に指定されていないようですが、1と2のコントラスト比を考慮した上でそれぞれのテキストの色の違いが識別できるコントラスト比が必要です。WCAG 2.0 実装方法集 G183はリンクテキストに下線がない場合の実装方法ですが、リンクテキストとその周辺のテキストの色のコントラスト比を3:1 以上にすべしとあるのは、1つの参考になるかと思います。

 なお、コントラスト比については、以下のようなツールが存在します。

 

参考

 

WCAG2.0(JIS X8341-3:2010)での関係する要件

 W3CのウェブアクセシビリティガイドラインであるWCAG2.0でリンクのみせ方に関係する要件は「1.4.1 色の使用」でしょうか。

1.4.1 色の使用(JIS X8341-3:2010では7.1.4.1)

情報を伝える、何が起こるか又は何が起きたかを示す、ユーザの反応を促す、もしくは視覚的な要素を区別する唯一の視覚的な手段として、色だけを使用しない。 (レベルA)

注記: この達成基準は、特に色の知覚に関するものである。その他の知覚形態については、色やその他の視覚的な表現のコーディングへのプログラムによるアクセスも含めて、ガイドライン 1.3で網羅されている。

参考: 達成基準 1.4.1 を理解する | WCAG 2.0解説書
 
 色の選択では、「1.4.3 最低限のコントラスト」と「1.4.6 より十分なコントラスト」も関係してきます。ただし、以下の要件はテキストと背景色のコントラストの要件ですのでご注意ください。

1.4.3 最低限のコントラスト(JIS X8341-3:2010では7.1.4.3)

テキスト及び画像化された文字の視覚的な表現には、少なくとも 4.5:1 のコントラスト比をもたせる。ただし、次の場合は除く: (レベルAA)
大きな文字: サイズの大きなテキスト及びサイズの大きな画像化された文字には、少なくとも 3:1 のコントラスト比がある。
付随的: テキスト又は画像化された文字において、次の場合はコントラストの要件は該当しない。アクティブではないユーザインタフェース・コンポーネントの一部である、装飾だけを目的にしている、誰も視覚的に確認できない、又は重要な他の視覚的なコンテンツを含む写真の一部分である。
ロゴタイプ: ロゴ又はブランド名の一部である文字には、コントラストの要件はない。

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

1.4.6 より十分なコントラスト(JIS X8341-3:2010では7.1.4.6)

テキスト及び画像化された文字の視覚的な表現には、少なくとも 7:1 のコントラスト比がある。ただし、次の場合は除く: (レベルAAA)
大きな文字: サイズの大きなテキスト及びサイズの大きな画像化された文字には、少なくとも 4.5:1 のコントラスト比がある。
付随的: テキスト又は画像化された文字において、次の場合はコントラストの要件は該当しない。アクティブではないユーザインタフェース・コンポーネントの一部である、装飾だけを目的にしている、誰も視覚的に確認できない、又は重要な他の視覚的なコンテンツを含む写真の一部分である。
ロゴタイプ: ロゴ又はブランド名の一部である文字には、コントラストの要件はない。

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

関連エントリ

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

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

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

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では、さらにリンクの文脈をプログラムが解釈可能であることも求めています。
 

参考

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

 「プログラムが解釈可能」と言っても、人間のようにリンクの文脈を意味としてプログラムが解釈できることを求めているわけではありません(無理・・・)。ここで求められているのは、リンクの目的を説明する文脈をプログラムからでも特定できるようにすることです。

 以下のように「続きを読む」のリンク部分のパラグラフが前のパラブラフから独立していると、「続きを読む」のリンクがどこの文章と関係しているのかが特定できず、ユーザーに混乱を与えてしまいます。

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

 

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

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

 
 つまり、コンテンツをタグ付けしてきちんと構造化しましょうという話になります。スクリーンリーダーなどはセンテンス、パラグラフ、見出しなどの単位でフォーカスを移動させる機能を備えているため、きちんと構造化することで必要な説明にすばやく到達させることが可能になります。

 例えば、リンクをul要素とli要素でグループ化することで、これらのリンクが1つのグループであることと、リンク同士が並列関係にあることをプログラムに理解させ、ユーザーに伝えることができます。

<a name="categories" id="categories"></a><h2>商品カテゴリー</h2>
<ul class="navigation">
    <li><p><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>

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

参考

代替手段を用意する(2.4.9の要件)

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

参考

 

関連エントリ

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

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

 これは面白いなぁと思った視覚障害者のための歩行補助具オーデコ(AuxDeco)を紹介します。東京大学とアイプラスプラスが共同開発したもので、カメラで眼前の視覚情報を電子情報として取得し、その輪郭を電子刺激(触覚情報)に変換して額に伝える機器です。

オーデコ(AuxDeco)
http://www.eyeplus2.com/

 まずは以下の(おそらく)公式の紹介動画をご覧ください。

 

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

①小型カメラで、前方を撮影する
内蔵された小型カメラで、前方を撮影します。前方とはカメラの向いている方向、つまり使用者の顔の向きです。使用者は「見たい」方向に顔を向けることで、撮影する方向を定めます。

②撮影した映像を電気刺激に変換する
撮影した映像は小型コンピューター(以下「本体」)に送られます。本体ではまず、送られてきた映像の輪郭線を抽出します。そして、抽出した輪郭線を電気刺激に変換します。

③額(おでこ)で刺激を感じとる
電気刺激に変換された輪郭線は、使用者の額部分に装着された512個の電極から出力します。使用者は、出力される輪郭線刺激を額の触覚で感じとります。

④白杖の先の前方をイメージする
使用者は、額で感じとった刺激の位置・動き・形から、前方の空間をイメージします。白杖を使って歩きながら、白杖の届かない範囲の情報を額から得られると、より安心して、そして楽しく歩行できるようになります

仕組み」より

 

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


オーデコの視覚情報を触覚情報に変換される画像(「トレーニング」より)

 白い杖では、杖の届く範囲の周辺情報しかを取得することができませんが、この支援機器なら杖の届かない遠方の障害物の存在を把握することができます。

 オーデコのような歩行補助具以外にも、視覚情報を触覚情報に変換する機器はいろいろな用途でありえそうです。この分野、もっと拡がるといいですね。

2月 14

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

 ということが、ちょっと前に私の周りで議論になりました。

 なんとなくよくなさそうな気がしますが、実際のところどうなの?というあたり、それを説明できる文書や説明を当時はうまく見つけることができませんでした。しかし、改めて時間をおいて調べてみると、(意外とあっさりと・・)いろいろと出てきましたので今回は、

リンクを別ウィンドウ(タブ)で開くことをユーザーに強いることはアクセシビリティ上どうなのか。

について考えてみたいと思います。いつものように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解説を参照してください。
 

参考

 

さいごに

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

関連エントリ

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

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

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

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

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

 例えば、iOS機にはVoice Overのような支援機能が搭載されているとはいえ、タッチスクリーンは平面的で視覚障害者の方にとって使いやすいものではありません。とはいえ、タッチスクリーンは必要な時に必要なボタンだけ表示できるUIが可能ですので、触覚がより活用できるタッチスクリーンが登場すれば、必要な時に必要な物理的ボタンだけを備えたUIを実現できる。結構理想的かもしれません。アクセシビリティが大きく向上すると思われます。タッチスクリーンの次は触覚の時代です。

 電子書籍の普及で「書籍」がよりアクセシブルになることが期待されたわけですが、ほとんどの端末がタッチスクリーンだけのものになってしまい、ボタンがあったとしてもほとんど脇に追いやられてしまっています。非常に残念ですが、触覚技術の進化とその普及がその状況が逆転されるかもしれません。

 将来的に点字を浮かび上がらせるところまでできれば本当に理想的です。