WCAG 2.0 達成方法集

Skip to Content (Press Enter)

失敗例

このウェブページは、「WCAG 2.0達成方法集 : WCAG 2.0の達成方法と失敗例」における失敗例を掲載している。ウェブコンテンツ技術特有の達成方法は、「一般(General)」の達成方法に取って代わるものではない。コンテンツ制作者は適合に向けて作業する際には、「一般(General)」の達成方法とウェブコンテンツ技術特有の達成方法の双方を考慮に入れる必要がある。

ウェブコンテンツ技術特有の達成方法は、あらゆる状況で WCAG 2.0 の達成基準と適合要件を満たすコンテンツを作るために使うことができる技術を指しているわけではない。 コンテンツ制作者はその技術の限界に注意を払い、障害のある人にアクセシブルな方法でコンテンツを提供す必要がある。

達成方法についての情報は、WCAG 2.0 達成方法集のイントロダクションを参照のこと。他のウェブコンテンツ技術の達成方法一覧については、目次を参照のこと。




F1: 達成基準 1.3.2 の失敗例 - CSS で情報を配置することにより、コンテンツの意味を変えている

適用(対象)

CSS をサポートする全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

これは、コンテンツの視覚的なレイアウトを変更するのに構造的なマークアップではなく CSS が用いられていて、かつ、レイアウトの変更によってコンテンツの意味が変わってしまっているという失敗例について述べている。CSS2 の position プロパティを用いると、利用者のビューポート上のどんな位置にでもコンテンツを表示させることができる。その場合、個々のアイテムが画面上に表示される順序は、ソース文書内に登場する順序とは異なる可能性がある。しかし、支援技術は、コンテンツを正しい順序でレンダリングするために、ソースコードでの順序又はプログラムが解釈する順序を用いている。そのため、CSS によってコンテンツの順序を指定する際には、それによってプログラムで解釈される音声読み上げ順序とは異なる意味になってしまうのであれば、CSS を用いてコンテンツの視覚的な位置を指定しないようにすることが重要である。

事例

失敗例 1

次の例では、段組みのレイアウトを作成するために CSS が不適切に用いられている。また、テキストは、ブラウザの画面ではマークアップの順序とは異なる順序で視覚的に表示される。

この例では、配置される各オブジェクトに対してクラスが定義されている。スタイルシートが適用されると、テキストは 2 つの段組みで表示される。まず、「menu1」クラスの要素(製品)と「menu2」の要素(所在地)は、コラムの見出しとして表示される。そして、「電話機」「コンピューター」「ポータブルMP3プレイヤー」は、製品の下に表示され、「アイダホ」と「ウィスコンシン」は、所在地の下に表示される(アイダホとウィスコンシンの順序は、ソースコードの順序とは異なっている)。

適切な構造要素が使われていないため、スタイルシートが適用されない状況では、全てのテキストがソースの順序に則って1列に提示され、「製品 所在地 電話機 コンピューター ポータブルMP3プレイヤー ウィスコンシン アイダホ」となってしまう。

HTML のコンテンツは次の通り:

コード例:


     <div class="box">      
     <span class="menu1">製品</span>       
     <span class="menu2">所在地</span>       
     <span class="item1">電話機</span>       
     <span class="item2">コンピューター</span>       
     <span class="item3">ポータブルMP3プレイヤー</span>       
     <span class="item5">ウィスコンシン</span>       
     <span class="item4">アイダホ</span>
</div>

上記コンテンツに対するスタイルは次の通り:

コード例:


.menu1 { 
     position: absolute; 
     top: 3em; 
     left: 0em;     
     margin: 0px; 
     font-family: sans-serif;     
     font-size: 120%; 
     color: red; 
     background-color: white 
}        
.menu2 { 
     position: absolute; 
     top: 3em; 
     left: 10em;     
     margin: 0px; 
     font-family: sans-serif;     
     font-size: 120%; 
     color: red; 
     background-color: white 
}      
.item1 { 
     position: absolute; 
     top: 7em; 
     left: 0em; 
     margin: 0px 
}      
.item2 { 
     position: absolute; 
     top: 8em; 
     left: 0em; 
     margin: 0px 
}      
.item3 { 
     position: absolute; 
     top: 9em; 
     left: 0em; 
     margin: 0px 
}      
.item4 { 
     position: absolute; 
     top: 7em; 
     left: 14em; 
     margin: 0px 
}      
.item5 { 
     position: absolute; 
     top: 8em; left: 14em; 
     margin: 0px 
}      
#box { 
     position: absolute; 
     top: 5em; 
     left: 5em 
}

このコンテンツの場合は、テーブル又は定義リストのように、意味のある要素を用いたほうがよいだろう。

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

CSS を用いて配置されているコンテンツに対して:

  1. ドキュメントからスタイル情報を取り除く、又はユーザエージェントでスタイルシートの適用をオフにする。

  2. コンテンツの音声読み上げ順序が正しく、コンテンツの意味が変わっていない。

判定基準

  • 2. を満たしていなければ、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F2: 達成基準 1.3.1 の失敗例 - 適切なマークアップ又はテキストを用いずに、テキストの見た目の表現の変化を用いて情報を伝えている

適用(対象)

画像又は表現のマークアップをサポートする全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書では、何らかの意味を伝えるためのテキストの見た目の変化が、適切なセマンティックマークアップを用いずに実現されている場合に発生する不適合について解説する。この失敗例は、適切なセマンティックマークアップを用いて表されていない画像化されたテキストにも適用されるものである。

事例

失敗例 1: CSS を用いて p 要素を見出しのような見た目にする

コンテンツ制作者が、見出しの作成にあたってHTML の見出し要素のデフォルトとは異なる見た目にする目的で、p 要素に対して CSS を適用して見出しのような見た目を実現し、これを見出しとして扱っている場合。このような場合においては、適切なマークアップがされていないために支援技術がこれを見出しとして認識できない。

コード例:


<style type="text/css">
 .heading1{
        font-family: Times, serif;
        font-size:200%;
        font-weight:bold;
 }
 </style>

 <p class="heading1">はじめに</p>
 <p>この章では、この製品の詳しい使い方について
 ........
 </p>

注記: この事例で用いるべき適切な手法は、HTML の h1 要素を対象にした CSS を用いて見た目を制御する方法である。

失敗例 2: 画像化されたテキストが見出しとして用いられている際、その画像が見出しタグでマークアップされていない場合

Chapter1.gif は、20 ピクセルの Garamond フォントで表示した「Chapter 1」という文字列を画像化したものである。この場合、少なくともこの画像を見出し要素に入れる必要があるため、不適合である。よりよい手法は、このテキストを見出し要素でマークアップし、この要素に対する CSS を用いて見た目を指定する方法である。

コード例:


      <img src="Chapter1.gif" alt="Chapter 1">
 
<p>むかしむかし、ウェブの国で.....
</p>

失敗例 3: 単語やフレーズを強調するために CSS を用いて見た目を制御しているが、その強調のセマンティックを表すマークアップが行われていない場合

以下の例では、CSS の font-weight プロパティを用いて太字に変更している部分の持つ情報について、セマンティックを表すマークアップがされておらず、また明示的なテキスト情報も提供されていないため不適合となる。

以下が CSS で太字の書体を指定するためのクラスである:

コード例:


.yell {
  font-weight:bold;
  text-transform: uppercase;
}

そして以下が対応する HTML である:

コード例:

<p>
「<span class="yell">だめよ</span>、食事の前はだめだって言ったでしょ!」
ティミーが母親に 4 回アイスクリームをねだった時、彼女は苛立ってそう答えた。
 </p>

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. 画像化されたテキストについて:

    1. 画像化されたテキストが、ドキュメントの持つ構造的な情報を表すために使用されている。

    2. 適切なセマンティック構造(例: HTML の見出し)を用いて画像化されたテキストの情報が表されている。

  2. (何らかの構造的な) 情報を表すために見た目が変更されているテキストについて:

    1. 構造的な情報を表現するために、見た目が変更されているテキストがある。

    2. 見た目に加えて、適切なセマンティック構造によってテキストが表されている。

判定基準

  • 1. の a. に該当する場合は、1. の b. を満たしている。

  • 2. の a. に該当する場合は、2. の b. を満たしている。


F3: 達成基準 1.1.1 の失敗例 - 重要な情報を伝える画像を表示させるために、CSS を使用している

適用(対象)

CSS に対応しているウェブコンテンツ技術全て

これは、次の達成基準に関連する失敗例である:

解説

CSS の background-image プロパティは、HTML コード内での参照なしに、画像を CSS で文書に含める方法を提供する。CSS の background-image プロパティは装飾のために使用するものであるため、CSS で組み込まれる画像に代替テキストを付けることはできない。 テキストによる代替は、重要な情報を伝える画像を見ることのできない人にとって必須のものである。 したがって、このプロパティを重要な情報を伝える画像を追加するために使用した場合は失敗となる。この失敗は、背景画像が HTML の style 属性で宣言された場合、及び背景画像宣言がクライアントスクリプトで動的に作成された場合(下の失敗例 3: を参照)にも同様に適用される。

注記: 背景画像の中に情報を組み込むことは、読みやすくする目的で背景を変えている人や、OS のハイコントラスト・モードの利用者に対しても問題を引き起こす。これらの利用者は、代替テキストが存在しないことで背景画像に含まれている情報を失うことになる。

事例

失敗例 1:

以下の例では、コンテンツの一部として CSS によってのみ表示させられている画像が含まれている。その画像 (TopRate.png) は 180×200 ピクセルで「基準金利 年 19.3%」というテキストを含んでいる。

コード例:


CSS内: 
p#bestinterest {
  padding-left: 200px;
  background: transparent url(/images/TopRate.png) no-repeat top left;
}

上記コードの適用先:

コード例:


<p id="bestinterest">
  これ以上の金利を発見できましたか?
</p>

失敗例 2:

ある書籍販売業者は、「新刊」「限定版」「在庫あり」「在庫なし」を示すためのアイコンとして背景画像を使用している。

CSS内:

コード例:


ul#booklist li {
  padding-left: 20px;
}

ul#booklist li.new {
  background: transparent url(new.png) no-repeat top left; 
}
                            
ul#booklist li.limited {
  background: transparent url(limited.png) no-repeat top left; 
}
                            
ul#booklist li.instock {
  background: transparent url(instock.png) no-repeat top left; 
}

ul#booklist li.outstock {
  background: transparent url(outstock.png) no-repeat top left; 
}

上記コードの適用先:

コード例:


<ul id="booklist">
  <li class="new">ある書籍</li>
  <li class="instock">他の書籍</li>
  <li class="limited">オススメできない書籍</li>
  ...
  <li class="outstock">あなたの本当に欲しい書籍</li>
</ul>

失敗例 3:

失敗例 1 のコードで使用されている、同じ背景画像が HTML style 属性で宣言されている。

<p id="bestinterest" style="background: transparent url(/images/TopRate.png) no-repeat top left;" >
これ以上の金利を発見できましたか?
<p>

次のコードでは、背景画像の宣言がクライアントスクリプト内で作成されている。

<script type="text/javascript">
var newP = document.createElement('p');
var newPText = document.createTextNode('Where else would you find a better interest rate?');
newP.appendChild(newPText);
newP.style.background = 'transparent url(/images/TopRate.png) no-repeat top left';
document.body.appendChild(newP);
</script> 

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. CSS によってコンテンツに追加されているすべての画像を検査対象とする。

  2. 画像は重要な情報を伝えていない。

  3. 画像が重要な情報を伝えている場合、その情報は支援技術にも伝えられ、かつCSSによる画像が表示されない場合でも伝えられるようになっている。

判定基準

  • 2と3の両方を満たさない場合は不適合となり、コンテンツは達成基準を満たさないことになる。


F4: 達成基準 2.2.2 の失敗例 - 5 秒未満でそれを停止させるメカニズムを提供せずに、text-decoration:blink を使用している

適用(対象)

カスケーディング・スタイルシート(CSS)

これは、次の達成基準に関連する失敗例である:

ユーザエージェント及び支援技術によるサポート

F4 に関するユーザエージェントサポートノート (英語)を参照のこと。

解説

CSSでは、text-decorationプロパティにblinkという値を定義している。これを用いると、このプロパティを持つ要素のあらゆるテキストが、あらかじめ設定された間隔で点滅する。これは、利用者が中断することはできず、またユーザエージェントの環境設定によって無効にすることもできない。つまり、ウェブページが表示されている限り、点滅は続くことになる。そのため、点滅が3秒より長く続く可能性があることから、text-decoration:blinkを用いているコンテンツは達成基準を満たしていないことになる。

事例

失敗例 1

製品リストのページで、セール価格に注意を引くため、その要素をtext-decoration:blinkでスタイル指定している。利用者が点滅をコントロールできないため、このウェブページは達成基準を満たしていない。

コード例:

<p>良品<span style="text-decoration:blink">セール!たったの44,995ドル!</span></p>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. インラインでのスタイル指定、ドキュメント内のスタイルシート及びドキュメント外部のスタイルシートに、"blink" の値を持つtext-decoration プロパティがある。

  2. プロパティを用いている場合、このプロパティが定義されているセレクタによって特定されるID、クラス又は要素がドキュメント内で用いられている。

判定基準

  • 1. 及び 2. が該当すれば、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F7: 達成基準 2.2.2 の失敗例 - 例えば Java 又は Flash のようなオブジェクト又はアプレットに点滅するコンテンツがあり、5 秒よりも長く点滅するコンテンツを一時停止させるメカニズムがない

適用(対象)

オブジェクト、アプレット又はプラグインにおいて、点滅するコンテンツをサポートするウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

プラグインによってレンダリングされるコンテンツ又はアプレットに含まれているコンテンツが点滅している際、ユーザエージェントがその点滅を一時停止させることができない場合がある。 プラグイン、アプレット又はコンテンツ自体がその点滅を一時停止させるメカニズムを提供していない場合、利用者が点滅しているコンテンツを読み取れない、又は点滅によって気が散ってしまってそのページにある他のコンテンツを読むことができなくなる恐れがある。

事例

検証

チェックポイント

プラグイン又はアプレットで点滅するコンテンツのあるページに対して:

  1. コンテンツが5秒よりも長く点滅するかどうかを測定する。

  2. 点滅しているコンテンツを一時停止させる手段があるかどうかを確認する。

判定基準

  • 1.で5秒よりも長く点滅し、2.で手段がない場合、そのコンテンツは達成基準を満たしていないことになる。


F8: 達成基準 1.2.2 の失敗例 - キャプションがいくつかの発話内容又は重要な効果音を省略している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書では、キャプションを含む全てのウェブコンテンツ技術に対する失敗例について述べている。「キャプション」が(逐語的、又は要点のいずれかで)全ての発話内容、及び全ての重要な音を含んでいない場合、その「キャプション」は実質的にキャプションとはいえない。

注記:キャプションでは、読みやすくするため、また見る人に非常に速く読ませるのを強いることのないように、発話内容を簡略化することがある。これは標準的な手法であり、無効なキャプションとはならない。

事例

失敗例 1:

キャプションとはいえない字幕の事例:

  • 発話内容(簡略化した発話内容の場合もある)を含むが、重要な音についての説明がないテキスト

  • 内容の一部分の発話内容が省略されたテキスト

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. キャプションを表示させてコンテンツを見る。

  2. 全ての発話内容がキャプションで示されている。

  3. 全ての重要な音がキャプションに記述されている。

判定基準

  • 2.及び3.を満たしていない場合、この不適合の条件が適用され、そのコンテンツは達成基準及を満たしていないことになる。


F9: 達成基準 3.2.5 の失敗例 - 利用者がフォーカスをフォーム要素から他の要素へ移動させた際に状況を変化させる

適用(対象)

全般

これは、次の達成基準に関連する失敗例である:

解説

この文書では、次の要素にフォーカスを移動させることのように、フォーカスをフォーム要素から移動させた場合に状況の変化を引き起こす失敗例について述べている。

事例

失敗例 1:

順番に従って、フォームのフィールドに入力している。3 つめのフィールドから 4 つめのフィールドに移動するとき、フォームが送信されてしまった。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. フォーム要素をすべて探す。

  2. フォーム要素を順番に進んでいく。

  3. 次のフォーム要素に移動するときにフォームが送信される。

  4. 次のフォーム要素に移動するときに新しいウィンドウが開く。

  5. 次のフォーム要素に移動するときに別のスクリーンに遷移する。

判定基準

  • 3.、4.、又は 5.に該当すれば、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F10: 達成基準 2.1.2 及び 適合要件 5 の失敗例 - 利用者が一つのフォーマットの中に閉じ込められてしまうように、複数のコンテンツ・フォーマットを組み合わせている

適用(対象)

利用者がキーボードを使ってコンテンツに入ることができるが、キーボードでコンテンツから抜け出すことができない状況を作り出すコンテンツ

これは、次の達成基準に関連する失敗例である:

解説

コンテンツに複数のフォーマットが含まれている場合、そのコンテンツを利用者に正しく提示するのに、しばしば 1 つ以上のユーザエージェント又はプラグインが必要となる。例えば、XHTML、SVG、SMIL、XForms を含んだウェブページは、利用者がコンテンツと情報のやり取りを行えるように、ブラウザに 3 つもの数のプラグインを要求することがある。一部のプラグインでは、キーボードのフォーカスがプラグインで「閉じ込められ」て、キーボードのみの利用者は他のコンテンツに戻ることができないという共通の状況が発生する。

事例

  • 利用者を閉じ込めるプラグイン: 利用者が Tab キーを押してプラグインに入ると、プラグインの外のコンテンツにキーボードを使って戻ることができなくなる。元の状態に戻って、新しいウェブページにナビゲートするには、利用者はブラウザを再起動しなければならず、このプラグインのコンテンツの後に続くコンテンツへは、アクセスできない。

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. キーボードを使って、コンテンツ内を行き来する。

  2. キーボードフォーカスが「閉じ込め」られることはなく、また、ユーザエージェントを閉じたり、OS を再起動したりすることなく、キーボードフォーカスをプラグインのコンテンツの外に移動させることが可能である。

判定基準

  • キーボードフォーカスが「閉じ込められている」場合、この不適合の条件が適用され、そのコンテンツは達成基準及び適合要件 5 を満たしていないことになる。


F12: 達成基準 2.2.5 の失敗例 - 利用者の入力を保存し再認証時にその情報を回復させるメカニズムがない状態で、セッションの制限時間がある

適用(対象)

入力を送信するのに利用者のログインが必要で、しばらく操作しない期間の後にセッションを切断するサイト。

これは、次の達成基準に関連する失敗例である:

解説

通常、利用者の認証を必要とするウェブサーバーは、利用者が操作しない期間の後、セッションをタイムアウトするセッションのメカニズムを持っている。これはセキュリティ上の理由のためで、コンピュータを銀行口座振替や不正な購入などの有害な行為をする可能性がある状態のままにしておくと思われる利用者を保護するために行われることがある。障害のある利用者は、フォームに入力する時間が普通に予測される時間よりもかかることがあるため、実際はまだフォームの入力中かもしれない。再認証のとき、これまでフォームに入力したすべてのデータを含め、利用者のセッションの状態が復旧しないと、利用者はやり直さなければならなくなる。そして、そういった利用者の場合には、再びフォームを入力し終わる前に、セッションは再びタイムアウトしてしまうだろう。これは、フォームに入力するのにより多くの時間を必要とする利用者が、決してそれを完了できない状況を引き起こしてしまう。

事例

  • ログインの期限が切れた後に、利用者が認証されたサイトのフォームを送信する。フォームを送信すると、利用者は再びログインするように促され、そしていわゆるウェルカムページに連れて行かれる。データは処理されておらず、利用者はまたやり直さなければならない。

  • ログインの期限が切れた後に、利用者が認証されたサイトのフォームを送信する。フォームを送信すると、利用者は再びログインするように促され、そして、この場合、利用者が送信を試みたフォームを含むログイン前のページに戻される。しかしながら、フォームには利用者が入力したデータは残っておらず、利用者は再入力しなければならない。

検証

チェックポイント

認証が必要で、利用者の入力を収集していて、一定の時間の間何も操作がないと利用者のセッションを切断するサイトにおいて:

  1. 必要な入力をした後、セッションをタイムアウトさせ、それからフォームを送信する。

  2. 要求された場合、サーバで再認証する。

  3. タイムアウト後に送信したデータが処理されない。

判定基準

  • 3.に該当すれば、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F13: 達成基準 1.4.1 の失敗例 - 画像上の色の違いで伝えている情報が、代替テキストに含まれていない

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この達成方法の目的は、画像が色の違いを用いて情報を伝えていても、その画像のテキストによる代替がその情報を伝えていないときに生じる失敗例について述べることである。 全盲又は色弱の利用者は色の違いによって伝えられている情報を知覚することができないため、そのような利用者に対して問題を引き起こす恐れがある。

事例

  • 売上データの棒グラフが画像で提供されている。そのグラフには、営業部4名の社員の年間売上高が含まれている。その画像のテキストによる代替には、 「営業部の年間売上額を示す棒グラフ。メアリー 310万 ドル、フレッド 260 万ドル、ボブ 220 万ドル、そしてアンドリュー 340 万ドル。赤い棒は、年間のノルマを達成できなかったことを示している。」と書かれている。この代替テキストは、画像が赤色を使って伝えている情報を提供していない。 テキストによる代替では、色を説明するのではなく、誰が年間のノルマを達成できなかったのかを示すべきである。

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

コンテンツ内で、色の違いによって情報を伝えている画像すべてに対して:

  1. 色の違いによって伝えられている情報が、画像のテキストによる代替に含まれていることをチェックする。

判定基準

  • 1. を満たしていない場合、この失敗基準が適用され、そのコンテンツは達成基準を満たしていないことになる。


F14: 達成基準 1.3.3 の失敗例 - 形又は位置のみでコンテンツを特定している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この達成方法の目的は、コンテンツをその形又は位置のみによって特定すると、コンテンツの理解及び操作が困難になってしまう失敗例について述べることである。視覚的な識別又は位置のみが用いられている場合、視覚障害のある利用者は画面を見ることができないため、又は一度に画面のごく一部しか知覚できないため、そのコンテンツを見つけることが困難になることがある。また、ページのレイアウトがフォント、ウィンドウ又は画面サイズに応じて変化する場合には、コンテンツの位置が変わってしまうこともある。

事例

  • サイトの操作説明に「次のページへ行くには、右のボタンを押してください。前のページに戻るには、左のボタンを押してください」と書いてある。

  • 利用者がオンライン新聞サイトで新着記事を読んでいる。記事にはイラスト及びより多くの情報へのリンクがある。記事の文中には次のように書いてある。「この記事の続きへのリンクは、イラストの左側の関連記事欄にあります。」支援技術の利用者は、イラスト及び関連記事欄を見つけるのが困難である。考えられる解決策としては、記事の文中にリンクの一覧を含めること、記事文中に関連記事欄へのページ内リンクを提供すること、又は関連記事欄に何らかの見出しをつけて支援技術のナビゲーション機能が使えるようにして、説明文中でその見出しを示すことが挙げられる。

  • 利用者がオンライン調査のフォームに入力している。調査フォームの最後に 3 つのボタンがある。説明文には「保存せずに入力を終えるには四角いボタン、入力内容を保存するには三角のボタンを押してください。後から入力を続けることができます。フォームを送信するには円いボタンを押してください。」と書かれている。スクリーンリーダーの利用者には、どのボタンが四角形、三角形又は円形なのかを知る術がない。ボタンには、それぞれの機能を示す情報(ラベル)を付加しなければならない。

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. ウェブページ内にあるコンテンツを示しているテキスト情報がある。

  2. テキスト情報がコンテンツの形又は位置だけに依存していない。

判定基準

  • 2. で依存している場合、この失敗基準が適用され、そのコンテンツは達成基準を満たしていないことになる。


F15: 達成基準 4.1.2 の失敗例 - ウェブコンテンツ技術のアクセシビリティAPIを用いていない、又は完全には用いていないカスタム・コントロールを実装している

適用(対象)

アクセシビリティAPIをサポートする全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

アクセシブルなウェブコンテンツ技術の標準コントロールを用いる際、通常はアクセシビリティAPIを使用して、アクセシビリティAPIをサポートする方法でプログラムされている。しかし、カスタムコントロールを作成する場合には、新しく作成したコントロールがアクセシビリティAPIをサポートしているかどうかを、プログラマーが確認しなければならない。アクセシビリティAPIをサポートしていないと、支援技術は、そのコントロールが何なのか、又どのように操作できるのかが分からず、場合によっては、そのコントロールの存在すら感知しないことがある。

注記: 上記をサポートする技術である WAI-ARIA は、カスタムコントロールのロール(role)、名前(name)、値(value)、状態(states)、及びプロパティ(properties)をウェブコンテンツ技術のアクセシビリティ API を介して対応させることができる。

事例

失敗例 1

音楽プレーヤーで、音量や音色等を制御するための、引き伸ばされた音符のように見えるカスタムコントロールが使われている。プログラマーは、この新しいコントロールがアクセシビリティAPIをサポートするようにしていない。結果として、このコントロールは、支援技術から特定又は制御することができない。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

(今のところ、なし。)

検証

チェックポイント

  1. 使用しているウェブコンテンツ技術用のアクセシビリティチェッカーで確認すると(又は、チェッカーがない場合は、コードを検証するか、支援技術で動作確認をすると)、コントロールがアクセシビリティAPIをサポートしている。

判定基準

  • 1. を満たしていない場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F16: 達成基準 2.2.2 の失敗例 - 動きが不可欠ではないところにスクロールするコンテンツがあり、そのコンテンツを一時停止及び再開するメカニズムがない

適用(対象)

目で見える動きやスクロールをサポートする全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この失敗例では、動きのある又はスクロールするコンテンツを利用者が一時停止したり再開したりすることができない。この場合、ロービジョンの又は認知障害のある利用者のなかには、コンテンツを知覚できないことがある。

事例

検証

チェックポイント

動きのあるコンテンツ又はスクロールするコンテンツのあるウェブページ上で、

  1. ウェブページ又はユーザエージェントに、動きのあるコンテンツ又はスクロールするコンテンツを一時停止させるメカニズムが提供されている。

  2. 一時停止させるメカニズムを用いて、動きのあるコンテンツ又はスクロールするコンテンツを一時停止させる。

  3. 動きのあるコンテンツ又はスクロールするコンテンツが停止し、そのまま再開しない。

  4. ウェブページ又はユーザエージェントに、一時停止したコンテンツを再開させるメカニズムが提供されている。

  5. 再開させるメカニズムを用いて、コンテンツの動きを再開させる。

  6. コンテンツの動き又はスクロールが、一時停止したところから再開される

判定基準

  • 1.、3.、4.、又は 6. を満たしていない場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F19: 適合基準 1 の失敗例 - 適合していないウェブページの代替となる適合しているバージョンを利用者が見つけられる手段を提供していない

適用(対象)

適合していない元のコンテンツの代替となる WCAG 適合バージョンを提供するサイト。

これは、次の達成基準に関連する失敗例である:

解説

この達成方法に対する失敗例では、コンテンツに対して適合している代替版が提供されているにもかかわらず、利用者がそのことを知る方法、又はどこで見つけられるかを知る方法が提供されていないことについて述べている。 利用者が適合したバージョンを見つけることができないため、このようなコンテンツは、達成基準を満たしていないことになる。

事例

検証

チェックポイント

  1. 適合している代替版がある、適合していないウェブページを特定する。

  2. 適合していないウェブページは、適合している代替版へのリンクを提供している。

判定基準

  1. 2. を満たしていない場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F20: 達成基準 1.1.1 及び 達成基準 4.1.2 の失敗例 - 非テキストコンテンツの変更時に代替テキストを更新していない

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この失敗例の目的は、非テキストコンテンツが更新されているが、テキストによる代替が同時に更新されないことについて述べることである。テキストによる代替の中のテキストが、情報や機能を失なわずに非テキストコンテンツの代わりとして用いることができなくなった場合は、もはや非テキストコンテンツに対する代替テキストは意味をなさなくなる。

事例

  • 失敗例 1: 10 月の成績に更新された売上表に対して、テキストによる代替が 9 月の成績の説明となっている。

  • 失敗例 2: ホームページの絵を毎日変えているが、テキストによる代替が同時に更新されていない。

  • 失敗例 3: スクリプトを使ってページ上の画像の source 属性を定期的に更新しているが、テキストによる代替が同時に更新されていない。

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. テキストによる代替が現在表示されている非テキストコンテンツとは異なるコンテンツについて説明している。

判定基準

  • 1. を満たしている場合、テキストによる代替は現在のアイテムに追随していないため、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F22: 達成基準 3.2.5 の失敗例 - 利用者が要求していないウィンドウを開く

適用(対象)

全般

これは、次の達成基準に関連する失敗例である:

解説

利用者が期待しないときに、新しいウィンドウが開くことによる失敗例。新しいウィンドウは、利用者が閲覧又は操作している場所からフォーカスを奪ってしまう。利用者がユーザインタフェースを操作したことで、オプションダイアログのように新しいウィンドウが開くことがわかっている場合は問題にならないが、予期せずポップアップウィンドウが開いてしまう場合がには問題となる。

事例

失敗例 1:

ウェブページをナビゲートしているとき、新しいウィンドウが既存のユーザエージェントのウィンドウの前面に現れ、フォーカスが新しいウィンドウに移動する。

失敗例 2:

利用者がリンクをクリックすると、新しいウィンドウが現れる。元のリンクには新しいウィンドウを開くことを予告するテキストがない。

失敗例 3:

利用者がウェブページのボディをクリックすると新しいウィンドウが現れる。クリックしたエリアに機能があるということは全く示されていない。

失敗例 4:

ウェブページ内の装飾されてないテキストを利用者がクリックすると、新しいウィンドウが開く。ウェブページにはそのエリアに機能があるという視覚的な表示は何もない。

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. ウェブページを表示させる。

  2. 新しい(追加の)ウィンドウが開く。

  3. ウェブページ上のリンク及びボタンのような、アクションのある要素を探し出す。

  4. 各要素を操作する。

  5. 要素を操作すると新しいウィンドウが開く。

  6. ウィンドウを開かせた要素にウィンドウを開くことを示す関連づけられたテキストがある。そのテキストはリンクの中に表示されている、又は HTML の title 属性といった非表示の関連づけで利用できる。【訳注:a 要素内でアイコン画像を用いる際は、代替テキストで示されていればよい。また、title 属性の使用は推奨できない。】

判定基準

  • 2. に該当すれば、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。

  • 5. に該当して、6. を満たしていなければ、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F23: 達成基準 1.4.2 の失敗例 - 3秒よりも長く音声を再生していて、音声を停止するメカニズムを提供していない

適用(対象)

音声でのインタラクションがあるものを除く、全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書は、音声に関連する達成基準における失敗例について述べている。音声の再生が3秒以内に自動的に停止せず、その音声を停止させる方法がない場合、達成基準 1.4.2 を満たすことができない。3 秒よりも長く再生される音声には、コンテンツにその音声を停止するメカニズムがない場合、この失敗例が適用されることになる。

事例

失敗例 1

  • 絶え間なく BGM を再生しているサイト。

失敗例 2

  • 停止するまでに 3 秒よりも長く続くナレーションがあり、それを停止させるメカニズムのないサイト。

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. 自動的に再生されて3秒よりも長く続く音声を停止させる方法がウェブページにあることをチェックする。

判定基準

  • 手順 1. でその方法がない場合、そのコンテンツは達成基準 1.4.2 を満たしていないことになる。


F24: 達成基準 1.4.3、1.4.6 及び 1.4.8 の失敗例 - 背景色を指定せずに前景色を指定する(又は、前景色を指定せずに背景色を指定する)

適用(対象)

ユーザエージェントが個人のスタイルシート又は他の方法を通して前景と背景の色を制御することを可能にする全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

失明、認知障害、言語又は学習障害のある利用者は、多くの場合特定の前景色と背景色の組み合わせを好む。弱視の利用者は黒の背景に白い文字のウェブページの方がより見やすく、そしてそれぞれのユーザエージェントをこのコントラストに設定していることがある。多くのユーザエージェントでは、制作者が指定したすべてのスタイルを上書きせずに、好みの前景色または背景色に関する設定を利用者が選択できるようになっている。これにより、利用者は好ましい色の組み合わせの中でコンテンツ制作者によって色が指定されていないページを閲覧することが可能になる。

コンテンツ制作者が前景と背景の両方の色を指定しない限り、コンテンツ制作者は、コントラストの要求を満足したコントラストになっていることを保証できない。たとえば、コンテンツ制作者がテキストを灰色に指定していたら、それはユーザエージェントの設定より優先され、(ユーザエージェントによって利用者に設定された)明るい灰色の背景に(コンテンツ制作者に指定された)灰色のテキストというページが描画される。この原則は逆も成り立つ。もしコンテンツ制作者が背景を白にしていたら、コンテンツ制作者に指定された白い背景は、利用者のユーザエージェントの設定によって表現されている好みのテキストの色に似ているかもしれない。そのため、利用者にとって使用できないページに描写されてしまう。コンテンツ制作者は利用者がどのようにして好みの設定にしているかを予測できないため、コンテンツ制作者が前景色を指定していたら十分なコントラストを持つ背景色も指定すべきであり、逆もまた同様である。

前景色と背景色の両方を同じ CSS 規則上で定義する必要はない。CSS の色のプロパティは、先祖要素から引き継がれるので、前景色と背景色の両方が直接的に、又はその色が要素に対して適用される継承を通して定義されるのであればそれで十分である。

注記: 実践するにあたっては、テキストの全ての状態を含めることが重要である。例えば、テキスト、リンクテキスト、訪問済みリンクテキスト、マウスフォーカスがあたったとき及びキーボードフォーカスがあたったときのリンクテキストなど。

事例

失敗例 1: CSSで背景色のみ指定する

次の例では、背景色はCSSスタイルシートで定義されているが前景色は定義されていない。よって、この事例は達成基準を満たしていない。

コード例:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<html>
<head>
 <title>キャンバス背景の設定</title>
    <style type="text/css">

       body {background-color:white}
    </style>
  </head>
  <body>
    <p>背景は白です。</p>
  </body>
</html>

失敗例 2: CSSで前景色のみ指定する

次の例では、前景色はCSSスタイルシートで定義されているが背景色は定義されていない。よって、この事例は達成基準を満たしていない。

コード例:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<html>
<head>
 <title>キャンバス背景(←前景の間違い?)の設定</title>
    <style type="text/css">
       body {color:white}
    </style>
  </head>

  <body>
    <p>前景は白です。</p>
  </body>
</html>

失敗例 3: CSSでリンクテキストの色を指定する

次の例では、リンクテキスト(前景)の色をボディ要素で定義している。しかし背景色は定義していない。よって、この事例は達成基準を満たしていない。

コード例:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 
    "http://www.w3.org/TR/html4/strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<html>
<head>
 <title>人口動態の研究</TITLE>
 <style type="text/css">
  a:link { color: red }
  a:visited { color: maroon }
  a:active { color: fuchsia }
 </style>

</head>
<body>
  <p>... ドキュメント本文 ... <a href="foo.htm">Foo</a></p>
</body>
</html>

失敗例 4: HTML の bgcolor 属性で背景色のみ指定する

次の例では、背景色はbody要素で定義されているが前景色は定義されていない。よって、この事例は達成基準を満たしていないことになる。

HTML 4 の時点で bgcolor 属性の使用は廃止予定である、しかしこの失敗例は、この使用法がまだ一部のウェブサイトで見られるため含まれていることに注意する。

コード例:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html xmlns="http://www.w3.org/1999/xhtml">
      <html>
          <head>
              <title>人口動態に関する研究</title>
          </head>
          <body bgcolor="white">
              <p> ... ドキュメント本文 ...</p>
          </body>
  </html>

失敗例 5: HTML の text 属性を持つ前景色のみを指定する

次の例では、前景色は body 要素で定義されているが、背景色は定義されていない。したがって、この例は達成基準を満たしていない。

HTML 4の時点で text 属性の使用は廃止予定である、しかしこの失敗例は、この使用法がまだ一部のウェブサイトで見られるため含まれていることに注意する。

コード例:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<html>
<head>
 <title>人口動態に関する研究</title>

</head>
<body color="white">
  <p>... ドキュメント本文 ...</p>
</body>
</html>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. ウェブページのソースコードを見る。

  2. コンテンツ制作者が指定した前景色がある。

  3. コンテンツ制作者が指定した背景色がある。

注記 1: 色と背景色は外部のスタイルシート又は継承ルールによって、先行する一連のセレクターのあらゆるレベルで指定することができる。

注記 2: 背景色は CSS の「background-image」プロパティ又は「background」(画像の URL、例えば、'background: url("images/bg.gif")')プロパティで背景画像を用いて 指定されているかもしれない。背景画像があるとしても背景色を指定する必要がある。なぜならば利用者は ブラウザ上で画像を非表示にしているかもしれないからである。よって、背景画像と背景色をチェックする。

判定基準

2. を満たしているが 3. を満たしていない、又は、3. を満たしているが 2. を満たしていない場合、この不適合の条件が適用され、コンテンツは達成基準に不適合となる。


F25: 達成基準 2.4.2 の失敗例 - ウェブページのページタイトルがコンテンツの内容を示していない

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

これは、ウェブページにページタイトルはあるが、そのページタイトルがウェブページのコンテンツ又は目的を示していないことによる失敗例について述べている。

事例

失敗例 1

次に挙げるのは、ページタイトルとはいえない文言の例である:

  • オーサリングツールの初期設定のページタイトル。例えば、

    • "ここにHTMLドキュメントのタイトルを入れてください"

    • "無題ドキュメント"

    • "タイトルなし"

    • "無題ページ"

    • "新しいページ 1"

  • それぞれの内容を示していないファイル名。例えば、"report.html"又は"spk12.html"など。

  • 空の(又は、意味のない)テキスト

  • 埋め草又はプレースホルダーのテキスト

失敗例 2

テンプレートを用いて生成されたサイトにおいて、サイトの各ページに同じページタイトルがついている。 そのため、ページタイトルによってページの違いを見分けることができない。

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. 各ウェブページのページタイトルが、そのウェブページのコンテンツ又は目的を示している。

判定基準

  • 1.を満たしていない場合、この不適合事例が適用され、そのコンテンツは達成基準を満たしていないことになる。


F26: 達成基準 1.3.3 の失敗例 - 情報を伝えるために、グラフィカルなシンボルだけを使用している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この達成方法の目的は、グラフィカルなシンボルを用いて情報を伝えることによって、コンテンツを理解することを困難にしてしまう失敗例について述べることである。グラフィカルなシンボルには、言葉を使わないで情報を伝える、画像、画像化された文字、あるいは絵で表した又は装飾的な文字のシンボルがある。グラフィカルなシンボルの例としては、斜線の入った赤い円、"スマイリー"と呼ばれる顔文字、 あるいはチェックマーク、矢印又はその意味を持つ文字ではないその他のシンボルなどを表すグリフが挙げられる。支援技術の利用者は、そのようなグラフィカルなシンボルの意味を判断するのが困難なことがある。 グラフィカルなシンボルを用いて情報を提供する場合、ウェブコンテンツ技術の機能を用いて代替物を提供する、又はそのグラフィカルなシンボルの代替を示すことが可能な異なるメカニズムを用いるべきである。例えば、グリフの代わりに、テキストによる代替のある画像を用いることができる。

事例

失敗例 1: ステータスを示すために用いるグリフ

ショッピングカートが2つのシンプルなグリフを用いて、その商品がすぐに発送可能かどうかを示している。具体的には、チェックマークが商品の在庫があり発送可能であることを示し、"×"マークが商品は入荷待ちの状態ですぐには発送できないことを示している。このようにグリフを用いているため、支援技術の利用者は、その商品の現在のステータスを把握することができなかった。

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. ページで情報を伝えているグラフィカルなシンボルを抽出する。

  2. グラフィカルなシンボルによって伝えている情報を把握できる他の手段があるかどうかをチェックする。

判定基準

  • 2. で他の手段がない場合、この失敗基準が適用され、そのコンテンツは達成基準を満たしていないことになる。


F30: 達成基準 1.1.1 及び 達成基準 1.2.1 の失敗例 - 代替ではない代替テキストを使用している(例:ファイル名、プレースホルダー・テキストなど)

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

これは、テキストによる代替を使用している全ての達成方法に対する失敗条件について述べている。"テキストによる代替"の中のテキストを、情報又は機能を失うことなく非テキストコンテンツの代わりに使用することができない場合、事実上、非テキストコンテンツに対する代替物としては意味をなさなくなる。

事例

失敗例 1

テキストによる代替とはならないテキストの事例は次の通り:

  • 画像や絵の「テキストによる代替」の位置に埋め込まれた、" "、"スペーサー"、"画像"、"絵" といったプレースホルダーテキスト。

  • 非テキストコンテンツの情報又は機能を伝達しない、"絵 1"及び"絵 2" 、"0001"及び"0002" 又は"イントロ #1"及び"イントロ #2"といったプログラム上の参照情報

  • 10月.jpg、"グラフ.jpg" 又は "売上げ\\10月\\上位3名.jpg"といったそれ自体では有効なテキストによる代替とならないファイル名

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. テキストによる代替が実際には非テキストコンテンツに対するテキストによる代替にはなっていない。

判定基準

  • 1. を満たしてる場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F31: 達成基準 3.2.4 の失敗例 - ウェブページ一式の様々なウェブページ上にある同じ機能に対して、2つの異なるラベルを使用している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

異なるウェブページ上にある同じ機能のコンポーネントは、一貫して同じラベルが用いられているとより容易に認知されやすくなる。名称に一貫性がない場合、利用者が混乱してしまうことがある。

注記: "一貫性を保った"テキストによる代替が常に"同一のもの"であるとは限らない。例えば、次のページへのリンクになっている矢印の画像がウェブページの一番下にある。テキストによる代替は"4 ページへ"となっている。当然、これと全く同じテキストによる代替を次のウェブページで繰り返すことは適切でない。"5 ページへ"とする方が適切である。これらのテキストによる代替は同一のものではないが、一貫性を保っており、この達成基準の失敗例とはならない。

事例

失敗例 1:

同じ機能のコンポーネントに対して一貫性のないラベルを使用している例で最もよく見かけるのは、どちらも同じ機能であるのに、あるページでは「検索」という名称のボタンを使用し、別のページでは「探す」という名称のボタンを使用している場合である。

失敗例 2:

オンラインのオーサリングツールで、あるページでは「ページを保存」というボタン、別のページでは「保存」をそれぞれ同じ機能に対して使用している。

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. ウェブページ一式の中で、複数のページで繰り返し使用されている同じ機能を持つコンポーネントを探す。

  2. 1.で見つけた同じ機能の個々のコンポーネントに対して、名称が一貫して同じである。

判定基準

2.を満たしていない場合、この不適合事例が適用され、そのコンテンツは達成基準を満たしていないことになる。


F32: 達成基準 1.3.2 の失敗例 - 単語内の文字間を空けるために、スペースを使用している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書は、単語を視覚的にフォーマットするために、単語の中でスペース、タブ文字、改行文字又は行送り文字のような空白文字を用いると、それらを意味のある並びとして適切に提示するのが困難になるという失敗例について解説する。文字間を制御するために空白文字を挿入すると、単語の解釈を変えてしまうかもしれないし、それが一つの単語であるとプログラムで解釈できないようにしてしまうことがある。

頭文字語の文字間に空白文字を挿入することはこの失敗例には当たらない。空白文字が頭文字語の解釈を変えるわけではないし、むしろ理解しやすくするかもしれないからである。

単語間のスペースを利用して視覚的なフォーマットを行うことはこの失敗例には当たらない。空白文字が単語の解釈を変えることはないからである。

事例

失敗例 1: 単語の途中に空白を挿入することによる不適合

この事例では、見出しとして文字をまばらに配置するために単語の途中にスペースを置いている。スクリーンリーダーは、"Welcome" という単語としてではなく、文字を一つずつばらばらに読み上げてしまうだろう。

コード例:


      <h1>W e l c o m e</h1>

&nbsp; を用いてスペースを追加することもできるが、同様の失敗例となる:

コード例:


     <h1>H&amp;nbsp;E&amp;nbsp;L&amp;nbsp;L&amp;nbsp;O</h1>

失敗例 2: 単語の途中に入れた空白によって意味が変わってしまう

日本語においては、一つの漢字がそれぞれ意味の異なるいくつかの読み方を持っていることがある。この例では、スクリーンリーダーは空白文字があるためにこれらの文字列を一つの単語と認識できず、誤った読み方をしてしまう可能性がある。この文字列は「東京(とうきょう)」を意味しているが、スクリーンリーダーは「ひがし きょう」と読み上げてしまう。

コード例:


     <h1>東 京</h1>

失敗例 3: 縦書きのテキストを表現するために改行文字を使用している

データテーブルの行見出しセルに日本語が含まれる場合に、制作者は改行文字を使用して縦書きのテキストを表現することがよくある。しかし、単語中に改行文字があるために、スクリーンリーダーはこのような縦書き文字列にある単語を正しく読み上げることができない。次の例は「東京都(とうきょうと)」ではなく「ひがし きょう みやこ」と読み上げられてしまう。

コード例:


<table>
<caption>表1. 都道府県別一覧表</caption>
<tr>
<td></td>
<th scope="col">(見出しセル 1.)</th>
<th scope="col">(見出しセル 2.)</th>
</tr>
<tr>
<th scope="row">東<br />京<br />都</th>
<td>(データセル 1.)</td>
<td>(データセル 2.)</td>
</tr>
・・・・・・
</table>

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

文字間に標準的でない空白又は改行があるように見えるすべての単語について:

  1. コンテンツのテキストを構成する単語が空白文字又は改行を含んでいる。

判定基準

  • 1. を満たしている場合、この不適合条件が適用され、達成基準に不適合となる。


F33: 達成基準 1.3.1 及び 達成基準 1.3.2 の失敗例 - プレーン・テキストのコンテンツで、複数の段組みにするために、スペースを使用している

適用(対象)

すべてウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この達成方法の目的は、スペース、タブ、改行又はキャリッジリターン(CR)のような空白文字を用いてテキストコンテンツのデータ列を整形しようとすると、構造を正しく示すことができなくなる失敗例について述べることである。支援技術は、現在用いている自然言語の音声読み上げ順序でコンテンツを解釈するため、空白文字を用いて複数の段組を作ると、自然な音声読み上げ順序では意味を成さなくなることがある。このように、空白文字を用いてデータ列を整形すると、支援技術の利用者が理解できるように情報が提示されない。

複数の段組みを表現するために、プレーンテキストを用いるべきではない。他のレイアウトでデータを提示できるようにコンテンツを修正する必要がある。代替手段として、複数段にわたるデータを表現するときは、構造を示す要素のあるウェブコンテンツ技術を用いるとよい。

事例

失敗例 1

次の事例では、2 段組フォーマットにするために、空白文字列を用いているが、正しい使い方ではない。

コード例:


ウェブコンテンツ・アクセシビリティ     運動制限、発話困難、及びその他の障
ガイドライン 2.0(WCAG2.0)は、ウェ     害を含む様々な障害のある利用者にと
ブコンテンツをよりアクセシブルにす     って使うことができることを意味する。
るためのポイントや推奨事項を幅広く     このガイドラインに従うことによって、
カバーしている。この文書には原則、     ウェブコンテンツは高齢者を含む大多
ガイドライン、達成基準、利用者のメ     数の利用者にとっても、よりアクセシ
リット、そして事例が含まれており、     ブルなものになる。また、利用者が、
ウェブベースの情報およびアプリケー     多様な支援技術を含む実にさまざまな
ションをアクセシブルにするための要     デバイスを用いて、ウェブコンテンツ
件を定義して説明している。「アクセ     にアクセスすることができるようにも
シブル」とは、全盲及びロービジョン、    なる。 
ろう及び難聴、学習困難、認知障害、

スクリーンリーダーで読上げると、このテーブルは次のように読まれる:

  • ウェブコンテンツ・アクセシビリティ運動制限、発話困難、及びその他の障

  • ガイドライン 2.0(WCAG2.0)は、ウェ害を含む様々な障害のある利用者にと

  • ブコンテンツをよりアクセシブルにすって使うことができることを意味する。

  • るためのポイントや推奨事項を幅広くこのガイドラインに従うことによって、

  • (以下省略)

一度削除したテキストを復活させたり、固定サイズのフォントが可変サイズに変更したり、何行かに及ぶテキストをそのページに収まらないくらい文字サイズを大きく変えたりしたときは、先ほど説明したのと同じように、見た目上、間違って解釈されるという問題が起こりうる。

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. データや情報の文書が、多段組で示されている。

  2. 段組みが空白文字列を用いて情報を配置して作られている。

判定基準

  • 2. を満たしている場合、この失敗基準が適用され、そのコンテンツは達成基準を満たしていないことになる。


F34: 達成基準 1.3.1 及び 達成基準 1.3.2 の失敗例 - プレーン・テキストのコンテンツで、テーブルをフォーマットするために、スペースを使用している

適用(対象)

全てのウェブコンテンツ技術。

これは、次の達成基準に関連する失敗例である:

解説

この達成方法の目的は、テキストコンテンツ内でスペース、タブ、改行又はキャリッジリターン(CR)といった空白文字を使用してテーブルを整形すると、適切に構造を示すことができない失敗例について述べることである。 テーブルがこのような方法で作成されると、セルを見出しセルとして示すことができなくなり、見出しのセルとデータのセルを関連付けできなくなる。又はテーブルの中のセルへ直接誘導することができなくなる。

さらに、支援技術は現在の自然言語の音声読み上げ順序でコンテンツを解釈していく。視覚的なテーブルにおいて、データをレイアウトするために空白を使用すると、ドキュメントのソースの情報を自然な音声読み上げ順序で提供できなくなってしまう。このように、支援技術の利用者に対して情報が論理的な音声読み上げ順序で提示されなくなる。

プレーンテキストはテーブルのような複雑な情報を表示するのには適していない。なぜなら、テーブルの構造は知覚できないからである。テーブルの情報は見た目の書式を整える方法によって表形式の情報の関係を表現するよりは、別のウェブコンテンツ技術を使用するか又は直線的に読上げられるように提示する(プレーンテキストでテーブルの情報を表現するを参照)。

事例

失敗例 1

次の事例では、空白を不適切に使ってメニューを見かけ上のテーブル形式にしている。

コード例:


メニュー
     朝食        昼食       ディナー

月曜   目玉焼き2つ     トマトスープ   ガーデンサラダ
     ベーコン      ハンバーガー   フライドチキン
     トースト      オニオンリング  緑豆
     オートミール    マッシュポテト

火曜   ホットケーキ    野菜スープ    シーザーサラダ
     ソーセージ     ホットドッグ   ミートボールスパゲティ
     オレンジジュース  ポテトサラダ   イタリアンブレッド
               ブラウニー    アイスクリーム

この表は、スクリーンリーダでは次のように解釈され、読上げられる。

  • メニュー

  • 朝食 昼食 ディナー

  • 月曜 目玉焼き2つ トマトスープ ガーデンサラダ

  • ベーコン ハンバーガー フライドチキン

  • トースト オニオンリング 緑豆

  • オートミール クッキー マッシュポテト

このテーブルには、支援技術がこのメニューをテーブルとして特定するための構造がないため、この音声読み上げ順序では意味が伝わらない。テキストが折り返す、又は固定フォントから可変フォントに変更になる、又はページ内で行が収まらないほど文字サイズを拡大するといった場合、視覚表現で同様の問題が発生すると考えられる。

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. 見かけ上のテーブルがドキュメントにある。

  2. 空白文字を使ってデータをテーブル形式にレイアウトしてテーブルが作られている。

判定基準

  • 2. を満たしていれば、この不適合基準が適用され、コンテンツはこれらの達成基準を満たさない。


F36: 達成基準 3.2.2 の失敗例 - フォームの最後のコントロールに入力すると、自動的にフォームを送信し、事前の予告なしに新しいコンテンツを提示している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

利用者がすべてのフィールドに入力し終わるか、最後のフィールドからフォーカスが外れると、自動的に送信されるように設計されたフォームが多くある。この方法には二つの問題がある。まず、障害のある利用者で前後関係の情報を必要としている人が、フォームの記入方法や、他のテキストに移動するためにフィールドからフォーカスをはずしてしまい、意図せずに送信してしまう場合がある。もう一つは、いくつかのフォームの要素において、それぞれの項目の値がキーボードで移動している間に変化してしまい、誤って送信してしまうことである。送信ボタン及び Enter キーによる標準的なフォームのふるまいに依存している方がよい。

事例

失敗例 1

この失敗例では、利用者が3つのフィールドで構成される電話番号のフォームの最後のフィールドから離れたときにフォームを送信する。フォームは、利用者が編集を終えてフィールドから離れたときに、たとえタブ順序で前に戻ったとしても送信される。開発者はフォームを送信するためにこの達成方法を使用すべきではなく、送信ボタンやフォームのデフォルトのふるまいである、利用者がテキストフィールドで Enter キーを押したときに送信されるようにすべきである。

コード例:

 
<form method="get" id="form1">
  <input type="text" name="text1" size="3" maxlength="3"> - 
  <input type="text" name="text2" size="3" maxlength="3"> - 
  <input type="text" name="text3" size="4" maxlength="4" onchange="form1.submit();">
</form>

失敗例 2

この失敗例は、利用者がメニューから項目を選択すると、事前の警告なくフォームを送信する。メニューから項目が選択されると、直ちにフォームが送信される。キーボード利用者は、最初のメニュー項目を超えて移動することができない。全盲の利用者や手の震えがある利用者は、ドロップダウンメニューから項目を選ぶときに間違いを起こしやすく、修正する前に間違った行き先に連れて行かれてしまう。

コード例:

 
<form method="get" id="form2">
 <input type="text" name="text1">
  <select name="select1" onchange="form2.submit();">
    <option>1</option>
    <option>2</option>
    <option>3</option>
    <option>4</option>
  </select>
</form>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. ページ上のすべてのフィールドに、上から順にデータを入力する。

  2. 最後のフィールドにデータを入力して抜け出す(タブで抜ける)。

  3. 最後のフィールドから離れることで、状況の変化が起こるかを確認する。

判定基準

  • もしステップ 3 を満たしている場合、この不適合条件が適用され、コンテンツは達成基準に不適合となる。


F37: 達成基準 3.2.2 の失敗例 - ラジオボタン、チェックボックス、又はセレクトリストを変更すると、事前の予告なしに新しいウィンドウを開いている

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

ユーザエージェント及び支援技術によるサポート

F37 に関するユーザエージェントサポートノート (英語)を参照のこと。

解説

この文書では、ラジオボタン、チェックボックス、またはセレクトリスト内の項目の選択を変更すると、新しいウィンドウが開く失敗例について解説する。要素が選択されたとき、コンテキストの変更(フォームの送信、新しいページを開く、新しいウィンドウ)を引き起こす input 要素を生成するために、スクリプトを使用することができる。 開発者は代わりに送信ボタンを使用する(G80: 状況の変化を開始する実行ボタンを提供するを参照)、又はそこで起こる動作を明確に示す必要がある。

事例

失敗例 1

下記の例では、送信ボタンを使うのではなく、ラジオボタンが選択されたときにフォームが処理されるため、達成基準を満たしていない。

コード例:


<script type="text/JavaScript"> 
  function goToMirror(theInput) {
   var mirrorSite = "http://download." + theInput.value + "/"; 
   window.open(mirrorSite); 
  }
</script>
  …
<form name="mirror_form" id="mirror_form" action="" method="get">
       <p>ミラーダウンロードサイトを選択して下さい:</p> 
       <p> 
       <input type="radio" onclick="goToMirror(this);" name="mirror" 
       id="mirror_belnet" value="belnet.be" /> 
       <label for="mirror_belnet">belnet (<abbr>BE</abbr>)</label><br /> 
       <input type="radio" onclick="goToMirror(this);" name="mirror" 
       id="mirror_surfnet" value="surfnet.nl" /> 
       <label for="mirror_surfnet">surfnet (<abbr>NL</abbr>)</label><br /> 
       <input type="radio" onclick="goToMirror(this);" name="mirror" 
       id="mirror_puzzle" value="puzzle.ch" /> 
       <label for="mirror_puzzle">puzzle (<abbr>CH</abbr>)</label><br /> 
       <input type="radio" onclick="goToMirror(this);" name="mirror" 
       id="mirror_voxel" value="voxel.com" /> 
       <label for="mirror_voxel">voxel (<abbr>US</abbr>)</label><br /> 
       </p> 
</form>

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. ページの中からフォームを探す。

  2. ラジオボタン、チェックボックス、またはセレクトリストの項目であるフォームコントロールそれぞれに、コントロールの選択を変更すると、新しいウィンドウが立ち上がるかどうかを確認する。

  3. ステップ2の結果として生成されたそれぞれの新しいウィンドウが、事前に利用者に警告されているか確認する。

判定基準

3. を満たしていない場合、この不適合条件が適用され、コンテンツは達成基準に不適合となる。


F38: 達成基準 1.1.1 の失敗例 - HTML で装飾を目的にして用いられている非テキストコンテンツの alt 属性を省略している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

これは、支援技術によって無視されるべき画像のテキストによる代替に対する失敗条件を記述する。alt 属性が全くない場合、支援技術は非テキストコンテンツを無視することができない。この達成基準の失敗を回避するには、alt 属性を指定し、空値(alt="")を指定しなければならない。

これは、支援技術(AT)によって無視されるべき画像のためのテキストによる代替の失敗条件を記述する。画像が属性role="presentation"を持つ場合、テキストによる代替はATによって無視される。ただし、role="presentation"を持たない場合、かつ alt 属性が全くない場合は、支援技術は画像を無視することはできない。AT によって無視される必要のある装飾画像の場合、この達成基準の失敗を避けるために、role="presentation"を使用するか、又は空値(alt="")の値を持つ alt 属性を提供しなければならない。

事例

  • alt 属性がなく、role 属性がない装飾画像

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

純粋に装飾的なコンテンツとして使用される img 要素の場合:

  1. 要素に role 属性がないか、又は role 属性値が "presentation" ではないかどうかを確認する。

  2. 要素に alt 属性がないか、又は alt 属性に空ではない値が含まれていないかどうかを確認する。

判定基準

  • 1. を満たし、かつ 2. も満たす場合、この失敗条件が適用され、コンテンツは達成基準を満たしていないことになる。


F39: 達成基準 1.1.1 の失敗例 - 支援技術が無視すべき画像に対して、空ではない代替テキストを提供している(例: alt="spacer" 又は alt="image")

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

この達成方法は、支援技術によって無視されることが望ましい画像に対する失敗条件について述べている。画像のテキストによる代替は、画像の意味を伝えることが望ましい。ページ内に意味のないコンテンツの一部である装飾、スペーシング又は他の目的で画像が使用される場合、画像は意味を持たず、支援技術では無視することが望ましい。

空のテキストによる代替(alt="")を提供すると、支援技術によって画像が無視され、この達成基準の失敗を回避できるだろう。

事例

失敗例 1: alt 属性を持たない装飾画像

コンテンツ間に空白領域を作成するために、それ自体は意味を持たない画像が使用されている。その画像の代替テキストの値は"spacer"である。テキストによる代替が同等の目的を果たさないため、この画像は達成基準に適合しない。その画像は無視されることを意図されているが、代替テキスト"spacer"はスクリーンリーダーによって読み上げられ、いくつかの代替カラースキームでは表示される。

<div>Tree type: <img src="spacer.gif" width="100" height="1" alt="spacer"/>Cedrus deodara</div>

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. 装飾、スペーシング、又はページ内の意味のあるコンテンツに含まれない他の目的に使用される img 要素を特定する

  2. これらの要素に対する alt の値が空である。

判定基準

  • 2. を満たさない場合、この失敗条件が適用され、コンテンツは達成基準を満たしていないことになる。


F40: 達成基準 2.2.1 及び 達成基準 2.2.4 の失敗例 - meta 要素による制限時間付きのリダイレクトを使用している

適用(対象)

すべてのページ

これは、次の達成基準に関連する失敗例である:

解説

meta http-equivの{time-out}; url=...はしばしば、自動的に利用者をリダイレクトする目的で使用される。これが時間をおいて発生した場合、予期しない状況の変化によって利用者の邪魔をする可能性がある。

タイムアウトが0に設定されている場合には、meta 要素をリダイレクトのために利用することが容認される。なぜなら、リダイレクトが即時に行われるので、状況の変化として知覚できないからである。しかしながら、これを実行するためにはサーバーサイドの達成方法を用いることが望ましい。SVR1: クライアントサイドではなく、サーバサイドで自動リダイレクトを実装する (SERVER) を参照のこと。

事例

失敗例 1

以下のページは 5 秒後に http://www.example.com/newpage という URI へリダイレクトされるため、不適合である。

コード例:


<html xmlns="http://www.w3.org/1999/xhtml" lang="ja">
   <head>     
      <title>使用禁止!</title>     
      <meta http-equiv="refresh"
      content="5; url=http://www.example.com/newpage" />   
   </head>   
   <body>     
      <p>       
         ブラウザがリフレッシュをサポートしている場合、5秒後に
         <a href="http://www.example.com/newpage">新しいサイト</a>        
         に移動します。サポートしていない場合には、リンクを選択してください。     
      </p>   
   </body> 
</html>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. ページを表示させる。

  2. 一定の時間が経過しても、ページがリダイレクトされない。

判定基準

  1. 2. を満たしていれば、この不適合事例が適用され、そのコンテンツは達成基準を満たしていないことになる。


F41: 達成基準 2.2.1、達成基準 2.2.4、及び 達成基準 3.2.5 の失敗例 - meta要素によるタイムアウト付きのリフレッシュを使用している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

リフレッシュの meta http-equiv は、定期的にページを更新したり、利用者を別のページにリダイレクトしたりするためにしばしば用いられる。もし時間間隔が短すぎ、かつ自動リフレッシュを無効にする方法がない場合、全盲の人はスクリーンリーダーでページを読み終わらないうちに、予期せずページが更新されてしまい、スクリーンリーダーがページの先頭から読み上げてしまう。目の見える利用者も、予期しないリフレッシュによって混乱させられる。

事例

失敗例 1

この非推奨例では、利用者ページが一定間隔で変化する。コンテンツ制作者はこの手法を「プッシュ」テクノロジーのシミュレートに用いるべきではない。制作者は、利用者がページを読むのにどれくらいの時間を必要とするかを予期することはできない。早すぎるリフレッシュは利用者を混乱させることになる。コンテンツ制作者は周期的なリフレッシュを避け、利用者自身にいつ最新の情報がほしいかを選択させるべきである。(content 属性内の数字はリフレッシュまでの秒数である。)

コード例:


<html xmlns="http://www.w3.org/1999/xhtml" lang="ja">   
  <head>     
    <title>WCAG 2.0のためのHTMLの達成方法</title>     
    <meta http-equiv="refresh" content="60" />   
  </head>   
  <body>
    ...     
  </body> 
</html>

(今のところ、なし。)

検証

チェックポイント

  1. ドキュメント内の meta 要素を探す。

  2. meta 要素について、http-equiv 属性の値に"refresh"(大文字小文字を区別しない)が含まれており、かつ content 属性が 0 より大きいの数値(秒を表す)で、"; url ="(大文字小文字を区別しない)ではないことを確認する。

  3. リフレッシュを無効にするメカニズムがあるかどうかを確認する。

判定基準

  • 2. を満たし、かつ 3. を満たしていない場合、この失敗条件が適用され、コンテンツは達成基準を満たしていないことになる。


F42: 達成基準 1.3.1 及び 達成基準 2.1.1 の失敗例 - スクリプトのイベントを用いて、プログラムで解釈できない方法で、リンクをエミュレートしている

適用(対象)

スクリプトを含むHTML及びXHTML。

これは、次の達成基準に関連する失敗例である:

解説

この失敗は、JavaScript のイベントハンドラが、リンクをエミュレートするために要素に付加されている場合に発生する。この方法で作成されたリンクは、キーボードでタブ移動することができず、他のコントロール及び/又はリンクのようにキーボードでフォーカスを受け取れない。スクリプトのイベントがリンクをエミュレートするために使用される場合、支援技術を含むユーザエージェントは、コンテンツ内のリンクをリンクとして識別できないかもしれない。インタラクティブなコントロールとして認識されてもリンクとして認識されないかもしれない。そのような要素は、ユーザエージェントや支援技術によって生成されたリンクリストには現れない。

支援技術がリンクコントロールとして不明な要素を識別するために、ARIA role 属性を使用することは可能である。しかし、ARIA の最善の対応策としては、可能な限りネイティブな要素を使用することが求められ、不明な要素をリンクとして識別するために role 属性を使用することは推奨しない。

aarea 要素は、リンクをマークアップするためのものである。

事例

失敗例 1: span 要素のスクリプト

スクリプトによるイベントハンドリングがspan要素に追加されているので、それがマウスでクリックされた場合はリンクとして機能する。支援技術はこの要素をリンクとして認識しない。

コード例:


<span onclick="this.location.href='newpage.html'">
    偽のリンク
</span>

失敗例 2: img 要素のスクリプト

スクリプトによるイベントハンドリングがimg要素に追加されているので、それがマウスでクリックされた場合はリンクとして機能する。支援技術はこの要素をリンクとして認識しない。

コード例:


<img src="go.gif" 
   alt="新しいページへ移動" 
   onclick="this.location.href='newpage.html'">

失敗例 3: キーボードサポートがある img 要素のスクリプト

スクリプトによるイベントハンドリングが img 要素に追加されているので、リンクとして機能する。この例では、リンク機能がマウス又はユーザエージェントが要素をタブ移動可能な範囲に含まれる場合には Enter キーで機能する。それでもなお、この要素はリンクとしては認識されない。

コード例:


function doNav(url)
{
   window.location.href = url;
}

function doKeyPress(url)
{
   //Enterキーが押された場合
   if (window.event.type == "keypress" &amp;&amp;
       window.event.keyCode == 13)
   {
      doNav(url);
   }
}

画像のためのマークアップ:

コード例:


<p>
	<img src="bargain.jpg"
		tabindex="0" 
		alt="バーゲンを見る"
		onclick="doNav('viewbargains.html');"
		onkeypress="doKeyPress('viewbargains.html');"
	>
</p>

失敗例 4: div 要素のスクリプト

この例では、div 要素がリンクとして機能するようにスクリプトを使用している。制作者は、完璧なキーボードアクセスを提供し、コンテンツの再利用を可能にするためイベントハンドラをマークアップから切り離しているが、この div 要素は支援技術にリンクとして認識されない。

コード例:


window.onload = init;

function init()
{
	var objAnchor = document.getElementById('linklike');

	objAnchor.onclick = function(event){return changeLocation(event,
'surveyresults.html');};
	objAnchor.onkeypress = function(event){return changeLocation(event,
'surveyresults.html');};
}

function changeLocation(objEvent, strLocation)
{
	var iKeyCode;

	if (objEvent &amp;&amp; objEvent.type == 'keypress')
	{
		if (objEvent.keyCode)
			iKeyCode = objEvent.keyCode;
		else if (objEvent.which)
			iKeyCode = objEvent.which;

		if (iKeyCode != 13 &amp;&amp; iKeyCode != 32)
			return true;
	}

	window.location.href = strLocation;
}

div 要素のためのマークアップ:

コード例:


<div id="linklike">
アンケートの結果を見る。
</div>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

要素がリンクをエミュレートするために JavaScript のイベントハンドラを使用したリンクとして提示されるすべての要素について:

  1. プログラムによって解釈された要素のロールがリンクかどうかを確認する。

  2. エミュレートされたリンクについて、キーボード操作で有効にできるかどうかを確認する。

判定基準

  • 1. が満たされない場合、この失敗条件が適用され、コンテンツは達成基準 1.3.1及び 4.1.2を満たしていないことになる。2. が満たされない場合、この失敗条件が適用され、コンテンツは達成基準 2.1.1及び 2.1.3を満たしていないことになる。


F43: 達成基準 1.3.1 の失敗例 - コンテンツにおける関係を表さない方法で、構造を示すマークアップを使用している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

この失敗例では、プレゼンテーション上の効果を実現するために用いられている構造的マークアップが、コンテンツ上には存在しない関係を示している場合に発生する失敗について解説する。この不適合は、コンテンツ上の構造的関係を頼りにナビゲーションを行ったり、コンテンツの一部と他の部分の関係を理解している利用者の混乱を招く。なお、<th> 要素や <caption> 要素など、不適切な構造的マークアップが含まれていない限り、HTML テーブルをレイアウトに使用することはこの失敗例には当たらない。

注記: 要素のセマンティックな意味は一般的に支援技術に受け渡されているが、WAI-ARIA presentation roleは、要素のネイティブなセマンティクスを隠してアクセシビリティ API にマップされないようにするために使用できる。要素の role を presentation に設定すると、その要素のセマンティクスを利用者から隠すことでこの失敗を避けられるかもしれない。

事例

失敗例 1: 視覚的効果の実現のみのために用いられている見出し

この例では、太字の大きな文字で連絡先住所を表示するために見出しが用いられている。しかし、この連絡先住所がページ中の新しい章や節の開始を示しているわけではないので、見出しとしてマークアップするのは不適切である。

コード例:


<p>詳細に興味をお持ちでしたら、以下までご連絡ください。</p> 
<h4>3333 Third Avenue, Suite 300 · New York City</h4>

<p>完全な情報を一切無料でお送りします。</p>

失敗例 2: プレゼンテーション上の効果を目的とした見出し要素の使用

この例では、見出し要素が文書構造を表すため、そして視覚的な効果を実現するための二つの異なる目的で用いられている。h1 及び h2 要素はそれぞれ、文書全体の始まりと概要を示す目的で適切に使用されている一方で、タイトルと概要の間にある h3 及び h4 要素は、作者の名前と日付を表示するためのフォントを制御する目的で使用されている。

コード例:


<h1>ウェブページにおける見出し要素の利用に関する研究</h1>
<h3>Joe Jones and Mary Smith<h3>
<h4>2006年3月14日</h4>
<h2>概要</h2>
<p>研究は2006年初頭に行われ ...
</p>

失敗例 3: 追加の字下げを目的とした blockquote 要素の使用

以下の例では、視覚的な表示を行うブラウザにおいてテキストを目立たせる目的で、引用文ではないテキストに対して blockquote 要素が使用されている。

コード例:


<p>同社のウェブサイトに関する詳細な検討の結果、タスクフォースは
以下の問題がサイト全体に多く見られることを指摘した。</p>

<blockquote>
<p>視覚的効果を目的としたマークアップの利用により、ページが
スクリーンリーダーの利用者にとって分かりづらいものになっている。</p>
</blockquote>

<p>委員会では、これによってもたらされる問題の具体例を以下に
示している。</p>

失敗例 4: テキストの枠線を表示する目的で fieldset 要素と legend 要素を使用する

コード例:


<fieldset>
<legend>バーゲンコーナー</legend>
<p>今購入すると20パーセント割引</p>
</fieldset>

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. 要素のセマンティックな意味が支援技術に受け渡され、かつ要素の内容に対して適切であることを確認する。

判定基準

  • 1. が満たされない場合、この失敗条件が適用される。


F44: 達成基準 2.4.3 の失敗例 - tabindex 属性を用いて、意味及び操作性を保持しないタブ順序を指定している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

この文書は、タブ順序がコンテンツの論理的な関係性及び順序に従っていない失敗例について述べている。

リンク及びフォーム要素のようなフォーカス可能な要素には、tabindex 属性がある。要素は、tabindex 属性の値が小さいものから大きいものへという順序でフォーカスを受け取る。tabindex 属性の値が、コンテンツ内での関係性及び順序とは異なる順序で割り当てられていると、もはやタブ順序はコンテンツの関係性及び順序に従っていないことになる。

この失敗例の最も一般的な原因の1つは、tabindex が使用されているページを編集するときに発生する。コンテンツが編集されても、tabindex 属性がコンテンツの変更を反映するように更新されない場合、タブの順序とコンテンツの順序が一致しなくなり易い。

事例

失敗例 1

次の事例は、代替のタブ順序を指定するために tabindex を誤って用いている。

コード例:


  <ol>
   <li><a href="main.html" tabindex="1">ホーム</a></li>
   <li><a href="chapter1.html" tabindex="4">第1章</a></li>
   <li><a href="chapter2.html" tabindex="3">第2章</a></li>
   <li><a href="chapter3.html" tabindex="2">第3章</a></li>
  </ol>

このリストを Tab キーを用いてナビゲートする場合、リストは、ホーム、第 3 章、第 2 章、第 1 章、という順序でナビゲートされ、コンテンツにおける順序通りではなくなってしまう。

失敗例 2

すべてのテキストフィールドに対して tabindex 属性を提供することによって、ウェブページでのタブ順序が明確に設定されていた。後に、そのページには新しいテキストフィールドがページの中央付近に追加されたが、コンテンツ制作者はその新しいテキストフィールドに tabindex 属性を付加し忘れてしまった。結果として、新しいテキストフィールドのタブ順序がそのページの最後になってしまっている。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. tabindex 属性を用いている場合、tabindex 属性によって指定されているタブ順序がコンテンツの関係性に従っている。

判定基準

  • 1. を満たしていない場合、この失敗基準が適用され、そのコンテンツは達成基準に不適合となる。


F46: 達成基準 1.3.1 の失敗例 - レイアウトテーブルで、th 要素、caption 要素、又は空ではない summary 属性を使用している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

この達成方法の目的は、レイアウトにのみ使用されるテーブルに th 要素、summary 属性、又は caption 要素が含まれる場合に発生する失敗について記述することである。これは、構造化(又はセマンティック)マークアップをプレゼンテーションにのみ使用するため、失敗例である。HTML 及び XHTML の table 要素の目的は、データを提示することである。

レイアウトテーブルの中で用いられることは少ないが、以下の構造的なマークアップもレイアウトテーブル内で用いられると達成基準 1.3.1 に不適合となる:

  • headers 属性

  • scope 属性

支援技術は、HTML 及び XHTML のテーブルに含まれる構造的な情報を用いて、利用者に対してデータを論理的な形で伝えるようになっている。th 要素は、行や列の見出しを表すために用いられる。スクリーンリーダーを利用している場合、表の中を移動しながら読む時、移動した先のセルの行や列の見出しを読み上げるために th 要素の内容が利用される。summary 属性は、その表の目的や機能についてのテキストによる説明を提供するために用いられ、利用者はスクリーンリーダーを用いてこの情報を得ることができる。caption 要素は表の一部であり、その表を特定する役割を持つ。

WCAG 2.0 ではレイアウトテーブルの使用を禁じてはいないが、HTML で定義されているテーブル関聨の要素が持つセマンティックを保持し、プレゼンテーションとコンテンツを分離して記述するコーディング・スタイルを遵守するためにも、CSS によるレイアウトを行うことが推奨される。テーブルレイアウトを行う際には、th 要素を用いてはならない。この場合、この表はデータを示しているわけではないから、どのセルも行や列の見出しとしてマークアップする必要はない。同様に、レイアウトテーブルを実現するだけのために用いられている表について、追加の説明を提供する必要はない。summary 属性は使用するべきではなく、また summary 属性を使って、たとえば「レイアウトテーブル」のような説明を追加するべきではない。このような情報が記述された場合、スクリーンリーダーを使ってコンテンツを利用している利用者に有用な情報が提供されないだけでなく、ナビゲーションの邪魔になる。レイアウトテーブルに値が空の summary 属性を指定することは許容されるが、推奨されない。

事例

失敗例 1

以下は、テーブルを使ってコンテンツを 3 段組にする単純な例である。左側にナビゲーション・バー、中央にメインのコンテンツ、右側に追加のサイドバーが配置されている。ページの上部にはページのタイトルが表示されている。この例では、ページのタイトルを <th> を使ってマークアップし、この表がレイアウトテーブルであることを示す summary 属性が指定されている。

コード例:


<table summary="レイアウトテーブルです。">
 <tr>
   <th colspan="3">ページのタイトル</th>
 </tr>
 <tr>
   <td><div>ナビゲーション・コンテンツ</div></td>
   <td><div>メイン・コンテンツ</div></td>
   <td><div>右側のサイドバー・コンテンツ</div></td>
 </tr>
 <tr>
   <td colspan="3">フッター</td>
 </tr>
 </table>

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. HTML 又は XHTML のソースコードに、table 要素があることを確認する。

  2. そのコンテンツ中で、視覚的レイアウトのみの目的でテーブルが用いられている場合

    1. その table 要素には、th 要素が含まれていない。

    2. その table 要素に対して、値が空ではない summary 属性が指定されていない。

    3. その table 要素には caption 要素が含まれていない。

判定基準

  • 2. のいずれかを満たしていない場合、不適合条件が適用され、そのコンテンツは達成基準に不適合となる。


F47: 達成基準 2.2.2 の失敗例 - blink 要素を使用している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

ユーザエージェント及び支援技術によるサポート

F47 に関するユーザエージェントサポートノート (英語)を参照のこと。

解説

blink 要素は正式な HTML 又は XHTML の仕様の一部ではないが、多くのユーザエージェントによりサポートされている。要素内のあらゆるテキストが予め決定された周期で点滅する。これは、利用者が中断することはできず、また環境設定によって無効にすることもできない。ウェブページが表示されている限り、点滅は続くことになる。そのため、点滅が3秒より長く続く可能性があることから、blink を用いているコンテンツは達成基準を満たしていないことになる。

事例

失敗例 1

製品リストのページで、セール価格に注意を引くため、blink 要素を用いている。利用者が点滅をコントロールできないため、このウェブページは達成基準を満たしていない。

コード例:

<p>わが社の素晴らしい製品 <blink>セール! 44,995ドル!</blink></p>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. コードに blink 要素が存在する。

判定基準

  • 1. を満たしているならば、そのコンテンツは達成基準を満たしていないことになる。


F48: 達成基準 1.3.1 の失敗例 - 表形式の情報をマークアップするために、pre 要素を使用している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

この文書は、表形式の情報をマークアップするために HTML の pre 要素を使用することによる失敗例について述べている。pre 要素は、テキストの視覚的なフォーマットだけを保持するためのものである。pre 要素を用いて表形式の情報をマークアップすれば、利用者が画面を見ることができない場合、又はその視覚的な表現が大きく変わってしまった場合には、表のデータセルと見出しセルとの間で視覚的にほのめかされている論理的な関係性は失われてしまう。

その代わりに、HTML には表形式のデータを提示するために用いる table 要素がある。支援技術は、利用者にデータを論理的な方法で提示するために、HTML のテーブルの構造を用いている。pre 要素を使用した際には、支援技術はその構造に関する情報を得ることができない。

事例

失敗例 1: 列の間をタブ区切りで整形したスケジュール

コード例:


<pre>
 	月曜日		火曜日	水曜日		木曜日		金曜日
 8:00-
 9:00	サムと会う				
 9:00-
 10:00				Dr.ウィリアム	再びサムと	サン・アントニオに出発
 </pre>

失敗例 2: フォーマット済みのテキストを用いて表示した選挙結果

コード例:


<pre>
   サーキット COURT JUDGE 支部 3
                                                   ラ
                                                    イ
                                          M R エ    ト
                                           ア .  ル    
                                     マ ラ   リ   バ    
                                      イ ン   ー   ー    ・
                                       ク グ        ト     イ
                                                         ン
                                       -----   -----   -----
0001 アルビオンタウン WDS 1-2            22      99       0
0002 ベリータウン WDS 1-2                52     178       0
0003 ブラックアースタウン                16      49       0
0004 ブルーミンググローブタウン WDS 1-3  44     125       0
0005 ブルータウン MOUNDS                 33     117       0
0006 ブリストルタウン WDS 1-3            139    639       1
0007 バークタウウン WDS 1-4              80     300       0
0008 クリスティーナタウン WDS 1-2        22      50       0

 </pre>

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. pre 要素が使われている。

  2. pre 要素が使われている部分について、それが表形式の情報である。

判定基準

  • 2. を満たしている場合、この失敗基準が適用され、そのコンテンツは達成基準を満たしていないことになる。


F49: 達成基準 1.3.2 の失敗例 - リニアライズした際に、意味の通じない HTML のレイアウトテーブルを使用している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

ユーザエージェント及び支援技術によるサポート

F49 に関するユーザエージェントサポートノート (英語)を参照のこと。

解説

WCAG 2.0 はレイアウトテーブルの使用を禁止してはいないが、HTML の table 要素に定義されたセマンティックな意味を維持するため、また構造を表現から分離するコーディング上の慣習に従うためにも、CSS に基づくレイアウトを推奨する。それでもレイアウトテーブルを用いる場合には、コンテンツを線形化しても意味が通るようにすることが重要である。

この失敗例は、コンテンツの視覚的配置を制御するために使用されるHTMLテーブルが正しく「線形化(リニアライズ)」されないことによって、提示を通じて伝えられる意味のあるコンテンツの順序が失われた場合に発生する。テーブルは、横及び縦の 2 つの視覚的な次元でコンテンツを提示する。しかし、スクリーンリーダーは、この 2 次元コンテンツを最初の行の最初のセルから最後の行の最後のセルまで、ソース内のコンテンツの線形的順序で提示する。スクリーンリーダーは、上から下にテーブルを読み上げ、次の行に移動する前に各行の内容全体を読み上げる。セル内にネストされたテーブルのすべての内容を含む、各行の各セルのすべての内容が読み上げられる。これは線形化と呼ばれる。

あるウェブページが 22 行 9 列のテーブルによってレイアウトされているとしよう。スクリーンリーダーは最初に 1 行目の第 1 セル、続いて第 2、第 3、第 4と第 9セルまで読み上げる。しかし、いずれかのセルがネストされたテーブルを含む場合、スクリーンリーダーはネストされたテーブルのすべての内容を、元の (外側の) テーブルの次のセルよりも先に読み上げる。 たとえば 6 行目 3 列のセルに、5 行 6 列のテーブルが含まれる場合、含まれたテーブルのすべてのセルが、元の (外側の) テーブルの 6 行目 4 列のセルよりも先に読み上げられる。その結果、視覚的表現によって伝えられている意味のある順序がスクリーンリーダーによる読み上げでは知覚できないかもしれない。

事例

失敗例 1: 正しく線形化できないレイアウトテーブル

ある広告では視覚的配置をうまく用いているが、線形化されると意味が変わってしまう。

コード例:


<table>
<tr>
  <td ><img src="logo.gif" alt="XYZ mountaineering"></td>
  <td rowspan="2" valign="bottom">top!</td>
</tr>
<tr>
  <td>XYZ gets you to the</td>
</tr>
</table>

このテーブルの読み上げ順序は次のようになってしまうだろう:

  • XYZ mountaineering top!

  • XYZ gets you to the

訳注:本来は「XYZ mountaineering XYZ gets you to the top!」となるべきである

失敗例 2: 線形化されると意味のある列が分割されてしまうレイアウトテーブル

ある美術館の展覧会に関するウェブページでは、リンクの長い一覧を含むナビゲーションバーをページ左側に配置している。そのナビゲーションバーの右側には展覧会に展示される絵の一つが置かれている。その絵の右側には、美術館でその絵の横の壁にみられるであろうプラカードのテキストが置かれている。そのテキストの下には、「Description,」という見出しと、その見出しの下にその絵の説明が置かれている。絵、プラカードのテキスト、説明の見出し、そして絵の説明というのが意味のある順序となっている。

ページ中で各要素を配置するためにレイアウトテーブルが用いられている。ナビゲーションバー中の一連のリンクは、最も左の列の異なるセルに分割されている。

コード例:


<table>
<tr>
	<td><a href="#">リンク 1</a></td>
	<td rowspan="20"><img src="img.png" alt="美術館の絵"></td>
	<td rowspan="6"><img src="placard.png" alt="プラカードのテキスト"></td> 
</tr> 
<tr>
	<td><a href="#">リンク 2</a></td>
</tr>
<tr>
	<td><a href="#">リンク 3</a></td>
</tr>
<tr>
	<td><a href="#">リンク 4</a></td>
</tr>
<tr>
	<td><a href="#">リンク 5</a></td>
</tr>
<tr>
	<td><a href="#">リンク 6</a></td>
</tr>
<tr>
	<td><a href="#">リンク 7</a></td>
	<td rowspan="2"><h2>説明の見出し</h2></td> 
</tr> 
<tr>
	<td><a href="#">リンク 8</a></td>
</tr>
<tr>
	<td><a href="#">リンク 9</a></td>
	<td rowspan="12">Description of the image</td> 
</tr> 
<tr>
	<td><a href="#">リンク 10</a></td>
</tr>
 ...
<tr>
	<td><a href="#">リンク 20</a></td>
</tr>
</table>

この例の読み順は次のようになってしまうだろう:

  • リンク 1

  • 美術館の絵

  • プラカードのテキスト

  • リンク 2

  • リンク 3

  • リンク 4

  • リンク 5

  • リンク 6

  • リンク 7

  • 説明の見出し

  • リンク 8

  • リンク 9

  • リンク 10

  • ...

  • リンク 20

ナビゲーションバーの一連のリンクに絵を説明するコンテンツが割り込んでいるため、スクリーンリーダーは視覚的な順序に対応した意味のある順序でコンテンツを提示することができない。

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. 以下のいずれかの方法によってコンテンツを線形化する:

    • コンテンツをソースコード中の順序で表示する

    • コンテンツを囲むテーブルのマークアップを除去する

  2. 線形化した読み上げ順序が、表現によって伝えられている意味のある順序と合致する

判定基準

  • 2. を満たしていない場合、この不適合条件が適用され、達成基準に不適合となる。


F50: 達成基準 2.2.2 の失敗例 - 点滅させるスクリプトを用いていて、その点滅を 5 秒以内に停止させるメカニズムがない

適用(対象)

スクリプトで制御されたコンテンツの点滅をサポートするウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

スクリプトを用いてコンテンツの表示、非表示を定期的に切り換えることで、コンテンツを点滅させることができる。スクリプトが5秒以内に点滅を止めるためのメカニズムを含まない場合は不適合となる。点滅を停止させるための達成方法をどのように修正するかについての情報はSCR22.html: (Scripting) (Scripting) を参照。

事例

失敗例 1

以下の例では点滅するコンテンツのためにスクリプトが使用されているが、点滅は5秒後に止まるのではなく、無期限に点滅し続ける。

コード例:


...
<script type="text/javascript">
<!--
// 点滅「on」状態
function show()
{
	if (document.getElementById)
	document.getElementById("blink1").style.visibility = "visible";
	settime-out("hide()", 450);
}
// 点滅「off」状態
function hide()
{
	if (document.getElementById)
	document.getElementById("blink1").style.visibility = "hidden";
	settime-out("show()", 450);
}
// 開始
show();
//-->
</script>
...
<span id="blink1">このコンテンツは点滅します。</span>

検証

チェックポイント

点滅しているそれぞれのインスタンスに対して:

  1. 点滅が5秒以内で止まる。

判定基準

1.を満たしていない場合、コンテンツは達成基準を満たしていないことになる。


F52: 達成基準 3.2.1 の失敗例 - 新しいページを読み込むのと同時に、新しいウィンドウを開いている

適用(対象)

新しいウィンドウを開くために使用されるスクリプト

これは、次の達成基準に関連する失敗例である:

解説

製品又はサービスを宣伝するために、あるウェブサイトではページが読みこまれた時に新しいウィンドウが開く。この達成方法の目的は、ページが読み込まれたと同時に 1 つ以上の新しいウィンドウが開かれることによって、ページが利用者を混乱させないようにすることである。

事例

失敗例 1:

下記の事例は、ページがロードされた時に新しいウィンドウを開くために HTML 4.01 で一般的に使用される。

コード例:


window.onload = showAdvertisement;
 function showAdvertisement()
 {
  window.open('advert.html', '_blank', 'height=200,width=150');
 }

失敗例 2:

下記の事例は、ページがロードされた時に新しいウィンドウを開くために XHTML で一般的に使用される。

コード例:


if (window.addEventListener) { 
    window.addEventListener("load", showAdvertisement, true);
}
if (window.attachEvent) {
    window.attachEvent("onload", showAdvertisement);
}
function showAdvertisement()
{
window.open('noscript.html', '_blank', 'height=200,width=150');
}

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. 新しいページをロードする

  2. 新しいページをロードしたことの結果として新しいウィンドウが開いた

  3. 新しいウィンドウに自動的にフォーカスが移っている

判定基準

  • 2.を満たしているならば、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F54: 達成基準 2.1.1 の失敗例 - ある機能にポインティング・デバイス特有のイベント・ハンドラを使用している

適用(対象)

ポインティング・デバイス特有のイベント・ハンドラを用いたウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

ポインティング・デバイスに特有のイベント・ハンドラだけがコンテンツ上の機能を呼び出すメカニズムであるとき、(マウスのような、目と手による連携が必要な機器を利用できない)全盲の利用者をはじめとした、代替キーボード又はキーボードエミュレーターとして動作する入力機器を用いなければならない利用者は、コンテンツの機能にアクセスできない。

事例

失敗例 1

次に示すのは、マウスでのクリックに反応して他のページに移動する画像の例である。これは、キーボードを用いて次のページに移動できないため不適合である。 <p><img onmousedown="nextPage();" src="nextarrow.gif" alt="次のページへ移動"></p>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. ポインティング・デバイスに特有のイベント・ハンドラだけが、スクリプトの機能を呼び出す唯一の方法である。

判定基準

  • 1. を満たしている場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F55: 達成基準 2.1.1、達成基準 2.4.7 及び 達成基準 3.2.1 の失敗例 - フォーカスを受け取った際に、フォーカスを取り除くために、スクリプトを使用している

適用(対象)

スクリプトをサポートしているすべてのコンテンツに適用

これは、次の達成基準に関連する失敗例である:

解説

通常はキーボードでアクセスした場合フォーカスを受け取るコンテンツが、スクリプトによってフォーカスを失うことがある。これは、デザイナーがシステムのフォーカス・インジケータを見えなくしようとするときに時々起きる。しかしながら、システムのフォーカス・インジケータは、キーボード利用者のアクセシビリティにおける重要な一部分である。また、これを実行することによってフォーカスが完全に取り除かれると、コンテンツにはマウスのようなポインティング・デバイスでしかアクセスできなくなる。

事例

失敗例 1

コード例:

<input type="submit" onFocus="this.blur();">

失敗例 2

コード例:

<a onFocus="this.blur()" href="Page.html"><img src="myImage.gif"></a>

失敗例 3

コード例:

<a href="link.html" onfocus="if(this.blur)this.blur();">リンクの文言</a>

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. キーボードを使用して、すべてのインタラクティブな要素にキーボードでアクセスできる。

  2. それぞれの要素がフォーカスされたとき、利用者がフォーカスを移動するまでそこに残っている。

判定基準

  • 2. を満たしていない場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F58: 達成基準 2.2.1 の失敗例 - タイムアウト後にページを自動的にリダイレクトしているために、サーバサイドの実装方法を使用している

適用(対象)

  • サーバサイドのスクリプト言語全て

  • 制限時間に関する達成基準の例外に当てはまらないコンテンツ

これは、次の達成基準に関連する失敗例である:

ユーザエージェント及び支援技術によるサポート

F58 に関するユーザエージェントサポートノート (英語)を参照のこと。

解説

開発者は、サーバサイドのスクリプト言語を使って、標準ではないHTTPヘッダ「Refresh」を、タイムアウト(単位:秒)及び指定されたタイムアウト時間後にリダイレクトするURIとともに指定することができる。もし時間間隔が短すぎると、全盲の人はスクリーンリーダーでページを読み終わらないうちに、予期せずページが更新されてしまい、スクリーンリーダーがページの先頭から読み上げてしまう。目の見える利用者も、予期しないリフレッシュによって混乱させられる。

HTTPヘッダは、Refresh: {秒で表された時間}; url={新しい場所のURI}のように設定する。URIを省略することも可能で、周期的にページを更新し続けることになる。これも同様の問題を引き起こす。この場合に設定されるHTTPヘッダはRefresh: {秒で表された時間}となる。

事例

失敗例 1

次の事例は、時間によるサーバサイドのリダイレクトがJavaサーブレット又はJavaServer Pages(JSP)により実装されているため、不適合である。

コード例:


public void doGet (HttpServletRequest request, HttpServletResponse response)
      throws IOException, ServletException {
        response.setContentType("text/html");
	PrintWriter out = response.getWriter();
	response.setHeader("Refresh", "10; URL=TargetPage.html");
	out.println("<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"
	 \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">");
	out.println("<html><head><title>リダイレクト</title></head><body>");
	out.println("<p>このページは10秒後にリダイレクトします。</p>");
	out.println("</body></html>");
  }

失敗例 2

次の事例は、時間によるサーバサイドのリダイレクトがVBScriptを伴ったActive Server Pages(ASP)により実装されているため、不適合である。

コード例:


 <% @Language = "VBScript" %>
 <% option explicit 
 Response.Clear
 Response.AddHeader "Refresh", "5; URL=TargetPage.htm"
 %><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja">
 …
 <!--リダイレクトが実行される前に表示されるコンテンツのHTMLソース-->

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. ウェブページが描画された際、利用者の行動を伴わず、一定時間後に自動的に他のページへリダイレクトされる。

判定基準

  • そのようなリダイレクトがみつかった場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F59: 達成基準 4.1.2 の失敗例 - スクリプトを用いて、コントロールに役割(role)を提供することなしに、HTML の div 要素又は span 要素をユーザインタフェースのコントロールにしている

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

この不適合事例では、ユーザインタフェース・コントロールを生成するために汎用的なHTML要素を用いたとき、どのようにしてコントロールが支援技術に対してアクセシブルでなくなるかを示している。コンポーネントについての情報を利用者に伝達する際、支援技術は、コンポーネントのロール及びカレント・ステートの情報に依存している。多くの HTML 要素は、リンク、ボタン、テキストフィールドなどといった明確なロールを持っている。div 及び span などの汎用的な要素は、事前に定義されたロールがない。これらの汎用的な要素が、HTML でユーザインタフェース・コントロールを生成するために使用されると、支援技術は、コントロールを表現したり、コントロールとやり取りしたりするために必要な情報を得られないかもしれない。

通常、インタラクティブではない要素(spandiv など)にイベントハンドラを設定すると、利用者に混乱を招く可能性がある。そのような要素へのキーボードアクセスを提供することに注意が払われても、利用者はコンテンツにインタラクティブなコントロールを見つけたり、その要素の振る舞いを理解することが困難な場合がある。たとえば、利用者が要素をアクティブにするためにスクリプトでサポートされているキーストロークがわからない場合がある。さらに、これらの要素はインタラクティブ要素と同じオペレーティングシステムイベントを生成しないため、利用者がそれらをアクティブにしても支援技術に通知されないことがある。

W3C勧告の「Accessible Rich Internet Applications (WAI-ARIA) 1.0」は、完全にアクセシブルなユーザインターフェイスコントロールを作成するために必要な役割(role)と状態(state)の情報を提供するメカニズムについて説明する。

事例

失敗例 1

span 及び画像を使用したチェックボックスを生成するため、下記の事例は不適合となる。


  <p> 
  <span  onclick="toggleCheckbox('chkbox')"> 
  <img src="unchecked.gif"  id="chkbox" alt=""> 署名を含む
  </span> 
  </p>

失敗例 2

これは、マウスで span をクリックする時に、画像のソースを変更するスクリプトコードである。


  var CHECKED = "check.gif"; 
  var UNCHECKED = "unchecked.gif"; 
  function toggleCheckbox(imgId) { 
  var theImg = document.getElementById(imgId); 
  if ( theImg.src.lastIndexOf(CHECKED)!= -1 ) { 
  theImg.src = UNCHECKED; 
  // チェックをはずすアクションを実装するための追加コード
  } 
  else { 
  theImg.src = CHECKED; 
  // チェックをつけるアクションを実装するための追加コード
  } 
  }

このような方法で生成されたチェックボックスは、チェックボックスとして識別する情報がないため、支援技術では機能しない。加えて、この事例はキーボードからも操作できず、ガイドライン 2.1 に不適合となる。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. 解析されたソースコードで、マークアップ内またはスクリプトを介して割り当てられたイベントハンドラを持つ要素(ユーザインターフェイスコントロールであることを示す要素)を検証する。

  2. コントロールの役割(role)がマークアップ言語でネイティブに定義されているかどうかを確認する。

  3. 適切な WAI-ARIA の役割(role)の割り当てのように、他の有効なメソッドを使用してコントロールの役割(role)を定義しているかどうかを確認する。

判定基準

2. 及び 3. を満たしていないのであれば、失敗条件が適用される。


F60: 達成基準 3.2.5 の失敗例 - 利用者が入力フィールドにテキストを入力すると新しいウィンドウを開く

適用(対象)

全般

これは、次の達成基準に関連する失敗例である:

解説

この文書では、エラーの通知以外で、利用者のテキストフィールドへの入力に反応して新しいウィンドウが開く不適合事例について述べている。

事例

失敗例 1:

不適合となる推奨できない事例:利用者が郵便の宛先の入力をしている。郵便番号の入力をすると、彼の町で利用できるサービスの広告が記載された新しいウィンドウが開く。

失敗例 2:

許容できる事例:利用者がフォームの郵便の宛先の入力をしている。郵便番号のフィールドを入力をすると、有効な郵便番号であるかどうかを検証するスクリプトが実行される。値が無効な場合はフィールドへの入力方法を説明したウィンドウが開く。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. 全てのテキストフィールドを探し出す。

  2. 各テキストフィールドの値を変更する。

  3. 新しいウィンドウが開く。

  4. 新しく開いたウィンドウにエラーメッセージがあり、ウィンドウを閉じて元のフォーム要素にフォーカスを戻すボタンがある。

判定基準

  • 3.に該当して、4.を満たしていなければ、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F61: 達成基準 3.2.5 の失敗例 - 利用者がコンテンツ内で停止させることのできない自動的な更新によってメインコンテンツを完全に変更する

適用(対象)

全般

これは、次の達成基準に関連する失敗例である:

解説

この文書では、メインのビューポートに表示されているコンテンツが自動的に更新され、コンテンツに利用者がこの振る舞いを停止するための選択肢をがない不適合事例について述べている。

達成基準 3.2.5 の不適合事例となるかどうかを検証するためのチェックポイントが「検証」のセクションで挙げられている。チェックポイント 1. が可能であることが望ましく、コンテンツ制作者がビューポートのコンテンツを生成するコードを確認できることを想定している。

しかし、それが可能ではないケースも考えられる(例えば、CMS、djangoやruby-on-railsなどのアプリケーション環境、またはサードパーティによるAjaxやPHPなどのスクリプト言語によって生成されるコンテンツなど)。そのため、チェックポイント 2. がそのような場合の検証のために提示されている。時間枠は指標でしかなく、その他のチェックポイントを満たしていなければ、一定の時間が経過した後に生じるあらゆる変化は不適合事例としてみなすべきである。

事例

失敗例 1

ニュースサイトで、常に最新の見出しが表示されるように、コンテンツが自動的に更新される。この振る舞いを停止させる選択肢がない。

失敗例 2

スライドショーがビューポートの全体に表示されていて、自動的に次のスライドに進んでいく。停止ボタンはない。

失敗例 3

検索エンジンが自動的に検索結果を生成し、利用者の入力に応じてコンテンツを動的に更新する。この振る舞いを停止する選択肢がない。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

(今のところ、なし。)

検証

チェックポイント

  1. 平均的な利用者がページに費やす時間を測定または推定する。

  2. ページに移動する

  3. 平均的な利用者がページに滞在する10倍の時間を待つ。 (ステップ1から)

  4. この間にコンテキストに変化があるかどうか確認する。

  5. コンテキストの変化がない場合、終了する。

  6. コンテキストの変化がある場合は、そのコンテキストの変化を止めるメカニズムがページに存在するかどうかを確認する。

  7. コンテキストの変化を止めるメカニズムがある場合は、そのメカニズムを使用してコンテキストの変化を止めて、テストをやり直す。

  8. コンテキストの変化があり、コンテキストの変化を止めるメカニズムがない場合は失敗となる。

注記 1: ステップ 1 の時間を測定または推定する1つの方法は、ウェブサイトの解析結果から平均的な利用者がページをどのくらいの時間見ているかを確認する。

注記 2: ステップ 6 の例は、自動更新をオフにするメカニズムである。

判定基準

  • ステップ 8 に達すると、コンテンツはこの達成基準に合格しない。


F63: 達成基準 2.4.4 の失敗例 - リンクと関係のないコンテンツにおいてのみ、リンクの文脈を提供している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書は、リンクの目的を理解するために必要な文脈が、プログラムで解釈可能なリンクの文脈ではないコンテンツの中に置かれているという失敗例について解説する。リンクの文脈が次のいずれかの方法で提供されていない場合:

  • リンクとして同じ文章、段落、リストの項目、またはテーブルのセルの場合

  • 前の見出しの場合

  • aria-labelaria-labelledby などの適切な ARIA プロパティを介する場合

利用者はリンクがどこにあるのかを簡単に知ることができない。文脈を探るために利用者がリンクの場所を離れなければならないなら、その文脈はプログラムで解釈可能なリンクの文脈ではなく、この失敗例に該当する。

事例

失敗例 1: 隣接する段落のリンク

あるニュースサービスでは記事の冒頭のいくつかの文を一つの段落に入れている。その次の段落には「続きを読む...」というリンクが置かれている。そのリンクは導入文と同じ段落にないので、利用者はそのリンクが何についての続きを読むのかを容易に見つけることができない。


<p>ある英国のビジネスマンが200万マイルの
マイレージを獲得していて、世界初の消費者向け
宇宙旅行の旅に出ようと計画している。</p>

<p><a href="ff.html">続きを読む...</a></p>

失敗例 2: レイアウトテーブル内の隣接セルのリンク

あるオーディオサイトではプレーヤーがダウンロードできるリンクを提供している。何がダウンロードされるのかについての情報はレイアウトテーブル内の前の行に置かれており、これはプログラムで解釈可能なリンクの文脈ではない。


   <table>
   <tr> 
       <td>ブラウザで音楽を聴く</td>
   </tr>
   <tr>
       <td>
       <a href="http://www.example.com/download.htm">
       <img src="download.jpg" width="165" height="32" alt="今すぐダウンロード"></a>
       </td>
   </tr>
 </table>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

リンクの目的を理解するために、追加が必要なリンクの文脈を探す。各リンクについて:

  1. 文脈が同じ文章、段落、リスト項目、テーブルのセル、関連するテーブルのヘッダー、または前の見出しに含まれているかどうかを確認する。

  2. たとえば、リンク上で aria-labelaria-labelledbyaria-describedby などの WAI-ARIA プロパティを使用して、十分な文脈を提供するなど、リンクの文脈をプログラムで決定できるかどうかを確認する。

判定基準

  • 1 及び 2 が偽である場合、このコンテンツは達成基準に合格しない。


F65: 達成基準 1.1.1 の失敗例 - img 要素、area 要素、及び type "image"input 要素のalt属性を省略している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

この文章では、画像のテキストによる代替の失敗条件を示す。画像の代替を提供するテキストがない場合、支援技術は画像を識別することも、その目的を利用者に伝えることもできない。 alt 属性は画像の代替テキストを提供するための好ましい実装方法であり続ける。アクセシビリティ サポーテッドである限り、適切な WAI-ARIA 属性を使用して代替テキストを提供することができる。アクセシビリティサポートの詳細については、 アクセシビリティ・サポートを文書化するを参照する。アクセシブル リッチ インターネット アプリケーション(WAI-ARIA)1.0 仕様書は、要素の HTML および WAI-ARIA 属性からテキストによる代替を計算するための代替テキスト計算について説明している。

いくつかの支援技術は、画像のファイル名を読み取ることにより、欠落している代替テキストを補うことを試みる。しかし、多くの理由からファイル名に単純に頼るのは不十分である。例えば、ファイル名は説明的ではない場合があり(例 images/nav01.gif)、技術仕様には説明的なファイル名は必須ではない。そして多くの支援技術は HTML 属性を介して代替テキストが提供されていない場合はファイル名を読み取らない。

事例

失敗例 1: テキストによる代替が存在しない

以下のコード例において、スクリーンリーダーを使っている人は画像の目的を知ることはできない。(訳注:スクリーンリーダーを利用している利用者に限らず、ブラウザの設定を変更して画像を非表示にしている場合や点字ディスプレイを利用している利用者なども同様である。)

コード例:


    <img src="../images/animal.jpg" />

参考リソース

検証

チェックポイント

  1. imgarea 及びタイプ "image" の input を特定する。これらの要素のそれぞれについて:

  2. alt 属性が存在するかどうかを確認する。

  3. aria-labelledby 属性が存在するかどうかを確認し、かつページ内の 1 つ以上の id 要素を参照し、かつ aria-labelledbyアクセシビリティ サポーテッドかどうかを確認する。

  4. aria-label 属性が存在するかどうかを確認し、かつ aria-labelアクセシビリティ サポーテッドかどうかを確認する。

  5. title 属性が存在するかどうかを確認し、かつ titleアクセシビリティ サポーテッドかどうかを確認する。

判定基準

  • 1.、2.、3.、及び 4. のすべてが偽である場合、この失敗条件が適用される。


F66: 達成基準 3.2.3 の失敗例 - ナビゲーションリンクをさまざまなページで相対的に異なる順序で提示する

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書では、ウェブページ一式の中にある複数のウェブページ上で繰り返されているナビゲーションメカニズム(達成基準 3.2.3)を含むすべての達成方法における不適合の条件を説明している。メカニズムが、2ページ又はそれ以上のページに異なる順序でリンクの順番を提示する場合に、不適合が起こる。

事例

失敗例 1: 2つの異なるページで相対的に異なる順序で一連のリンクを提示しているXHTMLメニュー

異なる順序でリンクを提示するナビゲーションメカニズムの例。

1ページ目のメニュー

コード例:


    <div id="menu"> 
    <a href="Brazil.htm">ブラジル</a><br />
    <a href="Canada.htm">カナダ</a><br />
    <a href="Germany.htm">ドイツ</a><br />
    <a href="Poland.htm">ポーランド</a> 
</div>

2ページ目のメニュー

コード例:


    <div id="menu"> 
    <a href="Canada.htm">カナダ</a><br />
    <a href="Brazil.htm">ブラジル</a><br />
    <a href="Germany.htm">ドイツ</a><br />
    <a href="Poland.htm">ポーランド</a> 
</div>

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. ナビゲーションメカニズムが複数のウェブページ上で使用されている。

  2. 各ページのナビゲーションメカニズムのデフォルトのプレゼンテーションで、リンクリストが各ウェブページ上で相対的に同一の順番になっている。

注記: 「相対的に同一の順番」は、あるページではリンク項目間に二次的なナビゲーション項目があるかもしれないことを意味する。これらが存在しても、この検証の結果に影響を及ぼすことはない。

判定基準

  • 1.及び2.を満たしていなければ、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F67: 達成基準 1.1.1 及び 達成基準 1.2.1 の失敗例 - 非テキストコンテンツに対して、それと同じ目的を果たしていない、又は同じ情報を提示していない長い説明を提供している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書は、非テキストコンテンツに対する長い説明が非テキストコンテンツと同じ目的を果たしていない、又は非テキストコンテンツと同じ情報を提供していないことによる不適合事例について述べている。このことは非テキストコンテンツを読み取ることができない利用者にとって問題となる。なぜならば、これらの利用者は、非テキストコンテンツが伝達する必要な情報を長い説明から得ているためである。完全な情報を提供する長い説明がないと、ウェブページを理解したり、操作したりすることができない。

事例

  • 街路図にオリンピック種目の開催地が表示されている画像がある。画像には各開催地で催される競技種目のアイコンがある。長い説明には「地図には、オリンピック種目の開催地が表示されています。スケート、ホッケー、及びカーリングはウィンター公園アイスアリーナで開催され、滑降とジャンプはスノーマウンテン、体操はジャンプアップアリーナ、クロスカントリースキーはキロメーターフォレストです。」と書かれている。この説明は有益な情報を提供しているが、画像と同じ情報を伝達していない。なぜならば、説明には、住所又はいくつかの地点からの会場までの距離といった具体的な会場の位置情報が提供されていないからである。長い説明は常に文章形式である必要はないことに留意する。情報はテーブルや他の形式で提供されるほうが最もよい場合がある。

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

長い説明が必要な全ての非テキストコンテンツに対して:

  1. 長い説明が非テキストコンテンツと同じ目的を果たす、又は同じ情報を提供している。

判定基準

  • 1.を満たさない場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F68: 達成基準 4.1.2 の失敗例 - ユーザインタフェース コントロールがプログラム的に解釈される名前(name)を持っていない

適用(対象)

HTML のコントロール

これは、次の達成基準に関連する失敗例である:

解説

この失敗例は、フォームコントロールの名前が支援技術に公開されていない場合に発生する問題を説明する。その結果、一部の利用者はフォームコントロールの目的を特定できなくなる。名前(name)は、label 要素を含む複数の方法で指定できる。他のオプションには、アクセシビリティ名に使用されるテキストを直接提供するために使用される title 属性および aria-label の使用、又はその名前(name)を提供しているページ上の他のテキストとの関連を示す aria-labelledby が含まれる。ボタンコントロールには、以下に示すように、別の方法で名前(name)を割り当てることができるが、特定の状況ではlabeltitlearia-label、または aria-labelledby の使用が必要な場合がある。

注記 1: 明示的に関連付けられた label を使用できる要素は次のとおりとなる。

  • input

  • textarea

  • select

注記 2: 以下の要素については、ラベルを value 属性(サブミット(送信)およびリセット・ボタン)、 alt 属性(画像を用いたボタン)、あるいは要素の内容そのもの(button)でそれぞれ指定するため、label 要素を用いない。

  • サブミット(送信)及びリセット・ボタン (input type="submit" 又は input type="reset")

  • 画像を用いたボタン (input type="image")

  • 隠し入力フィールド (input type="hidden")

  • ボタン(button 要素又は <input type="button">

事例

失敗例 1:

以下の例では、視覚的には分かる形でフォームのコントロールに対応するラベルが提示されているが、label要素を用いてラベルとコントロールの対応が示されていない。この例の場合、ユーザエージェント(支援技術を含む)がどのラベルとどのコントロールが対応しているのかを判断できない可能性があるため不適合となる。


 <form>
 姓:
 <input type="text" name="lastname">
 <br>
 名: 
 <input type="text" name="firstname">
 <br />
 私は犬を飼っている <input type="checkbox" name="pet" value="dog">
 私は猫を飼っている <input type="checkbox" name="pet" value="cat">
</form>

失敗例 2:

次のコード例では、 label 要素は存在するが、対応するインプットコントロールとプログラム的に関連付けられていないため、支援技術によって正しく判定されない可能性がある。


<form action="..." method="post">
<p>
<label>
   姓
   <input type="text" name="lastname">
</label>
<label>
   名
   <input type="text" name="firstname">
</label>
</p>
</form>

<form action="..." method="post"> 
<p> 
<label>姓</label> 
<input type="text" name="lastname"> 
<label>名 </label>
<input type="text" name="firstname"> 
</p> 
</form>

失敗例 3:

次のコード例の検索テキストボックスには、プログラムによる解釈が可能な名前がない。名前(name)は、上記の方法のいずれかで提供することができる。


<input type="text" value="検索文字列を入力"><input type="submit" type="submit" value="検索">

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

ウェブページ内のすべてのinputtextarea 及び select要素("hidden"、"submit"、"reset"、又は "button" の input を除く):

  1. 次のいずれかの方法で、各要素にプログラムによる解釈が可能な名前が付いていることを確認する。

    1. テキストラベル又はラベルは、aria-labelledby 属性(aria-labelledby 属性の値として与えられた各idは、テキストラベル要素の id と一致する)を介して、コントロール要素とプログラムにより関連付けられている。

    2. コントロールは、その aria-label属性の値によってプログラムにより解釈される。

    3. テキストラベルは、ラベルの for 属性(for 属性の値として与えられた idは入力要素の idと一致する)を介して、それぞれの入力要素に正しく関連付けられたラベル要素に含む。

    4. コントロールはラベルテキストも含む label 要素内に含まれる。

    5. コントロールは type が "image" の inputであり、alt 属性はテキストラベルを提供する。

    6. コントロールは title 属性の値によってプログラムにより解釈される。

判定基準

  • 1. のすべてのオプションが偽である場合、この失敗条件が適用され、コンテンツは達成基準に合格しない。


F69: 達成基準 1.4.4 の失敗例 - 視覚的に描画されたテキストを 200 %まで拡大した際に、テキスト、画像又はコントロールが、切り取られたり、端が欠けたり、又は覆い隠されたりする

適用(対象)

HTML、XHTML及びCSS

これは、次の達成基準に関連する失敗例である:

解説

この文書は、テキストのサイズ変更によって、テキストが切り取られたり、端が欠けたり、又は覆い隠されたりして、利用者がテキストを入手できなくなるという不適合事例について述べている。一般的に、この不適合事例は、ユーザエージェントのレイアウトエンジンが、HTML 内の新しいフォントサイズについてのレイアウトヒントのすべてには対応できない場合に発生する。これが発生する方法には、下記のようなものがある:

  • 囲み要素の overflow プロパティをhidden に設定する

  • コンテンツを絶対配置にして使用する

  • 新しいフォントサイズで表示されたコンテンツに対して、十分な大きさがないポップアップを作成する

注記: WCAG ワーキンググループは、この不適合事例の検証方法に多くの誤解があることを確認している。この不適合事例の文書を次回の更新時に修正する予定である。それまでは、コンテンツが「十分な達成方法」のいずれかを用いて達成基準を満たしていれば、この不適合事例には該当しないと考えてよい。

事例

失敗例 1:

フォントサイズはスケーラブルな方法で設定されているが、コンテナは固定ピクセルサイズに設定されている。灰色のボーダーは、テキストのコンテナの境界線を示している。テキストが拡大されるとき、そのコンテナからあふれ、次のパラグラフを覆い隠す。

コード例:


<div style="font-size:100%; width:120px; height:100px; border: thin solid gray;> 
  Now is the time for all good men to come to the aid of their country. 
</div>
<p>Now is the time for all good men to come to the aid of their country.</p>

事例 1 のサンプルイメージ:

コンテナの枠の外にあふれ、ページの他のテキストを覆い隠しているテキスト。

失敗例 2:

この事例は、コンテナがテキストを切り取るように設定されることを除けば、前の不適合事例と同じである。テキストは次のパラグラフに流れ出してはいないが、端が欠けている。これも不適合事例である。

コード例:


<div style="font-size:100%; width:120px; height:100px; overflow: hidden; border: thin solid gray;>
 Now is the time for all good men to come to the aid of their country. 
</div>
<p>Now is the time for all good men to come to the aid of their country.</p>

事例 2 のサンプルイメージ:

拡大したテキストのために端が欠けたテキスト。

(今のところ、なし。)

検証

チェックポイント

注記: WCAG ワーキンググループは、この不適合事例の検証方法に多くの誤解があることを確認している。この不適合事例の文書を次回の更新時に修正する予定である。それまでは、コンテンツが「十分な達成方法」のいずれかを用いて達成基準を満たしていれば、この不適合事例には該当しないと考えてよい。

  1. コンテンツのテキストの文字サイズを 200 %拡大する。

  2. テキストが切り取られたり、端が欠けたり、又は覆い隠されたりしていない。

判定基準

  • 2. を満たしていなければ、不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F70: 達成基準 4.1.1 の失敗例 - 開始タグ及び終了タグ、又は属性のマークアップが正しくない

適用(対象)

マークアップ言語:HTML、XHTML、及び他のSGML又はXMLベースのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この不適合事例の目的は、要素タグにおいて、支援技術が満足できるページのモデルを生成できない原因となるマークアップの誤りの例を特定することである。 ユーザエージェントは、エラーから復旧するために、異なる推測に基づいた方法をそれぞれ実装している。結果として、ユーザエージェント間で一貫性のないページのプレゼンテーションとなっている。

(これは完全なりストではないが)この不適合の条件を生じさせる開始及び終了タグの一般的な問題:

  • 開始の < 及び終了の > の括弧が足りない開始及び終了タグ。

  • 終了タグであることを示す最初の / が足りない終了タグ。

  • 開始の引用符はあるが、終了の引用符がない属性値。 属性値は、引用符で完全にくくられているか、又はあるマークアップ言語では、引用符でくくられていないかのどちらかである。

  • 属性間の空白の欠如。

  • 値に空白のある引用符でくくられていない属性値。

  • 空の要素の構文が使用できない要素のための終了の要素タグを提供しない場合。

事例

失敗例 1: XHTMLの山形括弧が足りない

開始タグに山形括弧がなく、タグの意図する境界が不明瞭であるため、下記のコードは不適合となる。

コード例:


    <p これはパラグラフです</p>

失敗例 2: XHTMLの終了タグのスラッシュが足りない

終了タグにスラッシュがなく、事実上、別の開始タグのように見えるため、下記のコードは不適合となる。

コード例:


    <p>これはパラグラフです<p>

失敗例 3: 均衡が取れていない属性の引用符づけ

属性値に終了の引用符がないことで、属性値の対の境界が不明確となるため、下記のコードは不適合となる。

コード例:


    <input title="氏名 type="text">

失敗例 4: 属性間の空白の欠如

属性間に空白がないことで、属性値の対の境界が不明確となるため、下記のコードは不適合となる。

コード例:


    <input title="氏名"type="text">

失敗例 5: 空白スペースを含む値を持つ引用符がついていない属性

属性値に引用符がつけられておらず、値に空白が含まれていることで、属性値の対の境界が不明確となるため、下記のコードは不適合となる。

コード例:


    <input title=ここに氏名を入力する type=text>

失敗例 6: XHTMLの終了タグが足りない

第1パラグラフの終了タグがないことで、第2パラグラフが第1パラグラフの子なのか兄弟なのかが不明確になるため、下記のコードは不適合となる。

コード例:


    <p>これはパラグラフです
<p>これは別のパラグラフです</p>

(今のところ、なし。)

検証

チェックポイント

  1. ページのソースコードがマークアップ言語で実装されている。

  2. 開始タグ、終了タグ又は属性で不正な形式になっているものがある。

判定基準

  • 2.を満たしているならば、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F71: 達成基準 1.1.1 の失敗例 - テキストを表すのに、代替テキストを提供せずに、テキストのようなものを使用している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書は、文字を表現するにあたって、見た目がその文字に似た別の文字で代用している不適合事例について述べている。Unicodeの文字セットでは、数十種類の筆記方法にわたる何千もの文字が定義されている。一部の文字の見た目は、他の文字の見た目に視覚的には似ているかもしれないが、テキストを音声に変換するツールでは、同じようには処理されない。

例えば、U+0063とU+03F2は、どちらも「c」の文字に似ている。しかし、U+0063が西欧言語のアルファベットであるのに対して、U+03F2はギリシャ語のアルファベットで、西欧言語では使われないという違いがある。また、U+0033とU+04E0は、どちらも数字の「3」に似ている。しかし、U+04E0は、実際にはキリル文字のアルファベットである。

注記: この不適合事例は、文字符号の使用にも適用される。ただし、その見た目の表現のために使用される文字が不適切なために不適合となるのであって、文字符号のメカニズムを用いること自体は不適切ではない。

事例

失敗例 1: 文字

次の語は、適切なフォントサポートのあるブラウザで見ると、英語の「cook」という単語のように見える。しかし、実際にはU+03f2 U+043E U+03BF U+006Bという文字列で構成されていて、このうち西欧言語のアルファベットは1字しかない。この語は、意味のあるかたちでは処理されず、また代替テキストも提供されていない。

コード例:


ϲоοk

失敗例 2: 文字符号

次の例は、先の例と同様、適切なフォントサポートのあるブラウザで見ると、英語の「cook」という単語のように見える。この場合、これらの文字が、文字符号で実装されている。しかし、やはり単語として意味のあるかたちでは処理されず、代替テキストも提供されていない。

コード例:


      &amp;#x03F2;&amp;#x043E;&amp;#x03BF;&amp;#x006B;

コード例の実際の表示例: "ϲоοk"

(今のところ、なし。)

検証

チェックポイント

  1. テキストを表現するために、文字又は文字符号を用いている。

  2. 用いられている文字は、コンテンツの自然言語において表示される文字としては不適切で、見た目が似た文字が使われている。

判定基準

  • 見た目が似た文字が使われていて、その部分に対する代替テキストがない場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F72: 達成基準 1.1.1 の失敗例 - 代替テキストを提供せずに、ASCII アートを用いている

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

これは、代替テキストを提供せずにASCIIアートを使用するという不適合事例について述べている。ASCIIアートは文字列として実装されるが、その意味は、その文字列の視覚的な表現によって形成される絵柄のパターンから来るのであって、テキスト自体から来るのではない。そのため、ASCIIアートは非テキストコンテンツであり、代替テキストが必要となる。代替テキスト又は代替テキストへのリンクは、ASCIIアートと関連付けるために、その近くに置くべきである。

事例

失敗例 1: 代替テキストのないASCIIアートのチャート

次のASCIIアートのチャートは、代替テキストがないため、達成基準1.1.1を満たしていない。事実、この不適合となる事例を含んでいるため、このウェブページは適合していないページとなっている。ただし、ASCIIアートの例をスキップすることはできる。

コード例:


<pre>
  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __   
100 |             *                             |
 90 |                *  *                       |
 80 |          *           *                    |
 70 |             @           *                 |
 60 |          @                 *              |
 50 |       *        @              *           |
 40 |                   @              *        |
 30 |    *  @              @  @           *     |
 20 |                                           |
 10 |    @                       @  @  @  @     |
      0  5 10 15 20 25 30 35 40 45 50 55 60 65 70
      閃光頻度 (Hz)
</pre>

(今のところ、なし。)

検証

チェックポイント

  1. ASCIIアートのあるページを開く。

  2. それぞれのASCIIアートに対して、代替テキストが提供されている。

判定基準

  • 2. を満たしていなければ、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F73: 達成基準 1.4.1 の失敗例 - 色覚なしではリンクであることが視覚的にはっきりと分からない

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この失敗例の目的は、色の違いを認識できない人々がリンクを識別できない状況(色覚を持つ人々がリンクを識別できる場合)を避けることである。リンクのアンダーラインや他の色に依存しない視覚的な区別が必要である(リンクが色覚を持つ人に識別可能な場合)。

ナビゲーションリンクなど、いくつかのリンクは、ページデザインや文脈から視覚的に明らかであるが、テキスト内のリンクは、しばしばそれら自身の表示属性からのみ視覚的に理解される。下線を削除し、そのようなリンクの色差のみを残すことは、それがリンクであるという他の視覚的な表示(色以外に)がないため、失敗である。

注記 1: 赤とピンクは同じ色(色相)だが、明度が異なる(色彩ではない)。赤とピンクは明度(コントラスト)の差が 3 : 1 以上である限り、明度(色彩ではない)によって異なるため、「色(色相)のみで区別できない」という要件を満たす。(例えば、周囲のテキストが赤でリンクがピンクならば合格となる。同様に明るい緑と暗い赤は色と明度の両方で異なるため、フォーカスやポインティングする前にコントラスト(明度)の差が 3 : 1 以上の場合は通過する)

注記 2: 色覚を持つ人が知覚できない場合には、色を知覚できない人がリンクを識別できるようにするという要件はない。(例えば、ゲームやテストのようにリンクがすべての利用者に表示されない場合)。

注記 3: 色以外の手掛かりが、リンクをマウスオーバーした際、又はリンクがフォーカスを受けた際にだけ提示される場合、それもやはり不適合となる。

注記 4: リンクが他のテキストとは異なる色でかつ太字にされている場合、太字は色に依存していないため、不適合とはならない。

事例

失敗例 1:

ウェブページの本文のテキスト内に、多数のリンクが含まれている。これらのリンクは、下線がなく、ボディテキストに非常によく似た色で表示されている。利用者は、本文のテキストとリンクを見分けられないため、このウェブページは不適合である。

失敗例 2:

次のコードは、文章内又は段落内のリンクから下線を取り除いていて、なおかつ色以外に別の視覚的な手掛かりを提供していない例である。

コード例:


<head>
<style type="text/css">
p a:link {text-decoration: none}
p a:visited {text-decoration: none}
p a:active {text-decoration: none}
p a:hover {text-decoration: underline; color: red;}
</style>
</head>

<body>

<p>もし<a href="rain_in_spain.htm">スペインでの雨</a>に
関する情報を見つけたいならば、多くのリソースがある。</p>

</body>

注記: 視覚的な手掛かりが、(上の例のように)マウスオーバーした際のみ提供される場合、それはやはり不適合となる。

(今のところ、なし。)

検証

チェックポイント

  1. ウェブページにある文章中又は段落内(あるいは、リンクではないテキストと区別しづらいその他のエリア)のテキストにあるリンクそれぞれに、下線が付いているか、又は色(色相)に依存することなく視覚的にリンクとして区別できる(太字、イタリックなど)。

判定基準

  • 1. を満たしていなければ、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F74: 達成基準 1.2.2 及び 達成基準 1.2.8 の失敗例 - テキストに対する代替である同期したメディアを代替コンテンツとしてラベル付けしていない

適用(対象)

テキストに対する代替である同期したメディアを提供しているウェブページ

これは、次の達成基準に関連する失敗例である:

解説

この不適合事例の目的は、テキストの代替メディアとなる同期したメディアに対して、そのテキストを含んだラベルが付けられていないという状況を回避することである。テキストの代替メディアとなる同期したメディアは、同期したメディアの方がテキストよりも有効なフォーマットとなる利用者に対して、情報へのより良いアクセスを提供する。同期したメディアがテキストの代替メディアであるため、それ自体の代替テキストを提供すると内容が重複してしまうため、同期したメディアのコンテンツに対する代替テキストを提供する必要はない。しかし、その同期したメディアに対して、テキストの代替メディアであることを明確にラベル付けすることによって、利用者がテキストの代替メディアである同期したメディアを見つけられるようにし、また同期したメディアに対して通常はその代替テキストを期待する利用者が、代替テキストを探さないようにする必要がある。

事例

失敗例 1: 不適合となるウェブページ上の他のどこかで提供されている、テキストの代替コンテンツとなる同期したメディア

納税申告書の記入方法を説明したウェブページで、記入すべき項目や提供すべきデータなどの説明が文章で書かれている。さらに、テキストの代替メディアとなる同期したメディアが、音声による説明を提供しており、その音声で説明されている部分を記入している人の映像がある。文章のバージョンと同期したメディアのバージョンの両方がウェブページで提供されているにもかかわらず、同期したメディアのバージョンはそのウェブページの他の場所にあり、それがテキストの代替メディアであること示すラベルが明確に付けられていない。このため、テキストを見つけた利用者が同期したメディアのバージョンを見つけるのは難しく、また、音声付きの映像(同期したメディア)を見つけた利用者は、それがどのテキストの代替コンテンツであるのかが分からない。

(今のところ、なし。)

検証

チェックポイント

  1. ウェブページがテキストの代替メディアとなる同期したメディアを提供している。

  2. 同期したメディアがテキストの代替メディアであって,代替メディアであることが明確にラベル付けされている。

判定基準

  • 2. を満たしていない場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F75: 達成基準 1.2.2 の失敗例 - 同期したメディアがページ上にある情報よりも多くの情報を提示している際、キャプションなしで同期したメディアを提供している

適用(対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書は、テキストの代替となる同期したメディアが、元のテキストよりも多くの情報を提供しているが、利用者が元のテキストにはない情報にアクセスするために必要な代替テキストを提供していないという不適合事例について述べている。同期したメディアのほうがテキストよりも効果的なフォーマットである利用者にとっては、テキストの代替となる同期したメディアのほうが利用しやすい。テキストの代替となる同期したメディアは、テキストの代替コンテンツなので、キャプション形式の冗長な代替テキスト、音声による説明又は全文の代替テキストをそれ自身のために用意する必要はない。その元となるテキストよりも多くの情報を同期したメディアが含んでいる場合は、単なるテキストの代替メディアというよりは、それ自体が同期したメディアのコンテンツとなる。こういった場合、キャプションの提供に関しては、達成基準 1.2.2及び達成基準 1.2.3の要件に従うものとする。

事例

(今のところ、なし。)

検証

チェックポイント

  1. 同期したメディアに対する代替コンテンツとしてキャプションがある。

  2. テキストの代替となる同期したメディアは、ページ上にある元のテキストよりも多くの情報を提供していない。

    注記: テキストの代替となる同期したメディアでは、ページ上にあるのとは別の言葉を用いている場合がよくあるが、そのページのトピックについて新しい情報を提示するべきではない。

判定基準

  • 2.を満たさない場合、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F77: 達成基準 4.1.1 の失敗例 - id 属性の値が重複している

適用(対象)

HTML5 及び、HTML4 と SVG を含むあらゆる XML ベースのマークアップ言語

これは、次の達成基準に関連する失敗例である:

解説

この文書は、支援技術がコンテンツとやりとりをする際に、ID が重複しているエラーによって引き起こされる問題の不適合事例について述べている。ID の値が重複していると、ユーザエージェントが ID を示す属性を用いてコンテンツのさまざまな部分間の関係性を正確に伝える際に問題となりうる。例えば、スクリーンリーダーは、ID の値を用いて、データテーブル内にあるデータセルの見出しとなるコンテンツを特定したり、ラベルのテキストと関連付けられているフォームの入力コントロールを特定したりすることがある。もし、それらの値が一意的ではなかった場合、スクリーンリーダーは、どの見出しがそのデータセルと関連付けられているのか、あるいはどのコントロールがどのラベル又は名前と関連付けられているのかを、プログラムで解釈できなくなってしまう。

その仕様でドキュメントをバリデートすることによって、ID の属性値がそのドキュメント内で一意的であることを確認する。なぜなら、どの属性がドキュメント全体にわたって一意的な識別子を有しているかは、仕様によって定められているからである。

注記 1: ほとんどのマークアップ言語では、例えば HTML 及び SVG においてそうであるように、ID の値は属性値である。

注記 2: ID を示す属性として xml:id 属性のみを用いる XML ドキュメントでは、xml:id の仕様 をサポートするバリデータを用いて XML ドキュメントを解析すればよい。

事例

失敗例 1

コンテンツ制作者が、オンラインのバリデーション・サービスを使って、すべてのid属性値が一意的であることをチェックしている。

失敗例 2

コンテンツ開発者が、オーサリングツールの機能を利用して、id属性値が一意的であることを確認している。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. すべてのIDの値がウェブページにおいて一意的である。

判定基準

  • 1.を満たしていない場合、この不適合事例が適用され、そのコンテンツは達成基準を満たしていないことになる。


F78: 達成基準 2.4.7 の失敗例 - 要素のアウトライン及びボーダーを視覚的なフォーカスインジケータを除去する又は非表示にするようにスタイル指定する

適用(対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書は、ユーザエージェントでデフォルトに指定されているキーボードフォーカスの視覚的なインジケーターが非表示になっている、又はコンテンツ制作者が提供する視覚的なフォーカスインジケーターが提供されずに、ページ上の他のスタイル指定により非表示にされる時に起こる不適合の条件について述べている。フォーカスインジケーターを非表示に指定することで、ユーザエージェントはフォーカスインジケーターを表示しなくなる。他のスタイル指定によって、フォーカスインジケーターが提示されていても見づらくなることがある。例えばフォーカスのアウトラインと同じように見えるアウトライン、又はフォーカスインジケーターと同じ色になっているため識別できない太いボーダーといったものである。

事例

失敗例 1: CSSを用いて、フォーカスインジケーターを表示しないようにする

下記のCSSの事例では、デフォルトのフォーカスインジケーターを除去しているため、視覚的に認識可能なフォーカスインジケーターを提供するという要求に不適合となる。

コード例:

:focus {outline: none}

失敗例 2: 要素のアウトラインが、フォーカスインジケーターと視覚的に類似している

下記の CSS の事例は、リンクの周辺にフォーカスインジケーターと同じように見えるアウトラインを生成するものである。たとえユーザエージェントがフォーカスインジケーターを表示しているとしても、利用者にはどの要素が実際にフォーカスを持つのか判別できない。

コード例:

a {outline: thin dotted black}

失敗例 3: 要素が、フォーカスインジケーターを覆い隠すボーダーを持つ

下記のCSSの事例では、フォーカスインジケーターがボーダーの上に表示されたときに、フォーカスインジケーターに対してコントラストが十分でないボーダーをリンクの周辺に生成している。この場合、フォーカスインジケーターがボーダーのすぐ外側に表示されているが、両方とも黒で、ボーダーがフォカスインジケーターよりも太くなっている。これにより、「視覚的に認識可能」の定義を満たさない。

コード例:

a {border: medium solid black}

参考リソース

この達成方法に関する参考リソースはない。

検証

チェックポイント

  1. フォーカスを、キーボードを使ってページ上のすべてのフォーカス可能な要素に合わせる。

  2. フォーカスインジケーターが視覚的に認識可能である。

判定基準

  • 2. を満たしていない場合、この不適合の条件が適用され、そのコンテンツは達成基準及を満たしていないことになる。


F79: 達成基準 4.1.2 の失敗例 - ユーザインタフェース コンポーネントのフォーカスの状態がプログラムで解釈可能ではない、又はフォーカスの状態の変更が通知されていない

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

あるユーザインタフェース・コンポーネントにフォーカスがあるかどうかは、そのコンポーネントの状態(state)の特に重要な一面である。多くの種類の支援技術が、キーボードフォーカスの現在位置を追跡することに依存している。スクリーンリーダーは、利用者の注視点をフォーカスの当たっているユーザインタフェース・コンポーネントに移動させ、画面拡大ソフトはフォーカスが当たっているコンポーネントを見ることができるようにコンテンツの表示を変えていく。新しいコンポーネントにフォーカスが遷移した時に、支援技術に通知されなければ、利用者は意図と異なるコンポーネントとやりとりをしようとして混乱することになる。

通常ユーザエージェントが標準的なコンポーネントに対してこの機能で処理を行う一方、スクリプトで独自に記述されたユーザインタフェース・コンポーネントは、アクセシビリティAPIを用いてユーザエージェントがフォーカスについての情報及び通知を利用できるようにしなければならない。

事例

カスタムメニューがメニュー項目を明確に描画して表示している。マウス及びキーイベントを直接制御し、現在選択されているメニュー項目は反転表示となっている。プログラマーがフォーカスを持ったメニュー項目をアクセシビリティAPI経由で引き渡さないようにしたため、支援技術は、フォーカスがメニューの中のどこかにあることまでしか分からず、どのメニュー項目にフォーカスが当たっているのか決定できない。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. ウェブコンテンツ技術に対してアクセシビリティ・チェッカーを用いる(又は、利用できない場合は、コードを検査する、又は支援技術で検証する)。コントロールがアクセシビリティAPIを経由してフォーカスの状態(state)を引き渡している。

  2. ウェブコンテンツ技術に対してアクセシビリティ・チェッカーを用いる(又は、利用できない場合は、コードを検査する、又は支援技術で検証する)。フォーカスが別のコントロールに遷移したとき、支援技術にそのことが通知される。

判定基準

  • 1. 又は 2. を満たしていない場合、この不適合の条件が適用され、そのコンテンツは達成基準及を満たしていないことになる。


F80: 達成基準 1.4.4 の失敗例 - 視覚的に描画されたテキストを 200%まで拡大していく際に、テキストベースのフォーム・コントロールのサイズが変更されない

適用(対象)

HTML、XHTML及びCSS

これは、次の達成基準に関連する失敗例である:

解説

この不適合の条件の目的は、テキストのサイズ変更が、それに応じてテキストベースのフォーム・コントロールを拡大しない時に発生する問題を説明するものである。テキストは利用者が要求するテキストサイズで表示されないので、利用者がテキストの入力及び入力したものを読むのに苦労するかもしれないことを意味している。

テキストベースのフォーム・コントロールは、ボタンと同様に入力ボックス(テキスト及びテキストエリア)を含んでいる。

事例

失敗例 1: お問い合わせフォーム

お問い合わせフォームは、いくらかの前置き情報、及び利用者が名、姓、電話番号及び電子メールアドレスを入力するためのフォーム・コントロールがある。見出し、前置きのテキスト及びフォーム・コントロールのラベルは、拡張性のある方法で実装されているが、フォームのコントロール自体は拡張性のある方法では実装されていない。

XHTMLコンポーネント:

コード例:


<h1>お問い合わせ</h1>
 <p>あなたの個人情報をご記入いただければ、できるだけ早くご連絡いたします。なお、すべての入力項目が必須項目となっております。</p>
 <label for="fname">名</label><input type="text" name="fname" id="fname" /><br />
 <label for="lname">姓</label><input type="text" name="lname" id="lname" /><br />
 <label for="phone">電話</label><input type="text" name="phone" id="phone" /><br />
 <label for="email">電子メール</label><input type="text" name="email" id="email" /><br />
 <input type="submit" name="Submit" value="送信" id="Submit" />

CSS:

コード例:


h1 { font-size: 2em; }
 p, label { font-size: 1em; }
 input {font-size: 12pt}

参考リソース

この達成方法に関する参考リソースはない。

(今のところ、なし。)

検証

チェックポイント

  1. 利用者が入力したテキストを受け取るテキストベースのフォーム・コントロールにテキストを入力する。

  2. 200%までコンテンツのテキストサイズを拡大する。

  3. テキストベースのフォーム・コントロール内のテキストが200%まで拡大したことを確認する。

判定基準

  • 3.を満たしていなければ、不適合の条件が適用され、コンテンツはこれらの達成基準に不適合となる。


F81: 達成基準 1.4.1 の失敗例 - 色の違いだけで、必須項目又はエラー項目を示している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書は、フォームの必須項目又はエラー項目が色の違いだけで示されていて、その必須項目又はエラー項目を特定するその他の方法がないことによる不適合事例について述べている。全盲又は色弱の利用者は、どれが必須項目で、どれがエラー項目なのかを示す色の違いを知覚できないため、そのような利用者にとっては問題となる恐れがある。

事例

  • 利用者がオンラインフォームを入力していて、電話番号が必須項目である。電話番号のテキストフィールドへの入力が必須であることを示すために、 「電話番号」というラベルが赤のテキストだけで示されており、「電話番号」が必須項目であることを示すものが他にはない。全盲又は色弱の利用者は、「電話番号」が必須項目であることを確認できないかもしれない。

  • 利用者が必須項目を入力しないままオンラインフォームを送信してしまい、エラーになった。エラーになったフォームの入力項目が赤のテキストだけで示されていて、 その入力項目がエラーであることが色以外の方法では示されていない。

注記: どちらの例でも、もしテキストが視覚的な表現において色が取り除かれた場合も周辺のテキストからたやすく区別がつけられるような充分な差異を持たない場合(たとえば太さや違うフォントなど)、間違いなく色が用いられている。また、モノクロでも容易に区別がつけられるようなほかのテキストから充分な輝度の差(明るさ)を選んだ色なら失敗しないだろう。これらのケースでは - 情報は色(色相)だけではなく、また「表現」や「明るさ」それぞれを用いて表現されている。

検証

チェックポイント

ウェブページで、色の違いを用いて必須又はエラーであることが示されている項目すべてに対して:

  1. 必須項目又はエラー項目であることを特定できる方法が色以外にもある。

判定基準

  • 1.を満たしていない場合、この不適合事例が適用され、そのコンテンツは達成基準を満たしていないことになる。


F82: 達成基準 3.3.2 の失敗例 - 電話番号を入力するテキスト・フィールド一式を視覚的にフォーマットしているが、テキストのラベルが提供されていない

適用(対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書では、視覚障害、又は認知障害のある利用者が、電話番号入力欄であることを認識し、フィールドにどのような情報を入力すればよいかを理解できない不適合事例について述べている。電話番号は多くの場合、固定の、特有の書式で示されるため、コンテンツ制作者は電話番号入力欄であることを示すにはフィールドに視覚的な書式を設定すれば十分であると考えているかもしれない。しかし、全てのフィールドがプログラムで解釈可能な識別名を持っている場合においても、テキストラベルでフィールドの一式を電話番号として特定するようにしなければならない。

事例

失敗例 1

アメリカ合衆国では、電話番号は3桁の市外局番と3桁の市内局番、及び4桁の番号に区切られている。あるウェブページ上で電話番号の3つの部分に対して固定長のテキスト入力フィールドを作成し、最初のフィールドをカッコで囲い、ダッシュ「-」で2番目と3番目のフィールドを区切っている。この書式から、利用者はフィールドを電話番号として認識するが、そのウェブページではそれが電話番号であることを示すテキストラベルがつけられていない。それぞれのフィールドのラベルはその直前にあるテキストであることが多いので、3つのフィールドのラベルはそれぞれ「(」、「)」と「-」ということになってしまう。

検証

チェックポイント

  1. 一つの電話番号を表すウェブページ上の電話番号フィールド一式に対して、電話番号フィールド一式が近くに配置された目に見えるテキストラベルでラベル付けされている。

  2. 一つの電話番号を表すウェブページ上の電話番号フィールド一式に対して、フィールドへの入力方法の説明がある。

判定基準

  • 1.及び2.の両方を満たさなければ、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F83: 達成基準 1.4.3 及び 1.4.6 の失敗例 - 前景にあるテキスト(又は画像化された文字)とのコントラストが十分ではない背景画像を使用している

適用(対象)

あらゆるウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この不適合事例は、弱視の利用者が背景画像の上に表示されているテキストを読むことができない場合に関するものである。背景画像とテキストのコントラストが十分ではない時、背景画像はテキストと混同し、正確に読むことを困難にさせることがある。

達成基準1.4.3と1.4.6を満たすためには、テキストとその背景画像の間に十分なコントラストを確保しなければならない。画像に対して、これはテキストの背後にあってテキストにとても似ている画像の一部とテキストの間に十分なコントラストが必要であることを意味している。

事例

失敗例 1

黒いテキストが黒い線の画像と重なっている。その線は文字の背景にあり、F'sをまるでE'sのように見せている。

失敗例 2

黒いテキストが濃い灰色の場所のある画像と重なっている。テキストが濃い灰色のどこの場所で交差していても、コントラストがとても不十分なため、テキストを読むことができない。

検証

チェックポイント

  1. クイックチェック: まず初めに、テキストとその場所の一番暗い部分(色の濃いテキストに対して)又は一番明るい部分(色の明るいテキストに対して)のコントラストが達成基準(1.4.3又はは1.4.5)による要求事項を満たしている、又は上回っている。

  2. クイックチェックを満たしていないとき、各文字の背後にある背景がその文字と十分なコントラストがある。

判定基準

  • 上記1.を満たしておらず、2.も同様に満たしていなければ、この不適合の条件が適用され、そしてこのコンテンツはコントラストの達成基準に不適合となる。


F84: 達成基準 2.4.9 の失敗例 - リンクテキストを具体的なテキストに変更するメカニズムを提供せずに、「ここをクリック」又は「続きを読む」といった不明確なリンクを使用している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

この不適合事例は、「ここをクリック」又は「続きを読む」といったリンクテキストがアンカー要素として使われている、よくある状況について述べている。ただし、リンクはその目的を理解するために周囲のテキストを必要とし、またテキストリンクを拡張するためのボタンのように、リンクテキストだけでリンク先を明確にするメカニズムも持っていない。

スクリーンリーダーを使用する全盲の利用者は、ページ内にあるリンクの一覧を表示したダイアログボックスを呼び出すことがある。彼らは、行き先を決定するためにこのリンクの一覧を使用する。しかし、その一覧の中の多くのリンクが、「ここをクリック」又は「続きを読む」とだけしか読上げられないのであれば、主要なナビゲーション方式であるこの機能をスクリーンリーダーで使用することができなくなる。このような理由から、リンクテキストのみでリンク先を知ることができる方法を一つも提供していないと、達成基準 2.4.9 の不適合事例となるのである。こうした状況は、リンクをTabキーで移動する利用者にも当てはまる。ウェブページ内をTabキーで移動しているとき、「ここをクリック」、「ここをクリック」、「ここをクリック」としか聞こえてこなかったとしたら、利用者は困惑してしまうだろう。

事例

失敗例 1

コード例:

ロッキー山脈の詳細な情報は <a href="file110.htm">ここをクリック</a> 。

失敗例 2

コード例:

<h2>ニュース・ヘッドライン</h2>
中東和平会議は、実りの多い対話をもたらした。
<a href="r4300.htm">続きを読む</a>

検証

チェックポイント

  1. ページにある個々のリンクを検証する。

  2. リンクの目的が、周囲のテキストと組み合わせれば定まるがリンクテキストからだけでは定まらない、「ここをクリック」又は「続きを読む」といったリンク先の分からないリンクテキストがある。

  3. ページ内にあるリンク先の分からないリンク全てを、リンク先の分かるリンクテキストに変えるメカニズムがページ内にある。

判定基準

  • 2.に該当し、3.を満たしていないのならば、この不適合の条件が適用され、コンテンツは達成基準を満たしていないことになる。


F85: 達成基準 2.4.3 の失敗例 - 連続するナビゲーション順序において、トリガーとなるコントロールに隣接していないダイアログ又はメニューを使用している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

この文書では、連続するナビゲーション順序の中での順番が原因で、キーボードだけで操作している利用者がウェブページ上に実装されたダイアログ又はメニューのインタフェースコンポーネントの操作が困難になってしまう失敗例について述べている。ボタン又はリンクを起動してウェブページ上のダイアログ又はメニューを開いたとき、利用者の次の行動は、ダイアログ又はメニューを操作することである。もしフォーカスがダイアログ又はメニューに設定されていないと、連続するナビゲーション順序の中で、トリガーとなるコントロールと連続していない場合、キーボードだけで操作している利用者がダイアログ又はメニューを操作することが困難になる。

事例

失敗例 1: ウェブページ上のダイアログ又はメニューが連続するナビゲーション順序の最後に追加されている

DHTML のメニュー又はダイアログは、起動されると、動的に生成され、視覚的にはトリガーの近くに配置され、DOM の最後に付け加えられる。DOM の最後に付け加えられるため、連続するナビゲーション順序の最後となる。利用者は、メニュー又はダイアログを操作するまでに、ページ上の残りの部分をタブ操作で進んで行かなければならない。

失敗例 2: ページ上に実装されたメニューを閉じるとフォーカスがドキュメントに設定される

メニューが閉じられるとき、メニューはウェブページから削除又は隠されてフォーカスはドキュメントの先頭に設定される。利用者はメニューを開いた場所までナビゲーション順序の最初からタブを操作しなおさなければならない。

検証

チェックポイント

トリガーとなるコントロールによって開くウェブページ上のあらゆるメニュー又はダイアログに対して:

  1. トリガーとなるコントロールをキーボードで起動させる。

    • a. メニュー又はダイアログにフォーカスがある。

    • b. 連続するナビゲーション順序においてフォーカスを進めていくと、メニュー又はダイアログにフォーカスが置かれる。

  2. メニュー又はダイアログを閉じる。

    • a. トリガーとなるコントロールにフォーカスがある。

    • b. 連続するナビゲーション順序においてフォーカスを後ろに戻すと、トリガーとなるコントロールにフォーカスが置かれる。

判定基準

  • 1a. 及び 1b. を両方とも満たしていなければ、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。

  • 2a. 及び 2b. を両方とも満たしていなければ、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F86: 達成基準 4.1.2 の失敗例 - 例えば電話番号にように、複数に分けられたテキストフィールドのそれぞれに対して、識別名が提供されていない

適用(対象)

全般

これは、次の達成基準に関連する失敗例である:

解説

これは、複数のテキストフィールドから成るフォームの入力項目で、その一部又は全部に識別名がないことによる達成基準 4.1.2 の不適合事例について述べている。多くの場合、複数のテキストフィールドから成るフォームの入力項目の全体に対してラベルが 1 つあり、そのラベルが最初のテキストフィールドに対してプログラム的に関連付けられているか、又はどのテキストフィールドに対してもプログラム的に関連付けられていない必要がある。

注記: 識別名は、必ずしも視覚的に表示しなければならないわけではないが、支援技術に対しては明示されている必要がある。

事例

失敗例 1

米国の電話番号は、3 桁の市外局番、3 桁の市内局番、それに続く 4 桁の番号で構成されている。通常はこれが、例えば(206)555-1212のように、(市外局番)市内局番-番号というフォーマットで示される。多くの場合、電話番号の記入を求めるフォームは 3 つのテキストフィールドに分かれているが、次の例ではラベルが1つしかない。


電話番号: 
(<input type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">

この不適合となる事例は、アクセシビリティ API に 3 つのテキストフィールドそれぞれに対する識別名(name)がない場合に生じる。支援技術を使っている利用者は、3 つの不明確なテキストフィールドを提示されることになる。また、3 つのテキストフィールドから成る米国の電話番号の場合、一部の支援技術は、1 つ目のフィールドを「(」、2 つ目のフィールドを「)」、3 つ目のフィールドを「-」とラベル付けすることがあり、これも決して利用者の役に立つものではない。

失敗例 2

同じく米国の電話番号で、この事例では、ラベルがプログラム的にどの部分にも関連付けられていない。


電話番号:
(<input type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">

支援技術を使っている利用者は、3 つの不明確なテキストフィールドを提示されることになる。

失敗例 3

同じく米国の電話番号で、この例では、ラベルが1つめのテキストフィールドにプログラム的に関連付けられている。


<label for="area">電話番号:</label> 
(<input id="area" type="text" size="3">) <input type="text" size="3">-<input type="text" size="4">

支援技術を使っている利用者は、1 つめのテキストフィールドが電話番号全体のためのテキストフィールドであると理解し、2 つめと3 つめは不明確なテキストフィールドとして認識することになる。

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

マルチパートフォームフィールドにある各サブフィールド:

  1. プログラム上そのフィールドに割り振られた名前(name)があることを確認する。

判定基準

  • もし確認 #1 がどのサブフィールドでも偽になる場合、失敗例に該当し、コンテンツは達成基準を満たさない。


F87: 達成基準 1.3.1 の失敗例 - CSS の :before や :after 疑似要素及び 'content' プロパティを用いて、装飾目的ではないコンテンツを挿入している

適用(対象)

CSSをサポートする全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

ユーザエージェント及び支援技術によるサポート

F87 に関するユーザエージェントサポートノート (英語)を参照のこと。

解説

CSSの:before:afterの擬似要素が、要素のドキュメントツリーコンテンツの前及び後のコンテンツの位置を指定している。そして、contentプロパティが、それらの擬似要素とあわせて、何が挿入されるかを指定している。スタイル情報をカスタマイズしたり完全にオフにしたりして、自分のニーズに合わせてコンテンツを閲覧している利用者の場合、CSSを用いて挿入されている情報に支援技術がアクセスできないことがある。そのため、これらのプロパティを使って非装飾的なコンテンツを挿入するのは、不適合となる。

事例

失敗例 1

次の例では、:before 及び :after を用いて話者の切り替わりを示し、また脚本内の引用文を挿入している。

CSSは、次のようになっている。

コード例:


p.jim:before {	content: "Jim: " }
p.mary:before { content: "Mary: " }

q:before { content: open-quote }
q:after  { content: close-quote }

これが、次のように使われている。

コード例:

 <p class="jim">
 <q>彼は間に合うかな?</q>
</p>
<p class="mary">
 <q>無理そうよね。</q>
</p>

失敗例 2

この例では、:before を用いて、意見と事実の違いを区別している。

CSSは、次のようになっている。

コード例:

p.fact:before { content: "Fact: "; font-weight: bold; }
 p.opinion:before { content: "Opinion: "; font-weight: bold; }

これが、次のように使われている。

コード例:


<p class="fact">
 事件発生時、被告人はその犯罪現場にいた。 
</p>
<p class="opinion">
 被告人がその罪を犯した。 
</p>

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. :before:after の疑似要素及び content プロパティを用いて挿入されている全てのコンテンツを探し出す。

  2. コンテンツは、装飾を目的にしたものである。

  3. 挿入されたコンテンツが装飾を目的にしたものではない場合、その情報が支援技術に対して提供されており、CSSをオフにした際にも入手可能である。

判定基準

  • 2. 又は 3. を満たしていなければ、この不適合の条件が適用され、そのコンテンツは達成基準を満たしていないことになる。


F88: 達成基準 1.4.8 の失敗例 - 両端揃え(左右両端を揃えた配置)のテキストを使用している

適用(対象)

全てのウェブコンテンツ技術

これは、次の達成基準に関連する失敗例である:

解説

認知障害のある利用者の多くは、両端揃え(左右両端を揃えた配置)されたテキストのブロックで重大なトラブルに陥ることがある。単語間のスペースによって、ページ上を流れる「余白(隙間)の川」ができる。それによって、一部の人々はテキストを読むことが困難になる。この不適合事例は、この混乱させるテキストレイアウトが発生する状況について説明している。この問題を回避する最良の方法は、両端揃え(左右両端を揃えた配置)されたテキストレイアウトにしないことである。

事例

失敗例 1

次の不適合事例では、HTMLのalign要素が両端揃えのテキストを生成するために用いられている。

コード例:

 
<p align="justify">Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vestibulum sit amet pede. Phasellus 
nec sem id mauris vehicula tincidunt. Morbi ac arcu. Maecenas vehicula velit et orci. Donec 
ullamcorper porttitor velit. Sed arcu lorem, cursus sit amet, auctor eu, convallis ut, purus. 
Vivamus imperdiet accumsan nunc. Maecenas pellentesque nunc a libero. Vestibulum ante ipsum 
primis in faucibus orci luctus et ultrices posuere cubilia Curae; Curabitur pharetra commodo 
justo. Nulla facilisi. Phasellus nulla lacus, tempor quis, tincidunt ac, rutrum et, mauris.
</p>

失敗例 2

この不適合事例では、CSSのtext-align属性が両端揃えのテキストを生成するために用いられている。

コード例:

 
...
p {text-align: justify}

...

<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Vestibulum sit amet pede. Phasellus 
nec sem id mauris vehicula tincidunt. Morbi ac arcu. Maecenas vehicula velit et orci. Donec 
ullamcorper porttitor velit. Sed arcu lorem, cursus sit amet, auctor eu, convallis ut, purus. 
Vivamus imperdiet accumsan nunc. Maecenas pellentesque nunc a libero. Vestibulum ante ipsum 
primis in faucibus orci luctus et ultrices posuere cubilia Curae; Curabitur pharetra commodo 
justo. Nulla facilisi. Phasellus nulla lacus, tempor quis, tincidunt ac, rutrum et, mauris.</p>

検証

チェックポイント

  1. 一般的なブラウザでページを開く。

  2. コンテンツが両端揃え(左右両端を揃えた配置)されていない。

判定基準

  • 2. を満たしていないならは、この不適合の条件が適用され、コンテンツは達成基準 1.4.8 を満たすことができない。


F89: 達成基準 2.4.4、達成基準 2.4.9、及び 達成基準 4.1.2 の失敗例 - 画像のみがリンクのコンテンツの場合に、アクセシブルな名前(name)が提供されていない

適用(対象)

リンクを提供するコンテンツ

これは、次の達成基準に関連する失敗例である:

ユーザエージェント及び支援技術によるサポート

F89 に関するユーザエージェントサポートノート (英語)を参照のこと。

解説

この文書は、画像のような非テキストコンテンツのみで提供されているリンクについて、そしてそのリンクがアクセシブルな名前で特定できないときに起こる失敗例について述べている。リンクのアクセシブルな名前(name)はAccessible Name Calculationによって決定される。

これはテキスト及び画像が同じリンク先に別々にリンクしている場合にも適合する。このケースでは、実装方法H2: 隣り合った画像とテキストリンクを同じリンクの中に入れる (HTML) は別々のリンク及び望ましくない冗長性を減少させるのに推奨される方法である。

事例

失敗例 1: HTML検索結果

検索サイトは、試合のサイトへのテキストリンク及びイメージリンクの両方を含んだ検索結果を返す。 検索結果には既にテキストリンクがあるため、画像の alt 属性は空になっている。 しかし、スクリーンリーダーは画像リンクを無視しないで、リンクの目的が説明されていそうなテキストを見つけるための推測に基づいた修復を試みる。 例えば、スクリーンリーダーは「フットボール ドット ジフ フットボール スコアカード」と読み上げるかもしれない。

コード例:


<a href="scores.html">
   <img src="football.gif" alt="" />
 </a>
 <a href="scores.html">
   フットボールのスコアボード
 </a>
}

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. リンクが非テキストコンテンツのみを提供している。

  2. 非テキストコンテンツが支援技術により無視される方法、role="presentation" や空の alt 属性で実装されている。

  3. aria-labelaria-labelledbyのようなほかの方法でアクセシブルな名前(name)を持たないリンクをチェックする

判定基準

  • もしチェックが正なら、失敗例に当たり、そのコンテンツは達成基準を満たさない。


F90: 達成基準 1.3.1 の失敗例 - headers 属性及び id 属性によってテーブルの見出しセルとデータセルが不正確に関連付けられている

適用(対象)

HTML 及び XHTML。

これは、次の達成基準に関連する失敗例である:

解説

コンテンツ制作者にとってデータセルと見出しセルを明示的に関連付けるひとつの方法は id 属性及び headers 属性を使用することである。これによりコンテンツ制作者は複数の見出しセルに特定のデータセルを関連付けられる。これは複数の見出しをレベルをもつ複雑なデータテーブルの場合に必要になる。

データセルと関連する見出しセルの関係がプログラム的に正しく設定されていない場合、id 属性と headers 属性の関連付けが間違っているために失敗例となる。例えば、テーブルのコードをコピーしたりコードのアップデートを忘れたときにおこる。

事例

H43: データテーブルのデータセルを見出しセルと関連付けるために、id 属性及び headers 属性を使用する (HTML) の例1のような複雑なデータテーブルが存在することによる。

失敗例 1: ネストされた見出しと正しく関連付けられていないテーブルコンテンツ

この例では、ネストされた見出しが使われているが、コンテンツのセルは id 属性及び headers属性によって正しく関連付けられていない。全セルは「練習」(id="e")のようなトップレベル見出しを参照する - これは「プロジェクト」見出しを参照すべき最後の3つのセルにとって正しくない。また、第2レベルの列見出しの参照はコンテンツ(1, 2, ファイナル)が繰り返されるようなこちらの例と違いはなくても、誤って取り違えられる。

Example Code:


<table>
   <tr>
     <th rowspan="2" id="h">宿題</th>
     <th colspan="3" id="e">練習</th>
     <th colspan="3" id="p">プロジェクト</th>
   </tr>
   <tr>
     <th id="e1" headers="e">1</th>
     <th id="e2" headers="e">2</th>
     <th id="ef" headers="e">最終</th>
     <th id="p1" headers="p">1</th>
     <th id="p2" headers="p">2</th>
     <th id="pf" headers="p">最終</th>
   </tr>
   <tr>
     <td headers="h">15%</td>       
     <td headers="e p1">15%</td>  // 「e e1」とすべき
     <td headers="e p2">15%</td>  // 「e e2」とすべき
     <td headers="e pf">20%</td>  // 「e ef」とすべき
     <td headers="e e1">10%</td>  // 「p p1」とすべき
     <td headers="e e2">10%</td>  // 「p p2」とすべき
     <td headers="e ef">15%</td>  // 「p pf」とすべき
   </tr>
</table>
							

Failure example of table incorrectly associating headers attributes in table content (td) to table headers (th).

検証

チェックポイント

  1. データセルが id 属性と header 属性によって見出しセルと関連付けられたテーブルのために、プログラム的な関連付けが正しいかどうか確認する

判定基準

  • チェック #1 が偽の場合、この失敗条件は適用され、コンテンツは達成基準を満たさない。


F91: 達成基準 1.3.1 の失敗例 - テーブルの見出しセルを正しくマークアップしていない

適用(対象)

HTML 及び XHTML。

これは、次の達成基準に関連する失敗例である:

ユーザエージェント及び支援技術によるサポート

F91 に関するユーザエージェントサポートノート (英語)を参照のこと。

解説

見出し要素(th)やテーブルコンテンツの中からプログラム的に見出しを算出させるためにほかの適切なテーブルマークアップ(scope属性、headers及びidあるいはARIA ロール columnheaderrowheader)が使われていないときにこの失敗例は起こる。データセルが見出し情報と組み合わせるときだけはっきりする場合、見出しをプログラム的に算出可能にするのは特別に重要である。スクリーンリーダーの利用者がテーブルコンテンツを縦あるいは横に閲覧する場合、見出しは必要な文脈を提供するために読み上げられる。

事例

失敗例 1: 見出しが適切にマークアップされていない

このテーブルは見出しとして th(あるいはほかの適切なヘッダマークアップ)を使っていない。かわりに、すべてのセルに td 要素が使われている。セルからセルへ移動するのに、スクリーンリーダーは見出しセルに関連付けられたコンテンツの読み上げにしばしば失敗する。

Example Code:


<table>
   
   <tr>
      <td>氏名</td>
      <td>年齢</td>
      <td>身長 (cm)</td>
      <td>体重 (kg)</td>
   </tr>   
   
   <tr>
      <td>リンダ</td>
      <td>33</td>
      <td>169</td>
      <td>59</td>
   </tr>   
   
   <tr>
      <td>ジャック</td>
      <td>37</td>
      <td>184</td>
      <td>74</td>
   </tr>    
   
   <tr>
      <td>キラ</td>
      <td>8</td>
      <td>120</td>
      <td>21</td>
   </tr>   
   
   <tr>
      <td>ダニエル</td>
      <td>3</td>
      <td>79</td>
      <td>14</td>
   </tr>  
</table>
							

View example 1 (opens in same browser window)

検証

チェックポイント

全てのデータテーブルにとって、テーブル見出しが正しくプログラム的に設定されているかどうかを次の仕組みのどれか一つを使って確認する:

  1. テーブル見出し要素(th)でマークアップされた見出し

  2. テーブル見出しが1行以上あるいは 1 列以上あるテーブルの th における scope 属性

  3. テーブル見出しが1行以上あるいは 1 列以上あるテーブルの th における scope 属性

  4. headers 属性と id 属性を用いて関連付けられたヘッダとデータのセル

  5. scope 属性を持つ td 要素としてマークアップされたヘッダ

  6. ARIAのロールの rowheader 属性あるいは columnheader 属性でマークアップされた見出し

判定基準

  • もし全部が偽なら、これは失敗例に当たり、コンテンツは達成基準を満たさない。


F92: セマンティックな情報を伝えるコンテンツに presentation ロールを使用している

適用(対象)

HTML 及び XHTML

これは、次の達成基準に関連する失敗例である:

解説

この失敗例は、情報あるいはコンテンツの関係性を伝達する目的で用いられる要素に表現の役割が適用されるときに起こる。table のような要素はセマンティックなマークアップによってコンテンツがもつ情報を伝達することができる。一方 WAI-ARIA の "presentation" のロールは、アクセシビリティ API からコンテンツのセマンティックな情報を抑制し、利用者への情報の伝達をユーザエージェントが行わないよう意図されている。"presentation" ロールをセマンティックな情報を伝達するべきコンテンツに用いるのは利用者のコンテンツの理解を妨げるだろう。

事例

失敗例 1:

この例では、表のデータは role=presentation でマークアップされている。そのようなレイアウトテーブルのデザインのマークアップに関わらず、データテーブルはセマンティックな情報を維持する必要がありそれゆえ role=presentation でマークアップされるべきではない。

例:


<table role="presentation">
   <caption>フルーツとその色</caption>
   <tr>
     <th>名称</th>
     <th>色</th>
   </tr>
   <tr>
    <td scope="row">バナナ</td>
    <td>黄色</td>
   </tr>
   <tr>
    <td scope="row">オレンジ</td>
    <td>オレンジ</td>
   </tr>
  </table>
                            

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

検証

チェックポイント

  1. もしセマンティックなマークアップを通じて情報や構造や関係性を伝えている要素を確認するなら

  2. 要素が role="presentation" 属性を持っている

判定基準

  • もし確認 #2 が真なら、失敗例に当たり、コンテンツは達成基準を満たしていない。


F93: 達成基準 1.4.2 の失敗例 - 自動再生する HTML5 のメディア要素を一時停止または停止する方法がない

適用(対象)

HTML5

これは、次の達成基準に関連する失敗例である:

解説

この失敗例は、audio あるいは video 要素が autoplay 属性をもつ音声トラックを含むときや、muted 属性を含まなかったり、メディアの停止または一時停止のコントロール機能かコマンドがないときに起きる。

autoplay属性が存在している場合、ユーザエージェントはできる限り停止させずに自動的にメディアの再生をはじめる。muted 属性がもし存在していたら、ユーザエージェントは最初にメディアの音声出力を無音にし、ユーザ設定で上書きする。

メディア要素が 3 秒より短い場合、失敗は起こらない。もしユーザエージェントが自動再生の挙動を上書きする利用者設定と提供していたら、失敗例は起こらない。

HTML の仕様は次の注を含む:

  • ユーザエージェントは自動再生のサポートを必要としないが、それはユーザエージェントが事例についての利用者設定を優先することを示している。製作者は動画を再生するスクリプトを使うより、利用者が望むような挙動を上書きすることを許すのと同じように、autoplay属性を使うよう促される。

  • 制作者は、スクリーンリーダーを使用している場合のように、利用者が望まない場合に自動再生状態を上書きできるよう、自動再生を行うスクリプトよりむしろ autoplay 属性を使用することを促されている。制作者は、利用者が再生を開始するのをユーザエージェントが待つかわりに、自動再生を行わないよう考慮することもすすめられている。

事例

事例 1: 音声の自動再生

この例では、動画広告が音声トラックを含む。動画は loop 属性をもっているため連続再生され、動画は autoplay 属性のため及び利用者が動画を停止できるどんなコントロール方法もないために自動的に開始される。

コード例:


				 <video src="ads.cgi?kind=video" autoplay loop></video>
            

参考リソース

この参考リソースは、あくまでも情報提供のみが目的であり、推薦などを意味するものではない。

(今のところ、なし。)

検証

チェックポイント

  1. アクティブな音声トラックに audio もしくは video 要素が含まれていないか確認する。

  2. 音声あるいは動画が3秒以上続くか確認する。

  3. 要素が autoplay 属性を持っているか確認する。

  4. 要素が muted 属性を持っていないか確認する。

  5. メディア要素が停止または一時停止するためのコマンドやコントロール方法を持っていないか確認する。

判定基準

  • もし 1-5 までが真なら、失敗例に適合しコンテンツは達成基準を満たさない。