3月 04

オライリー提唱の執筆・制作用フォーマットHTMLBook仕様案の日本語訳

公益社団法人日本印刷技術協会(JAGAT)XMLパブリッシング研究会が米国の出版社O’Reilly Mediaが提唱するHTMLBookフォーマットの仕様案及びHTMLBookの紹介ページの日本語訳を公開しています。

 HTMLBookはオープンで、XHTML5ベースでプリントとデジタル双方の本を執筆・制作するためのフォーマットです。XHTML5(HTML5)のサブセットでセマンティクスにEPUBの語彙(EPUB 3 Structural Semantics Vocabulary)を使用しています。

 PDF、EPUB、mobi(Kindle形式)、DAISYなどの電子書籍フォーマットをマルチに提供するO’Reilly Mediaですが、そのO’Reilly Mediaがgitでバージョン管理する出版プラットフォームAtlas(ベータ版)を立ち上げています。そのメインの制作用フォーマット(マルチフォーマット対応のためのソースファイル)にHTMLBookを据えようとしているようです。

 HTMLBookの仕様はまだドラフトの段階であり、HTMLBookの仕様案そのものがAsciiDoc形式で公開されているように、AtlasではまだAsciiDocがメインに使われているように思われます。なお、AsciiDoc形式の他にMarkdownDocBook XMLでの入稿も可とのことです(→参考)。

 HTMLBook、DocBook、AsciiDocの関係については、CAS-UBブログが以下のエントリで解説をしています。

 O’Reilly Mediaのマルチフォーマット対応については以下をご参照ください。

2月 06

W3C Annotation Working Groupの憲章案が公開されている

先のエントリの続報になりますが、W3C Annotation Working Groupの憲章案が公開されています。 Digital Publishing Activityの下に設置されることになったんですね。

 すでにAnnotation Working Groupのメーリングリストは立ち上がっていて、 上の憲章案について意見が交換されています。
 

Open Annotationに関するエントリ

9月 25

障害と開発に関する国連総会ハイレベル会合で成果文書として配布された手話動画とテキストハイライトを同期させたHTML5文書

 9月23日にニューヨークの国連本部で、障害と開発に関する国連総会ハイレベル会合が開催されました。

 この会合の成果文書が、HTML5 with video、マルチメディアDASIY、EPUB3など様々なアクセブルな形式で公開されています。

 

 この中ですごいのはHTML5 with videoでしょうか。手話動画とテキストハイライトが同期されています。


Sign language with text (HTML5 with video)

 マルチメディアDAISYやMedia OverlaysなEPUBの動画版といったものですが、動画とテキストハイライトの同期はDAISYやEPUB3の仕様のではサポートされていません(EPUB3は動画を埋め込むこと自体は可能です)。

 なお、この国連総会の会合は、NHK WORLDでも報道されています。

8月 03

Open Annotationとウェブアーカイブのちょっとした関係

 先のエントリでOpen Annotationの紹介をしましたが、余談としてOpen Annotationとウェブアーカイブのちょっとした関係を1つ。

 Open Annotation Data Modelのエディタの1人にロスアラモス国立研究所のHerbert Van de Sompel氏が名を連ねています。Sompel氏はOpen Annotation Collaboration(OAC)でプロジェクトのフェーズ1から主任研究員(principal investigator)の1人としてOpen Annotationに中心人物として参加され続けているようです。このSompel氏、このブログで時々紹介しているウェブアーカイブプロジェクトMementoの方でもありまして(その他、いろいろな顔をお持ちですが)、忙しいにも関わらず毎日、Mementoの“SiteStory Web Archiveのデモ用に自分の写真をBBCのトップページとともにを毎日公開している方でもあります。

 

 Open Annotatationとウェブアーカイブに関係する部分ですが、Open Annotation Data Modelの「3.3.1. Time State」あたりにでています。ウェブアーカイブされたウェブサイトなどデジタルリソースの過去のバージョンを参照するモデルを規定するところです。例示としてMementoプロトコルが言及されていますね

Time Stateのモデル
Time Stateのモデル

 
 Open Annotation Core Data Model Example Listには上のモデルの例示が掲載されています(ウェブアーカイブされたコンテンツがターゲットではありませんが)。

  <x:MyAnno> a oa:Annotation ;
    oa:hasBody <http://www.youtube.com/watch?v=uPh81LIe7B8> ;
    oa:hasTarget <urn:uuid:5D9AD68D-2043-4C77-A40C-ECB00F6248F9> .

  <urn:uuid:5D9AD68D-2043-4C77-A40C-ECB00F6248F9> a oa:SpecificResource ;
    oa:hasSource <http://en.wikipedia.org/> ;
    oa:hasState <urn:uuid:681821DE-E7C3-4486-9E30-F8B9A75AD16B> .

  <urn:uuid:681821DE-E7C3-4486-9E30-F8B9A75AD16B> a oa:State ;
    oa:when "2012-01-18 12:00:00Z" .

Example ListからリンクされているStateより

関連エントリ

8月 02

日本よっ!これがOpen Annotationだっ!!

 我々は様々なサービスやデバイスを通じて、デジタルリソースに対してコメントなどの付加的な情報を日々付与しています。ウェブサイトにはソーシャルブックマークサービスを経由してコメントが大量につけられていますし、Flickr、Youtube、ニコニコ動画などのWebサービスが抱えるリソースに対して大量のコメントが付与されています。Twiiter、FacebookなどのSNSはリソースに対する付加的な情報の付与に特化したサービスといってもよいかもしれません。昨今の電子書籍ビューワーでは、ハイライトやコメントの付与する機能は当然のように備えていますし、電子書籍プラットフォームでは「ソーシャルリーリング」という名前のアノテーションサービスが提供されています。

 どのサービスもあるリソースに対する付加的な情報を他のユーザーや他のデバイスと共有することを目的としています。しかし、残念ながら共有できるのは、プラットフォーム内のユーザー同士のみであったり、プラットフォームが抱えるコンテンツに対するコメントのみであったりと、リソースに対して日々生成される大量の付加的な情報はプラットフォームごと、デバイスごとに分断されてしまっています。それぞれが独自の方法で機能を実現しているためにプラットフォームの枠を超えた共有が基本的にできません。異なる携帯電話会社同士では通話やメールができない時代がありましたが、それと同じ状況になっています。

platform

 リソースに対して付加的な情報を付与し、異なる情報同士を結びつける行為は学術情報の共有と連携に不可欠なものですが、デジタルリソースに対する付加情報の共有が十分にできないため、学術分野におけるデジタルリソースの活用の大きな障害になっています。

 この問題に注視し、デジタルリソースに対する付加的な情報の付与をオープンスタンダード化することでプラットフォームの枠を超えた相互運用を可能とし、付加的な情報(アノテーション)の再利用・共有を可能にしようとしている動きがOpen Annotationです。

Open Annotationとは

 Open Annotationはクライアント、サーバ、アプリケーション、プラットフォームの枠を超えて、アノテーションを共有できるようにすることを目的しています。ただし、これはアノテーションが全てオープンアクセスであることを求めているものではなく、認証によってアノテーションへのアクセスがプラットフォームの会員に制限されることを排除するものではありません。Open Annotationはアノテーションのプロトコルによるやりとりよりはアノテーションの表現部分に焦点を置いており、この表現部分を標準化することで、アノテーションの相互運用性を向上させようとしています。

 Open Annotationがアノテーション付与の対象とするデジタルリソースは、Webサイトに限りません。PDF、EPUB、動画、音声、画像などデジタルリソース全般を対象としています。

 アノテーション(Annotation)は、英和辞典の多くで「注釈、注記、注解」と訳されていますが、Open Annotationにおけるアノテーションでは「異なる情報同士を結びつけれたもの」であり、もう少し広い意味で用いられています。例えば、以下のような行動が「アノテーションの付与」に含まれています。

  • コメントの付与
  • ハイライト
  • タグ付け
  • ブックマーキング
  • 質問や回答

 Open Annotationにおけるアノテーションの本質は、オリジナルのコンテンツ本体に異なる別のレイヤーとして付加的な情報を追加することです。オリジナルコンテンツを改変せずに(オリジナルコンテンツの真正性を担保しつつ)、情報を追加すると言い換えてもよいかもしれません。

コンテンツレイヤーにアノテーションレイヤーを追加する

 このOpen Anntotationを進めているのは、Open Annotation Collaboration(OAC)Annotation Ontology (AO)であり、この2団体によってW3C内に設立されたOpen Annotation Community Groupです※1。そして、このCommunity Groupで議論され、公開されたのが以下の仕様です(どちらもCommunity Draft)。

 仕様の安定的な運用と変化への柔軟な対応を両立させるために、仕様をOpen Annotation Data ModelOpen Annotation Extension Specificationの2つに分けて、長期にわたり大きく変更する必要がない基本的な機能を前者の仕様としてまとめ、コミュニティへのフィードバックの反映や状況の変化への対応は後者の拡張仕様(Extension Specification)で行うという棲み分けがされているようです。
 

Open Annotation Data Model

 Open Annotation Data ModelはアノテーションのためのRDFベースのLinked Open Dataスタンダードです。

 Open Annotationの基本的なアノテーションのモデルは以下になります。targetがアノテーションを付与する対象となるコンテンツ、bodyが付与されるアノテーション本体を指しています。

body、annotation、targetからなる基本的な図

 コメントなしのブックマークやハイライトの場合は、アノテーションとなるコンテンツ部分はありません(body部分がありません)ので、以下のようになります。
annotation、targetのみのモデル

 リソース内部の任意の位置を参照してアノテーションを付与するモデルです。

 キャッシュに保存されたリソースやInternet Archiveなどにアーカイブされたウェブサイトなどある時点のリソースに対するアノテーションの付与のモデルです。

 以上、ほんの一部ではありますが、Open Annotation Data Modelの紹介でした。

Open Annotation Data Modelでは、その他、タグ付けのモデル、複数のターゲットに対する複数のアノテーションなどが様々なモデルが規定されています。

リソース内部の任意の位置を参照する

 出版物の特定の箇所にコメントをつけたり、ハイライトするように、アノテーションはリソース内部の一部分に対して付与されることがあります。リソースの一部分に対してアノテーションを付与するためには、アノテーションを付与する側がリソース内部を任意に部分指定できなければなりません。フラグメント識別子(URLの先の#から始まるもの)を用いることが考えられますが、以下の理由で既存のフラグメント識別子の仕様を活用するだけでは目的をはたせないということで、

  • 多くのファイル形式にフラグメント識別子に関する仕様が存在しない。
  • 仕様が存在しても記述が正確とはいえないものがある。
  • メディアタイプが判明しないと、フラグメント識別子を正確に解釈することができない。
  • システムがリソースの内部まで参照しないことがある。

 Open Annotation Data Modelでは、既存のフラグメント識別子の仕様を活用しつつ、既存の仕様で足りない部分を補うために以下のセレクタという指定子が用意されています(”Open Annotation Data Model Module: Specifiers and Specific Resourcess“)。

  • Range Selectors
    • Text Position Selector
    • Text Quote Selector
    • Data Position Selector
  • Area Selectors
    • SVG Selector

  詳細はOpen Annotation Data Modelのエディタの1人であるPaolo Ciccarese氏の以下のスライドをご覧ください。 


Open Annotation, Specifiers and Specific Resources tutorial from Paolo Ciccarese
  

 なお、Open Annotation Data Modelには、既存のフラグメント識別子の仕様として以下の仕様が掲載されています。

形式 フラグメント識別子の仕様
HTML,XHTML RFC3236
PDF RFC3778
プレーンテキスト RFC5147
XML RFC3023
RDF/XML RFC3870
画像・動画・音声 Media Fragments.
SVG SVG

  EPUBにはEPUB CFI(Canonical Fragment Identifier)というEPUBコンテンツ内部の任意の位置を参照・指定できるフラグメント識別子の仕様がすでにあります。Fragment SelectorとしてまだOAMの仕様には掲載されていませんが、EPUBで使うならこの仕様でしょう。

 

さいごに

 Open Annotationという言葉を最近、いろいろなところで目にするようになりました。

 WebアノテーションサービスHypothes.isはOpen Annotation Data Modelを活用していますし、

 最近、公開されたJavaScirptベースのEPUBビューワーのepub.jsはOpen Annotationの実証実験のために公開されたものだそうです。

 図書館関係者を賑わしているBIBFRAMEはOpen Annotaiton Modelを参照しています※。

※2013/08/29 追記
8/26に公開されたドラフトでOpen Annotationに触れていた箇所がばっさりと削られたようです。4月から8月の間に一体何が・・・というあたりはBIBFRAMEのMLを追っていけばわかるのでしょうか(すいません。そこまでは追えてません・・・・)。ちなみに7月に”BF annotation and OA annotation”というスレが立てられていました。

 Open Annotation Collaborationで行われた実証実験では、デジタルアーカイブに対するアノテーションの付与や学術出版の共同編集作業、ストリーミング動画に対するアノテーションの付与などが試みられており、Open Anntotationが覆う領域の広さを伺わせます。

 現在、アノテーションサービスは、プラットフォームが個別に提供するものになってしまっていますが、アノテーションの標準化が進めば、例えば、個々の機関リポジトリやデジタルアーカイブ、学会ホームページがそれぞれでアノテーションサービスを提供したとしても、相互運用性の向上により、理想的にはWebリソースのような、「ばらばらに作成されたけれども1つの大きなアノテーションの世界」をつくることができるようになります。Webにもう1つのレイヤー、アノテーションレイヤーを追加する試みはMosaicブラウザでも検討されたことがあり、その後、Googleも含めていくつかのプラットフォームでも試みられたことがありましたが、まだ成功と言えるものは存在していません※2。単体のプラットフォームが覆うにはデジタルリソースの世界は大きすぎるということでしょう。Open Annotationの推し進める標準化によって、個々の活動が結果として1つのアノテーションの大きな世界になり、もう1つの大きな世界(デジタルリソース)を覆うようになれば、デジタルリソースの活用がもう1つ別の次元に進むかもしれません。

 W3C内のOpen Annotationの検討体(Open Annotation Community Group)はまだCommunity Groupですが、2014年にはいよいよWorking Groupが立ち上げられ、Open Annotation Data Modelの仕様化が本格化する可能性があるようです※3。数年後にはブラウザや電子書籍ビューワーで標準で対応するようになるかもしれません。しばらくOpen Annotationの動向から目が離せません。

※2014/8/25 追記
日本時間で8月21日にWeb Annotation Working GroupがW3CのDigital Publishing Activityの下に設置されました。W3cの仕様化のトラックにのったことになります。このWGについて改めて紹介記事を書きました。

※1 W3CのCommunity GroupはWorking Groupの前の段階に置かれている検討体です。詳細は以下のエントリをご参照ください。

※2 過去のアノテーションの動向については、以下が参考になります。

※3以下のスライドを参照。

関連エントリ

3月 10

今年、Web Payments(Web上のオープンな金銭取引の標準化)が大きく動く?

 これまでW3CのComunity Groupレベルで検討が進められていたWeb Payments(Web上のオープンな金銭取引の標準)が2013年になって、少し、もしかすると大きく進展することになりそうです。W3Cが力を入れるようになったということなのでしょうか。

 W3CのブログとW3C Wikiによると、Web Paymentsについて、W3Cは今後以下のような活動を予定しているそうです。

  • W3C Advisory Committeeでの報告(2013年6月か7月。開催地は東京?)
  • 外部有識者の招聘
  • ニーズを調査するための開発者を対象としたアンケートの実施
  • キーステークホルダーとの直接的なコンタクトDirect contact with key stakeholder groups (who?)
  • Web Paymentsのスコープが明らかにできた段階で、2013年後半にWeb Paymentsに関するワークショップの開催
  • 公式の報告書の発行

 
 Payment Task Forceなんて、いつの間に立ち上がっていたのだろうか・・・。Wikiの履歴を見る限り、2013年になってからのようですが。

 どちらにしても特定のプラットフォームに依存しなくても、Web上のお金のやり取りができるようになれば、プラットフォーム非依存なコンテンツの流通に大きく寄与すると思われますので、期待したいところです。

関連エントリ

 
 

3月 04

Google Chrome がWebに音声認識機能を埋め込めるWeb Speech API に多言語で対応。WebへのTTS機能埋め込みも可能?

 Google Chromeが安定版のver. 25でWebアプリに音声認識機能を埋め込めるWeb Speech APIに対応しました。しかも、日本語を含む多言語対応です。音声でウェブアプリを操作するといったことが可能になるようです。

 Googleの中の人による紹介動画が公開されています。 

 Googleがデモサイトを公開していますので、音声認識の精度を実際に試すことが可能です。

Web Speech APIの仕様には、このAPIのユースケースとして以下が挙げられています。Web Speech APIはWebの音声入力(speech-input)と自動音声読み上げ(Text-To-Speech)の制御をJavaScriptによって実現することを目的としているようですが、自動音声読み上げ(Text-To-Speech)に該当するものがない・・・?

  • Voice Web Search
  • Speech Command Interface
  • Domain Specific Grammars Contingent on Earlier Inputs
  • Continuous Recognition of Open Dialog
  • Domain Specific Grammars Filling Multiple Input Fields
  • Speech UI present when no visible UI need be present
  • Voice Activity Detection
  • Temporal Structure of Synthesis to Provide Visual Feedback
  • Hello World
  • Speech Translation
  • Speech Enabled Email Client
  • Dialog Systems
  • Multimodal Interaction
  • Speech Driving Directions
  • Multimodal Video Game
  • Multimodal Search
参考

 

Web Speech APIとSpeech Input API

 Web Speech APIの他にフォームに音声入力機能を追加するSpeech Input APIというAPIがあり、こちらはChrome 11から対応しています。input要素にspeech属性を追加するだけなので、実装は非常に簡単です。

 Web Speech APIとSpeech Input APIは機能的に被っている部分があります。どちらもGoogleが提案したAPIのようですが、そのあたりの経緯は以下で説明されています。Speech Input APIを提案した後により広範なWebの音声入出力を扱うWeb Speech APIをJavaScirptベースのAPIとして提案したようです。

参考

 

Text-To-Speech(自動音声読み上げ)機能

 ここからは、勉強不足ということもあり、憶測が混ざります。ご注意ください。

 Web Speech APIによって、Text-To-Speech(自動音声読み上げ)機能をJavaScriptで制御することが可能になります。これがBookshareが提供するブラウザ版電子書籍リーダーでのTTS(自動音声読み上げ)機能でおそらく活用されているのではないかと思われます(Googleの公式ブログが言及しているので)。Google Chromeは2011年にTTS APIを公開TTSエンジンを搭載※していますので、それを使用しているのでしょうか。

※2013-07-08追記
Chrome自身がTTSエンジンを搭載したのではなく、OSなどが搭載しているTTSエンジンを利用するためのAPIを公開したという話でした。誤った情報を流してしまい、大変申し訳ありませんでした。
Chrome Text To Speech – Beautiful Google – Google活用の仕方

  以下の動画で紹介されていますが、テキストを読み上げながら、読み上げる箇所をハイライト表示しています。

参考
1月 25

アクセシビリティに配慮した顔文字、ASCIIアートの代替テキストの提供

 顔文字、ASCIIアートがスクリーンリーダーなどの読み上げで大変なことになることはお察しのとおりかと思いますが、これらをアクセシブルにするための代替テキストの提供方法がW3Cの以下のドキュメントにまとめられています。

 と、いいつつも、実はこれから紹介する方法はブラウザ、スクリーンリーダーなどの支援機器が充分にサポートしていないようです。現時点では、アクセシビリティを確保するためには、ASCIIアート、顔文字を使わないほうがよいようです。

 というわけですので、以下はあくまで参考情報として紹介します。

顔文字

例1 隣接する位置に説明するテキストを配置

 ASCIIアートや顔文字のすぐ隣にそれを説明するテキストを配置します。

=8-0(恐怖)

 上の事例では、
 「=8-0」部分がそのまま読まれてしまいますので、この部分がユーザーの混乱を招く恐れもありそうですが、必要最低限の措置としては有効かもしれません。

例2 abbr要素のtitle属性を使用する

 省略語を表すabbr要素のtitle属性を使用します。

<abbr title="恐怖">=8-0</abbr>

  title属性の読み上げに対応している機器やアプリケーションが十分でないようです。また、abbr要素は略語をマークアップするための要素なので、abbr要素の本来の使い方から外れてしまっている問題もあります。
 

参考

例3 画像化し、img要素のalt属性を使用する

 顔文字を画像化してしまい、img要素のalt属性を使用する事例です。

<img src="fright.gif" alt="恐怖"/>

 画像化してしまっては、あえてテキストで絵的に表現する意味が失われてしまいますが、alt属性をサポートするブラウザやアプリケーションは多いため、有効な方法です。
 

ASCIIアート

事例4 スキップリンク

コード例


 さし絵:蝶のASCIIアート
 <a href="#skipbutterfly">ASCIIアートをスキップ</a>

                                                                LLLLLLLLLLL
                                                            __LLLLLLLLLLLLLL
                                                           LLLLLLLLLLLLLLLLL
                                                         _LLLLLLLLLLLLLLLLLL
                                                        LLLLLLLLLLLLLLLLLLLL
                                                      _LLLLLLLLLLLLLLLLLLLLL
                                                      LLLLLLLLLLLLLLLLLLLLLL
                                              L     _LLLLLLLLLLLLLLLLLLLLLLL
                                             LL     LLLLLL~~~LLLLLLLLLLLLLL
                                            _L    _LLLLL      LLLLLLLLLLLLL
                                            L~    LLL~        LLLLLLLLLLLLL
                                           LL   _LLL        _LL   LLLLLLLL
                                          LL    LL~         ~~     ~LLLLLL
                                          L   _LLL_LLLL___         _LLLLLL
                                         LL  LLLLLLLLLLLLLL      LLLLLLLL
                                         L  LLLLLLLLLLLLLLL        LLLLLL
                                        LL LLLLLLLLLLLLLLLL        LLLLL~
                  LLLLLLLL_______       L _LLLLLLLLLLLLLLLL     LLLLLLLL
                         ~~~~~~~LLLLLLLLLLLLLLLLLLLLLLLLL~       LLLLLL
                       ______________LLL  LLLLLLLLLLLLLL ______LLLLLLLLL_
                   LLLLLLLLLLLLLLLLLLLL  LLLLLLLL~~LLLLLLL~~~~~~   ~LLLLLL
             ___LLLLLLLLLL __LLLLLLLLLLLLL LLLLLLLLLLLLL____       _LLLLLL_
          LLLLLLLLLLL~~   LLLLLLLLLLLLLLL   LLLLLLLLLLLLLLLLLL     ~~~LLLLL
      __LLLLLLLLLLL     _LLLLLLLLLLLLLLLLL_  LLLLLLLLLLLLLLLLLL_       LLLLL
     LLLLLLLLLLL~       LLLLLLLLLLLLLLLLLLL   ~L ~~LLLLLLLLLLLLL      LLLLLL
   _LLLLLLLLLLLL       LLLLLLLLLLLLLLLLLLLLL_  LL      LLLLLLLLL   LLLLLLLLL
  LLLLLLLLLLLLL        LLLLLLLLLLLLL~LLLLLL~L   LL       ~~~~~       ~LLLLLL
 LLLLLLLLLLLLLLL__L    LLLLLLLLLLLL_LLLLLLL LL_  LL_            _     LLLLLL
LLLLLLLLLLLLLLLLL~     ~LLLLLLLL~~LLLLLLLL   ~L  ~LLLL          ~L   LLLLLL~
LLLLLLLLLLLLLLLL               _LLLLLLLLLL    LL  LLLLLLL___     LLLLLLLLLL
LLLLLLLLLLLLLLLL              LL~LLLLLLLL~     LL  LLLLLLLLLLLL   LLLLLLL~
LLLLLLLLLLLLLLLL_  __L       _L  LLLLLLLL      LLL_ LLLLLLLLLLLLLLLLLLLLL
 LLLLLLLLLLLLLLLLLLLL        L~  LLLLLLLL      LLLLLLL~LLLLLLLLLLLLLLLL~
  LLLLLLLLLLLLLLLLLLLL___L_ LL   LLLLLLL       LLLL     LLLLLLLLLLLLLL
   ~~LLLLLLLLLLLLLLLLLLLLLLLL     LLLLL~      LLLLL        ~~~~~~~~~
           LLLLLLLLLLLLLLLLLL_ _   LLL       _LLLLL
               ~~~~~~LLLLLLLLLL~             LLLLLL
                         LLLLL              _LLLLLL
                         LLLLL    L     L   LLLLLLL
                          LLLLL__LL    _L__LLLLLLLL
                          LLLLLLLLLL  LLLLLLLLLLLL
                           LLLLLLLLLLLLLLLLLLLLLL
                            ~LLLLLLLLLLLLLLLLL~~
                               LLLLLLLLLLLLL
                                 ~~~~~~~~~
<a name="skipbutterfly></a>            

 

 こういうやる夫系はどうするんだろう・・・・。

       ____
     /      \
   /  _ノ  ヽ、_  \
  / o゚((●)) ((●))゚o \  ほんとはVIPでやりたいんだお…
  |     (__人__)    |
  \     ` ⌒´     /



       ____
     /      \
   /  _ノ  ヽ、_  \
  /  o゚⌒   ⌒゚o  \  でもVIPPERはクオリティ高いスレしか相手してくれないお・・・
  |     (__人__)    |  
  \     ` ⌒´     /



       ____
     /⌒  ⌒\
   /( ●)  (●)\
  /::::::⌒(__人__)⌒::::: \   だからニュー速でやるお!
  |     |r┬-|     |
  \      `ー'´     /

 

参考

例5 画像化し、img要素のalt属性を使用する

 ASCIIアートを画像化してしまい、img要素のalt属性を使用する事例です。

<img src="yaruo.gif" alt="だからニュー速でやるお!と言っているやる夫"/>

 画像化してしまっては、あえてテキストで絵的に表現する意味が失われてしまいますが、alt属性をサポートするブラウザやアプリケーションは多いため、有効な方法です。
 

(2014/12/6追記)例6 figure要素とWAI-ARIAのrole属性を使う

WAI-ARIAのrole属性を解釈できるユーザーエージェントであれば、ASCIIアートを画像に相当するものであると、解釈させることもできるようです。

 詳細は、@momdo_ さんの以下のブログをご参照ください。

関連エントリ

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

 

1月 21

アクセシビリティに配慮した代替テキストの話

 代替テキストといえば、img要素のalt属性に入れるテキストとしてよく知られています。しかし、alt属性に画像の「タイトル」が記述されていることが多いような気がします(あくまで気がするだけです・・・)。代替テキストは「タイトル」ではないため、結果として「タイトル」が適切であることはありますが、代替テキストとして適切でない場合があります。かくいう私もこれまで同じことをやってしまっていまして、これではイカン!と

 アクセシビリティに配慮した代替テキスト

について調べてみました。ここがおかしいという箇所がありましたらぜひご指摘ください。

代替テキストとは

 W3Cの文書※1の言葉を借りるならば、代替テキストとは

   「元の非テキストコンテンツと同じ目的及び情報を伝える」テキスト

です。代替テキストを非テキストコンテンツと置き換えてもそのページが持つ情報が失われないことが代替テキストの要件になります。

 置き換えても情報が失われないテキスト、と言われてもなかなかイメージしづらいですが、例えば、事例1のように文中で参照される図の代替テキストは、その図の内容を説明するテキストを提供します。

事例1:文中で参照される図

RSSのPing送信の仕組みをOPDSカタログで採用すると以下のような流れになります。

OPDSアグリゲータがOPDSカタログを取得する流れ
Webサイトが電子書籍カタログ(OPDSカタログ)を更新したことをOPDSアグリテータが設置するPingサーバーに通知する(Ping送信)。OPDSアグリテータは更新されたOPDSカタログを通知したWebサーバーから取得し、1つの大きなOPDSカタログに集約する

 OPDSカタログアグリゲータは更新されたタイミングでOPDSカタログをコンテンツプロバイダから取得し、それをすぐに読者の検索結果に反映させていくことができるのです。

 

事例1の代替テキスト

<img src=”image.png” alt=”Webサイトが電子書籍カタログ(OPDSカタログ)を更新したことをOPDSアグリテータが設置するPingサーバーに通知する(Ping送信)。OPDSアグリテータは更新されたOPDSカタログを通知したWebサーバーから取得し、1つの大きなOPDSカタログに集約する。“/>
  
 事例1の場合、「以下のように」で図を参照し、その図で得るべき情報をうけて下の「OPDSカタログアグリゲータは~」という文章が続いているため、その図で得るべき情報を代替テキストで提供する必要があるのです。 

音声で代替テキストを事例1を読み上げられた場合

RSSのPing送信の仕組みをOPDSカタログで採用すると以下のような流れになります。
OPDSアグリゲータがOPDSカタログを取得する流れ
Webサイトが電子書籍カタログ(OPDSカタログ)を更新したことをOPDSアグリテータが設置するPingサーバーに通知する(Ping送信)。OPDSアグリテータは更新されたOPDSカタログを通知したWebサーバーから取得し、1つの大きなOPDSカタログに集約する。
OPDSカタログアグリゲータは更新されたタイミングでOPDSカタログをコンテンツプロバイダから取得し、それをすぐに読者の検索結果に反映させていくことができるのです。

 

 代替テキストとして図のタイトルの「OPDSアグリゲータがOPDSカタログを取得する流れ」を提供しても、その前後の文章とうまくつながりません(それどころか、この場合同じタイトルが二度読み上げられてしまう)。

代替テキストとしてタイトルを提供されたものを音声で読み上げられた場合(不適切な事例)

 RSSのPing送信の仕組みをOPDSカタログで採用すると以下のような流れになります。
 OPDSアグリゲータがOPDSカタログを取得する流れ
 OPDSアグリゲータがOPDSカタログを取得する流れ
 OPDSカタログアグリゲータは更新されたタイミングでOPDSカタログをコンテンツプロバイダから取得し、それをすぐに読者の検索結果に反映させていくことができるのです。

 

 音声ブラウザやスクリーンリーダーのユーザーなど、実際のユーザーを意識して考えるとよいかもしれません。
  

代替テキストを提供する上で大事なこと

 代替テキストは情報が不足することがあってもいけませんが、情報を盛りすぎてもよくありません。そのあたりのバランスをとるには以下の2点を押さえることが重要になってきます。

  • 非テキストコンテンツと同じ目的及び情報を持つ。
  • 可能な限り簡潔である。

  

非テキストコンテンツの目的を考えなければならない

  同じ非テキストコンテンツであれば常に同じ代替テキストを提供すればよいかといえば、そうではありません。非テキストコンテンツがそのページの中で与えられている役割に応じてその目的に合致した情報を代替テキストとして提供しなければなりません。

 例えば、以下の虫眼鏡の画像です。 

mushilens
 
 この画像は例えば、以下のような情報をもっています。

  • 虫眼鏡である。
  • 写真ではなく、絵である。
  • 柄が茶色で縁が黒である。
  • もしかすると、虫眼鏡の画像ではなくて、虫眼鏡に似た丸と台形を組みあわせ図である。
  • PNG形式の画像である。
  • 150px × 134pxである。

 この画像をいろいろな角度から眺めるとまだまだ様々な情報を持っており、挙げるとキリがありません。しかし、この画像が持つ情報を網羅的に提供する必要はありませんし、するべきではありません。ページにおける非テキストコンテンツの目的に合致するものだけを過不足なく提供すればよいのです。
 

事例2:こんな虫眼鏡

 虫眼鏡そのものに触れる文章の中で使用される場合は、虫眼鏡そのものの情報を提供する必要があります。

一郎「そういえば、よく昔のアドベンチャーゲームに出てくるようなこんな虫眼鏡って、実はあまり見ないよね(笑)」
mushilens 
二郎「ははは、そういえば、ゲームにこんな虫眼鏡出てたね。僕の家には昔、これに似た大きな虫眼鏡があったよ。」

事例2の代替テキスト

<img src=”image.png” alt=”柄が真っ茶色でレンズの縁の部分が丸い虫眼鏡。“/>

 

事例3:検索エンジンのボタン

  検索ボタンとして虫眼鏡の画像を使用する場合は、その画像の用途を考慮して「検索」といれるほうが適切です。

 

事例3の代替テキスト

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

 ページにおける非テキストコンテンツの目的に合致する非テキストコンテンツが持つ同等の情報だけを提供すればよいのです。逆にいえば、その目的に合致しない情報を代替テキストとして提供するべきではありません。

 

代替テキストは簡潔であるべきである

 代替テキストは可能な限り簡潔に提供する必要があります。提供される情報が多ければよいというものではありません。簡潔に記述するためにも、その判断基準として非テキストコンテンツのそのページにおける目的をよくよく考える必要があります。 
 
 なお、img要素のalt属性について、W3Cの以下の文書では、75から100文字(1から2文)までの長さが「簡潔」と見なされるコンセサンスのある長さであるとしています(あくまで目安です)。

 

 しかし、代替テキストがどうしても長くなりすぎる場合があります。長くなりすぎる場合は、コンテンツ内において同じ目的を果たし同じ情報を提供する長い説明にその役割を委ね、代替テキストは簡易な記述で済ませることも認められています。

事例4:アクセスマップ

 電車、バス、自動車による施設へのアクセスをそれぞれ代替テキストとして提供するとどうしても長くなってしまいます。

○○株式会社○○事業所のアクセスマップ
○○株式会社○○事業所アクセスマップ。この地図の直後に地下鉄と車によるアクセス情報

(地下鉄でお越しの場合)
○○線○○駅8番出口を南に徒歩約10分

(お車でお越しの場合)
○○高速○○線○○インターからA通りを南下。B通りを右折して西に3ブロック進んだところで左折。C通りを南下して5分。

 代替テキストが果たす役割はアクセスマップにあわせてに提供されるテキストによる解説に委ね、代替テキストとして、その画像の目的と代替テキストの代わりを果たす長い説明がどこに存在するかをしめすことでよいようです。

事例4の代替テキスト

<img src=”map.jpg” alt=”○○株式会社○○事業所アクセスマップ。この地図の直後に地下鉄と車によるアクセス情報” />

参考

 

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

 最後に少し固い話になりますが、代替テキストの提供がウェブアクセシビリティ上どの程度求められているかについてです。

 W3CのウェブアクセシビリテイのガイドラインWCAG2.0では、1.1とその下の1.1.1が代替テキストの要件に該当します(JIS X8341-3:2010では、それぞれ7.1.1と7.1.1.1)。 

ガイドライン 1.1 代替テキスト(JIS X8341-3:2010では 7.1.1)

 すべての非テキストコンテンツには代替テキストを提供して、拡大印刷、点字、音声、シンボル、平易な言葉などのような、ユーザが必要とする形式に変換できるようにする

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

ユーザに提示されるすべての非テキストコンテンツには、同等の目的を果たす代替テキストがある。ただし、以下に挙げる場合は除く (レベル A):

  • コントロール、入力: 非テキストコンテンツが、コントロールまたはユーザの入力を受け入れるものである場合、代替テキストは、その目的を説明する識別名を提供している。(コントロールおよびユーザの入力を受け入れるコンテンツに関するその他の要件は、ガイドライン 4.1を参照のこと。)
  • 時間の経過に伴って変化するメディア: 非テキストコンテンツが、時間の経過に伴って変化するメディアであるとき、代替テキストは、少なくとも、その非テキストコンテンツを識別できる説明を提供している。(メディアに関するその他の要件は、ガイドライン 1.2を参照のこと。)
  • 試験: 非テキストコンテンツが、テキストで提示されると無効になる試験あるいは演習のとき、代替テキストは、少なくともその非テキストコンテンツを識別できる説明を提供している。
  • 感覚的: 非テキストコンテンツが、特定の感覚的体験を創り出すことを主に意図しているとき、代替テキストは、少なくともその非テキストコンテンツを識別できる説明を提供している。
  • CAPTCHA: 非テキストコンテンツが、コンピュータではなく人間がコンテンツにアクセスしていることを確認する目的で用いられているとき、代替テキストは、その非テキストコンテンツの目的を特定し、説明している。なおかつ、他の感覚による知覚に対応して出力するCAPTCHAの代替形式を提供することで、様々な障害に対応している。
  • 装飾、整形、非表示: 非テキストコンテンツが、装飾だけを目的にしている、あるいは見た目の整形のためだけに用いられている、またはユーザに提供されるものではないとき、支援技術が無視できるように実装されている。

from WCAG2.0 ガイドライン 1.1

 
 1.1.1に挙げられている一部の例外(次のエントリで解説)を除き、代替テキストを提供することはWCAG2.0(JIS X8341-3:2010)は、最低限満たすべき要件達成等級A ⇒参考 適合レベル)という扱いになっています。つまり、JIS X8341-3:2010に準拠(参考 対応度表記ガイドライン)しようとする場合、このエントリで述べたような代替テキストの提供は必須となります。

参考(WCAG2.0とJIS X8341-3:2010の関係について)

※1 G94: 非テキストコンテンツに対して、それと同じ目的を果たし、同じ情報を提供する、簡潔な代替テキストを提供する|WCAG 2.0 実装方法集

関連エントリ

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

W3C Web Content Accessibility Guidelines(WCAG) 2.0が国際規格化

 W3C Web Content Accessibility Guidelines(WCAG) 2.0ISO/IEC 40500:2012として承認されたようです。World Wide Web Consortium (W3C) ISO/IEC joint technical committee for information technology(ISOとIECの情報技術のための合同技術委員会)が共同で本日、発表しています。

ISO/IEC 40500:2012 Information technology — W3C Web Content Accessibility Guidelines (WCAG) 2.0
W3C Web Content Accessibility Guidelines 2.0 Approved as ISO/IEC International Standard

Web Content Accessibility Guidelines(WCAG) 2.0
http://www.w3.org/TR/WCAG20/

ウェブコンテンツ・アクセシビリティ・ガイドライン (WCAG) 2.0 日本語訳
http://www.jsa.or.jp/stdz/instac/commitee-acc/W3C-WCAG/WCAG20/index.html

 ちなみにWCAG 2.0は日本でもJIS X8341-3:2010として、JIS規格に組み込まれています。
JIS X 8341-3:2010 解説 | 公開資料&リンク集 | ウェブアクセシビリティ基盤委員会(WAIC)

 なお、これは蛇足ですが、「X8341」の「8341」は「や・さ・し・い」の語呂合わせからきているそうで、その他の「X8431-」の規格もアクセシビリティに関する規格にあてられています(Xは情報技術分野の規格であることを示す)。覚えやすい。
JIS X8341概要:情報アクセシビリティ国際標準化委員会:INSTAC:JSA