カテゴリー: ウェブアクセシビリティ

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

kzakza

　顔文字、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_ さんの以下のブログをご参照ください。

関連エントリ

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

　

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

kzakza

　先のエントリですべての非テキストコンテンツに対して非テキストコンテンツと同じ目的及び情報を持つ代替テキストを提供することは、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）に詳しく記述されていますので、こちらも参照するべきです。

　
　

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

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

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

参考

　
　

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

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

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

参考

  • G82: 非テキストコンテンツの目的を特定する代替テキストを提供する｜WCAG 2.0 実装方法集

    • 　
    　

    (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>
<a href="http://www.yahoo.co.jp/">Yahoo! Japan</a>

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

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

Yahoo! Japan

</a>

    　

    参考

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

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

    関連エントリ

    ウェブアクセシビリティガイドラインについて

    代替テキスト

    リンクのはり方

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

    kzakza

    　代替テキストといえば、img要素のalt属性に入れるテキストとしてよく知られています。しかし、alt属性に画像の「タイトル」が記述されていることが多いような気がします（あくまで気がするだけです・・・）。代替テキストは「タイトル」ではないため、結果として「タイトル」が適切であることはありますが、代替テキストとして適切でない場合があります。かくいう私もこれまで同じことをやってしまっていまして、これではイカン！と
    　アクセシビリティに配慮した代替テキスト
    について調べてみました。ここがおかしいという箇所がありましたらぜひご指摘ください。

    代替テキストとは

    　W3Cの文書※1の言葉を借りるならば、代替テキストとは
    　　　「元の非テキストコンテンツと同じ目的及び情報を伝える」テキスト
    です。代替テキストを非テキストコンテンツと置き換えてもそのページが持つ情報が失われないことが代替テキストの要件になります。
    　置き換えても情報が失われないテキスト、と言われてもなかなかイメージしづらいですが、例えば、事例1のように文中で参照される図の代替テキストは、その図の内容を説明するテキストを提供します。

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

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

    OPDSアグリゲータがOPDSカタログを取得する流れ

    新たな電子書籍をWeb上で提供した、または内容を更新したときにOPDSカタログを更新し、OPDSアグリゲータが設置したPing Serverにその更新情報をPing送信によって伝えるのです。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ブロック進んだところで左折。Ｃ通りを南下して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 実装方法集

    関連エントリ

    ウェブアクセシビリティガイドラインについて

    代替テキスト

    リンクのはり方