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

 先のエントリですべての非テキストコンテンツに対して非テキストコンテンツと同じ目的及び情報を持つ代替テキストを提供することは、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でも対応しているようであまり気にしなくてもよさそうです。

    関連エントリ

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

    代替テキスト

    リンクのはり方

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

     代替テキストといえば、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 実装方法集

    関連エントリ

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

    代替テキスト

    リンクのはり方

    ウェブアクセシビリティガイドライン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部:アクセシビリティ設定

       

      関連エントリ

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