月: 2013年2月

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

kzakza

　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

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

kzakza

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

『アクセシビリティハンドブック』（O’Reilly Japan）
　ウェブアクセシビリティについていろいろと調べていくと、これはこうだからダメ、あれはああなのでそうしたほうがいいということがある程度わかってきますが、調べれば調べるほど表層的な部分に触れる程度の理解でしかないことを痛感します。
　それでこの書籍です。目次をみて、障害者がどのような困難に遭遇しているかを障害別に詳しく書いてあるのかと期待してすぐに読んでみました。しかし、内容は障害別にウェブアクセシビリティを配慮したコンテンツの作成の方法をまとめたもので、そう言う意味では少し期待を裏切られました。
　とはいえです。他の本のようにJavaScript、フォーム、テーブルといった開発者視点の分類でのウェブアクセシビリティ解説より、なぜ対応しなければならないかという理由とその対応方法がセットになっているこの本のほうが初めてウェブアクセシビリティについて触れる人には理解しやすいかもしれません。ページ数も10.5インチのiPadで読めば、だいたい100頁強ですので、数時間で通読できるものだと思います。巻末に障害別にツール類を紹介したまとめが掲載している点もポイントが高い。
　なお、ですが、この本を手にとったそもそもの動機を満足させるためには、個々に書籍にあたっていくしかないようです（し、実際にいろいろと読んでもいる）。しかし、障害者の抱える困難については、国立国会図書館が公開する以下の研修資料がよくまとまっています。

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

kzakza

　なんとなく強調するために使われているっぽい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解説書
　

関連エントリ

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