アクセシビリティに配慮した顔文字、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_ さんの以下のブログをご参照ください。

関連エントリ

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

 

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

 代替テキストといえば、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ブロック進んだところで左折。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 実装方法集

関連エントリ

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

代替テキスト

リンクのはり方

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