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

ウェブコンテンツで「非テキストコンテンツと同等の目的を果たす代替テキスト」を提供しなくてもよいもの

 先のエントリですべての非テキストコンテンツに対して非テキストコンテンツと同じ目的及び情報を持つ代替テキストを提供することは、W3CのウェブアクセシビリテイのガイドラインWCAG2.0(JIS X8341-3:2010)において最低限の要件(達成等級A ⇒参考 適合レベル)となっているという話をしました。 

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

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

from WCAG2.0 ガイドライン 1.1.1

 

 しかし、この要件には例外がいくつか認められており、同じ1.1.1(JIS X8341-3:2010では 7.1.1.1)でその例外が列記されています((1)〜(6)は私の補記)。

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

from WCAG2.0 ガイドライン 1.1.1

   
 今回はこの例外、つまり、非テキストコンテンツと同等の目的を果たす代替テキストを提供しなくてよい事例について紹介します。

参考(本エントリ全体)

 なお、以下、1.1.1 に記載されている順番に紹介していきますが、最初の(1)が抽象的でややわかりづらいかもしれませんので、最初は(1)を飛ばして、(2)以降から読み始めてもよいかもしれません。

(1)ユーザーのコントロール、入力を受け付けるインタラクティブなコンテンツ

コントロール、入力: 非テキストコンテンツが、コントロールまたはユーザの入力を受け入れるものである場合、代替テキストは、その目的を説明する識別名を提供している。(コントロールおよびユーザの入力を受け入れるコンテンツに関するその他の要件は、ガイドライン 4.1を参照のこと。)

  
 ユーザーのコントロールや入力を受け付ける非テキストコンテンツを指しており、フォームのラジオボタンやテキストフィールドなどがそれに該当するようです。イメージマップや複雑なアニメーションなどもこれに該当するようです。

  コントロール、入力を受け付けるインタラクティブな非テキストコンテンツの場合、代替テキストではなく、識別名を提供することが求められています。

  識別名とは「ソフトウェアがこれを用いて、ウェブコンテンツのコンポーネントを利用者に識別させることができるテキスト」という説明がWCAG 2.0解説書でされているのですが、よくわかりませんね・・・。

 識別名の抽象的な文言による定義を読むより、以下のドキュメントを読んだ方がわかりやすいと思います。これが識別名であると表と事例で具体的に示しています。

参考(識別名について)

  識別名の実装方法は以下で解説されています。

参考(実装方法)

 コントロールや入力を受け付ける非テキストコンテンツについては、その他の要件が「4.1.2 プログラムで解釈可能な識別名・役割及び設定可能な値」にありますので、こちらもあわせて参照してください。

参考(ガイドライン 4.1)

 

(2)動画・音声(時間の経過に伴って変化するメディア)

時間の経過に伴って変化するメディア: 非テキストコンテンツが、時間の経過に伴って変化するメディアであるとき、代替テキストは、少なくとも、その非テキストコンテンツを識別できる説明を提供している。(メディアに関するその他の要件は、ガイドライン 1.2を参照のこと。)

 
 時間の経過に伴って変化するメディアとは、動画や音声などを指しています。
 
 同等の目的を果たす代替テキストの提供が容易ではないため、その非テキストコンテンツがそのページ内にある目的をユーザーが理解できるようなテキストを代替テキストとして提供することが求めれます。

参考

 なお、「時間の経過に伴って変化するメディア」の代替コンテンツの提供については、ガイドライン 1.2(JIS X8341-3:2010 7.1.2)に詳しく記述されていますので、こちらも参照するべきです。

参考(ガイドライン 1.2)

 
 

(3)試験に用いられるコンテンツ

試験: 非テキストコンテンツが、テキストで提示されると無効になる試験あるいは演習のとき、代替テキストは、少なくともその非テキストコンテンツを識別できる説明を提供している

 
 ヒアリングテストなど試験のために用いられ、同等の目的を果たす代替テキストを提供すると非テキストコンテンツ本来の目的を果たせない非テキストコンテンツです。

 もちろん試験の回答になるようなものは避けつつ、その非テキストコンテンツがそのページ内にある目的をユーザーが理解できるようなテキストを代替テキストとして提供し、ユーザーが非テキストコンテンツをどうしたいか判断できるようにすることが求めれます。

参考

 
 

(4)芸術作品など言葉では完全に表わせない表現物

感覚的: 非テキストコンテンツが、特定の感覚的体験を創り出すことを主に意図しているとき、代替テキストは、少なくともその非テキストコンテンツを識別できる説明を提供している。

 
 交響曲や芸術作品などのテキストで非テキストコンテンツを完全に表現することができない非テキストコンテンツです。
 
 その非テキストコンテンツのラベルと補足説明を代替テキストとして提供し、ユーザーがその非テキストコンテンツがそのページ内にある目的を理解し、どうしたいか判断できるようにすることが求めれます。

参考

 
 

(5)CAPTCHA

CAPTCHA: 非テキストコンテンツが、コンピュータではなく人間がコンテンツにアクセスしていることを確認する目的で用いられているとき、代替テキストは、その非テキストコンテンツの目的を特定し、説明している。なおかつ、他の感覚による知覚に対応して出力するCAPTCHAの代替形式を提供することで、様々な障害に対応している。

  
 CAPTCHA(Wikpedia)とは、認証時に以下のような手書き風の画像テキストを用いて、機械ではなく人間が入力していることを確認する方式です。

 CAPTCHAで用いられる画像の例

 画像と同等の目的を果たす代替テキストを提供するとCAPTCHAを用いる意味がありませんので、その非テキストコンテンツがそのページ内にある目的をユーザーが理解できるようなテキストを代替テキストとして提供し、また、音声読み上げなどの他の出力形式による代替コンテンツを提供することが求められます。
  

参考

 
 

(6)装飾目的の画像

装飾、整形、非表示: 非テキストコンテンツが、装飾だけを目的にしている、あるいは見た目の整形のためだけに用いられている、またはユーザに提供されるものではないとき、支援技術が無視できるように実装されている。

 
 透過画像のように見栄えを調整するためだけに用いられる非テキストコンテンツを指しています。ユーザーに何ら情報を与える意図を持たないコンテンツであり、代替テキストを提供すると逆にユーザーに混乱を与えてしまいますので、スクリーンリーダーなどの支援技術が無視できるように実装されることが求められます。
 
 支援技術が無視できるように実装ということですが、具体的には以下のようにalt属性を空(alt=””)にし、title属性を付与しないことが推奨されるようです。HTMLの仕様でalt属性は必須となっており、また、alt属性を省略すると画像ファイル名を読み上げるアプリケーションもあるので、alt属性そのものは省略してはなりません

<img src="image.jpg" alt="">

 
 

参考

 
 なお、ブラウザやスクリーンリーダーによって、挙動が異なるため、上の方法で提供してもファイル名を読み上げるものもあったりするようです。この提供方法が現時点ですべてのユーザーに対して優しいとは限らないことは知っておくべきです。
 

実際にアプリケーションがどう読み上げるかの参考

  

(おまけ)非テキストコンテンツを用いたリンク

  上のどれかに該当する事例かもしれませんが、そうではないかもしれないので、おまけとして。これも代替テキストを提供しなくてもよい事例といえば事例です。
 
 しばしば以下のようにテキストだけではなく、画像へもリンクを貼ることで、リンクの存在を目立たせる手法が用いられます。

例:Yahoo! Japanへの画像を用いたリンク

Yahoo! Japan
  Yahoo! Japan

 
 画像を用いた手法そのものは問題ではないのですが、リンクのはり方が以下のようになっているサイトをしばしば見かけます。

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

 代替テキストの「Yahoo! Japan」とリンクテキストの「Yahoo! Japan」が重複していますので、「Yahoo! Japan」が二度読み上げられてしまいます。

 リンクテキストと代替テキストが同一の場合は、リンクテキストに代替テキストが果たす役割を委ねることができます。alt属性を空にし、一つのa属性で全体をラップして1つの大きなリンクにすることで、スクリーンリーダーのユーザーが利用する場合もリンクのテキストを一度読み上げるだけですむようになります。

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

 

参考

 a要素でp要素をラップすることに違和感を感じる方もいらっしゃるかもしれませんが、HTML5からa要素はp要素やdiv要素のようなブロック要素に対しても用いることができるようになりました。

参考

 HTML5というと、対応していないブラウザが・・・、つまり、IE7とIE8への対応が問題となりそうですが、ブロック要素に対するリンクはIE7とIE8でも対応しているようであまり気にしなくてもよさそうです。

関連エントリ

ウェブアクセシビリティガイドラインについて
代替テキスト
リンクのはり方
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 実装方法集

関連エントリ

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

ウェブアクセシビリティガイドラインWCAG 2.0とJIS X8341-3:2010に関する整理

 ウェブアクセシビリティを考慮する場合、、ガイドラインであるW3CのWCAG2.0と日本のJIS X8341-3:2010に対する理解が重要になってきます。この2つのドキュメントの位置づけと読み方を中心にまとめました。

 なお、これから言及するドキュメントに日本語訳がある場合で、特に断りのない場合は財団法人日本規格協会もしくはウェブアクセシビリティ基盤委員会による日本語訳です。 

Web Content Accessibility Guidelines (WCAG) 2.0の概要

 Web Content Accessibility Guidelines (WCAG) はW3Cが策定したウェブコンテンツアクセシビリティのガイドラインで、WCAG2.0が2008年にW3C勧告になっています(最初のWCAG 1.0は1999年にW3C勧告として公開)。

 そして、WCAG2.0は先日、国際規格(ISO/IEC 40500:2012)にもなりました(中身はWCAG2.0と同じ)。

 WCAG2.0はW3Cの規格文書であり、コロコロとその内容を変更するわけにはいきません。長期的な使用に耐えうるよう技術非依存な形で抽象的に記述されており、具体的な意図や技術などについては、以下の関連文書を参照するようになっています。

 つまり、WCAG2.0を理解するためには、WCAG2.0だけではなく、上の関連文書も参照する必要があるのです。 

JIS X8341-3:2010とWCAG2.0の関係

 日本のウェブコンテンツアクセシビリティについて規定した最新の規格はJIS X8341-3:2010(高齢者・障害者等配慮設計指針-情報通信における機器,ソフトウェア及びサービス-第3部:ウェブコンテンツ)です。2004年に発表されたJIS X8341-3:2004を見直し、WCAG2.0の成果を取り込んで2010年に発表されました。

 なお、閲覧だけなら日本工業標準調査会のウェブサイトから無料で可能です。

 JIS X8341-3:2010 は「箇条7 ウェブコンテンツに関する要件」にWCAG 2.0 ガイドラインをほぼそのまま取り込む形になっています。

例: WCAG 2.0の1.4.8 とJIS X8341-3:2010の7.1.4.8
 章節の関係も維持されている(WCAG 2.0の「1.4.8」がJIS X8341-3:2010の「7.1.4.8」に)

○WCAG 2.0の”1.4.8 Visual Presentation”

1.4.8 Visual Presentation

For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)
Foreground and background colors can be selected by the user.
Width is no more than 80 characters or glyphs (40 if CJK).
Text is not justified (aligned to both the left and the right margins).
(以下、略)

 

○JIS X8341-3:2010の「7.1.4.8 視覚的な表現に関する達成基準」

7.1.4.8 視覚的な表現に関する達成基準

テキストブロック(テキストの一文よりも長いもの)の視覚的な表現には、次を実現するメカニズムを提供しなければならない。
a) 利用者が前景色と背景色を選択できる。
b) 1行の長さを、半角文字(英数字以外も含む。)で80字以内(日本語、中国語及び韓国語の場合は、40字以内。)収めることがができる。
c) テキストが、均等割付けされていない「両端そろ(揃)えではない。」。
(以下 略)
注記 この達成基準は、等級AAAの達成基準である。

  
  つまり・・

  • JIS X8341-3:2010の基準に従うことで、WCAG2.0に従うことになり、さらにWCAG2.0を国際規格化したISO/IEC 40500:2012に従うことにもなる。
  • JIS X8341-3:2010を理解するためには、上述のWCAG2.0の関連文書を読む必要がある。

     ということになります。

     なお、JIS X8341-3:2010にあって、WCAG2.0にないものは、「箇条6 ウェブアクセシビリティの確保・向上に関する要件」と「箇条8 試験方法」あたりのようです。
     

    JIS X8341-3:2010(=WCAG2.0)の達成基準

     JIS X8341-3:2010「箇条7 ウェブコンテンツに関する要件」の各要件には、やさしいほうから

    • 等級A
    • 等級AA
    • 等級AAA

    の三段階の達成基準が設けられています(WCAG2.0と同じ)。  

     各機関、団体は達成基準のいずれかの等級の要件をどの程度を満たすかを目標として設定します。設定した目標はウェブサイト上で公開することが推奨されています。そういえば、最近、自治体、企業のウェブサイトで以下のようなページを見かけるようになりました。

     ウェブサイトを外部の企業に発注する場合、仕様書に

    JIS X8341-3:2010 に対応する

     
    と書くのではなく、ウェブアクセシビリティ基盤委員会が公開する「JIS X 8341-3:2010 対応発注ガイドライン 2012年8月版」にあるように、

    JIS X 8341-3:2010の等級Aに準拠すること。
    本仕様書における「準拠」という表記は、情報通信アクセス協議会ウェブアクセシビリティ基盤委員会「ウェブコンテンツのJIS X 8341-3:2010 対応度表記ガイドライン 第1版 – 2010年8月20日」で定められた表記による。
    (http://waic.jp/docs/jis2010-compliance-guidelines/index.html)

     
    という書き方が求められます。

     なお、等級AAAの要件に適合、もしくは準拠することを目標とすることは、コンテンツによっては等級AAAを完全に満たすことができないため、「推奨しない」とWCAG2.0やみんなの公共サイト運用モデル改定版(2010年度)に書かれてあったりしています。まずは等級A、等級AAの達成基準に適合、準拠することを目指すのが現実的なのでしょう。

     
     

    WCAG2.0とJIS X8341-3:2010が対象とするウェブコンテンツとは

     WCAG2.0とJIS X8341-3:2010の対象は、ウェブサイトではなく、ウェブコンテンツ(Web技術によって作成されたコンテンツ)であり、ウェブサイトだけではありません。EPUBなどの電子書籍フォーマットなどもその対象になるかと思います。

    ウェブコンテンツとは、ウェブブラウザ、支援技術などのユーザーエージェントによって利用者に伝達されるあらゆる情報及び感覚的な体験を指し、例えば、ウェブアプリケーション、ウェブシステム、携帯端末などを用いて利用されるコンテンツ、インターネット、イントラネット、CD-ROMなどの記録媒体を介して配布されるウェブコンテンツ技術を用いて制作された電子文書、ウェブブラウザを用いて操作する機器などに適用する。
    from JIS X8341-3:2010「1.適用範囲」

     
     Web技術はその汎用性の高さから、電子文書のフォーマットやアプリケーションのGUI部分、家電などなど、その利用される範囲はさらに拡大していくものと思われます。それはWCAG2.0とJIS X8341-3:2010の適用範囲が今後拡大していくことを意味しますので、ガイドラインに対するより深い理解が求められることになります。Webに慣れていない業種にとっては大変なことではありますが、アクセシリビリティガイドラインの標準化がWebを超えて進むことになれば、よいことのほうが多いような気がします。
     
     

    (補足)HTML5の仕様 ※2013/1/3追記

     ウェブアクセシビリティを考慮する場合には、W3Cが規定するウェブに関する各種仕様、特にHTMLの仕様は参照する必要があります。

     HTMLの仕様には各要素・各属性にどのように記述するべきかが記述されていますので、img属性のalt属性には何に記述するべきか迷った場合などに参考になるはずです。HTMLもバージョンごとに要素や属性の定義が変化していますので、準拠するHTMLのバージョンの仕様を参照しましょう。すでにHTML5の仕様が勧告候補になっています。img要素など既存の要素の定義もかなり見直されているようですので、HTML5に準拠する場合は注意が必要です。

     

    参考文献

    • ウェブアクセシビリティ基盤委員会(WAIC)
      このウェブサイトで公開されている各種ドキュメント類はほぼ全て必読です(私自身、まだ全部読んだわけではないのですが)。
    • みんなの公共サイト運用モデル改定版(2010年度)
      公的機関のホームページをJIS X 8341-3:2010に準じてアクセシブルにするためにやるべきこと、その手順や段取りなどが示されています。
    • 『Webアクセシビリティ完全ガイド―2010年改正JIS規格対応』(アライド・ブレインズ編、日経BP、2010年)
      現時点では唯一のJIS X 8341-3:2010の解説書です。JIS X 8341-3:2010を理解しようと思うなら必読ですが、これだけは充分ではないので、次は、もしくは最初から”Understanding WCAG 2.0 (日本語訳)”を読むとよいと思います。
    • 『JISハンドブック 38 高齢者・障害者等[アクセシブルデザイン]』
       アクセシブルデザインに関する規格がまとめられたJISハンドブックです。JIS X 8341は高齢者・障害者配慮設計指針(アクセシブルデザイン)分野における情報通信関係の規格でウェブコンテンツはその枝番3がふられています。JIS X 8341-3:2010の規格票単体を購入することも可能ですが、JIS X 8341-3:2010単体で3,150円、 JISハンドブックは、もろもろの規格が収録されて8,085円ですので、アクセシブルデザインに関係するその他の規格も参照したい場合はハンドブックがお得です(→収録規格[PDF]

      【参考】高齢者・障害者等配慮設計指針-情報通信における機器,ソフトウェア及びサービス(JISX8341)
        JISX8341-1 第1部:共通指針
        JISX8341-2 第2部:情報処理装置
        JISX8341-3 第3部:ウェブコンテンツ
        JISX8341-4 第4部:電気通信機器
        JISX8341-5 第5部:事務機器
        JISX8341-7 第7部:アクセシビリティ設定

     

    関連エントリ

    代替テキスト
    リンクのはり方
    11月 25

    W3CのWebアクセシビリティに関するオンラインシンポジウム "Easy-to-Read on the Web" (日本時間12/4 0:00-)

     W3CがWebアクセシビリティに関するオンラインシンポジウム “Easy-to-Read on the Web”を開催するそうです。
     
     「いろいろな分野の研究者がいろいろな角度やレイヤーでアクセシビリティについて研究を進め、いろいろなガイドラインやツールを作ってきたけど、みんなあつまって議論しようぜ!なっ!」という趣旨のようです。

    ・概要

     シンポジウムの概要は以下の通り。
    名称:Easy-to-Read on the Web Online Symposium
    主催: W3C/WAI Research and Development Working Group (RDWG)
    時間:12/3 15:00-18:00(UTC) ※日本時間で12/4 00:00-03:00
    参加無料。登録は11/28まで(もしくは申し込み上限に達するまで)。
    参加方法: メールによる事前質問、電話会議、ライブキャプショニング(テキストによる実況?)、チャット
    URL: http://www.w3.org/WAI/RD/2012/easy-to-read/

     参加者にはシンポジウムが開始される前が事前に報告書が配布されます。開始する前に読んでおけということです。君は限られた枠に入っているのだから、積極的に参加してねという雰囲気で「UST中継みよっかな」という気分で参加するとはポカーンとしてしまうかもしれません。

     日本からだとなかなか参加しづらい時間帯ではありますが、(そして、私はおそらく参加しませんが)個人的になかなかなツボなシンポジウムなので紹介してみました。

    ※2012/11/29追記
     上の締め切りは電話会議参加の締め切りのようで、ライブキャプショニング(テキストによる実況?)、チャットによる参加は登録不要とのことです。
     
    すでに終了しましたが、以下のオンラインシンポジウムもおもしろそうでした。

    Text Customization for Readability Online Symposium 19 November 2012

    ・アジェンダ(2012/11/29追記)

     アジェンダは以下の通り(時刻はUTC)。

    Time: 15:00-18:00 UTC (times in different locations).

    1. Introduction to topic and symposium (15:00 – 15:10)
    2. Easy-to-Read Guidelines and impact on WCAG 2.0 (15:10 – 15:35)
      1. What are the key aspects of Easy-to-Read that must / should / “would be nice to have” added to WCAG 2.0 – where to draw the line.
      2. How to value the chances to implement a) Plain Language and b) Easy-to-Read in everyday web design processes and at what level should they be integrated into WCAG 2.0?
      3. Transferability of Easy-to-Read guidelines, concepts and tools between different languages and cultural contexts?
    3. Tools for Easy-to-Read (15.35 – 16.25)
      1. Based on research and experiences,
        • How to make WCAG 2.0 more concisely related to Easy-to-Read?
        • How to formulate guidelines which can be followed and implemented efficiently supported by tools?
      2. Are tools to support Easy-to-Read and Plain Language in practice sufficient in terms of a) covering areas and b) intended user groups?
      3. Do tools support transferability into other languages, cultural contexts and application scenarios (e.g. legal, medical, technical, … information)?
    4. Workflow, Process and Services of Easy-to-Read (16.25 – 16.50)
      1. What sets of guidelines are applied predominantly on the web: Easy-to-Read, Plain Language or others?
      2. Is there a need for transfer in other languages and cultural contexts and to build up Easy-to-Read test corpora?
      3. Is there a defined workflow for Easy-to-Read, would it be useful and how should it be designed?
    5. Short Break (16:50 – 17:00)
    6. Next steps and conclusions – Further questions and answers to the panel with input from the symposium participants (17:00-18:00)

    ・事前配布される報告書(とそのアブストラクト)

     事前配布される報告書の一覧とそのアブストラクトが公開されています。

    Easy-to-Read Guidelines and Impact on WCAG 2.0

    Tools for Easy-to-Read:

    Workflow, Process and Services of Easy-to-Read:

    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

    8月 23

    DAISY4からEPUB3への橋渡し役、DAISY Pipeline 2

     先のエントリで紹介したように、DAISY4こと、ANSI/NISO Z39.98-2012の仕様が先日正式に公開されました(以下、ANSI/NISO Z39.98-2012をDAISY4)。これはいわゆる中間(交換)フォーマットの仕様で、そのまま利用者が読書をする目的のフォーマットではありませんので、利用者が読書に利用するためにはEPUB、DAISYなどの配布フォーマットに変換する必要があります。そのDAISY4と配布フォーマットの間を橋渡しをする役目を担うのがDAISY Pipeline 2です。

    DAISY Pipeline2
    http://www.daisy.org/pipeline2/

    (河村 宏氏の講演「DAISYの新時代―EPUB3を使って自分らしい知識のスタイルを選ぶ」より)

     今回は、DAISY4と並んで重要である配布フォーマットへの変換ツール、DAISY Pipeline2をその使用方法を含めて紹介します。なお、このエントリを書いている2012年8月22日時点で2012年7月3日に公開された2.1.3beta版が最新となっていますので、この2.1.3beta版を中心に話を進めていきます。

    1.出入力フォーマット

     現時点でDAISY Pipeline 2.1.3betaで変換出来るフォーマットは主に以下の通りです。上では、DAISY4を起点にと、紹介しましたが、DAISY2.02などからもEPUB3に変換することができます。

    • DAISY2.02 → EPUB3
    • DTBook(DAISY3のXMLドキュメント) → EPUB3
    • DTBook(DAISY3のXMLドキュメント) → DAISY4 XML
    • DAISY4 XML → EPUB3

     現時点では、DAISY3、DAISY4については、出入力ともそれぞれのコンテンツファイル部分(DAISY3、DAISY4という器のなかに入っているコンテンツ本体)のみの対応になっているようです。

    将来的に以下のように出入力フォーマットとしてDAISY3、DAISY4に対応していく必要があります。

    • DAISY3 → EPUB3
    • DASIY3 → DAISY4
    • DAISY4 → EPUB3

      DAISY3→EPUB3は、2012年6月以降の開発スケジュールに組み込まれています。それ以外のDAISY4→EPUB3、DASIY3→DAISY4はロードマップには掲載されていませんが、”ZedAI to EPUB 3“のLimitationの行間を読むといずれ対応するのではないかと思います。
     
     その他、ドキュメントで確認できた範囲では今後、以下の変換に対応できるようにするとのことです。

    • Word/ODT → EPUB3
    • HTML5 → EPUB3
    • DAISY4 → PEF(点字)

      点字とTTSについては、WGが立ち上がって議論が進められている(いた?)ようです。これは期待したいですね。

     点字
    Pipeline 2 Working Group: Braille Production
    Braille WGのまとめた要件、議事録など
     
     TTS
    Pipeline 2 Working Group: TTS-based Production
    TTS WGのまとめた要件、議事録など

    2. インターフェイス

     DAISY Pipeline2で提供されているのは、現時点ではCI版のみです(Pipleline1はすでにGUI版の提供あり)。ローカルで実行する場合は、Windowsならコマンドプロンプト、Mac OS、Linuxならばターミナルを使用しましょう。なお、開発ロードマップによると、GUI版も2012年12月に公開される予定とのことです。
     
     また、これはユーザーというよりも開発者向けの話になりますが、開発中であるものの、Web UIとしてWebサービスとして展開することも可能なようです。
    DAISY Pipeline 2 Web UI

    3.DAISY Pipeline 2を使う

     
     簡単ですが、実際に使用法を紹介します。

    3.1. 対応OS

     Windows/Mac OSX/Linux

    3.2. ダウンロード

     以下でダウンロードできます。
    Downloads – daisy-pipeline

    3.3. インストール・実行環境

     とくにインストールは必要ありません。解凍したフォルダを作業しやすい適当なディレクトリに置いてください。

     ただし、プログラムの実行にはRubyとJavaを実行できる環境が必要です。詳細はREADME.txtもしくは以下を参照してください。Mac OSならば、RubyもJavaもすでにはいっているはずです。

    Installing the Pipeline2

     

    3.4. DAISY AI(DAISY4 Book Profile)を変換してEPUB3を生成してみる

     まずはDASIY Pipeline2の実行の基本から。README.txtに記載のあるとおり、カレントディレクトリをcliディレクトリに変更して実行します。

     
       
     では、サンプルファイルとしてついている以下のDAISY4のコンテンツファイル、alice.xmlをEPUB3に変換してみます。

      コマンドの構文は以下です。

    #Windows
     cli/dp2.exe command [option]
    
    #Mac OS/Linux
     cli/dp2 command [option] 
     
    

     

      今回は私はMac OS上で実行して、EPUB3に変換したのでコマンドは以下のようになります。

     
     $ cli/dp2 zedai-to-epub3 --i-source samples/zedai/alice.xml --x-output-dir  samples/output 
     
    

     上のコマンドを分解すると以下のようになります。

    • cli/dp2: アプリケーションの指定。Windowsなら cli/dp2.exe
    • zedai-to-epub3: zedaiからepub3を生成を命令するコマンド
    • -i-source:入力ファイルを指定するオプション。今回は”samples/zedai/alice.xml”と指定。
    • –x-output-dir:変換して出力するEPUB3の置き場所を指定するオプション。今回は”samples/output”ディレクトリ下に出力するように指定。

    実行すると以下のようにソースファイルからうねうねとEPUB3へ変換していってくれます。

     
     $ cli/dp2 zedai-to-epub3 --i-source samples/zedai/alice.xml --x-output-dir samples/output
    [DP2] Waiting for the WS to come up
    [DP2] The daisy pipeline 2 WS is up!
    [DP2] Job with id b86104ce-30c8-4527-936d-e43e6969e66b submitted to the server
    [WS] INFO(1) - Message:writing in-memory document to file:/Users/hogehoge/daisy-pipeline/samples/output/epub/Content/alice-1.xhtml
    [WS] INFO(2) - Message:writing in-memory document to file:/Users/hogehoge/daisy-pipeline/samples/output/epub/Content/alice-2.xhtml
              ・
              ・
              ・ 
    [WS] INFO(5) - Message:copying disk file to file:/Users/hogehoge/daisy-
    [WS] INFO(13) - Message:copying disk file to file:/Users/hogehoge/daisy-pipeline/samples/output/epub/Content/images/alice09a.png
    [WS] INFO(14) - Message:writing in-memory document to file:/Users/hogehoge/daisy-pipeline/samples/output/epub/Content/package.opf
    [DP2] The job b86104ce-30c8-4527-936d-e43e6969e66b has been deleted from the server
    [DP2] DONE 
     
    

     

     ”DONE”と表示されると指定したディレクトリにEPUB3ファイルとEPUB3としてパッケージ化する前の状態のファイルが生成されています。


      
     今回実行したのは、zedai-to-epub3というコマンドですが、他にも以下のようなコマンドが実行できます。

    • dtbook-to-zedai(DTBookからDASIY4のコンテンツファイルに変換)
    • daisy202-to-epub3(DAISY2.02からEPUB3に変換)
    • dtbook-to-epub3(DTBookからEPUB3へ変換)

     オプション等はヘルプコマンドや以下のページでも参照することができます。samplesディレクトリにはDAISY2.02、DTBook(DAISY3)、ZedAI(DAISY4)のサンプルファイルもありますで、興味をお持ちの方はぜひお試しください。
    Scripts — Short description of available scripts with links to each script

     なお、最後になりますが、以下のワークショップのスライド資料も参考になります。
    Pipeline 2 Web Service Workshop: Integration and Interoperability 
      

    関連エントリ

    EPUB 3とDAISY 4の関係
    DAISYからEPUB 3に変換する
    DAISY再生ソフト・機器のEPUB対応
    8月 16

    ANSI/NISO Z39.98-2012 (DAISY4) の読み方指南である"1.3 Overview"の 日本語訳

    DAISY4こと、ANSI/NISO Z39.98-2012の仕様がついに正式に公開されました。

    ANSI/NISO Z39.98-2012 Authoring and Interchange Framework for Adaptive XML Publishing Specification
    http://www.daisy.org/z3998/2012/z3998-2012.html
    次世代DAISY規格(ANSI/NISO Z39.98-2012)が公表 | カレントアウェアネス・ポータル

    この仕様の1章3節の”Overview”がこの仕様を概観し、その読み方を指南するガイドラインになっています。読解の一助になればと”1.3 Overview”を日本語に訳してみました(以下)。あくまで非公式の翻訳ですので、参考程度にお読みください。

    翻訳・解釈の正確性を保証しておりません。誤訳の指摘はコメント欄や Twitter(@kzakza) にお願いします。


    原文: ANSI/NISO Z39.98-2012 (DAISY4)  1.3 Overview
    http://www.daisy.org/z3998/2012/z3998-2012.html#introductionSpecOverview

    1.3 Overview(概要)

    この仕様に従うprofileを作成するには、このドキュメントの中で概説される様々な概念と技術が情報リソースを定義するためにどのように結びつけられているかを理解する必要がある。XMLテクノロジーに十分に慣れ、本仕様を一気に読み進められる者もいるだろうが、本概要では初心者と経験豊富な開発者のためにprofileがどのように構築されているのか、そして、どこで要件が定義されているのかについてのクイックレファレンスガイドを提供する。

    Z39.98-AI の仕様の核といえるものがAbstract Document Modelである。Abstract Document Modelは全てのprofile実装を通して共通するフレームワーク、そして、文法間の一貫性と予測可能性を担保するためにprofile作成者が忠実に従わなければならないハイレベルのルールを導入する。Abstract Document Modelはprofileを構築するための地図のようなものであり、その概念は 4, Abstract Document Modelで十分に解説されている。

    Abstract Document Modelは抽象的な概念を強制するルールを定めることを伴うprofile作成のプロセスであるため、Abstract Document Modelを理解することは、以下のFigure 1で描かれているような本仕様のその他の部分を理解するために不可欠である。

    Overview of the Z39.98-AI profile creation process
    Figure 1: Z39.98-AIプロファイル作成プロセスの概観

    profileはZ39.98-AIの仕様の実質的な産物であり、情報リソースの構造を定義するmarkup modelsという形になる。profileを作成するためのそのルールと要件は 6, Profiles において詳述されている。

    profileはモジュール方式モデルに基づいている。それによって、component definitions(構成要素定義) がZ39.98-AIの複数のprofileに渡って再利用できるようになり、その他の工業規格の文法を取り入れることができるようになっている。本仕様の次のセクションでは以下のようにそれらの構造における様々なパーツについて紹介する。

    • 5, Modules– moduleは意味論的にかつ/または構造的に自身を示す特質を通してリンクされた要素と属性のセットである。moduleはprofileが作成され、moduleのcomponent(構成要素)が新しい文法を構成する構成単位になった時に有効化される。
    • 5.6, Core modules– core moduleは複数のprofileに渡る構成要素の再利用を推奨するためにZ39.98-AI ワーキンググループによって開発されたmoduleのセットである。
    • 7, Features– 縮小図であるprofileと高度に専門化したmoduleの間をとったようなもので、featureは非常に特殊な構造(例えば、MathML、ルビなど)を表現するために複雑なマークアップを提供する。featureはZ39.98-AIのドキュメント類の間で専門化したマークアップの一貫性を担保し、Z39.98-AIのprofileが適切に工業規格と足並みを揃えていることを担保する助けとなる。

    RDFはドキュメントのメタデータの表現と要素が持つ意味の意味論的変化(semantic inflection)のためのフレームワークによって提供される第一の手段である。profile作成者はデータに注釈をつけるために他の方法を使用するかもしれないが、 本仕様に強い結びつきのあるRDF vocabularies(RDF語彙) の使用が推奨されている。利用可能な要素と語彙を採用する方法に関する情報は11, RDF vocabulariesで参照することができる。

    完成したprofileは用法とその他のドキュメントに加えスキーマファイル、RDF語彙、付加的な散文制限のような異なる様々なリソースから構成されている。profileの作成はidentity URIをprofileに割り当てる行為である(6.3.1, Profile identity URIを参照せよ)。identity URIが示す場所でリソースを一覧し、その取得する方法に関するさらなる情報を提供するresource directory ドキュメントが利用できる。resource directoryとドキュメントの作成方法に関する完全な情報は10, Resource directoriesで参照することができる。

    本仕様はドキュメントの作成の際に有効な一般に利用可能にしたprofileのカタログも含んでいる(Appendix A, Profile, feature, and vocabulary catalogs で利用できる)。作成者はこれらのprofileを使用することが必須とされているわけではないが、これらのprofileはその採用を推奨するため幅広く利用されるにたり得るものとして設計された。これらのprofileは開発者や本仕様の実質的な表現を探す個人を対象にした本仕様に準拠した実装を表現している。

    本仕様は特にドキュメント作成者を対象にしたものではないが、ドキュメントを識別するためにもつことが必須になっているメタデータに加え、ドキュメントが適合するprofileの指定法、使用されるfeatureなどドキュメント作成の全般的な性質に関する情報を記載している。その情報は8, Documentsで参照することができる。

    本仕様は Open Container Format [OCF]をベースとしたパッケージフォーマットも取り入れており、Z39.98-AI document setを構成するXML、イメージ、その他のローカルに置かれたリソースをまとめるために利用されるかもしれない。これらのファイルの交換を容易にするためにこのコンテナフォーマットのMIME type [RFC2046] も指定している。その情報は9, ContainerAppendix C, Media type registrationで参照することができる。

    プロセシングエージエント(訳者注:Z39.98-AIドキュメントを処理するアプリケーション 参照 processing agent)の開発者は上で概説した全てのトピックを充分に理解することに加え、自分が作成するアプリケーションが12.2, Processing agent conformance definitionで詳述されている適合性要件を満たすことも担保しなくてはならない。